Ch12. Evals와 품질 게이트

Eve eval은 agent를 함수처럼 흉내 내지 않고 실제 Eve HTTP surface로 session을 만들어 stream event를 검증한다는 데 강점이 있습니다. eval이 통과했다면 적어도 agent server가 부팅됐고 route가 메시지를 받았으며 runtime이 turn을 실행했다는 뜻입니다.

Eval 구조

my-agent/
├── agent/
└── evals/
    ├── evals.config.ts
    └── smoke.eval.ts

import { defineEval } from "eve/evals";
import { includes } from "eve/evals/expect";

export default defineEval({
  description: "Weather smoke behavior.",
  async test(t) {
    await t.send("What is the weather in Brooklyn?");
    t.completed();
    t.calledTool("get_weather");
    t.check(t.reply, includes("Sunny"));
  },
});

세 가지 assertion surface

deterministic assertion으로 시작하는 게 기본입니다. judge는 비용도 들고 결과가 흔들리므로 핵심 품질에만 씁니다.

Gate와 soft

Eve assertion은 severity를 assertion handle에 둡니다.

CI에서는 eve eval --strict를 권장합니다. soft metric까지 regression 신호로 쓰려면 strict에서 걸려야 합니다.

공식 Running Evals 문서 기준으로 CI에서 자주 쓰는 실행 옵션은 다음과 같습니다.

실행 artifact는 .eve/evals/<timestamp>/ 아래에 남습니다. 실패했을 때는 console summary만 보지 말고 summary.json, results.jsonl, captured event stream, assertion result를 failure artifact로 올려 둡니다.

엔터프라이즈 eval taxonomy

Tool eval 예시

export default defineEval({
  async test(t) {
    await t.send("Refund charge ch_123 for $150.");
    t.waiting();
    t.calledTool("refund_charge", {
      input: { chargeId: "ch_123", amount: 150 },
    });
  },
});

승인형 tool은 t.completed()가 아니라 t.waiting()이 맞을 때가 많습니다. 여기서 확인할 건 실행 완료가 아니라 “승인 없이는 실행되지 않음”이기 때문입니다.

Negative eval

고급 에이전트에는 negative eval이 필요합니다.

에이전트 회귀는 “해야 할 일을 못 함”보다 “하면 안 되는 일을 함”이 훨씬 비쌉니다.

Event 기반 escape hatch

t.event(predicate, label)은 stream event를 직접 검사합니다. built-in assertion으로 모자랄 때 씁니다.

t.event(
  (events) =>
    events.some((event) => event.type === "input.requested" && event.data.requests.length > 0),
  "asks for human input",
);

복잡한 event predicate는 helper로 빼서 unit test를 붙여 둡니다.

Dataset fan-out

여러 케이스를 같은 eval logic으로 돌릴 수 있습니다.

Dataset eval은 prompt/skill 변경 회귀를 잡는 데 좋습니다. 다만 dataset이 커지면 maxConcurrency, timeout, provider rate limit을 함께 설계해야 합니다.

Braintrust/JUnit reporter

evals.config.ts에서 reporter를 설정할 수 있습니다.

import { defineEvalConfig } from "eve/evals";
import { JUnit } from "eve/evals/reporters";

export default defineEvalConfig({
  maxConcurrency: 4,
  timeoutMs: 60_000,
  reporters: [JUnit({ outputPath: "eval-results.xml" })],
});

운영 기준:

• CI는 JUnit을 남긴다.
• 실험/품질 분석은 Braintrust 등 외부 reporter를 사용한다.
• 외부 reporter로 전송되는 prompt/output 데이터는 privacy review를 거친다.

공식 eval 문서는 Cases, Assertions, Judge, Targets, Reporters를 따로 다룹니다. 팀 표준 문서도 이 구분을 따라 test case authoring, matcher policy, judge model policy, target auth, reporter data export를 각각 소유자에게 맡기면 운영하기 쉽습니다.

Release gate 예시

Eval 운영 루프

평가는 한 번 만들고 끝나지 않습니다. production trace에서 실패 사례가 나오면 dataset/eval로 승격합니다.

체크리스트

Eve eval은 AgentOps의 중심입니다. 프롬프트와 모델은 계속 바뀌므로 품질은 “좋은 프롬프트”가 아니라 “회귀를 잡는 게이트”로 관리해야 합니다.