Key takeaways
- Every deployed ML model needs monitoring — without it, silent performance decay is invisible until it becomes a business problem.
- Two broad categories of drift: data drift (input distribution changes) and concept drift (the relationship between inputs and outputs changes).
- Ground-truth accuracy is usually delayed, so monitoring relies on proxy metrics — prediction distributions, confidence scores, feature-level statistics, and downstream business metrics.
- Automated alerts + retraining pipelines turn drift detection into closed-loop model maintenance.
- Monitoring tooling ranges from free (Evidently, Prometheus custom metrics) to enterprise SaaS (Arize, Fiddler, WhyLabs, Mona).
Why models decay
A model’s accuracy at the moment of deployment is not a permanent property. Three things erode it over time:
- Input distribution shift — the real-world inputs change. New product categories enter a recommendation system. Seasonal patterns return. A new customer segment starts using the product.
- Concept drift — the rules that map inputs to outputs change. User preferences shift. Fraud tactics evolve. Economic conditions change which features predict default.
- Upstream data pipeline changes — a field is renamed, a data source goes offline, a calculation formula is updated. The model sees something different from what it was trained on, with no one noticing until outputs are wrong.
A model that performs well on a test set is only guaranteed to perform well on data drawn from the same distribution. Production data is rarely stationary. See our mlops primer for the broader operations context.
What to monitor
Prediction distribution
Track the distribution of model outputs over time. If a spam classifier suddenly flags 40% of messages when it historically flagged 5%, something is wrong — either spammers changed tactics, upstream preprocessing changed, or the model broke.
Feature distributions
Track summary statistics (mean, median, standard deviation, null rate, unique-value count) for every input feature. Use statistical tests — Kolmogorov-Smirnov, chi-squared, Wasserstein distance — to quantify drift versus a reference window. Population Stability Index (PSI) is popular in financial services.
Model confidence and calibration
Are predictions becoming less confident? Is the model’s stated probability of class membership still matching actual outcomes (calibration)? Degraded calibration often precedes degraded accuracy.
Ground-truth metrics (when available)
If you can measure accuracy, precision, recall, AUC, RMSE, or business-specific metrics, do so continuously. In most production systems ground truth arrives with a lag — a week after a loan decision you learn whether the borrower repaid; a month after a product recommendation you learn whether it drove a repeat purchase.
Proxy business metrics
Downstream metrics often move before explicit accuracy drops. Recommendation click-through rate, conversion rate, customer-support escalation rate, fraud-case resolution time — changes in these signal model issues even when direct metrics lag.
System metrics
Request latency, error rate, throughput, GPU/CPU utilization, cost per query. These are DevOps metrics but matter equally for ML — a model that runs on a stuck cache or overloaded GPU gives bad user experience regardless of accuracy.
Detecting drift
Statistical tests
Compare a recent window of feature values to a reference window (typically the training distribution). Statistical tests quantify how different they are. Set thresholds — if the PSI on “user_age_bucket” exceeds 0.25, fire an alert.
Density-based methods
Kernel density estimation, isolation forests, or density-ratio estimation can flag multivariate drift that univariate tests miss. Used selectively — they are heavier compute.
Model-based drift detection
Train a classifier to distinguish “is this sample from the reference distribution or the current one?”. If it works well, there is drift; if it can’t tell, there isn’t. This catches drift that statistical tests miss but adds complexity.
Ground-truth degradation
When ground truth becomes available, track accuracy over time windows. A sustained decline versus the training baseline is the strongest drift signal — but also the most delayed.
Alerting strategy
Drift metrics generate a lot of noise. Every feature drifts a little; most does not matter. Thresholds must be tuned — too tight and you drown in false alarms; too loose and real problems are missed. Multi-layer alerting helps: minor drift logs silently, moderate drift notifies the owning team, major drift pages on-call.
Alerting should point at actions. “Feature X drift exceeded threshold” is a fact; “consider retraining, here’s the drift dashboard and last retraining date” is an action. Dashboards linking directly from the alert to the relevant data reduce mean-time-to-action.
Response patterns
Investigate first, retrain second
Not every drift requires retraining. A pipeline bug that should be fixed. A temporary blip that will self-correct. A known seasonal pattern the model already handles. Investigate before retraining — otherwise you retrain on corrupted data and make things worse.
Scheduled retraining
For slowly-drifting domains, retraining on a fixed cadence (weekly, monthly) keeps the model current without needing drift-triggered logic. Many teams pair this with monitoring — a monthly retrain is the default, drift alerts can trigger faster retrains.
Automated retraining pipelines
For mature setups, drift triggers an automated pipeline: retrain, evaluate on a held-out set, compare to the current deployed version, promote if better, alert if degraded. Full automation demands strong CI gates — you do not want an adversarially-poisoned retrain auto-deploying.
Rollback and canaries
When a newly-deployed model misbehaves, roll back fast. Canary releases (new model serves a small fraction of traffic) and shadow deployments (new model runs alongside old, predictions compared) catch regressions before full rollout. See our model training guide for pre-deployment evaluation.
Monitoring for LLMs
LLM monitoring extends classical ML monitoring with new metrics. Latency and token cost per query matter for cost control. Quality metrics — human or model-as-judge ratings, embedding-based similarity to reference answers — replace classification accuracy. Safety metrics (harmful content rate, PII leakage) and security metrics (prompt-injection detection rate) are LLM-specific. Tools like LangSmith, Humanloop, Helicone, and PromptLayer specialize in this space.
Common pitfalls
- Monitoring everything, alerting on nothing. Metrics fill dashboards no one reads. Pick a small set of metrics with clear thresholds and owners.
- Reference-window mismatch. Using the whole training set as the reference masks slow drift. Rolling windows (last 30 days vs. previous 30 days) surface changes more clearly.
- Ignoring null-rate drift. A feature with suddenly 80% missing values is a major upstream pipeline problem, often overlooked because “missing” is treated as normal.
- Retraining on bad data. If monitoring fired because an upstream data source is corrupted, retraining incorporates the corruption. Human review before auto-retrain is a common safeguard.
Getting started
For a team starting fresh, a pragmatic minimum: log all model inputs and outputs with timestamps; compute daily feature summary statistics and prediction distribution statistics; set simple thresholds on feature null rates and prediction mean; alert a slack channel when thresholds breach. This is buildable in a week on top of any production data warehouse. Add drift tests, ground-truth tracking, and automated retraining incrementally. See our machine learning primer for the underlying fundamentals.
Frequently asked questions
How often should I retrain my model?
It depends on how fast the data changes. Spam filters retrain daily. Fraud models retrain daily to weekly. Recommendation systems often retrain daily or continuously on user interactions. Credit scoring models in regulated settings retrain quarterly with full revalidation. Use monitoring to inform cadence — if drift metrics are small between scheduled retrains, you probably could retrain less often.
Is model monitoring the same as software observability?
Overlapping but not the same. Observability gives you system-level signals — latency, error rate, throughput — which you need for any service. Model monitoring adds ML-specific signals around drift, predictive quality, and calibration. Mature teams run both, often in integrated dashboards.
What if my ground-truth labels arrive weeks late?
Very common in credit, insurance, fraud, and health. Strategies: use proxy metrics that respond faster (downstream business metrics, confidence scores, user-behaviour signals); backfill labels and recompute accuracy retrospectively; use change-point detection on predictions to catch drift even without labels. Accept that you will sometimes discover model problems after the fact and plan for fast remediation rather than perfect prevention.
