Data Drift
Your model didn't get worse — the world moved. The most common way a working system quietly stops working.
When not to use it
- (It's a failure mode. The question is when your monitoring lies.)*
- Input drift as a proxy for accuracy. Inputs can shift with accuracy stable, and vice versa. It's a hint, not a measurement.
- Significance tests at scale. With enough data everything is significantly different. Use effect size.
- Per-feature tests alone. They miss the shifts that matter. Test the model's representation.
- Retraining reflexively on recent data. You may be chasing noise and overfitting to last month.
Reach for something else instead
- Labelled sample monitoring — the only real measurement. Buy the labels.
- Prediction drift — cheap, and it aggregates the input changes that actually mattered.
- Scheduled retraining — crude, and it's what most production systems do.
- Shadow deployment — run the new model alongside, compare before switching.
Sources & further reading
- Gama et al. (2014), A Survey on Concept Drift Adaptation — the taxonomy; covariate vs. concept vs. label shift.
- Rabanser, Günnemann & Lipton (2019), Failing Loudly: An Empirical Study of Methods for Detecting Dataset Shift — per-feature tests are poor; test the model's representation instead.
- Sculley et al. (2015), Hidden Technical Debt in Machine Learning Systems — feedback loops and why the drift is sometimes yours.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Treating input drift as evidence of degradation. It's correlated, not equivalent.
- Firing alerts on statistical significance. At scale, everything is significant.
- Not noticing the drift is yours. Recommenders shape the data they're retrained on.
- Assuming a retrain fixes it. You've chosen a window, which encodes an unverifiable assumption about how fast the world moves.