Model Monitoring — Drift Detection and Retraining
How to know your model is degrading before users complain. Data drift, concept drift, Evidently AI, and automated retraining triggers.
A model trained in January works well in January. By June, the world has changed — new fraud patterns, different traffic, monsoon season — and the model is quietly producing wrong predictions that no one has noticed yet.
Every deployed model degrades over time. The question is not whether it will degrade but whether you will notice before your users do. Without monitoring, degradation is discovered via user complaints, dropped revenue, or a business review showing a metric that looked fine six months ago is now at half its original performance. With monitoring, you catch it in days, not months.
Two types of drift cause degradation. Data drift: the input feature distribution has shifted. DoorDash trained on pre-monsoon delivery patterns. During monsoon, distance_km distributions shift (longer routes around flooded roads), is_peak_hour patterns shift (orders cluster differently), and the model receives inputs far from what it was trained on. Concept drift: the relationship between features and the target has changed. A fraud model trained before a new fraud scheme emerged correctly identifies old patterns but the new scheme looks like legitimate traffic to it. The input distribution may look the same but the correct output for those inputs has changed.
A doctor trained in the 1990s using the medical knowledge of that era. Data drift: the patient population has changed — more diabetes, more sedentary lifestyle, new drug interactions. Concept drift: the same symptoms now indicate different conditions due to new pathogens. A good doctor keeps learning. A monitoring system is the mechanism that tells the doctor which patients they are getting wrong, so they know what to study next.
Monitoring without ground truth labels is like checking a patient's vital signs without doing bloodwork. You can detect that something is wrong (features look unusual) but not what is wrong (model is wrong) without comparing predictions to actual outcomes. Both layers — leading indicators and lagging indicators — are needed.
Data drift, concept drift, and prediction drift — three failure modes
KS test, PSI, and chi-squared — detecting distribution shift statistically
Drift detection requires comparing two distributions: the reference distribution (features seen during training) and the current distribution (features seen this week). Three statistical tests are standard. The Kolmogorov-Smirnov test measures the maximum difference between two empirical CDFs — works for continuous features, no binning required. Population Stability Index (PSI) measures how much a distribution has shifted — widely used in credit risk and fraud at major banks. Chi-squared test compares observed vs expected frequencies — works for categorical features.
Evidently AI — automated drift reports and monitoring dashboards
Evidently generates HTML drift reports comparing a reference dataset (training data) to a current dataset (recent production data). It runs all relevant statistical tests automatically per feature type, generates visual distributions, and produces a JSON summary that can be parsed to trigger retraining alerts. It is the standard open-source monitoring tool used at startups everywhere.
Performance monitoring — track actual model accuracy over time
Drift monitoring detects input distribution shifts without labels — it is a leading indicator. Performance monitoring requires ground truth labels and is the lagging indicator. For delivery time prediction: the actual delivery time is available 30-60 minutes after prediction. For fraud detection: chargebacks confirm fraud 7-30 days after the transaction. The monitoring system joins predictions with delayed labels and tracks accuracy metrics over rolling windows.
Automated retraining — trigger, retrain, evaluate, promote
Manual retraining — a data scientist noticing a metric, running a notebook, and deploying — does not scale to dozens of models. Automated retraining monitors metrics and triggers the training pipeline (Module 69) when thresholds are breached. The trigger calls the Airflow DAG or Prefect flow with a flag indicating emergency retraining. The pipeline runs, evaluates the new model, and either promotes it automatically (if above a quality threshold) or sends a human alert for review.
Every common monitoring mistake — explained and fixed
Dashboards, alert routing, and who actually gets paged
In production, model monitoring is rarely one system — it is a stack. Infrastructure metrics (request latency, error rate, pod CPU and memory) flow into Prometheus or Datadog and get graphed in Grafana, exactly like any other backend service. Statistical drift metrics — the PSI and KS test results from earlier in this module — are usually computed on a schedule (an Airflow DAG running nightly or every few hours) rather than per-request, then written to the same metrics store so they show up alongside infra metrics on one dashboard. Business KPIs — fraud dollars lost, delivery complaints, conversion rate — get pulled from the warehouse into a separate executive-facing dashboard, often reviewed weekly in a recurring "model health review" meeting rather than watched in real time.
Who gets paged depends entirely on what broke. An infra symptom — the serving endpoint's p99 latency spikes, or the drift job itself crashes — pages the on-call engineer the same way any other service outage would, usually through PagerDuty, regardless of whether that engineer knows anything about the model. A drift alert on a specific feature is different: it routes to the ML engineer or data scientist who owns that model, usually as a Slack notification rather than a page, because drift alone is not an emergency — it is a signal that something needs investigating, not that something is on fire. A confirmed performance regression against ground truth (accuracy or MAE clearly worse than baseline) is treated with more urgency and can escalate to a page if it crosses a severity threshold. A business KPI regression — fraud losses suddenly climbing, complaint rate spiking — is the most cross-functional case: it usually triggers an incident channel involving product, data science, and sometimes support, because by the time a business metric has moved, real money or real users have already been affected.
Notice what actually gets monitored day to day is broader than "check accuracy": data drift and feature skew catch problems before labels ever arrive, prediction drift catches upstream pipeline bugs even when the input features look fine, and business KPIs catch the cases where the model is statistically unremarkable but the real-world impact is not — a small accuracy dip in a high-volume fraud model can still mean a large dollar loss. No single metric covers all three; production monitoring means running all of them side by side and knowing which one to trust for which kind of problem.
Five things people get wrong about model monitoring
Accuracy requires a ground truth label, and for most production models labels arrive late (delivery time: thirty to sixty minutes; fraud chargebacks: a week to a month) or in some cases never arrive at scale at all. If monitoring only meant tracking accuracy, a model could be silently broken for weeks before anyone noticed, simply because the labels needed to compute accuracy had not shown up yet. Real monitoring leans on leading indicators that need no labels — input feature drift, prediction distribution shift — precisely so problems surface before the lagging, label-dependent metric ever catches up.
Running a statistical test costs nothing computationally, but making its output useful is ongoing work. Thresholds need tuning against real production noise or every model gets flooded with false alarms. The reference distribution the current data is compared against goes stale and needs periodic refreshing, or the test starts flagging drift against a world that no longer resembles today's baseline anyway. New features added to the model later have to be deliberately wired into the monitoring job — they do not appear there automatically just because they exist in the model. None of that is a one-time cost.
A monitoring configuration that was well-tuned at launch degrades on its own as the business changes: normal seasonal patterns look like drift to a threshold set before the team had seen a full year of data; a model retrain shifts what "normal" prediction output even looks like, so the old baseline is now wrong; a new feature or a new market segment needs its own reference distribution before monitoring can say anything useful about it. Treating the initial monitoring setup as finished work is exactly how a monitoring system quietly stops being trustworthy without anyone deciding that it should.
Data drift only checks whether the input feature distributions have moved. Concept drift — where the relationship between the same features and the correct outcome has changed — can happen with the input distribution looking completely unchanged. A fraud model can see the exact same feature ranges it always has while an entirely new fraud scheme, invisible to those features, is bypassing it undetected. Data drift monitoring alone would report a perfectly clean, stable-looking dashboard the entire time this is happening, which is precisely why performance monitoring against delayed ground truth cannot be skipped just because the drift dashboard looks calm.
A monitoring system that fires constantly trains its own team to stop reading it — alert fatigue is a real failure mode, not a minor annoyance. Statistical significance is sensitive to sample size, so at high production volume even a practically meaningless shift can produce a technically significant p-value and trigger an alert every single day. A smaller number of well-calibrated alerts, routed to the right person at the right urgency, catches real problems faster than a dashboard so noisy that a genuine critical alert gets lost in the same channel as twenty routine ones from that week.
Model monitoring — 5 questions interviewers actually ask
Data drift is a shift in the input feature distribution — it is detectable immediately, without any ground truth label, using statistical tests like KS or PSI directly on incoming features. Concept drift is a change in the relationship between those features and the correct outcome — the inputs can look completely unchanged while the correct prediction for them has shifted, and detecting it requires ground truth labels, which are usually delayed. The distinction matters operationally because it determines what tooling can even see the problem: a monitoring stack that only watches feature distributions will report a clean bill of health during a concept drift event, so performance monitoring against delayed labels has to run in parallel, not as a replacement.
I would alert on anything that is both statistically meaningful and actionable right now — a confirmed performance regression past a defined threshold, a majority of features drifting at once, or a business KPI moving in the wrong direction. I would only log, not alert, on individual feature drift below a severity threshold, small fluctuations that fall within normal week-to-week noise, or anything that requires a human to gather more context before it is even clear whether action is needed. The test I would apply to any candidate alert: if this fired right now, is there a specific person who should do something today, or does it just want an audit trail in case it becomes relevant later?
I would rely on leading indicators that need no labels at all in the interim: input feature drift, prediction distribution shift, and for a classification model, the distribution of predicted confidence scores — a sudden rise in low-confidence predictions is often an early sign of trouble long before labels confirm it. I would also set up a small label-sampling programme where a subset of predictions gets manually reviewed or fast-tracked to a confirmed outcome within a day, giving an early, lower-volume performance signal well before the full delayed label set arrives at scale. Neither approach replaces eventual ground truth evaluation — they buy time to react sooner.
It comes down to the feature's type and how the result needs to be interpreted. For a continuous feature I would default to the KS test when I want a clean statistical significance answer with a p-value, since it directly compares empirical distributions with no binning decisions to second-guess. I would use PSI when I want a single interpretable severity score with industry-standard thresholds — it is the default in credit risk and fraud teams specifically because everyone already agrees on what a PSI above 0.2 means. For a categorical feature, neither KS nor PSI directly applies the same way, so chi-squared, which compares observed to expected category frequencies, is the natural choice.
I would treat this as a monitoring design problem, not a data problem. First, I would switch from pure statistical significance to effect-size thresholds — requiring a KS statistic above a meaningful cutoff, not just a p-value below 0.05, since large sample sizes make almost any tiny shift statistically significant. Second, I would require drift to persist across several consecutive checks before alerting, to filter out single-day noise. Third, I would re-route by severity so only genuinely critical signals reach a page, with the rest going to a digest a human actually has time to read. The underlying goal is restoring trust in the alerts that do fire, since a monitoring system nobody reads is equivalent to having no monitoring at all.
Your model is monitored. Next: version your data like you version your code.
Monitoring tells you when to retrain. But when you retrain, you need to know exactly what data produced each model — so you can reproduce results, audit decisions, and debug regressions. Module 73 covers retraining pipelines with champion-challenger evaluation, safe model promotion, and the rollback patterns that protect production when a new model unexpectedly underperforms after deployment.
Champion-challenger evaluation, safe model promotion, and rollback patterns that protect production.
🎯 Key Takeaways
- ✓Two types of drift cause model degradation. Data drift: input feature distributions shift (P(X) changes) — detectable immediately without labels using statistical tests. Concept drift: the relationship between features and target changes (P(Y|X) changes) — requires ground truth labels and is invisible until labels arrive. Both need separate monitoring strategies.
- ✓Three statistical tests cover all feature types: KS test for continuous features (compares empirical CDFs, p-value + statistic threshold), PSI for continuous features (industry standard in finance: PSI < 0.10 safe, 0.10-0.20 investigate, > 0.20 retrain), chi-squared for categorical features (compares observed vs expected frequencies).
- ✓Evidently AI automates drift reporting: run Report(metrics=[DataDriftPreset()]) with reference and current DataFrames. It selects the right test per feature type, generates HTML dashboards, and produces JSON results for programmatic alerting. Schedule as an Airflow task daily, parse JSON results to trigger retraining.
- ✓Performance monitoring requires delayed ground truth labels. Log every prediction with a prediction_id. When labels arrive (actual delivery time, fraud confirmation), join them back to predictions. Compute rolling metrics (MAE, within-N-minutes rate, bias) over daily/weekly windows. A 25%+ MAE increase is a critical retraining trigger.
- ✓Automated retraining trigger hierarchy: critical (performance drop > 25% → retrain immediately), high (> 40% features drifted or prediction distribution shifted 2σ+ → retrain if 2+ high triggers), medium (> 10,000 new samples accumulated → scheduled retrain). Add 24-hour cooldown to prevent retrain loops.
- ✓Alert fatigue is the primary failure mode of monitoring systems. Use effect size thresholds not just p-values — require KS statistic > 0.10, not just p < 0.05. Require drift to persist 3 consecutive days before triggering. Route by severity: critical = page on-call, high = Slack, medium = weekly digest. A monitoring system that fires 20 false alarms per week is worse than no monitoring.
Discussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.