Monitoring, Drift, and When to Retrain

Google's MLOps guidance puts the distinction plainly: models can decay in more ways than conventional software systems, and they do it because of constantly evolving data profiles rather than because of bad code.

This is the reason ML needs its own observability story. A web service that breaks returns a 500, and your existing alerting catches it. A model that breaks returns a confident, well-formed, wrong prediction, at normal latency, with no exception in the logs.

So the monitoring question is not the usual one. Uptime, latency and error rate can all be perfect while the model is worthless. You need signals that describe what the model is being asked and what it is answering, not just whether the service responded.

Two things can change underneath a deployed model, and they call for different responses.

Data drift is a change in the inputs. The distribution $P(X)$ moves: your traffic shifts to a new country, a marketing campaign brings in younger users, a sensor is recalibrated. The relationship the model learned may still hold perfectly. It is simply being asked about a region of the input space it saw little of in training.

Concept drift is a change in the relationship itself. $P(y \mid X)$ moves: the same inputs now imply a different outcome. A fraud pattern that was rare becomes standard. A word acquires a new meaning. Here the model is wrong even on inputs that look entirely familiar.

Data drift is often survivable. Concept drift means the learned function is stale.

The distinction is not academic, because it changes what you do.

Retraining fixes data drift almost mechanically: show the model the new region of input space and it adapts. Retraining fixes concept drift only if the new relationship is present in your recent labels, and only for as long as it holds.

A useful clue: data drift is visible in the inputs alone, with no labels required. Concept drift is invisible in the inputs. You can only see it by comparing predictions against outcomes, which is why it is the harder of the two to catch early.

The obvious monitor is accuracy. Often you cannot compute it for months.

A churn model predicts whether a customer will leave within 90 days. The label for today's prediction exists in 90 days. A credit model predicting 12-month default waits a year. A recommendation might get feedback in seconds, but a purchase-intent label takes a full sales cycle.

This delay is what makes ML monitoring genuinely different from service monitoring. Your most meaningful metric is the one you get last, and by the time it confirms a problem the model has been making bad decisions for a quarter.

So production monitoring is built in layers, ordered by how quickly each signal arrives. Fast proxies raise suspicion; slow ground truth confirms it.

Order your monitors by latency of signal, not by importance.

1. Input distributions. Available immediately. Per feature: null rate, mean and variance, category frequencies, out-of-range counts. Catches broken upstream pipelines within minutes.
2. Prediction distribution. Available immediately. If a fraud model scored 0.4 percent of traffic as fraud last month and 6 percent today, something changed regardless of which side is right.
3. Model confidence. Available immediately. A rising share of predictions near the decision boundary suggests inputs unlike the training set.
4. Business proxies. Days. Click-through, acceptance rate, manual override rate. Overrides are especially useful, since a human disagreeing with the model is a free label.
5. Ground truth accuracy. Weeks to months. The real answer, arriving last.

The first three cost almost nothing and catch the majority of real incidents, because most production failures are broken data rather than subtle concept drift.

To alert on drift you need a number, which means comparing a reference distribution against a current window.

Several statistics are used. The Kolmogorov-Smirnov test compares two continuous distributions. The chi-squared test handles categoricals. In credit scoring the long-standing convention is the population stability index, which bins both distributions and sums $(a_i - b_i) \ln(a_i / b_i)$ across bins $i$.

PSI carries widely used rules of thumb: below 0.1 is treated as no meaningful shift, 0.1 to 0.25 as moderate, above 0.25 as significant. Treat those as industry convention rather than derived thresholds, because the right cut-off depends on how sensitive your model is to that particular feature.

The practical trap is window size. Too short and seasonality fires the alert every Monday. Too long and a genuine shift is averaged away.

A drift alert is not a retraining instruction. It is the start of a decision, and most branches of that decision are not retraining.

Google's guidance lists the trigger types for a continuous training pipeline explicitly: on a schedule, on demand, on the availability of new data, on model performance degradation, and on significant changes in the data distribution.

The first is the one most teams start with, and it has an underrated property. A scheduled retrain is predictable, so its failures surface on a known cadence rather than during an incident. If nightly retraining is cheap and validated, it removes an entire class of staleness problem without anyone deciding anything.

The last two are the sophisticated ones, and they only exist if the monitoring from the previous steps is in place. This is the dependency worth noticing: you cannot have performance-triggered retraining without performance monitoring. Automation does not remove the need for observability, it presupposes it.

Retraining is the reflex, and there are four common cases where it does not help.

• The data is broken. A feature went null because an upstream job failed. Retraining on it teaches the model that the feature is always null. Fix the pipeline.
• The labels lag the shift. If the world changed last week and your labels take 90 days, recent training data still describes the old world. Retraining bakes in the past.
• There is a feedback loop. A recommender trained on clicks it caused will narrow. More retraining accelerates the narrowing rather than correcting it.
• The shift is seasonal. December is not drift. Retraining hard on December gives you a model that is wrong every January.

The first question after an alert is always whether the data is right, not whether the model is old.

The six-stage pipeline from earlier in this path ends at monitoring, and monitoring points back at two places: a retraining trigger, and a new round of experimentation.

That return path is what makes the whole thing a loop rather than a deployment checklist. A model in production is not a finished artifact. It is a claim about a relationship in the world, and the world keeps voting on whether the claim still holds.

What MLOps buys is a shorter interval between the world changing and your system noticing. Every practice in this path serves that: version the pipeline so you can rebuild, validate data so corruption stops at the gate, share feature definitions so training and serving agree, and monitor so the interval is measured in days rather than quarters.