Bayes, done slowly, with real numbers

The formula, and then the arithmetic that matters

P(H | E) = P(E | H) * P(H) / P(E)

Four parts, each with a name. P(H) is the prior: how likely the hypothesis was before the evidence. P(E | H) is the likelihood: how likely the evidence is if the hypothesis holds. P(E) is the evidence: how likely the evidence is at all. P(H | E) is the posterior: what you believe now.

The formula is worth knowing. The arithmetic below is worth more, and you can do it without the formula.

Do it by counting, always

Bayes calculations go wrong when done symbolically and go right when done by imagining a concrete population. Here is a moderation classifier.

A platform's classifier flags policy-violating posts. It is good: it catches 98 per cent of genuine violations, and it wrongly flags 3 per cent of acceptable posts. Violations are 1 per cent of all posts.

A post is flagged. What is the chance it really violates policy?

Take 100,000 posts.

Genuine violations:        1,000
  correctly flagged:         980   (98% of 1,000)
  missed:                     20

Acceptable posts:         99,000
  wrongly flagged:         2,970   (3% of 99,000)
  correctly passed:       96,030

Total flagged: 980 + 2,970 = 3,950
Of those, genuine: 980

P(violation | flagged) = 980 / 3,950 = 0.248

Twenty-five per cent. Three out of four flags from a 98-per-cent-accurate classifier are wrong. Nobody made a mistake; there are simply ninety-nine times as many acceptable posts, so even a small error rate on the large group swamps the correct detections on the small one.

Why this is the most important calculation in applied AI

Every deployment where a model looks for something rare has this structure. Fraud, disease, security intrusions, defects, policy violations, exam cheating, sanctions matches. In each case the base rate is small and the false positives outnumber the true ones.

Three practical implications follow.

Human review capacity must be sized from the flag count, not the violation count. In the example above, 3,950 flags need reviewing per 100,000 posts, and 2,970 of those reviews will find nothing. If you budgeted reviewers on the basis of 1,000 violations, you are short by a factor of four.

The false-positive rate is the number to optimise. Halve it, from 3 per cent to 1.5 per cent, and the arithmetic becomes 980 / (980 + 1,485) = 0.40. Precision jumps from 25 to 40 per cent from a change that barely moves overall accuracy, because it acts on the large group. Improving recall from 98 to 99 per cent moves precision by less than a percentage point.

Do not tell users a flag means guilt. At 25 per cent precision, treating a flag as a finding is wrong three times in four. It is a reason to look, not a conclusion, and the interface should say so.

Evidence accumulates by multiplying odds

The tidier way to combine several pieces of evidence is in odds form. Odds are p / (1 − p), and Bayes becomes:

posterior odds = prior odds x likelihood ratio

where the likelihood ratio is P(E | H) / P(E | not H). For the classifier above, 0.98 / 0.03 = 32.7.

prior odds     = 0.01 / 0.99 = 0.0101
posterior odds = 0.0101 x 32.7 = 0.330
posterior prob = 0.330 / 1.330 = 0.248

Same answer, and now you can chain. A second independent signal with a likelihood ratio of 10 multiplies again: 0.330 × 10 = 3.30, giving a posterior of 0.77. Multiplying odds is why the log-odds form appears throughout machine learning — in log space, evidence simply adds.

The word doing the work is independent. Two signals derived from the same text are usually correlated, and multiplying their likelihood ratios as if they were independent overstates the evidence, often badly. This is exactly the assumption naive Bayes makes, and it is why naive Bayes produces well-ordered but badly calibrated probabilities: the ranking survives the wrong assumption, the numbers do not.

Where the prior comes from, honestly

The obvious objection is that the prior is a guess. Sometimes it is. Three honest responses:

• Often it is measurable. The rate of fraud in your transaction log is a fact you can compute, not an opinion.
• Sometimes the conclusion is robust to it. Try 0.5 per cent and 2 per cent as well as 1; if the decision is the same across that range, the prior's uncertainty does not matter here.
• Sometimes it is not, and you should say so. Reporting "precision is between 15 and 40 per cent depending on an assumed base rate we have not measured" is more useful than a single number with false precision.

The alternative to a stated prior is not neutrality. It is an unstated prior, usually the assumption that the thing is common, which is the error that produced the 95-per-cent guess in the first place.

The rule to keep

Draw the population. Ten thousand or a hundred thousand cases, four boxes, count them. The formula is easy to misapply and the counting is almost impossible to get wrong.