Part 8 — Production Observability

Drift detection

Measuring production quality·Evaluation·7 min read

A system that was correct at launch can degrade without a single line of code changing, because the world around it moves. This chapter is about drift — the input distribution shifting, the model changing under you, quality sliding — and how to detect it before it becomes an incident, by watching the right things over time.

An LLM system can pass every test at launch and quietly get worse over the following months while its code sits untouched. That's drift: the gradual divergence between the system-and-world you evaluated and the system-and-world you now have. Inputs shift toward things your test set never covered; a hosted model updates under you; quality slides a little each week until it's a problem. Nothing "broke" — the ground moved. Detecting drift is about watching the right quantities over time so you catch the slide while it's still small.

What you will understand by the end

  • What drift is, and the main kinds: input drift, model drift, quality drift.
  • Why drift is dangerous precisely because nothing "broke."
  • How to detect each kind by watching distributions and signals over time.
  • Why drift is the production face of the maintenance problem.

The kinds of drift

  • Input drift. The distribution of requests changes — new topics, new phrasings, new user segments, seasonal shifts. Your system was measured on last quarter's inputs; it's now serving this quarter's, which your test set no longer represents.
  • Model drift. For hosted models, the provider can update the weights under you — same model id, different behaviour — so the system you evaluated is silently replaced by one you didn't.
  • Quality drift. The downstream result of the above: correctness slides over time, showing up in quality signals (edit rates up, sampled scores down) even though no one changed the system.
Key idea

Drift is degradation with no change event to point at — the code is identical, the deploy log is empty, and the system is nonetheless getting worse because the inputs or the model moved beneath it. That's what makes it insidious: there's no commit to blame and no alert designed for it. You only catch drift by comparing the system to its past self, over time.

Detect it by watching over time

Drift is invisible in any single snapshot; it only appears as a trend. So detection means tracking distributions and signals across time and watching for divergence from a baseline:

  • Input drift — monitor the distribution of incoming requests (topics, lengths, embeddings, segments) against a baseline; a growing divergence means production is moving away from what you tested. Cross-check against coverage: drift often pushes traffic into your blind spots.
  • Model drift — for hosted models, track quality signals and a canary set (a fixed set of inputs you re-score periodically); a sudden shift with no deploy of yours points at a provider-side change. (Self-hosting pins the weights and removes this axis.)
  • Quality drift — watch the quality-signal panel over time; a slow slide in edit rate, fallback rate, or sampled score is drift even when each week's move is within noise.
Watch out

Drift hides in the gap between snapshots. A weekly quality dip that's each time "within the noise" can compound into a serious decline over a quarter — no single week trips an alert, but the trend is real. Watch trends against a baseline, not just current-vs-threshold, or slow drift will accumulate under your radar until it's an incident.

Drift is maintenance, seen from production

This is the production-facing twin of Maintaining the evaluation program. There, drift was a reason your test set goes stale; here, it's a thing happening to your live system. The response is the same loop: when you detect input drift, re-sample and refresh the test set so it tracks reality again; when you detect model drift, re-clear the gate on the changed model; when you detect quality drift, open the failing cases and feed them back. Detecting drift in production is what triggers the maintenance that keeps both the system and its evaluation honest.

Observed evidence

This project is a frozen offline snapshot — fixed models (some pinned open weights, some hosted at a point in time) on a fixed 88-task set — so it doesn't experience drift, which is exactly why it can be a stable, reproducible reference. That stability is the offline baseline; the moment the same system serves live, shifting business questions and a hosted model that could change under it would introduce precisely the input and model drift this chapter tracks. The project shows the "before drift" state you measure against. The frozen baseline drift is measured against →

Mental model

Drift is degradation with no change event — inputs shift, a hosted model updates under you, and quality slides while the code sits still. It's invisible in a snapshot and only shows as a trend, so detect it by comparing the system to its past self: track input distributions, a re-scored canary set, and the quality-signal panel over time against a baseline. Detecting drift triggers the maintenance that re-honests the system and its test set.

Common mistakes

  • Assuming a stable system stays correct. Inputs and hosted models move; correctness can slide with no code change.
  • Only checking current-vs-threshold. Slow drift stays "within noise" each week and compounds; watch trends against a baseline.
  • Trusting a hosted model id as stable. The weights can change under you; use a canary set to detect it.
  • Detecting drift but not acting. Drift should trigger refreshing the test set, re-gating the model, and capturing new failures.

Practical guidance

  • Track input distributions over time (topics, lengths, embeddings, segments) against a baseline, and cross-check against coverage blind spots.
  • Keep a canary set you re-score periodically to catch hosted-model drift with no deploy of your own.
  • Watch the quality-signal panel as trends, not snapshots — a slow, in-noise slide is still drift.
  • On detection, run the maintenance response: refresh the representative set, re-clear the gate, and capture new failing cases.

Summary

  • Drift is degradation with no change event — input drift (distribution shifts), model drift (hosted weights change under you), and quality drift (correctness slides).
  • It's dangerous because nothing "broke" — no commit, no alert — and it's invisible in a single snapshot.
  • Detect it by watching input distributions, a canary set, and quality signals over time against a baseline.
  • Drift is the production face of evaluation maintenance; detecting it triggers refreshing the test set and re-gating the model.

Knowledge check

Your system's sampled quality score drops about 1 point each week for two months. Each weekly drop is within the noise. Is there a problem, and what likely kinds of drift could cause it with no code change?

Yes — even though each week is "within noise," a consistent one-directional slide for two months is a real trend (~8 points total) that no single-week threshold would catch; watching current-vs-noise misses it, watching the trend against a baseline reveals it. With no code change, the likely causes are input drift (production questions gradually shifting toward types your system handles worse, possibly into coverage blind spots) and/or model drift (a hosted model being updated under you). Diagnose by comparing the input distribution to its baseline and re-scoring a fixed canary set: if the canary score dropped, it's model drift; if the canary held but production slid, it's input drift. Then refresh the test set / re-gate accordingly.

Why does self-hosting eliminate one axis of drift that hosted models are exposed to?

Because model drift — the weights changing under you while the model id stays the same — is a property of relying on a provider who can update their model whenever they choose. Self-hosting pins the exact weights: the model you deployed is the model you keep running until you decide to change it, so it can't silently change behaviour underneath you. You still face input and quality drift (the world's requests still move), but you remove the provider-side model-drift axis entirely — one of the control advantages that can justify self-hosting for reproducibility- or stability-critical systems.

Related chapters