Monitoring a deployed model for drift: inputs, outputs and delayed labels

Goal

Detect, before users do, that a deployed model has stopped behaving as its test score promised, and distinguish the three causes: the inputs changed, the serving pipeline computes features differently from training, or the world changed so that the same inputs now mean different outcomes.

Prerequisites

A reference sample of training features and predictions stored with the model version; serving code that logs, per prediction, the model version, the feature vector as served, the output and a request identifier; and a path by which true outcomes arrive later with the same identifier.

Steps

1. Log the features exactly as the model saw them at serving time. Google's Rules of Machine Learning defines training-serving skew as a difference between performance during training and during serving, names pipeline discrepancies and data changes as causes, and advises saving the set of features used at serving time and piping them to a log for training, so that consistency between serving and training can be verified.
2. Compare, per feature and per time window, the served distribution with the training reference: for numeric features a two-sample test such as the Kolmogorov-Smirnov test (scipy.stats.ks_2samp compares the underlying continuous distributions of two independent samples) or a distance between binned histograms; for categorical features the frequency of each value and the share of unseen values.
3. Compare the prediction distribution (score histogram, positive rate) with the reference in the same way; a shift here with unchanged inputs points at the serving pipeline.
4. When labels arrive, join them by request identifier and compute the offline metric over the window the labels cover; plot it next to the input-drift signals with the known lag.
5. Alert on sustained shifts, not single windows, and keep the thresholds per feature in configuration with the model version.
6. On a confirmed shift, decide between retraining on recent data, fixing the pipeline discrepancy, or rolling back; record the decision with the evidence.

Expected result

A dashboard per model version with feature drift, prediction drift and lagged true performance; skew caused by pipeline differences is separated from genuine change in the data.

Limits and test basis

Distribution tests on large windows flag tiny, harmless shifts; the threshold is a judgement per feature. Drift in inputs does not prove a drop in performance, and performance can drop without visible input drift. Label delay bounds how fast real degradation can be confirmed. No detection rates are claimed.