The pattern that ties this whole track together
An eval gate is a job in your deploy pipeline that runs the eval suite against the candidate version and refuses to promote it if any agreed metric regressed.
The shape
- Build the candidate (model checkpoint, prompt set, code).
- Run eval against the candidate. Compare to the current production baseline.
- If candidate ≥ baseline within tolerance: promote, deploy.
- If candidate < baseline: fail the deploy. Surface the diff (which prompts regressed) on the PR or deploy failure.
What makes this hard
- Baseline drift — when do you update the baseline? Auto-update on each successful deploy is fine for monotonic improvements; for behavior changes, human approval is needed.
- Score noise — eval scores have variance. A 1% drop might be noise. Define tolerance bands.
- Cost — full eval on every PR is expensive. Smoke gate on PRs, full gate on merge to main.
- Slice regressions — overall score might be flat, but Korean inputs degraded by 8%. Slice metrics catch this.
The promise
An eval gate means the next time someone tweaks a prompt 'just to make this one case work', the gate will tell them what they broke. No more silent regressions in production.