Precision Versus Recall

## The two counts they do not share Every binary prediction lands in one of four cells: a **true positive (TP)** the model called positive and was right about, a **false positive (FP)** it called positive and was wrong about, a **false negative (FN)** it called negative but was actually positive, and a **true negative (TN)** it called negative and was right about. - **Precision** = `TP / (TP + FP)` — the denominator is everything the model *predicted* positive. - **Recall** = `TP / (TP + FN)` — the denominator is everything that *actually is* positive. That is the whole difference, and it is the thing candidates most often blur. Precision is read down the model's positive column; recall is read across the true positive row. Recall goes by three names depending on the field — recall, **sensitivity**, and the **true-positive rate** — and they are the same quantity. Precision is also called **positive predictive value**. In words: precision answers *"when this thing fires, how often should I believe it?"* Recall answers *"of everything I was supposed to catch, how much did I actually catch?"* Note that neither metric uses TN anywhere. Both are entirely about the positive class, which is exactly why they are the pair of choice when positives are the rare and interesting thing. ## Why they trade off A classifier does not emit a label directly; it emits a score, and a decision rule turns that score into a label. Slide that rule so more examples get labelled positive and two things happen at once. The set of predicted positives grows, so it can only gain true positives — recall never goes down. But the added examples are the ones the model was less sure about, so proportionally more of them are wrong, and precision typically falls. The two extreme cases make it concrete. Label *everything* positive: you catch every real positive, so recall is 1.0, but precision collapses to the fraction of the data that is genuinely positive — on a rare-positive problem, a terrible number. Label only the single example you are most confident about: precision may be a perfect 1.0 while recall is almost zero. Neither model is useful, and both look excellent on one metric alone. This is why the two are always quoted as a pair. The crucial caveat: this trade-off describes moving the decision rule of *one fixed model*. It is not a law that precision and recall cannot both improve. A model with better features, more data, or a better ordering of examples by risk dominates the old one — at the same recall it makes fewer false positives. That is what "the model got better" means, as opposed to "the model got more or less trigger-happy". ## The degenerate corners Precision is undefined when the model predicts no positives at all — the denominator is zero. Tooling usually reports 0 in that case, which quietly hides a model that has stopped firing entirely. Recall is undefined if the evaluation set contains no actual positives, which happens more often than people expect on small held-out slices of a rare-event problem. ## Mapping the pair onto cost The choice between them is not statistical, it is an argument about which mistake hurts. Take an email spam filter. A **false positive** is a legitimate message — a customer's invoice — quarantined into a folder nobody reads; the recipient may never learn it existed. A **false negative** is one piece of junk mail sitting in the inbox, which the user deletes in a second. The costs are wildly asymmetric in favour of precision, so a spam filter is tuned to almost never quarantine real mail even though that means letting some junk through. Flip the asymmetry and the answer flips. When the positive class is a disease, a fraud case, or a safety fault, a miss is expensive and a false alarm merely triggers a cheap second look — there, recall is the metric you protect and false positives are the price you pay. ## What to report Quote both numbers, and quote the raw cell counts behind them. "Precision 0.82, recall 0.61" is informative; "precision 0.82" alone is a sales pitch. Counts matter too, because the same rates on a stream of ten million items mean a very different absolute number of angry users than they do on a batch of two hundred.