Order the stages of a production LLM quality assurance pipeline from development to release
- 1Online metric monitoring in full production
- 2Staging canary eval on a representative traffic slice
- 3Pre-merge CI quality gate blocking regression
- 4Prompt or model change is made by an engineer
- 5Offline golden set eval against a frozen test set
- 6A/B test or shadow deployment measuring real traffic quality
A change climbs an exposure ladder: engineer edit, offline eval, CI gate, staging canary, A/B test, then continuous full production monitoring.
Imagine test-driving a new bus route before letting passengers ride. First the planner sketches the route on paper, which is the engineer's change. Then they drive it empty against a checklist of known stops, which is the offline eval. Next a supervisor signs off before it can go live, which is the CI gate. Then they run one quiet trip with a few volunteers, which is the canary. Then half the buses use the new route while half keep the old one, so you can compare results, which is the A/B test. Finally, once it works, every bus uses it and you watch the daily ridership dashboards forever, which is production monitoring. Each step costs more and exposes more real riders, so you never jump to crowded rush hour before the empty test drive.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
A production LLM quality pipeline is the path a single prompt or model change takes from a developer's branch to full production rollout, with an evaluation gate at every step. The whole design rests on one ordering principle: escalating user exposure. Each stage costs more compute and touches more real users than the one before it, so you arrange them to fire the cheapest, zero-exposure checks first and the most expensive, highest-exposure ones last.
This question gives six stages out of order. Recovering the correct sequence is really about recognising that exposure and cost rise monotonically across the pipeline. The deep dive walks each stage, explains what unique signal it provides, and shows why the common inversions, like evaluating after shipping or skipping the canary, are exactly how silent regressions reach users.
The pattern is the same loop that mature software teams use for deployment safety, adapted for a system whose output quality is fuzzy rather than a crisp pass or fail. Because you cannot string-match an LLM answer against a single correct value, each gate substitutes a different proxy for quality: automated metrics and an LLM judge offline, then real user behaviour online. The ordering exists so that the weaker, cheaper proxies filter out obvious regressions long before the strong, expensive proxies are spent on them.
The ordering principle: exposure escalation
Every stage in the pipeline can be ranked by how many real users a bad change would touch if it slipped through. An offline eval touches zero users. A staging canary touches a tiny representative slice. An A/B test touches a partial, controlled fraction. Full production touches everyone. The pipeline is simply that exposure ladder, climbed from bottom to top.
The cost axis tracks exposure closely. Offline eval is the cheapest signal you can buy, a handful of API calls on a fixed set. Canary and A/B add real serving infrastructure and the opportunity cost of exposing a possibly worse version to users. Production monitoring runs forever, so its cost is unbounded over time.
Once you internalise that both cost and risk rise monotonically, the order is forced. You always pay the cheap, safe checks first, because catching a regression on the offline set is free compared with catching it after it has degraded a million live sessions.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- LangSmith and Braintrust both wire offline golden-set eval into CI as a pre-merge gate that blocks on score regression.
- Promptfoo runs a frozen eval suite locally and in CI before any prompt change is allowed to merge.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you keep the offline golden set from going stale as production traffic shifts?
Periodically sample fresh production queries, label them, and fold them into the frozen set on a cadence. Track per-stratum coverage so new query types do not slip through. The monitoring stage feeds this refresh loop.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Running the offline eval after deploy, or skipping the staging canary, so a regression reaches real users before any cheap automated gate had a chance to catch it.
60 second bullets to scan on the way to the call.
The ordering principle behind a production eval pipeline
Offline golden-set eval and what a frozen test set buys you
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.