A permitting and inspections bureau sees extreme water-meter spikes from known sensor glitches. Which outlier treatment best fits before modeling?
Select an answer to reveal the explanation.
Short Explanation
When you see a meter report a swimming-pool flood every Tuesday, you can treat a known sensor glitch as an outlier rather than real usage. Capping or winsorizing the extreme reading under an agreed rule preserves the account’s useful history without letting the glitch dominate. Deleting the whole history, replacing readings with the citywide maximum spike, or trusting GPU training to cancel sensor noise would all undermine the model.
Full Explanation
Extreme water-meter spikes known to come from sensor glitches should be treated with a documented outlier policy, such as winsorizing or capping, before modeling. Capping replaces impossible tails with agreed bounds so permitting and inspections analytics retain an account’s real usage pattern without letting glitch magnitudes dominate loss functions or civic anomaly alerts. Use an explicit, reviewable rule tied to sensor knowledge. Deleting the entire meter history for any account that ever spiked discards years of valid readings because of transient faults and biases models toward only “clean” accounts. Replacing every reading with the maximum observed spike citywide amplifies the glitch and destroys useful variation. Ignoring outliers because GPU training always cancels sensor noise is also wrong: gradient-based models can overweight extreme residuals, and GPUs do not magically remove bad labels or features. Exam caveat: distinguish sensor glitches from true extraordinary consumption, such as main breaks or leaks; a cap intended for glitches must not hide incidents operations needs to see. Practical check: define percentile or absolute caps with utility subject-matter experts, apply them in RAPIDS cleaning, compare model metrics and spike-alert rates before and after, and log how many values were capped per batch.