ML Monitoring & Drift Detection: Keeping Models Healthy in Production

A model deployed today will be wrong in 6 months. Not because the model was badly built, but because the world changes while the model stays fixed. Understanding the three root causes determines what you monitor and how you fix it.

Data drift (input distribution shift): The distribution of input features at serving time diverges from the training distribution. The model was trained on data from users aged 25–34 who primarily used desktop. Now 60% of traffic is from mobile users aged 18–24. Feature distributions like session_duration, device_type, and screen_size have shifted. The model is extrapolating to out-of-distribution inputs. The underlying relationship between features and labels hasn't changed — the model just hasn't seen this type of input.

Fix: Retrain on data that includes the new distribution. The model's architecture and feature set are fine.

Concept drift (target distribution shift): The statistical relationship between inputs and the correct output has changed. A fraud model trained on 2022 fraud patterns becomes less accurate as fraudsters adopt new techniques in 2023. The input features (transaction amounts, merchant types) may look similar, but what constitutes fraud has changed. The feature distributions may look stable, but model accuracy drops.

Fix: Relabeling required. Retraining on new data with updated labels. Sometimes the feature set itself needs rethinking.

Model staleness (domain shift over time): Gradual changes in the world — seasonality, product launches, user behavior evolution — make a model that was calibrated for last year increasingly misaligned. The model isn't 'wrong' in the sense of concept drift, but its weight assignments no longer reflect current reality.

Fix: Regular retraining cadence (weekly or monthly) to keep model weights current.

Population Stability Index (PSI) is the most widely used metric for detecting feature distribution drift. It's symmetric (unlike KL divergence), simple to compute, and produces interpretable thresholds.

Formula: PSI = Σ (P_current - P_reference) × ln(P_current / P_reference)

Where P_current and P_reference are the proportions in each bin of the feature distribution for the current production window vs the reference (training data).

Interpretation thresholds (industry standard, from finance/credit industry):

• PSI < 0.10: No significant shift. Model is stable. No action required.
• 0.10 ≤ PSI < 0.25: Moderate shift. Monitor more closely. Investigate if combined with performance degradation.
• PSI ≥ 0.25: Significant shift. Model is likely operating outside its training distribution. Trigger retraining review.

Implementation:

import numpy as np

def compute_psi(reference: np.ndarray, current: np.ndarray, bins: int = 10) -> float:
    # Bin boundaries from reference distribution
    breakpoints = np.percentile(reference, np.linspace(0, 100, bins + 1))
    ref_counts = np.histogram(reference, breakpoints)[0] / len(reference)
    cur_counts = np.histogram(current, breakpoints)[0] / len(current)
    # Add small epsilon to avoid log(0)
    ref_counts = np.clip(ref_counts, 1e-6, None)
    cur_counts = np.clip(cur_counts, 1e-6, None)
    psi = np.sum((cur_counts - ref_counts) * np.log(cur_counts / ref_counts))
    return psi

Limitation of PSI: PSI measures each feature independently. It cannot detect multivariate drift — where individual features appear stable but their joint distribution has changed. For high-dimensional models, complement PSI with a 'drift classification model': train a binary classifier to distinguish training data from current production data. High AUC of this classifier → multivariate drift exists.

Alternative metrics for specific feature types:

• Continuous features: Kolmogorov-Smirnov (K-S) test (returns p-value), Wasserstein distance
• Categorical features: Chi-squared test, Jensen-Shannon divergence
• High-cardinality categorical: % of new categories in production that didn't appear in training

Concept drift is harder to detect than data drift because it requires labels, which often arrive with delay. A fraud model might be suffering concept drift for 45 days before you know it — because fraud chargebacks take that long to arrive.

Strategy 1 — Delayed label monitoring: For systems with delayed labels (fraud, conversion), batch the evaluation: every Monday, pull labels for events from 45 days ago. Compute Precision@K and AUC-PR on that week's data. Compare to the model's performance at deployment time. If AUC-PR drops > 3% from baseline: trigger retraining review.

Strategy 2 — Proxy label monitoring: For systems with slow labels, identify fast-moving proxy labels that correlate. For e-commerce fraud: chargebacks take 30 days, but customer disputes take 7 days, and merchant blocks often happen within 24 hours. Monitor merchant block rate as a leading indicator. If merchant blocks spike, fraud is rising — retrain before chargebacks confirm it.

Strategy 3 — Behavioral testing / ChallengeSet evaluation: Maintain a handcrafted test set of representative inputs with known correct outputs, updated by domain experts. Evaluate the model on this test set weekly. When a new fraud pattern emerges, add test cases. If the model fails on new test cases before labels arrive in production, trigger retraining.

Strategy 4 — Output-based drift detection: Even without labels, the model's output distribution can signal concept drift. If a fraud model's average predicted fraud probability suddenly drops (model is less certain → fewer flags) while actual fraud volumes (from merchant reports) are stable, the model is becoming underconfident on current data patterns. This triggers an investigation even before labels arrive.

The difference matters for the fix: Data drift → retrain on new distribution, keep the same feature set and architecture. Concept drift → investigate whether the feature set captures the new patterns; may require new features or a fundamentally different model architecture.