A model that performs well at deployment will inevitably degrade over time. The world changes, but the model is frozen at training time. Data drift: the statistical distribution of input features shifts. A retail demand model trained on in-store sales data performs poorly when online sales surge. Concept drift: the relationship between inputs and outputs changes. A spam filter becomes less accurate as spammers adapt their techniques. Upstream data changes: a feature pipeline breaks, a data source changes format, or a third-party API returns different values. Without monitoring, you won’t know your model is degrading until users complain or business metrics drop — which could be weeks or months later.

Data drift detection compares the distribution of production data against a reference dataset (typically training data or a recent baseline). Statistical tests used depend on data type and size: Kolmogorov-Smirnov (KS) test — compares cumulative distributions of numerical features (best for small datasets, ≤1,000 samples). Jensen-Shannon divergence — measures distance between two probability distributions (works well for larger datasets). Wasserstein distance — measures the “earth mover’s distance” between distributions (sensitive to shape changes). Chi-squared test — compares categorical feature distributions. Population Stability Index (PSI) — popular in finance, bins the distribution and measures divergence. A feature is “drifted” if the test statistic exceeds a threshold (e.g., p-value < 0.05).

Concept drift is harder to detect because it requires ground truth labels, which are often delayed (fraud labels arrive weeks later, medical outcomes take months). Strategies: Direct monitoring — when labels are available, track model accuracy, precision, recall, and F1 over time. A sustained drop signals concept drift. Prediction drift — when labels are unavailable, monitor the distribution of model predictions. If the model suddenly predicts “fraud” 3x more often, something changed. Proxy metrics — use business metrics as proxies (conversion rate, customer complaints, escalation rate). Window comparison — compare model performance on recent data vs. older data using a sliding window.

Evidently AI is the most popular open-source tool for ML monitoring. It provides pre-built reports (visual dashboards for data drift, model quality, target drift) and test suites (automated checks that pass/fail). Key features: Data Drift Report — compares reference and current data distributions for all features, auto-selects appropriate statistical tests. Data Quality Report — checks for missing values, duplicates, out-of-range values, new categories. Model Performance Report — tracks accuracy, precision, recall, F1, AUC over time. Test Suites — define pass/fail conditions (e.g., “no more than 30% of features should drift”) for CI/CD integration. Evidently works as a Python library, generates HTML reports, and integrates with Grafana for real-time dashboards.

Monitor at three levels: Infrastructure metrics — CPU/GPU utilization, memory, request latency (p50, p95, p99), throughput (requests/second), error rates. Use Prometheus + Grafana. Model metrics — prediction distribution, confidence scores, feature distributions, model accuracy (when labels available). Use Evidently, Arize, or Fiddler. Business metrics — conversion rate, revenue impact, user satisfaction, escalation rate. These are the ultimate measure of model value. Connect model predictions to business outcomes. Set up dashboards for each level and alerts for anomalies. The most common mistake is monitoring only infrastructure and ignoring model and business metrics.

Bad alerting is worse than no alerting — alert fatigue causes teams to ignore real problems. Design alerts with severity tiers: P0 (page immediately) — model serving is down, error rate > 5%, latency > 10x baseline. P1 (ticket, fix today) — significant data drift (> 30% features), model accuracy dropped > 10%, data quality check failed. P2 (review this week) — moderate drift (10–30% features), slight accuracy decline, cost anomaly. P3 (informational) — minor drift, new feature values observed, usage patterns changed. Use anomaly detection on metrics rather than static thresholds — a 2% accuracy drop might be normal variance or a catastrophic signal depending on context.

When drift is detected, follow a structured response: 1. Diagnose — is it data drift, concept drift, or an upstream data issue? Check data quality first (a broken pipeline is more common than real drift). 2. Assess impact — is the model still performing acceptably? Check business metrics. Minor drift with no accuracy impact may not need action. 3. Choose response: Retrain (most common) — retrain on recent data. Use continuous training if drift is frequent. Recalibrate — adjust decision thresholds without retraining (e.g., change fraud threshold from 0.5 to 0.6). Fallback — switch to a simpler, more robust model or rule-based system. Pause — stop serving predictions if risk is too high. 4. Validate — confirm the fix works on recent data before deploying.

LLMs present unique monitoring challenges: No ground truth — there’s no “correct answer” for most LLM outputs, so traditional accuracy metrics don’t apply. Non-deterministic — the same input can produce different outputs. Provider changes — OpenAI and Anthropic update models without notice, changing behavior. Prompt sensitivity — small prompt changes cause large output changes. What to monitor: output quality (LLM-as-judge scores, user feedback), safety (toxicity scores, PII leakage), hallucination rate (claims not grounded in source documents), cost per interaction, latency (time to first token, total generation time), and user engagement (completion rate, follow-up questions, thumbs up/down).