Loading...
System Design and AI Engineering, by Roni Das. 980 interactive lessons.
Start LearningAI Engineering · Foundation · Core
When a model's accuracy decays over time because the live data has moved away from what it was trained on. Detected by monitoring inputs and outputs, and fixed by retraining.
In short
Model drift is when a model gets worse over time because the live world no longer matches the data it learned from. The service stays fast and error-free, so it takes drift checks on inputs and outputs, plus a sample of real answers, to see the damage.
In short
Model drift is when a model gets worse over time because the live world no longer matches the data it learned from. The service stays fast and error-free, so it takes drift checks on inputs and outputs, plus a sample of real answers, to see the damage.
Learn it in the course
This page is the free part.
₹999 in India$49 everywhere elseonce, for the whole course
The AI Engineering course covers Model Drift across a run of lessons, not one page. These 4 alone are about 258 minutes of step-by-step reading, every one with code you run in the browser, all with a quiz.
Five kinds of new data sent to a real model, 100 batches each, with three drift monitors and the true error measured every time. The alarm rang on every batch of a shift the model did not care about, and stayed silent through a 64% rise in error when prices moved. Alarm and harm lined up only when the model met data it had never seen, in the one such case tested, and there the model's own guesses drifted too. Fifty labelled rows per batch caught what no input monitor could, at a price in false alarms.
A new model goes live in one of two ways: a canary, where a share of real requests goes to it, or shadow, where it answers every request silently next to the old one. I measured both on electricity prices, with the right answer arriving half an hour later. On a known 4.09-point regression, shadow raised the alarm in all 20 starts (median 241.5 half-hours) and a 20% canary in 12. Checking after every half-hour turned a 1% false-alarm rate into 6 to 10% for a canary. What a rollout is, why comparing the same rows needs fewer of them, what shadow costs, and two faults in my own first design, kept on the record.
Real answers often arrive late, so teams watch a model's inputs and outputs in the meantime. I measured four drift measures for every month of 2012 against a bike-rental model trained on 2011, and ranked each against the model's real monthly error. None moved in step with it: the best rank correlation was 0.58. The usual psi, against the whole year, sat between 1.3 and 4.9 every month because it measures the season, and the model's own training months score just as high. Over the year, the weather in 2012 looked like 2011; the error came from more riders, which none of these weather inputs showed. What input, output and performance drift are, why they differ, and why a few early labels are the real alarm.
I served a bike-rental model 145 days of test data, broke one input at a time in seven ways, and ran six simple checks on every day before any real answer was known. Range, unseen-value, stuck-value and zero-count checks each caught the break they were built for, on every day, with few or no false alarms. The distribution check fired on every clean day and was useless as designed. The worst break, the hour shifted by 5, which made the average miss almost five times worse, got past every one of them. What each check catches, what a false alarm costs, a follow-up check that did catch the shifted hour, and why the real error is still needed.
all part of
AI Engineering
210 lessons · about 219 hours · 10 free to read
₹999in India, by UPI
$49everywhere else, by PayPal
pay once,
yours for life
A trained model is a snapshot of the world at training time. When the world moves, the model keeps answering quickly and confidently, but the answers get worse. That decline is model drift. Unlike a normal service that throws errors, a drifting model fails silently: every request returns a clean response, and latency and error dashboards stay healthy.
It helps to ask what moved. Data drift, also called covariate drift, is when the inputs change, for example most traffic moving from desktop to mobile. Concept drift is when the link between inputs and the right answer changes, so the same inputs now deserve different answers; after a price rise, a house with the same features is worth more. Prediction drift is when the model's own outputs shift, such as the share of transactions it flags jumping overnight.
The three differ in cost to detect. Data drift and prediction drift need no labels, meaning no true answers, so you can measure them within hours. Concept drift can only be seen through real outcomes, and outcomes arrive late: a fraud chargeback can land 30 to 90 days after the transaction.
You compare a frozen reference sample from training with a window of live data, one input column at a time. The Population Stability Index, or PSI, cuts a column into 10 ranges using the training data, then sums (live share minus training share) x ln(live share / training share) over the ranges. A common rule reads under 0.10 as stable, 0.10 to 0.25 as a moderate shift, and over 0.25 as a large shift. The Kolmogorov-Smirnov test, or KS, is a statistical test that asks how likely a difference this big would be if nothing had changed.
The reference must stay frozen until you retrain. If the baseline slides along with live traffic, you compare today with yesterday instead of with what the model learned, and a slow drift never shows up.
Test the thresholds before you trust them. In one measured check on real text, PSI at 0.25 fired only when 80 percent of traffic came from the new population. At 40 percent contamination, PSI read 0.081 on 20,000 samples, inside the 'stable' band, while KS caught 40 percent contamination with only 200 samples and 5 percent with 20,000. PSI also depends on sample size: with no drift at all it read 0.047 on 200 samples and close to zero on 20,000.
A lab sent five kinds of new data to a gradient-boosted tree, a model made of many small decision trees, that predicts house prices in California districts from 8 facts about each one. It used the public California housing dataset of 20,640 districts. Each kind of data was sent in 100 batches of 500 rows, with PSI and KS on every column, PSI on the model's own predictions, and the true error measured every time. A batch counted as harmed if its error was more than 10 percent above usual.
Only the most crowded districts: PSI rang on all 100 batches, yet the error fell 9 percent, to $28,577 from $31,277. Population was the column the model used least; shuffling it raised the error by only $493, against $53,302 for latitude. Every price raised 20 percent with inputs unchanged: PSI rang on 0 batches and KS on 4, while the error rose 64 percent to $51,357 and all 100 batches were harmed. That second case is concept drift, and no input monitor can see it.
The alarm and the harm matched in one case. A second model trained only on northern districts was sent southern ones, a region it had never seen. Input alarms rang on all 100 batches and the error rose 290 percent to $111,488. The whole-state model on the same southern rows also rang every time but lost only 4 percent. What told them apart without labels was the prediction monitor: quiet on all 100 batches for the whole-state model, ringing on all 100 for the north-only one.
The only way to see that the answers moved is to look at some answers. The same lab took 50 rows of each batch, looked up their true prices, and rang when the error on those rows was more than 10 percent above usual. It caught the price rise on 99 of 100 batches and the unseen region on 100. With only 20 labelled rows it still caught 93 and 100.
The price is false alarms. On ordinary batches with nothing wrong, the 50-row check rang 23 times and the 20-row check 31 times, because the error on a small sample wobbles: about 15 percent between batches for 50 rows and 25 percent for 20. Loosening the line to 1.2 times the usual error cut false alarms to 10 while still catching 97 price rises.
The wobble follows a standard rule: the spread of an average shrinks with the square root of the number of rows. Going from 20 to 50 rows predicts 0.251 / 1.58 = 0.159, close to the measured 0.155. To halve the wobble you need about four times as many labelled rows. Pick those rows at random, because the answers that arrive first, like the fraud cases reported fastest, are usually not typical.
Treat an input alarm as a question, not a verdict. It says a column moved, not that the model is worse. Rank columns by how much the model depends on them, using permutation importance: shuffle one column and see how much the error rises. A jump in a column the model barely uses is worth a look, and still worth fixing if it means a broken data feed.
Watch the model's predictions as well as its inputs, and label a small random sample of live rows every week. Measure how often each check rings on ordinary data before you wire it to a pager, because an alarm that rings on every harmless shift soon gets ignored. Watch hardest for data the model has never seen, such as a new region or a new kind of customer.
Do not retrain automatically on every alarm. On the crowded-district batches that would have meant 100 retrains for a model that was doing better than usual. A safer loop opens a retrain proposal for a person, retrains on fresh labelled data, keeps the new model only if it beats the old one in evaluation, often tries it on a small share of live traffic first, and then resets the drift reference to the new training data.
Evidently
An open-source Python library that compares a reference dataset with current data and produces per-column drift reports using tests such as PSI and KS.
Amazon SageMaker Model Monitor
An AWS service that runs data quality jobs comparing live inputs with a training baseline, and model quality jobs that merge real labels with saved predictions.
Prometheus and Grafana
Open-source tools often used to store drift scores as time series next to latency metrics and to chart and alert on them.
scikit-learn permutation_importance
A scikit-learn function that shuffles one column at a time and records how much the model's score gets worse, useful for ranking drift alarms.
Data drift is a change in the inputs, such as a new mix of users. Concept drift is a change in the link between inputs and the right answer, such as prices rising for the same houses. In a measured lab, a 20 percent price rise raised error 64 percent while input monitors stayed quiet.
By the common rule, PSI above 0.25 means a large shift in one input column compared with training data. It measures how much the inputs moved, not whether the model got worse. In one lab, PSI rang on every batch of a shift that actually lowered the model's error.
Compare live inputs and live predictions with a frozen reference from training, using tests such as PSI and KS. This is fast and free, but it cannot see concept drift. Adding a small random sample of real answers each week closes that gap, at the cost of some false alarms.
Usually not. Many input shifts do not hurt the model, and a retrain fired by a noisy signal can ship a worse model. Check which column moved and how much the model uses it, confirm harm with real answers, and keep an evaluation gate before any new model goes live.
Skew is a bug where your training and serving code compute a feature differently. Drift is the outside world changing after training, even when the code is identical. Skew is fixed with one shared feature definition; drift is handled with monitoring and retraining.
Feature Store
A single source of truth for features, so training and serving compute them from one definition and cannot drift apart. It ends the train-serve skew bug and lets teams reuse features across models.
Train-Serve Skew
When a feature is computed one way in training and a slightly different way in production, so every prediction is subtly wrong. Nothing crashes, accuracy just leaks away. Feature stores exist to prevent it.
Model Registry
A versioned catalog of trained models with their metadata, stage, and lineage, so you know exactly what is deployed and can roll back. The control plane for shipping models safely.
Model Serving
Exposing a trained model behind an API that answers predictions within a latency budget, with batching, autoscaling, and versioning. Where most of the production cost and the request-path complexity lives.
Feature Engineering
Turning raw data into the signals a model actually learns from. Often the highest-leverage work in a classical ML system, and where a feature store keeps definitions consistent.
Data Lakehouse
A design that keeps data as open files, usually Parquet, in cheap object storage and adds a log on top that makes changes all-or-nothing, checks column types and keeps old versions readable.
This page explains the idea. The "Drift Alarms Against Real Harm: When the Alarm Rings, Is the Model Worse?" lesson builds it up step by step, with diagrams. It is part of the AI Engineering course, which has 210 lessons. 10 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Drift Alarms Against Real Harm: When the Alarm Rings, Is the Model Worse? lessoncourse 2
Take models from notebook to production, with labs on real models.