The model that quietly stopped fitting

Nothing broke, and it got worse

A deployed model has a failure mode that no other part of your system has: it degrades with nobody deploying anything. The code is unchanged, the tests pass, latency is flat, error rate is zero, and the predictions are getting worse, because the world moved and the model did not.

A spam classifier trained on last year’s spam meets this year’s. A demand forecast trained before a festival season meets the season. A model trained on one country’s users meets an influx from another. In every case the machinery is healthy and the output is wrong.

Three different changes, often confused

• Data drift (covariate shift): the inputs change distribution. More mobile traffic, longer messages, a new language appearing in the text field.
• Concept drift: the relationship between inputs and the correct answer changes. The same message that meant “legitimate” now means “scam”, because the scammers adapted.
• Label delay: nothing has drifted, but you will not know for weeks, because ground truth arrives late: a fraud chargeback at 60 days, a churn label at 90.

They need different responses. Data drift may be harmless if the model handles the new region of input space. Concept drift always hurts. Label delay is what makes both hard to detect quickly, and it is the reason input monitoring exists at all.

Monitor the inputs, because they are free

You can measure input distributions today, without waiting for labels. For each important feature, compute a summary on a recent window and compare it with the training distribution:

• Numeric features: mean, standard deviation, and the share falling outside the training range.
• Categorical features: the proportion of unseen categories, and the shift in the top few.
• Text or embeddings: mean embedding distance from the training centroid, or the share of inputs beyond a distance threshold.
• Missingness: the share of nulls per field. A field that suddenly becomes 30% null is usually an upstream change and it is one of the highest-yield checks in this list.

The standard statistics are the Population Stability Index and the Kolmogorov–Smirnov test. PSI has widely used rules of thumb (under 0.1 stable, 0.1 to 0.25 worth investigating, above 0.25 significant), and those thresholds are conventions, not laws; calibrate them against your own history before you page anybody.

One caution repeated by everybody who has run this in anger: with enough features and daily tests, statistical drift alarms fire constantly on differences that do not matter. Test a handful of features you have reason to care about, use a window long enough to be stable, and treat a drift signal as a prompt to look, never as an automatic retrain trigger.

Monitor the outputs, which is cheaper still

The prediction distribution is available immediately and it moves before the labels do.

• The mean predicted score, day over day. A classifier whose average score jumps from 0.12 to 0.34 has met something new.
• The share of predictions near the decision threshold, which measures how much of your traffic is a coin flip.
• The rate of fallbacks, refusals, empty results or low-confidence answers.
• For a language model: output length, refusal rate, and the rate at which structured output fails to parse. That last one is a beautifully sensitive canary for a provider changing something under you.

Then get labels, slowly and deliberately

Input and output monitoring tell you something changed. Only labels tell you whether quality fell.

Three affordable sources: user actions that imply a judgement (a report, a correction, a deletion, an undo), a small stratified sample reviewed by a person each week, and delayed ground truth when it eventually arrives. Fifty labelled examples a week, chosen to over-sample the uncertain region, is a modest, sustainable practice that will detect real degradation within a month.

Keep those labelled examples forever. They become your regression set, and a set built from real production failures is worth more than a much larger synthetic one.

Retraining is a decision, not a schedule

“Retrain nightly” sounds diligent and is often a way to ship an unevaluated model every day. Retraining on a cadence is fine only if every retrained model passes the same evaluation gate, and is shipped through the same shadow-and-canary path, as a hand-made one. If it is not gated, a data pipeline bug on Tuesday becomes a production model on Wednesday.

Retrain when the evidence says to: measured quality has fallen, drift is sustained rather than a spike, or enough new labels exist to be worth learning from. Write the trigger down before you need it, and record which data snapshot each retrain used so the version lineage from the earlier lesson stays intact.

The free path

Evidently is a free, open-source library that computes drift reports and quality metrics and produces an HTML page you can look at. NannyML does the harder job of estimating performance when labels have not arrived yet. Neither is required: a weekly SQL query producing ten numbers, stored in a table and drawn on your dashboard, is a working drift monitor, and it is the version that actually gets built.