통과·실패 한 칸으로는 에이전트를 못 지켜

프롬프트 한 줄 고쳤을 뿐인데 에이전트가 엉뚱한 답을 하기 시작한 적 있잖아. eve의 평가 문서는 그 회귀를 잡는 검사를 막는 항목과 기록만 하는 항목으로 갈라 놨어.

Vercel이 6월 17일 오픈소스로 공개한 eve의 평가 문서 얘기야. 여기서 eval은 에이전트를 실제 세션으로 돌려 결과를 채점하는 검사고, 목적이 명시돼 있어. 프롬프트나 도구를 바꿨을 때 회귀를 잡는 것.

실제 서버를 띄워서 돌려

검사가 함수를 직접 호출하는 방식이 아니야. 진짜 에이전트 서버를 띄우고 클라이언트 프로토콜로 세션을 몰아서, 사용자가 쓰는 것과 같은 HTTP 표면을 그대로 통과시켜.

파일 규칙도 단순해. evals/ 디렉터리 아래 .eval.ts 파일을 자동으로 찾고, 파일 경로가 곧 그 검사의 이름이 돼. 설정 파일은 그 디렉터리 최상단에 evals.config.ts 하나만 둬.

판정 방법이 세 갈래야

  • 실행 상태 읽기: 세션이 끝난 뒤 남은 상태를 검사 문맥에서 바로 확인해.
  • 결정적 매처: t.check로 값을 정해진 규칙과 맞춰. 같은 입력이면 같은 결과가 나오는 검사야.
  • 모델 채점: t.judge.autoevals.*로 다른 모델한테 채점을 시켜. 기본 채점 모델은 openai/gpt-5.4-mini야.

세 번째가 문제야. 모델이 채점하면 같은 입력에도 판정이 흔들리거든. 이걸 앞의 두 개와 같은 등급으로 두면 배포가 무작위로 막혀.

그래서 심각도를 따로 붙여

막는 항목이 하나라도 깨지면 그 eval은 실패가 되고 eve eval 명령이 0이 아닌 값으로 끝나. CI가 그 값을 보고 배포를 세워.

기록만 하는 항목은 기준을 밑돌아도 실패로 치지 않아. 리포트에 점수로 남고 scored 상태가 될 뿐이야. 다만 --strict를 주면 이것도 빌드를 세워. 항목마다 .gate(), .soft(), .atLeast()로 등급을 바꿀 수 있어.

에이전트 회귀 테스트를 짜는 팀이 볼 것

  • 먼저 나눌 것: 도구 호출 여부, 반환 형식, 권한 확인처럼 맞고 틀림이 딱 갈리는 검사는 배포를 막는 쪽에 둬. 답변 품질이나 어조처럼 모델이 채점하는 항목은 점수로만 남기는 게 안전해.
  • 기준선 잡는 법: 기록만 하는 항목도 값이 계속 쌓이면 추세가 보여. 몇 주 데이터가 모인 다음에 막는 항목으로 올릴지 정해도 늦지 않아.
  • 적용 범위: 이건 eve 안에서의 규칙이라 다른 프레임워크에 그대로 옮겨지지는 않아. 가져갈 건 도구가 아니라 항목을 두 등급으로 나누는 기준이야.
  • 확인 못 한 것: 동시 실행 개수와 제한 시간 기본값은 문서의 해당 경로가 열리지 않아서 확인하지 못했어. 실행 규모를 잡으려면 직접 재봐야 해.