Why a 99%-accurate model can still be completely useless — and which of these three numbers actually tells you that.
Accuracy sounds like the obvious scorecard for a model: how often is it right? But "right" blends two very different kinds of correctness together, and when the thing you're trying to detect is rare, that blend can hide a model that is doing essentially nothing useful. Precision and recall exist because sometimes you need to know, specifically, how a model is right or wrong — not just how often.
Accuracy asks: out of every prediction the model made — positive and negative alike — what fraction were correct? (TP + TN) / total. It treats every correct call the same, whether it's correctly flagging a real case or correctly ignoring a case that was never a concern in the first place.
Precision asks a narrower question: of everything the model called positive, how much of it was actually positive? TP / (TP + FP). Precision answers "when the model says yes, how often is it actually right?" High precision means few false alarms.
Recall (also called sensitivity, or the true positive rate) asks the mirror-image question: of everything that was actually positive, how much did the model catch? TP / (TP + FN). Recall answers "of all the real positive cases out there, how many did the model actually find?" High recall means few missed detections.
Accuracy's formula — (TP + TN) / total — gives every correct prediction equal credit, whether it's a hard-won true positive or a trivial true negative. When 99% of cases are negative, a model can rack up 99 easy true negatives without ever engaging with the 1 case that actually matters, and the total still reads as 99% correct. Recall refuses to average over the majority class: it's computed entirely from the actual positives — TP / (TP + FN)— so a model that catches zero of them scores exactly 0%, no matter how many negatives it got right elsewhere. That's the whole point of separating precision and recall out from accuracy: they isolate performance on the class you actually built the model to find.
Most classifiers don't just output "positive" or "negative" — they output a score, and a decision threshold decides how much of that score counts as "positive." Loosen the threshold to flag more cases as positive, and the model catches more of the real positives (recall goes up) — but it also sweeps in more cases that weren't actually positive (precision goes down). Tighten the threshold, and the reverse happens. This is exactly the same threshold-driven tradeoff behind Type I vs. Type II error: loosening the threshold to raise recall means accepting more false positives (Type I errors, hurting precision), while tightening it to raise precision means accepting more false negatives (Type II errors, hurting recall).
False, especially for imbalanced datasets where the positive class you actually care about is rare. A trivial model that always predicts the majority class can post a very high accuracy score while having zero recall— it never catches a single real positive case, which makes it completely useless for the actual detection task it was supposedly built for. Accuracy alone can't reveal this failure because it's diluted across 99 easy negatives. Precision and recall are what actually reveal whether a model is doing its real job — and the right balance between the two isn't universal. It depends entirely on the real-world cost of a false positive versus a false negative for that specific application.
Explains why overall accuracy — the fraction of all predictions, positive and negative, that were correct — can be dangerously misleading for imbalanced datasets, and why precision (of everything predicted positive, how much was actually positive) and recall (of everything actually positive, how much was caught) are the metrics that reveal whether a model is doing its real job. Illustrated with a 100-case imbalanced-dataset example where a model that predicts nothing but 'negative' scores 99% accuracy with 0% recall, and a precision-recall tradeoff curve showing why cancer screening and spam filtering land in different places on the same curve.
Accuracy is the most intuitive-sounding metric, so it's often reported as if it were the whole story. But accuracy — (TP + TN) / total — weighs every correct prediction equally, including the easy ones. On a dataset where the positive class is rare (fraud, disease, defects, rare failures), a model can achieve very high accuracy by essentially ignoring the positive class altogether and still predicting the majority class every time. The accuracy number looks great; the model is doing nothing useful.
Accuracy = (TP + TN) / (TP + TN + FP + FN) — the fraction of all predictions, positive and negative, that were correct.
Precision = TP / (TP + FP) — of everything the model predicted positive, the fraction that was actually positive. Answers 'when the model says yes, how often is it right?' A low-precision model generates a lot of false alarms.
Recall (sensitivity, true positive rate) = TP / (TP + FN) — of everything that was actually positive, the fraction the model correctly identified. Answers 'of all the real positive cases, how many did the model catch?' A low-recall model misses a lot of real cases.
Precision and recall typically move in opposite directions as a classifier's decision threshold changes. Loosening the threshold to flag more cases as positive catches more real positives (higher recall) but also sweeps in more false alarms (lower precision); tightening the threshold does the reverse. Which one to prioritize depends entirely on the real-world asymmetry between the two error costs: a cancer-screening test wants high recall, because missing a real cancer case is far worse than a false alarm cleared by follow-up testing, while a spam filter often wants high precision, because misfiling a legitimate email is frequently worse than letting one spam message through. This maps directly onto the Type I (false positive, hurts precision) vs. Type II (false negative, hurts recall) error tradeoff — loosening the threshold trades Type II errors for Type I errors, and vice versa.
Accuracy is a fine summary metric when classes are roughly balanced and the cost of a false positive is similar to the cost of a false negative — it is cheap to compute and easy to explain. The problem is specifically imbalanced datasets, where one class vastly outnumbers the other, since a model can hide poor performance on the rare, usually more important, class behind a high overall score.
Yes — it just means the model is genuinely good at separating the two classes, not merely trading one error type for the other at a fixed threshold. Improving the underlying model (better features, more/better training data, a better architecture) can push both precision and recall up together, the same way more data shrinks both Type I and Type II error in hypothesis testing. Moving the decision threshold alone, however, only trades one against the other.
The F1 score is the harmonic mean of precision and recall — 2 × (precision × recall) / (precision + recall) — a single number that summarizes both at once. It is useful for comparing models or thresholds when you want a balanced view, but like accuracy, it can obscure which specific error type is high, which is why it is best reported alongside precision and recall individually, not as a replacement for them.
Precision is TP / (TP + FP) — it is only defined over the cases the model actually predicted positive. A model that never predicts positive at all has made zero positive predictions, so both TP and FP are zero, and the ratio is mathematically undefined rather than 0%. This is itself a useful red flag: a model with an undefined or unreported precision may simply never be flagging anything positive.
They describe the same 2x2 outcome matrix from opposite angles. A false positive is a Type I error and directly lowers precision; a false negative is a Type II error and directly lowers recall. Loosening a classifier's decision threshold to catch more real positives (raising recall) necessarily accepts more Type I errors (lowering precision), which is the same mechanical tradeoff explained in the Type I vs. Type II Error concept explainer.
Try our AI and Data Science Studio
More calculators, simulators, and guides for this discipline.