Anomaly detection and the alert burden

Learning outcome: Distinguish unusual behaviour from a confirmed problem.

An anomaly detector identifies observations that differ from a learned or defined pattern. Unusual does not mean harmful, and normal-looking does not mean safe. The detector's output needs interpretation in the setting where it is used.

Define the reference population and time period. A threshold controls the balance between missed events and review workload. Track whether alerts lead to meaningful findings, and investigate changes in the input distribution. If normal behaviour changes, an old baseline may generate many unhelpful alerts. Keep a feedback route so reviewers can record outcomes without silently relabelling every unfamiliar case as an error.

Worked example

A fictional building-energy monitor flags a weekend workshop because usage is higher than a normal Saturday. The increase is expected and authorised. Another day has a smaller but unexplained overnight load. The first alert is unusual without being a fault; the second needs investigation. Ranking only by raw size would miss that context.

Try it yourself

Create an alert-review form with expected event, observed value, comparison baseline, reviewer finding and next action. Fill it for both examples.

You can do this exercise on paper. If using an assistant, keep to the fictional material and an approved tool.

Check your understanding

What does an anomaly score establish?

1. That the largest value is always the most important case
2. Difference from a reference pattern, not a confirmed cause
3. That fraud or failure has occurred

Workbook

Download the course workbook to record your answer and compare it after the knowledge check.

Further reading

• scikit-learn: common pitfalls
• scikit-learn: model evaluation
• NIST: AI Risk Management Framework
• scikit-learn: time series splits
• scikit-learn: novelty and outlier detection
• modAL: uncertainty sampling
• Neo4j: entity resolution