Describe how to integrate LLM evaluation into a CI/CD pipeline as a quality gate. What components are needed, how is the regression threshold set, and what happens when the gate fails?
Free · 2 AI evals / day
A **CI/CD eval gate** is the LLM version of a unit-test gate. In normal code, the pipeline runs tests on every pull request and refuses to merge if they fail. For an LLM feature, the equivalent of a test failing is a quality regression: the new prompt or model scores worse on a fixed set of examples than the version already in production.
The gate has a few moving parts. A trigger decides when it runs: only on pull requests that touch a prompt template, a model setting, or a system prompt, not on frontend or infrastructure changes. A frozen golden set of 100 to 500 examples lives in the repository so every run grades the exact same questions. An eval run applies the change, scores the golden set with the same judge used in production, and compares against the baseline score from the main branch.
The hard part is deciding when a drop is real. Eval scores wobble run to run because judges are not perfectly stable. So you do not block on any drop, you block only when the drop is bigger than that normal wobble and statistically significant.
When the gate fails it blocks the merge, posts a report of which examples got worse, and lets a human override after review.
**A CI/CD eval gate** treats quality like a test suite. It runs on pull requests that touch a prompt template, model config, or system prompt. Frontend and infra changes skip it.
The gate needs a frozen golden set. That is a version-controlled set of 100 to 500 examples checked into the repo. Freezing it is non-negotiable. If you refresh the set each run, a score change could mean the model regressed or the questions got harder. You cannot tell which.
The run applies the candidate change. It scores the golden set with the same judge and rubric as production. It compares to the baseline score stored from the main branch.
The regression test is statistical, not a raw delta. Judges wobble a few points between runs. So you use McNemar's test or a bootstrap confidence interval. You block only when the drop clears your threshold and is significant.
Set the threshold relative to noise. Measure run to run variance first. Start the gate at roughly twice that variance, then tighten as the pipeline stabilises. Use stricter per-slice thresholds for high-stakes query types.
On failure the gate blocks the merge, posts which examples and slices regressed, and requires a human override. After merge, a canary eval in staging acts as a second gate before full rollout.
Quick reference
TL;DR
Trigger on prompt or model changes, score a frozen golden set against a stored baseline, and block the merge only when the drop beats both run to run noise and a significance test.
Think of a factory line that bottles soda. Before any recipe tweak ships, you pour a fixed set of 200 sample bottles and have the same taste-tester rate them. You keep last week's scores written down. If the new recipe scores clearly worse, the line stops and a person has to look before it restarts. The trick is the taste-tester is a little moody day to day, so you only stop the line if the new batch is worse by more than that normal moodiness, and worse on enough bottles that it is not just a fluke. You never swap the sample bottles between tests, otherwise you cannot tell whether the recipe got worse or the bottles just got harder. After the line restarts you also watch a few real customers quietly before serving everyone.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Very early prototype where the prompt changes hourly and no baseline exists yet A gate needs a stable baseline and a curated golden set. Without them it blocks everything and stalls iteration.
Changes that cannot affect model output, like styling or logging only diffs Running an expensive judge eval on inert changes wastes budget and slows the pipeline for zero signal.
Deliberate quality jumps where the new behavior is intended to differ from baseline The old baseline is no longer the right reference. Re-baseline first, otherwise the gate flags an improvement as a regression.
Pure latency or cost regressions with quality held constant Those are better caught by performance gates and budget alerts than by a quality judge eval.
Quick scan · 2–4 min
Everything important, quickly.
6 min: trigger scope, frozen golden set, the statistical regression test, threshold versus trend, flaky-judge handling, on-failure behavior, golden-set maintenance, and the staging canary as the second gate.
Real-world examples
Real products, models, and research that use this idea.
1Promptfoo runs as a GitHub Action that scores a checked-in eval set per PR and fails the check on a configured regression threshold.
2LangSmith and Braintrust both store baseline scores as artifacts and surface per-example regression diffs against the main branch run.
3OpenAI Evals lets teams register a frozen eval set and compare candidate prompt or model scores against a recorded baseline in CI.
4DeepEval ships pytest-style assertions so eval failures fail a CI job exactly like a unit test, with per-metric thresholds.
5Anthropic and OpenAI internally gate prompt and model changes on stratified golden sets plus staged canary rollout before full exposure.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you keep a flaky judge from blocking a clean PR or passing a real regression?
Sign in or go Pro to see the approach for this follow-up.
QWhy is trend tracking across merges needed if each PR already passes a threshold gate?
Sign in or go Pro to see the approach for this follow-up.
QHow do you maintain the golden set without invalidating historical comparisons?
Sign in or go Pro to see the approach for this follow-up.
QHow do you balance gate strictness against shipping velocity?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Gating on a raw score drop with no significance test. Judge noise alone produces a few points of wobble, so a naive threshold either blocks clean PRs or waves through real regressions.