Prediction Drift Monitoring

The most direct way to know a model has broken is to compare its predictions against the truth and watch accuracy fall. The problem is that truth often arrives late — a fraud label needs a chargeback to be filed, a credit default needs months to happen, a trade's real outcome needs the position to close. Prediction drift monitoring sidesteps the wait: it watches the distribution of the model's own output scores, day over day, and flags a shift long before any true label ever confirms something is wrong.

The analogy: a factory's output gauge, not the customer complaints

A factory could wait for customer complaints to learn a machine is producing bad parts, but complaints trickle in over weeks. A faster signal is watching the machine's own gauge readings shift — if a stamping press that always outputs parts of a certain thickness range suddenly starts outputting a different range, something changed upstream, even before any customer has noticed. Prediction drift monitoring is that gauge: it watches the shape of the model's output scores, which are available instantly, as an early proxy for a problem that would otherwise only show up in delayed complaints (the true labels).

Worked example 1: a fraud model's score distribution shifts

A fraud model outputs a probability score for every transaction. In training and for months in production, the average score is $0.04$ with 95% of scores below $0.15$. This week, the average score jumps to $0.11$ with 95% of scores below $0.35$. No fraud labels have come back yet to confirm anything — chargebacks take 60 days. But the shift itself is the alarm: either the incoming transactions genuinely look riskier (a real change in customer behavior) or the model is now seeing feature values (say, a new merchant category code) it was never trained on and is scoring everything defensively high. Either way, someone needs to look now, not in 60 days.

Worked example 2: quantifying the shift with population stability

A common metric is the Population Stability Index (PSI), which buckets scores into ranges and compares the share of predictions in each bucket now versus in training:

$$\text{PSI} = \sum_i (p_i - q_i) \ln\left(\frac{p_i}{q_i}\right)$$

where $p_i$ is the current share of predictions in bucket $i$ and $q_i$ is the training-time share. Suppose one score bucket (0.3–0.4) held 5% of predictions in training ($q_i = 0.05$) but now holds 15% ($p_i = 0.15$). That single bucket's contribution is:

$$(0.15 - 0.05) \times \ln(0.15/0.05) = 0.10 \times 1.099 = 0.110$$

Summed across all buckets, a total PSI above roughly 0.2 is the industry rule-of-thumb trigger for "investigate now" — well before any label confirms harm.

The two histograms above are one snapshot; the explorer below lets you see the same shifting-distribution idea move continuously as its parameters change, which is what a rolling drift metric is really tracking week over week.

What this means in practice

Teams track PSI (or a similar divergence measure) on prediction scores continuously, alert past a threshold, and then dig into the underlying feature distributions to find the cause — a new user segment, a broken upstream feature pipeline, or a genuine change in the world the model needs retraining for. Because drift can be real (the world changed and the model should adapt) or spurious (a data pipeline bug), an alert is the start of an investigation, never itself proof the model is wrong.