Probability for Machine Learning

Machine learning often gives engineers a number before it gives them a decision. A classifier returns 0.82, a retriever assigns a high similarity score, or a fraud detector flags an order for review. Probability is how you turn those numbers into named claims about an event, a population, and the evidence you observed.

Why probability shows up in ML

The preceding optimization chapter showed how gradients change model parameters. Once those parameters assign an order a risk score, the next question isn't an optimizer question. It's a probability question: what event became more likely, among which orders, after what evidence?

Machine learning usually gives you a sentence like this:

Given what I observed, this event seems more or less likely.

Probability is the language for making that sentence precise. It doesn't remove uncertainty. It gives you a disciplined way to count under uncertainty.^[1][2][3]

We'll first compute a posterior from a pile of orders by hand, then encode the exact accounting in small programs. Near the end, we'll connect the same idea to score calibration and token probabilities without stealing the next chapter's job: statistics will ask how trustworthy estimated rates are when your sample is finite.

One running example

We'll use one example for the whole article: a fraud detector that flags e-commerce orders for manual review.

The point isn't fraud detection itself. The point is learning how to read any ML score without fooling yourself.

Before the detector runs, you need a world to count in.

If any of those pieces are missing, the number is floating. Floating numbers are how teams turn model scores into bad product decisions.

Start with the population

Imagine 10,000 recent orders from the same product surface.

The probability of a fraudulent order is a fraction:

$$P(\text{fraudulent}) = \frac{100}{10000} = 0.01$$

Read that as: before the detector says anything, 1 percent of orders are fraudulent.

That starting probability is the prior. A prior isn't a guess pulled from nowhere. In an engineering system, it should usually come from a measured population: production logs, labeled eval data, reviewed tickets, or another concrete sample.

In probability language, a random variable is a number that depends on which case you happened to pick. If we let F = 1 when an order is fraudulent and F = 0 when it's legitimate, the expectation E[F] is the long-run average value, each outcome weighted by its probability:

$$E[F] = 1 \times 0.01 + 0 \times 0.99 = 0.01$$

That 0.01 is the base rate written as an average instead of a fraction. A 0/1 variable like this is called a Bernoulli variable, and its expectation is always just the probability of the 1 outcome.

Expectation alone hides how much outcomes move around. Variance measures the average squared distance from the expectation, Var[F] = E[(F - E[F])^2]. For a Bernoulli variable with success probability p, it simplifies to p(1 - p):

$$\text{Var}[F] = 0.01 \times (1 - 0.01) = 0.0099$$

Variance names outcome-level spread around the average. Later statistics chapters separate that spread from uncertainty in an estimated rate and from variation across product slices or repeated training runs.

Here is the count table written as a Bernoulli indicator. 1 means a fraudulent order and 0 means a legitimate order. The mean of that indicator is the prior.

Evidence changes the question

Now add the detector.

That top row is strong. If an order is fraudulent, the detector catches it 95 percent of the time.

But product teams ask a different question after seeing a flag:

Given that this order was flagged, how likely is it fraudulent?

That's a different question. Probability notation makes the difference visible:

Those two lines aren't interchangeable. Reversing them is one of the most common probability mistakes in ML systems.

Count the flagged pile

Work from the 10,000 orders. Don't start with Bayes rule yet.

Fraudulent orders:

$$100 \times 0.95 = 95$$

Legitimate orders:

$$9900 \times 0.05 = 495$$

Now put the flagged orders into one pile.

The false-positive rate is small, but it acts on the huge legitimate pile. Five percent of 9,900 is larger than 95 percent of 100.

That's why the posterior is surprising:

$$P(\text{fraudulent} \mid \text{flagged}) = \frac{95}{590} \approx 0.161$$

A flagged order is about 16 percent likely to be fraudulent, not 95 percent likely.

The detector didn't become bad. The question changed. We stopped asking how often fraudulent orders are caught and started asking what lives inside the flagged pile.

Turn the arithmetic into a confusion-table calculation. Notice that the program prints counts before it prints the posterior.

Conditioning means narrowing the world

Conditional probability always narrows the world first.

For $P(\text{fraudulent} \mid \text{flagged})$, the denominator isn't all 10,000 orders. The denominator is only the 590 flagged orders.

That's the whole mental move. Ask "among which cases?" before you divide.

This is the same flow as the diagram:

When a probability problem feels abstract, draw that flow. The formula should summarize the drawing, not replace it.

The following tiny dataset makes conditioning literal: filter to the evidence pile first, then count fraud only inside the filtered records.

Joint and marginal probability

Two more words tie the counts together.

A joint probability is the chance that two things happen together. In the population, 95 orders are both fraudulent and flagged, so:

$$P(\text{fraudulent and flagged}) = \frac{95}{10000} = 0.0095$$

A marginal probability is the chance of one event by itself, ignoring the other. The marginal probability of a flag adds up every way a flag can happen:

$$P(\text{flagged}) = \frac{95 + 495}{10000} = \frac{590}{10000} = 0.059$$

Joint, conditional, and marginal probabilities are linked by one identity. When $P(B) > 0$, conditional probability is the joint divided by the world you conditioned on:

$$P(A \mid B) = \frac{P(A \text{ and } B)}{P(B)}$$

Rearranged, that gives the multiplication rule: a joint probability is a conditional times a marginal.

$$P(A \text{ and } B) = P(A \mid B)\,P(B) = P(B \mid A)\,P(A)$$

Check it against the counts: $P(\text{fraudulent} \mid \text{flagged}) = 0.0095 / 0.059 \approx 0.161$, the same posterior as before. This identity is also where Bayes rule comes from. The next section just reads it from the other direction.

The same counts can be computed as shares of the full population. The two routes are mathematically identical, but the program below also shows why you should not compare floating-point results with exact equality: the last line is False even though the values match to every printed digit.

Bayes rule after the counts

Bayes rule is the formula version of the flagged-pile count.

For events $A$ and $B$ with $P(B) > 0$:

$$P(A \mid B) = \frac{P(B \mid A)P(A)}{P(B)}$$

In this article:

When $B$ is the observed evidence, $P(B \mid A)$ is its likelihood under hypothesis $A$. Here it asks how likely a flag would be if the order really were fraudulent. Bayes rule combines that likelihood with the prior to obtain the posterior.

The denominator $P(B)$ means "how often does a flag happen at all?"

It includes true flags and false alarms:

$$P(B) = P(B \mid A)P(A) + P(B \mid \text{not }A)P(\text{not }A)$$

The denominator $P(B)$ is the marginal probability of a flag. It averages over both kinds of orders, weighted by how common each kind is.

Plug in the numbers:

$$P(B) = 0.95 \times 0.01 + 0.05 \times 0.99 = 0.059$$

Now compute the posterior:

$$P(A \mid B) = \frac{0.95 \times 0.01}{0.059} \approx 0.161$$

Same answer as the count table. Bayes rule is the compact form of the same accounting: track where the flagged orders came from before you divide.

Independence means no update

Evidence helps when it changes the event rate.

When $P(B) > 0$, seeing $B$ leaves the probability of $A$ unchanged if the events are independent:

$$P(A \mid B) = P(A)$$

Imagine a broken fraud detector:

Out of 10,000 orders, this detector produces:

The flagged pile is still 1 percent fraudulent:

$$\frac{20}{2000} = 0.01$$

The flag created work, but it didn't create information. Useful ML signals are useful because they change the rate of the event you care about.

Code makes the "no update" claim testable. If both groups are flagged at the same rate, that rate cancels from Bayes rule.

Same detector, different world

Keep the detector fixed:

Now change only the population.

The model didn't change. The world around the model changed.

This is why the same classifier can behave differently across products, countries, languages, traffic sources, or time periods. A score without a population is like a map without a scale. It may look precise, but it isn't enough to act carefully.

Build it: compute posterior risk

The code should read like the table:

1. Check that each input is a valid probability.
2. Count true flags as true_positive * prior.
3. Count false flags as false_positive * (1 - prior).
4. Divide true flags by all flags.

Put this in probability_demo.py. It is small enough to audit line by line, but already exposes the input validation and evidence guard that production code needs.

The detector stayed fixed. The prior changed, so the posterior changed.

A threshold changes two probabilities at once

A deployed detector rarely emits only flag or not flag. It emits a score, and a threshold creates the flag. Raising a threshold normally sends fewer orders to reviewers and may make the flagged pile cleaner, but it can also miss more fraudulent orders.

Use an illustrative measurement table from the same 1 percent fraud population. These rates would need to be measured on labeled data in a real system.

The stricter policy reduces review load and improves the fraction of reviewed orders that are fraud, which is precision, but it catches fewer fraud cases, which lowers recall. This is a precision-recall tradeoff. Probability exposes the tradeoff; product cost and safety policy choose among the options. A threshold can also send no orders to review. In that case, queue precision is undefined because there is no flagged pile, so code should reject or explicitly represent the empty queue instead of dividing by zero.

Read the code as probability

Every line in flagged_posterior has a probability meaning.

The guard for all_flags == 0 matters. If evidence never appears, the conditional probability is undefined. Production code should reject that case instead of inventing a number.

Protect the calculation

The function needs a contract: the known worked example must remain correct, invalid inputs must fail, and impossible evidence must fail instead of returning an invented posterior.

The first test protects the numeric story. The second protects the failure path. Both are part of learning probability as an engineering skill, not just as a formula.

Where this shows up in ML work

The fraud example is one surface.

The same habit works everywhere:

1. Name the event.
2. Name the population.
3. Measure the base rate.
4. Name the evidence.
5. Ask how the evidence changes the event rate.

Skip those steps and a score starts pretending to be a conclusion.

A score isn't automatically a probability

So far, the evidence was a thresholded flag and all rates were given. A model may instead emit a score such as 0.80. That score earns the interpretation "80 percent probability of fraud" only if similarly scored orders are fraudulent about 80 percent of the time. That property is calibration. Modern neural classifiers can be accurate while still producing poorly calibrated confidence scores, which is why score calibration is measured rather than assumed.^[4]

This toy bucket demonstrates the check. Every order was assigned a score near 0.80, but only half of these labeled orders were actually fraudulent.

Six orders can't prove how a deployed model is calibrated. The calculation names the question. Statistics will teach how much evidence you need before trusting the measured gap.

A token model multiplies probabilities

This chapter used one binary event, but an LLM produces a categorical distribution over the next token. For a known target token, training cares about the probability assigned to that target. With a one-hot target, that token's cross-entropy contribution is its negative log probability, -log(p).^[3]

Low probability for the observed token costs more because the observation was more surprising under the model.

For a sequence, the model's joint probability follows the chain rule: multiply the conditional probability of each next token given the previous tokens.

$$P(t_1, t_2, \ldots, t_n) = P(t_1) \prod_{i=2}^{n} P(t_i \mid t_1, \ldots, t_{i-1})$$

Here, $t_i$ is the token at position $i$, and the expression to the right of the bar is the preceding context. Multiplying many small probabilities eventually underflows in floating-point arithmetic. Logs convert the product into a stable sum.

The 0.0 doesn't mean the sequence was impossible. It means ordinary floating-point multiplication lost a representable nonzero number. Later language-modeling chapters use this same log-space habit for cross-entropy and perplexity.

Common mistakes

Most probability bugs are question bugs.

The debugging question is short:

Among which cases am I counting?

If you can answer that, the formula usually becomes much easier.

Try it yourself

Use the same 10,000-order population.

1. Recompute $P(\text{fraudulent})$ from the first table.
2. Recompute the 495 false flags by hand.
3. Change the false-positive rate from 0.05 to 0.01.
4. Compute the new posterior.
5. Explain why the posterior changed even though the true-positive rate stayed 0.95.
6. Compare the broad and stricter review policies: which catches more fraud, and which sends a cleaner queue to reviewers?
7. Compute -log(0.80) and -log(0.10). Which observed token is more surprising to a model?

Then translate the lesson to product search:

The goal isn't to memorize the fraud numbers. The goal is to carry the counting habit into any model score.

Solution checks

Check your work after you try the practice.

If your explanation starts with Bayes rule, translate it back into piles. A good answer can move between counts, words, code, and notation.

What to carry forward

Probability turns model scores into named claims.

For an e-commerce product, a useful probability statement sounds like this:

Event: order is fraudulent. Population: electronics orders in the last 30 days. Evidence: fraud detector score above threshold. Decision: send to manual review when posterior risk is above 20 percent.

That sentence is longer than "score is high," but it's much safer.

Mastery check

Key concepts

• events and sample spaces
• priors and posteriors
• conditional probability
• independence
• Bayes rule
• base rates
• calibration as an empirical check on score meaning
• negative log probability for observed tokens
• log-space arithmetic for long probability products

Evaluation rubric

• Foundational: Names the event, population, evidence, prior, and posterior in one concrete ML example.
• Foundational: Computes a posterior from counts before using Bayes rule.
• Intermediate: Explains why $P(\text{flagged} \mid \text{fraudulent})$ and $P(\text{fraudulent} \mid \text{flagged})$ answer different questions.
• Intermediate: Uses Bayes rule and the runnable Python function to reproduce the same posterior.
• Advanced: Explains how base-rate shift changes a production threshold decision, checks whether a score is calibrated, and uses log probabilities to avoid sequence underflow.

Follow-up questions

Common pitfalls

• Symptom: A team treats a score like “0.82” as if it were automatically the probability of truth. Cause: The event, population, and evidence were never named. Fix: Rewrite the score as a full sentence: event, population, evidence, and action threshold.
• Symptom: Someone says “the model catches 95 percent of fraud, so a flagged order is 95 percent fraud.” Cause: They reversed the conditional. Fix: Write both questions in plain English before using notation.
• Symptom: The same threshold behaves very differently after a product launch in a new market. Cause: The base rate changed even if the detector stayed fixed. Fix: Recompute priors and posteriors for the new slice instead of carrying old percentages forward.
• Symptom: A detector produces many alerts but almost none are useful. Cause: The signal fires at similar rates on positive and negative cases, so it behaves like independent noise. Fix: Check whether the evidence changes the event rate at all.
• Symptom: Code quietly returns nonsense when the evidence pile is empty. Cause: The conditional probability is undefined when evidence has zero probability. Fix: Guard against zero-probability evidence and fail loudly. If a measured pile is tiny rather than empty, report uncertainty about the estimate.
• Symptom: A confidence score is shipped as a probability without a labeled bucket check. Cause: calibration was assumed. Fix: compare predicted risk with observed rates and quantify uncertainty in that estimate.
• Symptom: Sequence probabilities become zero during evaluation. Cause: many small probabilities were multiplied in ordinary floating-point arithmetic. Fix: add log probabilities and exponentiate only when a representable probability is required.