ML Monitoring, Drift & Retraining
A model is the only component in a production system whose correctness depends on the world staying the way it was when the component was built. A web server that returned 200 yesterday returns 200 today. A fraud model that had 0.92 AUC yesterday can be quietly worthless today because a card issuer changed a field format, a marketing campaign brought in a new population, or fraudsters adapted. Nothing crashes. Latency is fine. The dashboard is green. The only symptom is that predictions are wrong, and you usually find out from a business stakeholder weeks later.
In an ML system design interview, "how would you monitor this?" is not a closing pleasantry — it is where the interviewer checks whether you have actually run a model in production. Strong candidates describe monitoring as a stack of layers, name the statistics they would use and their thresholds, know that ground truth usually arrives late, and can explain how retraining is triggered and gated so it cannot make things worse. Weak candidates say "we'd track accuracy" and stop.
This subject covers that layered monitoring stack, drift statistics with worked calculations, the delayed-label problem, alerting that people will not mute, retraining policies, versioning for rollback, and one full incident walk-through. Deployment mechanics (shadow, canary, blue/green, rollback traffic shifting) are covered in the Model Serving & Deployment subject; here we treat "deploy the challenger" as a single step and focus on deciding when and whether.
Why Models Decay
A trained model is a frozen estimate of P(y \mid x) learned from data drawn from some joint distribution P_{\text{train}}(x, y). Production data comes from P_{\text{prod}}(x, y), and the two diverge over time for reasons that fall into a small number of categories:
| Cause | What changes | Example |
|---|---|---|
| Covariate shift | P(x) changes, P(y \mid x) stays | A new marketing channel brings younger users; the model never saw many of them |
| Label / prior shift | P(y) changes | Fraud rate doubles during a holiday season |
| Concept drift | P(y \mid x) changes | Fraudsters learn the model's rules; the same features now mean something else |
| Upstream data bugs | The pipeline changes, not the world | A schema change silently zeroes a feature |
| Feedback loops | The model's own decisions shape future data | A recommender only shows what it already likes |
Decay can be gradual (seasonality, slow population change), sudden (a product launch, a pipeline break, a regulation), or recurring (weekday/weekend, payday cycles). The monitoring you build must catch all three, and — critically — the response differs: a pipeline bug should be fixed, not retrained around; genuine concept drift should trigger retraining.