Anomaly Detection

Anomaly detection identifies examples that deviate from expected behavior. It is used in monitoring, fraud, data quality, experimental screening, system logs, and model-output triage.

An anomaly detector often assigns a score:

Predictions are made by thresholding:

where controls the tradeoff between false positives and false negatives.

If review capacity is limited, the operational objective is often top-k triage rather than binary classification:

In that setting, precision at , recall at , alert load, and time-to-detection may matter more than a global threshold.

Key Ideas

  • Anomalies can be rare, ambiguous, evolving, or defined only by operational cost.
  • Supervised anomaly detection needs labeled anomalies; unsupervised methods estimate unusualness from normal data.
  • A high anomaly score is not automatically a causal explanation.
  • Evaluation is sensitive to class imbalance and incomplete labels.
  • In monitoring workflows, alert fatigue can matter more than raw AUROC.

Task Variants

VariantOutputTypical Metric Risk
binary detectionanomaly / normalthreshold and prevalence dominate
ranking / triagesorted candidate listlabel incompleteness hides false negatives
time-series alertingevent time or alert windowdelayed labels and alert fatigue
data-quality checksuspicious record or batchroot cause may be outside the example
model-output triagegenerated output or prediction flagged for reviewscore is not an explanation

Practical Checks

  • Are anomaly labels complete, partial, delayed, or proxy labels?
  • Is the threshold chosen on validation data and frozen for test evaluation?
  • Is the metric aligned with review budget or intervention cost?
  • Does the anomaly definition drift over time?
  • Are anomalies grouped by event, user, molecule, run, or target rather than independent examples?
  • Is the base rate reported for each split or deployment slice?
  • Are repeated alerts for the same underlying event deduplicated before evaluation?