Monitoring, Drift Detection, and the ML Test Score

Monitoring vs observability

The two words are often blurred, and the distinction matters. Monitoring is watching known signals against known thresholds — latency, error rate, prediction volume, the model monitoring you met in Volume I. It answers questions you thought to ask in advance. Observability is the richer property of having enough instrumentation that you can ask new questions of the running system after something surprising happens — without shipping new code to collect more data.

Model observability instruments the full path — inputs, features, raw predictions, post-processing, and (eventually) outcomes — so a degradation can be diagnosed, not merely detected. The acid test: when accuracy drops, can you slice the failure by segment, feature value, and time without writing new logging? If yes, you have observability; if you must redeploy to investigate, you only had monitoring.

Drift detection: catching the world moving

The signature ML failure has no exception: the code is fine, the model is fine, but the world changed. Drift detection and monitoring watches for two distinct shifts. Data (covariate) drift is a change in the input distribution P(x) — a new device floods in, a feature's units change upstream. Concept drift is a change in the relationship P(y|x) — the same inputs now imply a different correct answer, as when fraud tactics evolve. This is the distribution shift from Volume I, now operationalized as a continuous production signal.

Fix a reference distribution: the training (or a trusted recent) feature distribution.
On a rolling window of live traffic, estimate the current distribution per feature.
Score divergence with a statistical distance (population stability index, KS test, or similar).
Alert when divergence crosses a threshold — and feed the signal to the continuous-training trigger.

D_{\mathrm{KL}}(P\,\|\,Q)=\sum_{x}P(x)\,\log\frac{P(x)}{Q(x)}

Drift as divergence: score how far the live feature distribution P has moved from the fixed reference Q with a statistical distance such as KL divergence.

Building model observability

Concretely, observability means logging, for a sampled fraction of requests, the joined record: input id, feature vector served, model version, raw score, final decision, latency, and — when it arrives — the eventual label. This joined log is the raw material for everything: drift scores, skew checks, slice analysis, and post-hoc model debugging. The art is sampling enough to be statistically meaningful and to capture rare segments, without logging so much that storage and privacy costs explode.

if sample_gate(request_id):           # e.g. 5% + always-log rare segments
    obs.log({
      'request_id': request_id,
      'model_version': version_key,
      'features': served_features,      # enables skew + drift checks
      'score': raw_score,
      'decision': final_action,
      'latency_ms': dt,
      'label': None})                   # joined later when ground truth lands

One joined observability record per sampled request powers drift, skew, and debugging.

Observability also subsumes out-of-distribution detection: rather than asking only 'has the aggregate distribution drifted?', you flag individual inputs that look unlike anything in training. An OOD-flagged request is a signal to abstain, defer to a human, or lower confidence — turning a silent confident error into a visible, handled uncertainty.

D_{M}(x)=\sqrt{(x-\mu)^{\top}\,\Sigma^{-1}\,(x-\mu)}

Out-of-distribution scoring: flag a single input whose Mahalanobis distance from the training feature distribution is unusually large.

Scoring production readiness: the ML test score

How do you know your operational practice is actually good, not just busy? The ML test score is a rubric — popularized by a well-known Google paper — that scores an ML system across four axes: tests for data (schema, distribution, feature ownership), tests for the model (offline metrics, fairness slices, staleness), tests for infrastructure (reproducible training, rollback, integration tests), and monitoring (drift, skew, served-feature health, latency). Each check earns points; the lowest-scoring axis is your weakest link.

The score's value is less the number than the conversation it forces: it makes invisible reliability work visible and comparable across teams, and it surfaces the embarrassing gaps — 'we have great offline metrics but no skew test and no rehearsed rollback' — that incidents would otherwise reveal the hard way. Treat a low score as a prioritized backlog, not a grade.

From alert to action

Monitoring is worthless if an alert just adds to a noisy dashboard nobody reads. Close the loop: each signal must route to a defined response. Input drift past threshold → trigger a continuous training candidate. A guardrail breach on the live model → automated rollback. An OOD spike → raise the abstention rate and page on-call. A skew alert → freeze promotions until the feature paths are reconciled.

We can now version, retrain, release, and watch a model. The final guide widens the lens to the two pressures that dominate real production: cost and scale (serving cheaply under latency SLOs) and trust (governance, audit) — plus the operational twist the LLM era adds on top of all of it.