What is Anomaly Detection?

Why not just train a classifier

If you have thousands of labelled examples of the thing you want to catch, supervised learning will outperform anomaly detection, and you should use it. Anomaly detection earns its place under three conditions that are common in practice: anomalies are extremely rare, they are diverse and take forms you have not seen, and future ones may look nothing like past ones.

That last point is the decisive one for adversarial problems. A fraud classifier learns the fraud patterns in its training data; a novel technique is unlike all of them. A model of normal flags the novel case precisely because it is unlike normal, without needing a labelled example of it. This is why the approach dominates in fraud, intrusion detection, equipment failure, and data-quality monitoring.

The methods worth knowing

Statistical baselines — z-scores, interquartile range, control charts. Genuinely underrated. For a single well-behaved metric, a control chart is interpretable, needs no training, and is frequently sufficient. Start here.

Isolation Forest isolates points with random splits, on the logic that anomalies separate in fewer splits than normal points. Fast, scales well, few assumptions, and a strong default for tabular data.

Local Outlier Factor compares a point's local density to its neighbours', which catches anomalies that are only anomalous relative to their local cluster rather than globally.

Autoencoders learn to compress and reconstruct normal data; anomalies reconstruct poorly, and the reconstruction error is the score. Suited to high-dimensional data such as images and sensor arrays.

Forecast residuals handle time series properly. Predict the next value from history and flag large deviations. Critically, this respects seasonality — a spike every Monday morning is normal, and a method without a temporal model will alert on it every week.

The base rate problem

This is the single most important thing to understand before deploying anomaly detection, and it is where most systems fail operationally rather than statistically.

Suppose 0.1% of transactions are fraudulent and your detector catches 99% of fraud with a 1% false positive rate. Those sound like excellent numbers. Across a million transactions: 1,000 are fraud, you catch 990. But 999,000 are legitimate, and 1% of those is 9,990 false alarms. Your alert queue is 11,000 items of which roughly 9% are real — reviewers see ten false alarms for every genuine case. Alert fatigue sets in, the queue stops being worked, and the system is abandoned despite performing exactly as specified.

Designing around this means treating the human workflow as part of the system. Set the threshold from review capacity, not from a statistical criterion — if analysts can process 200 cases a day, calibrate to produce roughly that. Rank by severity rather than emitting binary alerts, so scarce attention goes to the highest-value cases. Attach explanatory context to every alert so triage is fast. Group related alerts instead of firing one per event. And feed reviewer decisions back as labels, which over time lets you replace or supplement the detector with a supervised model and read its performance from a confusion matrix.