A production classifier that once scored well on live traffic is now less accurate week after week, even though the training code has not changed. Practitioners often label this degradation model drift. Which factor most commonly drives model drift?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal: if your model was fine last quarter and is stumbling now—and you didn't retrain or rewrite anything—you're probably looking at model drift. Think of it like a GPS map that was accurate when you bought it, but the city keeps adding roads. The map didn't break; the world moved. Same idea in ML: the live data distribution or the relationship between features and labels drifts away from what the model saw at training time. Exam trap? People blame architecture or hyperparameters. Those matter for initial quality, but they don't explain a slow fade after launch. When the boss asks why accuracy tanked, talk monitoring, data shifts, and retraining—not 'we needed more layers.' Got it? Sweet. Track production inputs and labels so you catch drift before customers do.
Full explanation below image
Full Explanation
Model drift (often discussed alongside concept drift and data drift) describes a decline in predictive quality after deployment when the conditions the model faces no longer match the conditions under which it was trained. The defining cause is change in the underlying data-generating process: feature distributions shift (data drift), the mapping from features to targets changes (concept drift), or both. Examples include new user behaviors, seasonal demand patterns, policy or product changes, sensor aging, and adversarial or population shifts. Because the trained parameters still encode an older world, error rates, calibration, and fairness metrics can all worsen even if training code, architecture, and hyperparameters remain fixed.
Under-capacity architectures and poorly tuned hyperparameters are important sources of weak models, but they typically manifest as poor performance from the first evaluation onward rather than as progressive degradation after a period of success. Excess training data is also a weak explanation for drift; larger, representative corpora usually reduce variance and improve generalization, though they do not freeze the future against distributional change.
Operational best practice is to treat drift as an MLOps concern: monitor input statistics, prediction confidence, and (when available) delayed ground truth; set alerts on metric decay; and plan periodic revalidation or automated retraining pipelines. Techniques such as sliding-window retraining, online learning, domain adaptation, and human-in-the-loop review help keep models aligned with reality. On certification exams, associate gradual post-deployment accuracy loss with changing data or relationships—not with static design choices made only at training time. Remember the triad: detect (monitoring), diagnose (data vs. concept drift), and remediate (refresh data, retrain, or redesign features). That framing separates drift from ordinary underfitting, overfitting, or one-shot hyperparameter mistakes and matches how production ML teams actually respond when live performance slides.