Model Monitoring in Production

TL;DR: A model can be up, fast, and silently wrong, no error is thrown when it produces a plausible-but-wrong answer, so monitoring uptime and latency is not enough. Monitor four layers: operational (latency, errors, cost), data/input (schema, missing values, drift), prediction (output distribution, confidence), and model quality (accuracy and business metrics, once labels arrive, which lag). Inputs and predictions are leading indicators you can watch without labels; the quality metric confirms later. Wire alerts into investigation and retraining.

Why ordinary monitoring misses it

A normal service is "healthy" if it is up and responsive. A model adds a failure mode ordinary monitoring cannot see: it keeps responding confidently and wrongly as the world drifts or a feature breaks. And the true quality signal (accuracy) needs labels, which often arrive late. A loan-default model only learns it was wrong when the loan matures months later; a fraud model gets a chargeback weeks after the transaction. So you monitor multiple layers and use early signals as proxies for quality before labels confirm it.

The four layers

1. Operational (table stakes): latency (TTFT and inter-token latency for LLMs), throughput, error rates, resource use, and cost. Necessary but not sufficient.
2. Data/input: schema/type validity, null rates, volume, and feature drift vs training. A broken or shifted upstream feature is a top, silent failure (training-serving skew, see feature store). Label-free.
3. Prediction/output: the model's score/class distribution over time and confidence. A sudden shift is an early warning, also label-free. For LLMs: refusal rates, guardrail trips, format validity, hallucination signals.
4. Model quality/outcome: accuracy/AUC and business KPIs, the real thing, but only once ground truth arrives. Track per-segment so a slice can be caught degrading under a healthy aggregate.

The point of the lower layers is timing, not redundancy. They alarm days or weeks before the quality metric can:

Closing the loop

Set alerts on sustained, significant changes per layer, not single-batch noise. A worked example for the prediction layer: the daily share of "approve" decisions sits at a stable 0.42 with a day-to-day standard deviation around 0.01. A jump to 0.55 is roughly thirteen sigma, page immediately; a drift to 0.45 over two weeks is the slow burn you catch with a Population Stability Index on the score distribution (PSI above ~0.2 is the usual "investigate" line). Wire alerts into investigation, retraining triggers, and rollback criteria. Monitoring feeds and is fed by evals: every production failure becomes a test case. Capture enough (via observability) to compute these signals, balanced against privacy.

Why interviewers probe this

Silent model decay is invisible to ordinary monitoring, so "how do you know your deployed model is still good?" tests whether you monitor the right layers. A strong answer rejects "latency and uptime," lays out the four layers (operational, data, prediction, quality), explains that inputs and predictions are leading indicators while labels lag, and ties alerts to retraining and rollback with per-segment tracking. The follow-up they hold in reserve is "your accuracy looks fine but a regulator-relevant slice is failing, how would you have caught that?" The answer is per-segment quality plus prediction-distribution drift on that slice.

Common misconceptions

• "Uptime and latency mean it is healthy." A model can be up and silently wrong; monitor data, predictions, and quality.
• "Wait for accuracy to drop." Labels lag by days to months; use input and prediction drift as leading indicators.
• "Aggregate metrics are enough." A slice can degrade under a healthy aggregate; monitor per-segment.
• "Detecting drift is the end." Wire alerts into investigation, retraining, and rollback.

Key takeaways

• Monitor four layers: operational, data/input, prediction, and model quality.
• A model can be healthy operationally yet silently wrong, so input and prediction signals are leading indicators while labels lag.
• Track per-segment to catch slice degradation under a good aggregate.
• Wire alerts into investigation, retraining, and rollback; feed failures back into evals.