Model Monitoring in Production:...

Drift Happens Slowly, Then All At Once

Model monitoring in production is the least glamorous part of machine learning, and it's the part that determines whether your model is actually useful or just occupying a GPU. I've watched teams spend months on model architecture and training optimization, then deploy with no monitoring at all. The model works great for six weeks, then performance silently degrades while everyone assumes it's still fine.

The fundamental challenge is that ML models fail differently than software. Software fails loudly — exceptions, error codes, crashed processes. Models fail quietly. They keep producing outputs that look reasonable but are increasingly wrong. By the time someone notices, you've been serving bad predictions for weeks.

What to Monitor and How to Prioritize

Not all drift signals are equally important. Focus monitoring effort in this order: input data quality (garbage in, garbage out), feature distribution drift (the world changed), prediction distribution shifts (the model's behavior changed), and actual performance metrics (the model is wrong).

Input data quality monitoring catches problems before they reach the model. Missing features, out-of-range values, and schema changes are all detectable at inference time with minimal overhead.

class InputMonitor:
 def __init__(self, schema_path, baseline_path):
 self.schema = load_schema(schema_path)
 self.baseline = load_baseline_stats(baseline_path)
 self.window = RollingWindow(size=10_000)
 self.metrics = PrometheusMetrics()

 def check(self, features: dict) -> MonitorResult:
 result = MonitorResult()

 violations = self.schema.validate(features)
 if violations:
 self.metrics.schema_violations.inc(len(violations))
 result.add_warning("schema", violations)

 null_count = sum(1 for v in features.values() if v is None)
 null_rate = null_count / len(features)
 self.metrics.null_rate.observe(null_rate)

 if null_rate > self.baseline.null_rate_p99:
 result.add_warning("null_rate", {
 "observed": null_rate,
 "threshold": self.baseline.null_rate_p99,
 })

 self.window.add(features)
 return result

Distribution Drift Detection

Feature distributions shift for many reasons. Seasonal patterns, product changes, user behavior evolution, upstream data pipeline modifications. Not all shifts require model retraining — some are expected and the model handles them fine. The monitoring system needs to distinguish between normal variation and problematic drift.

We use a two-tier approach. Statistical tests (Population Stability Index for categorical features, Kolmogorov-Smirnov for continuous features) run on hourly windows and flag features whose distributions have shifted beyond a threshold. Then a secondary check examines whether the shifted features are actually important to the model. A feature with zero importance can drift wildly without affecting predictions.

import numpy as np
from scipy import stats

def compute_psi(expected, actual, bins=10):
 breakpoints = np.percentile(expected, np.linspace(0, 100, bins + 1))
 breakpoints[0] = -np.inf
 breakpoints[-1] = np.inf

 expected_counts = np.histogram(expected, breakpoints)[0] / len(expected)
 actual_counts = np.histogram(actual, breakpoints)[0] / len(actual)

 expected_counts = np.clip(expected_counts, 1e-6, None)
 actual_counts = np.clip(actual_counts, 1e-6, None)

 psi = np.sum((actual_counts - expected_counts) *
 np.log(actual_counts / expected_counts))
 return psi

def check_feature_drift(baseline_data, current_data, features, threshold=0.2):
 drift_report = {}
 for feat in features:
 psi = compute_psi(baseline_data[feat], current_data[feat])
 if psi > threshold:
 ks_stat, ks_pval = stats.ks_2samp(
 baseline_data[feat], current_data[feat]
 )
 drift_report[feat] = {
 "psi": round(psi, 4),
 "ks_statistic": round(ks_stat, 4),
 "ks_pvalue": round(ks_pval, 6),
 "severity": "high" if psi > 0.5 else "medium",
 }
 return drift_report

A PSI above 0.1 means noticeable drift. Above 0.25 means significant drift that probably warrants investigation. Above 0.5 means the distributions look nothing alike and you should be worried. These thresholds aren't universal — they depend on your model's sensitivity to individual features — but they're reasonable starting points.

For a related perspective, see Model Registry Architecture and Versioning for Multi-Team Or.

Prediction Monitoring

Even when input distributions are stable, the model's output distribution can shift. This happens when the model is extrapolating into regions of the feature space it didn't see during training, or when the relationship between features and the target has changed (concept drift).

We track prediction distribution statistics — mean, variance, percentiles — on rolling windows and alert when they diverge from baseline. The alert threshold depends on the use case. A fraud model that suddenly starts flagging 30% of transactions instead of 2% needs immediate attention. A recommendation model whose average score shifts by 0.05 can wait for the next business review.

Performance Monitoring with Delayed Labels

The hardest part of model monitoring is that ground truth labels arrive late. A fraud model predicts whether a transaction is fraudulent at transaction time, but the actual fraud determination might not happen for 30 to 90 days. You can't wait three months to find out your model broke.

Proxy metrics bridge the gap. For fraud detection, we monitor the model's false positive rate against manual review outcomes (available within days) as an early indicator. For recommendations, click-through rate serves as a noisy but timely signal. The key is identifying metrics that correlate with model quality and arrive fast enough to be actionable.

When delayed labels do arrive, we run retrospective performance analysis. This weekly batch job computes the actual metrics and compares them against what the proxy metrics predicted. If the proxies consistently disagree with actual performance, the proxy metrics themselves need recalibration.

Alert Design and Fatigue Management

The biggest risk in model monitoring isn't missing a problem. It's creating so many alerts that the team ignores them all. Alert fatigue kills monitoring systems faster than any technical limitation.

We use three alert tiers. Critical alerts page the on-call engineer and indicate the model should be rolled back immediately — things like serving errors, extreme prediction distribution shifts, or data pipeline failures. Warning alerts go to Slack and should be investigated within a business day — moderate drift, proxy metric degradation, or data quality anomalies. Informational alerts go to a dashboard and get reviewed weekly — minor drift, feature importance shifts, or training data volume changes.

Each alert includes context: what metric triggered it, what the current and expected values are, which features or data sources are involved, and a link to the runbook for investigation. An alert that says "drift detected" is useless. An alert that says "feature merchant_category PSI=0.47, baseline=0.02, top drifted categories: online_gaming (+340%), crypto_exchange (+89%)" tells the engineer exactly where to start looking.

Building the Monitoring Stack

You don't need a specialized ML monitoring platform to start. Prometheus for metrics, Grafana for dashboards, and a Python service that computes drift statistics on a schedule will get you 80% of the way there. The specialized platforms (Evidently, WhyLabs, Arize) add nice-to-have features like automatic drift detection, explainability integration, and pre-built dashboards, but the core monitoring logic is straightforward enough to build in-house.

What matters more than the tooling is the operational discipline. Someone needs to own the monitoring dashboards and actually look at them. Weekly model health reviews — fifteen minutes per model, looking at drift trends, prediction distributions, and any alert patterns — catch slow degradation that no automated threshold will flag. It's boring work, but it's the difference between catching a problem in week three and catching it in month three.

Concept Drift vs Data Drift

People use "drift" as a blanket term, but there are two distinct phenomena that require different responses. Data drift means the input distribution changed — users are behaving differently, or a data pipeline modification altered the feature values. The model might still be correct for the original distribution; it's just seeing unfamiliar inputs.

Concept drift means the relationship between inputs and outputs changed. The same input features now map to a different correct answer because the underlying world changed. A fraud model trained before a new payment method launched will have concept drift when that payment method introduces new fraud patterns the model never saw.

The distinction matters because the response is different. Data drift might be addressed by retraining on recent data, expanding the training set, or adjusting feature engineering. Concept drift usually requires a model architecture change or a fundamental rethinking of the feature set, because the old patterns are no longer valid regardless of how much new data you collect.

We detect concept drift by comparing the model's error rate on recent data against its error rate on the original test set, conditioned on the same input distribution. If the error rate increases even when the input distribution is stable, concept drift is the likely culprit. This requires delayed labels, so the detection is inherently slower than data drift detection — typically weeks rather than hours.

Automated Retraining Triggers

When drift exceeds your threshold, somebody needs to decide whether to retrain the model. Fully automated retraining sounds appealing but introduces risks — if the data quality issue that caused the drift also corrupts the retraining data, you'll train a model on bad data and deploy it automatically.

Our approach is semi-automated. Drift alerts trigger a retraining pipeline that runs in shadow mode — it trains a new model and evaluates it against the current production model, but doesn't deploy it. A human reviews the comparison and decides whether to promote the retrained model. This adds a day or two of latency to the retraining response, but it prevents the worst-case scenario of automated deployment of a model trained on corrupted data.

For models where a day of latency is unacceptable, we allow automated retraining with additional safeguards: the retraining pipeline includes stricter data quality gates, the new model must pass all quality gates with wider margins than usual, and it deploys through a canary rollout instead of a full cutover. These extra checks reduce the risk enough that automation is acceptable for time-sensitive models.

Model Monitoring in Production: Detecting Data Drift and Performance Degradation