AI Literacy: The Confusion Matrix and Base Rates

Where this page sits

Level: Beginner. The only prerequisite is multiplication and division. Bring a pen.

This is rung two of Track C. If the words supervised learning, inference and model artefact mean nothing yet, do Fundamentals of AI first. If you already compute precision at low prevalence in your head, skip to Thresholds and Confidence.

Four cells, and the convention that trips everyone

A detector makes a binary call on every item it sees. Reality also has a binary answer. Cross those two and you get four cells. That is a confusion matrix, and it is the entire foundation.

The convention that trips people: "positive" means the thing you are hunting for, not the thing you want. A positive is malicious. A true positive is a caught attacker, which is a good outcome described by a word that sounds bad. Get this straight now, because a reversed convention silently inverts every number downstream.

Read the four cells as four human outcomes, because that is how you will have to argue about them:

• TP — an analyst investigates and finds a real attack. The detector earned its keep.
• FP — an analyst investigates and finds nothing. Time gone, and a little trust with it.
• FN — nobody investigates, because nobody was told. This is the cell you find out about from a breach notification.
• TN — silence. The overwhelming majority of everything, and invisible by design.

Every metric in this field is a ratio of those four numbers. There are no others. The reason the field feels complicated is that the same four numbers get sliced along different denominators, and the names do not tell you which denominator is in play.

The five metrics, and what each denominator means

Write these out once by hand and you will never need to look them up again. In each case, the thing to fix in your memory is what is on the bottom.

Precision and recall have different denominators, and that single fact is the source of nearly every argument about detection quality. Precision is the analyst's metric: it decides whether the queue is worth reading. Recall is the risk owner's metric: it decides how much gets through. They trade against each other, and a claim that quotes only one of them is not a claim, it is an advertisement.

Why accuracy is a lie: the always-benign detector

Here is a detector. Its source code is complete:

def detect(email):
    return "benign"     # every time, no exceptions

It has no model, no features, no training data and no cost. Now measure it on a realistic population: 100,000 emails a day, of which 1 in 10,000 is malicious.

That is 10 malicious emails and 99,990 benign ones. Fill in the matrix:

Accuracy = (0 + 99,990) / 100,000 = 99.99%.

A detector that has never detected anything, and never could, scores 99.99% accuracy. Its recall is 0/10 = 0%. Its precision is 0/0, which is undefined — it never fires, so the question "when it fires, is it right?" has no answer.

This is not a party trick. It is the reason accuracy must never be the headline number for a security detector, and it is the reason you should treat any accuracy figure in a vendor deck as a signal that the interesting numbers were left out. When the thing you are looking for is rare, the majority class dominates accuracy completely, and the majority class is "nothing is happening".

The main event: a 99% accurate detector, worked

Now a real-seeming detector. The claim on the slide is "99% accurate". First, pin down what that even means, because the phrase is ambiguous and the ambiguity is where the trouble hides. Take the most flattering reading — the vendor means both of the following:

• Recall = 99%: it catches 99 of every 100 malicious emails.
• Specificity = 99%: it correctly ignores 99 of every 100 benign emails, so the false positive rate is 1%.

Those are genuinely good numbers for a classifier. Now apply them to the same population.

Fewer than one alert in a hundred is real. The analyst opens roughly a hundred tickets before finding one that matters. The detector's accuracy, by the way, is (9.9 + 98,990.1) / 100,000 = 99.0% — exactly as advertised, and completely uninformative.

Push it into hours and the picture gets worse. At an optimistic five minutes of triage per alert, 1,010 alerts is over 84 person-hours of triage per day. To keep up you would need more than ten analysts doing nothing but this queue, for one detector, on one data source. That is not a staffing problem you can solve. It is an arithmetic problem that must be solved before the tool is deployed.

The napkin method

You will not have a spreadsheet in the meeting where the claim is made. You need one line you can do in your head. Here it is:

Check it against the worked example: FPR = 0.01, prevalence = 0.0001. Ratio = 0.01 / 0.0001 = 100 false alarms for every real one. The full arithmetic gave 999.9 / 9.9 = 101. The napkin is accurate to one percent and took two seconds.

Two corollaries fall straight out of it, and they are the ones worth memorising:

Corollary 1 — for precision above 50%, you need FPR below the prevalence. If one email in ten thousand is malicious, your detector must produce fewer than one false positive per ten thousand benign emails before most of its alerts are real. Say that out loud. It is a brutal bar and almost nothing clears it unaided.

Corollary 2 — for precision of 90%, you need FPR ≈ prevalence ÷ 9. At a prevalence of 0.0001 that is an FPR of about 0.0000111: roughly one false positive per ninety thousand benign items. Derivation, for completeness, with p = prevalence and recall ≈ 1:

precision ≈ p / (p + FPR)

set precision = 0.90:
    0.9 = p / (p + FPR)
    0.9p + 0.9·FPR = p
    0.9·FPR = 0.1p
    FPR = p / 9

Run the napkin over a few prevalences and the shape of the whole field becomes obvious. Same detector, FPR fixed at 1%, only the base rate changing:

The model is identical in every row. Only the denominator changed. This table is the single most actionable thing on the page.

Changing the denominator: forty-eight-fold precision, no retraining

Read the previous table as an instruction rather than an observation. If precision is governed by the population you run on, then narrowing the population is a detection-engineering lever that costs no compute and no model work. Work it properly.

Same 100,000 emails, same 10 malicious, same detector at 99% recall and 1% FPR. Now put a cheap deterministic pre-filter in front: only score mail that is from an external sender and carries an attachment and failed DMARC. Suppose that filter keeps 1% of all mail and, because attackers need those properties, it retains 90% of the malicious mail.

Precision went from 0.98% to 47.3% — a factor of roughly forty-eight — and the price was recall falling from 99% to 89%. Nineteen alerts a day is a queue a single analyst reads properly. A thousand is a queue nobody reads at all.

That trade is the actual craft of detection engineering, and it is worth being explicit about what was traded: you accepted that one malicious email in ten now bypasses this detector entirely, in exchange for a queue that gets read. Whether that is the right call depends on what else is in the stack — and that is a risk conversation, informed by arithmetic, rather than an arithmetic problem with one answer. The mistake is not making the trade; the mistake is making it without writing the numbers down.

Run it yourself

Everything above is reproducible in pure Python with no dependencies and no model. Grade yourself against the numbers on this page.

# docker-compose.yml — CPU-ONLY. No GPU, no model, no network after build.
services:
  lab:
    image: python:3.12-slim
    working_dir: /work
    volumes:
      - ./:/work
    command: python -m pytest -q test_matrix.py

# matrix.py — implement these four functions. Standard library only.

def confusion(population, prevalence, recall, fpr):
    """Return (tp, fp, fn, tn) as floats for a population of `population` items."""
    malicious = population * prevalence
    benign = population - malicious
    tp = malicious * recall
    fn = malicious - tp
    fp = benign * fpr
    tn = benign - fp
    return tp, fp, fn, tn

def precision(tp, fp):
    return tp / (tp + fp) if (tp + fp) else float("nan")

def napkin_false_per_true(fpr, prevalence):
    """The one-line rule: false alarms per real alarm."""
    return fpr / prevalence

def fpr_for_target_precision(prevalence, target):
    """What FPR do I need for this precision, assuming recall is near 1?"""
    return prevalence * (1 - target) / target

# test_matrix.py — the auto-grader. Run: docker compose up
from matrix import confusion, precision, napkin_false_per_true, fpr_for_target_precision

TOL = 0.01   # relative tolerance; this is arithmetic, so it is tight on purpose

def close(a, b, tol=TOL):
    return abs(a - b) <= tol * abs(b)

def test_the_worked_example():
    tp, fp, fn, tn = confusion(100_000, 0.0001, 0.99, 0.01)
    assert close(tp, 9.9) and close(fp, 999.9)
    assert close(fn, 0.1, 0.05) and close(tn, 98_990.1)
    assert close(precision(tp, fp), 0.0098, 0.02)

def test_always_benign_scores_99_99_percent_accuracy():
    tp, fp, fn, tn = confusion(100_000, 0.0001, 0.0, 0.0)
    accuracy = (tp + tn) / 100_000
    assert close(accuracy, 0.9999)
    assert tp + fp == 0            # precision is undefined, not 100%

def test_napkin_matches_the_full_arithmetic():
    tp, fp, fn, tn = confusion(100_000, 0.0001, 0.99, 0.01)
    assert close(napkin_false_per_true(0.01, 0.0001), fp / tp, 0.02)

def test_corollary_two():
    assert close(fpr_for_target_precision(0.0001, 0.90), 0.0001 / 9)

def test_narrowing_the_population_beats_retraining():
    tp, fp, fn, tn = confusion(1_000, 0.009, 0.99, 0.01)
    assert precision(tp, fp) > 0.40        # was under 0.01 on the full population
    assert (tp / 10) > 0.85                # recall against all 10 malicious

Questions to ask when someone shows you a detection metric

Written as a checklist because that is how you will use it.

Cheat sheet

Where to go next