Eval-Gated AI Releases: Treating Retrieval Quality Like Unit Tests

작성자

카테고리:

← 피드로
DEV Community · Venkatesh S · 2026-07-22 개발(SW)

Venkatesh S

No backend team would merge a PR that fails the test suite. Yet many AI teams ship prompt and model changes with no automated quality check at all — they eyeball a few responses and hope. The failure mode is silent: answers get slightly less faithful, citations drift, and nobody notices until a user does.

Atlas (my enterprise RAG copilot project) treats evals exactly like tests: a merge is blocked on a quality or cost regression. Here’s the shape of that pipeline and what I learned building it.

What gates the build

Every PR runs an offline, deterministic, GPU-free eval gate against committed cassettes:

Metric Baseline Floor Policy RAGAS faithfulness 0.706 0.656 blocking, regression band 0.05 Answer relevancy 0.832 0.782 blocking Context recall 0.738 0.668 blocking, band 0.07 Citation correctness 1.000 — tracked Adversarial suite (injection) 100% pass 100% zero-tolerance, blocking Cost per request committed baseline reduction target blocking (separate cost gate)

Three design decisions made this workable:

1. Floors + regression bands, not perfection. A hard “faithfulness ≥ 0.9” gate would have blocked every merge forever. Instead: an absolute floor (never ship below this) plus a regression band relative to the committed baseline (never get meaningfully worse). This is the eval equivalent of ratcheting code coverage.

2. Deterministic and GPU-free in CI. Live-model evals in CI are slow, expensive, and flaky. Atlas replays committed cassettes — recorded model interactions — so the gate is fast and reproducible. Cassettes are re-recorded deliberately when behavior is supposed to change, which turns “the model changed” into a reviewed diff instead of an ambient surprise.

3. Cost is a gated metric, not a dashboard. A prompt change that doubles token usage is a regression even if quality holds. Atlas’s cost gate asserts the measured cost-reduction against a committed baseline and fails the build when cost regresses below the band — the same way a p95-latency budget would gate a backend service.

The payoff: decisions you can defend

The gate earned its keep when I fine-tuned a QLoRA adapter for citation formatting. The benchmark (paired bootstrap, McNemar) showed: citation format validity 0.00 → 0.955 (p ≈ 0), serving cost −79% on the same GPU — and a faithfulness trade-off of −0.10, still above the floor. The promotion gate had the data to make that call explicitly, and the pipeline is proven to both promote and block a candidate in CI.

Without evals, that’s a vibes decision. With them, it’s an engineering decision with a paper trail.

Where to start (smaller than you think)

You don’t need RAGAS on day one. Start with:

  1. 20–30 golden questions with expected source documents — your retrieval hit-rate suite.
  2. A handful of adversarial prompts (injection attempts, out-of-scope questions) with expected refusals.
  3. A CI job that fails when either regresses.

That’s an afternoon of work, and it changes the culture immediately: prompts become code, model swaps become reviewed changes, and “did we get worse?” has an answer.

Backend engineering solved this problem twenty years ago — we just called it testing. AI systems don’t need a new philosophy; they need the old one applied.

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다