Model quality degrades without touching a single infrastructure metric
Classical dependencies and models can both return incorrect results without an error. A model fails by returning something plausible and wrong, which every status-code-based metric records as a success. Quality needs its own signals, its own threshold and its own budget, or it is unobservable until a customer complains.
TL;DR: Availability built on HTTP status codes reports 100 percent through an outage where every answer was useless. Detect quality with three layers: a scheduled offline suite for changes you made, online proxy signals for changes you did not, and a sampled review to keep the proxies honest. Then give the primary quality metric a threshold and an error budget so it behaves like any other SLO.
Successful transport can carry a wrong answer
A database can return stale rows, a cache can contain the wrong value and a queue consumer can process a message incorrectly. Availability metrics do not establish business correctness. Models make this distinction especially visible because open-ended output often needs statistical or human evaluation.
A model returns a confident, well-formed, wrong answer. It returns a refusal to a reasonable question. It returns prose where JSON was required. It answers a question nobody asked. All of that is an HTTP 200 with normal latency, and no dashboard moves.
What causes it, and why deploy gates are not enough
Check these possible changes:
- a model version changed, yours or a provider's
- a prompt template was edited three services away
- the retrieval index fell behind, so the model is reasoning over stale context
- someone shipped a quantised build to save money
- a tokeniser or truncation change silently dropped the end of long prompts
- the questions users ask moved away from what the system was tuned for
Only the first few are under your change control. A provider-side change arrives with no deploy of yours, which is why detection has to run on a schedule rather than only in a pipeline.
Three layers
A golden set, run on a schedule. A fixed, versioned collection of representative inputs with known-good expectations, scored automatically and stratified by the segments that matter: long context, each language, each customer tier. Aggregate-only scoring hides the regression that matters, which is usually confined to one stratum.
Online proxies, from real traffic. These move before anyone files a ticket, and the sharpest of them need no labels at all:
- structured-output parse and schema-validation rate
- regeneration or retry rate, which is a user saying the answer was not good enough
- tool-call validity, for anything agentic
- fallback-to-a-larger-model rate, if you cascade
- refusal and empty-answer rate
A sampled review. A small daily sample scored against a rubric, by a person or by a grading model validated against human labels. This keeps the proxies honest, because users adapt to a worse product without complaining.
Establish the noise band before the threshold
Put the unchanged system through the same suite several times and watch how far the score wanders by itself. A score inside that measured range is inconclusive, which is not the same as proof that nothing regressed.
The size of the band surprises people, so compute it. Suppose a golden set of 200 items, scored pass or fail, and the current build passes 184 of them, a pass rate of 184 / 200 = 0.92. Treating each item as an independent trial, the standard error on that estimate is sqrt(0.92 × 0.08 / 200) = sqrt(0.000368) ≈ 0.0192, so about 1.9 percentage points, and a 95 percent interval is roughly ±1.96 × 1.9 ≈ ±3.8 points. A score of 92 on this suite means somewhere around 88 to 96.
So a one-point or two-point movement on a 200-item set carries essentially no information, and this is the arithmetic that should settle most arguments about whether a model got worse. To resolve a 2-point drop against that noise with two independent runs you would need roughly 1,400 items, since the difference of two proportions has about sqrt(2) times the standard error of one, and the sample size scales with the inverse square of the effect you want to see.
There is a way out, and it is why the golden set is fixed and versioned rather than resampled. Run the same items before and after and the comparison becomes paired: most items pass both times or fail both times and carry no information, and what you are actually counting is the items that flipped. A build that turns 9 passes into failures while fixing 1 is strong evidence from 10 informative items, where comparing 92 percent against 90 percent across two different samples would have been worthless. Keep the set fixed, compare item by item, and look at which items moved rather than at the headline average.
Two caveats belong with the arithmetic. It assumes items are independent, and a golden set with several near-duplicate questions violates that and overstates its own precision. And it treats scoring as deterministic, which it is not when generation is sampled or a grading model is involved, so generation variability has to be measured rather than assumed away, usually by rerunning the unchanged build.
Make it an SLO
For a defined per-request quality success criterion, set a target and budget. A noisy mean grader score needs a sampling model and an actionable threshold before it can drive paging; it is not automatically an availability-style burn rate. That converts a vague argument about whether the model feels worse into the same mechanics as availability, and it gives a platform team the standing to block a model change, which is otherwise an argument they lose.
The organisational half
The golden set belongs to whoever owns the product outcome; the pipeline belongs to the platform. A golden set curated by infrastructure engineers drifts away from what the product cares about within a quarter, and a quality gate nobody in product recognises gets overruled the first time it blocks a launch.
Self-check
A nightly golden-set run on 200 items reports a pass rate of 90 percent, down from 92 the night before. Nothing was deployed. Decide whether this is a regression, say what you would look at before deciding, and then say what evidence would justify paging somebody rather than opening a ticket. Work it through before reading on.
On the numbers given, two points on 200 items is not evidence of anything. From the arithmetic above, a 92 percent result on this suite carries a 95 percent interval of roughly plus or minus 3.8 points, so 90 and 92 are indistinguishable, and a run-to-run wander of this size is what an unchanged system produces by itself. Reporting it as a regression trains everyone to ignore the signal, which is the same damage a noisy page does to an on-call rotation.
What makes it decidable is the pairing. Because the set is fixed, you can ask which items changed rather than how the average moved, and that turns 200 numbers into a handful of informative ones. Four items that flipped from pass to fail are four cases to read. If those four are unrelated, scattered across segments and marginal in their scoring, the sensible reading is noise. If all four are long-context inputs, or all four are the same language, or all four broke in the same way, that is a regression confined to one stratum, and the aggregate score was hiding it rather than revealing it, exactly as the golden-set section warns.
Then the causes worth checking, given nothing was deployed here: a provider-side model version change, a prompt template edited in another service, a retrieval index that has fallen behind, or a shifted question mix. The first three arrive without any deploy of yours, which is why the suite runs on a schedule.
On paging, the test is the same one any alert has to pass, and a quality score has a hard time passing it. A page has to be urgent, actionable and need a person now. A two-point golden-set movement is none of the three: it will not get worse while everyone sleeps, and there is no action available at 3am that is better than reading the four failing items in the morning. What would justify a page is a signal that is both unambiguous and actionable, which in practice means the online proxies rather than the suite: a structured-output parse rate falling from 99 percent to 60, or a refusal rate jumping tenfold, are large relative to their own noise, affect users right now, and have an obvious action in rolling back the pinned model version or the prompt.
So the honest split is that the golden set gates changes and files tickets, while the online proxies page. Giving the primary quality metric a threshold and a budget is what makes that split explicit instead of a matter of whoever is arguing loudest.
Next: error budgets and burn rate supplies the mechanics for turning a quality target into something that can page, and alert on symptoms, not causes covers the three conditions a page has to meet.
Tie the evaluation to an exact candidate using model release provenance, including tokenizer, runtime and generation settings alongside weights.
MLOps data contracts follows one source of quality failure: historical features that include information unavailable when production made the prediction.