모든 'LLM 평가 플랫폼' 발표 자료에는 다음과 같은 슬라이드가 있습니다: 모든 응답의 점수를 매기고, 모든 회귀를 포착하세요. 이는 책임감 있게 들립니다. 하지만 동시에 잘못된 것을 측정하면서 월 5자리 수의 청구서를 태우는 가장 빠른 방법이기도 합니다.

실수는 '모든 실행을 평가하는 것'을 커버리지 요구 사항으로 취급하는 것입니다. 그렇지 않습니다. 커버리지와 샘플링은 서로 다른 축이며, 이 둘을 혼동하는 것이 팀들이 아무도 읽지 않을 7/10 점수를 얻기 위해 모델에게 프로덕션 트래픽의 100%를 다시 읽게 하고 비용을 지불하게 만드는 이유입니다.

실제 주장을 펼치겠습니다.

증거는 비용 축이 아닌 독립성 축을 가집니다

무엇을 샘플링할지 결정하기 전에, 어떤 종류의 증거를 수집하는지를 먼저 결정해야 합니다. 대부분의 평가 사고가 잘못되는 지점이 바로 여기에 있습니다: 이는 체크 항목들을 비용(저렴한 정규식 대 값비싼 GPT 호출)으로 순위를 매기는 것이 아니라 독립성—테스트 대상 에이전트가 그 결과를 위조하기 얼마나 어려운지—에 따라 순위를 매겨야 합니다.

이것이 agent-eval의 핵심 원칙이며, 세 가지 단계로 나뉩니다:

• Tier 1 — 에이전트가 위조할 수 없는 외부적으로 관찰 가능한 증거. 출력물이 유효한 JSON으로 파싱되었습니까? 주장하는 파일이 실제로 디스크에 존재하는가요? 코드가 컴파일되었습니까? 테스트를 통과했습니까? 실행이 시간 초과 내에 완료되었습니까? 결과가 비어있지 않습니까? 이 중 어느 것도 의견이 아닙니다. 세상은 동의하거나 그렇지 않습니다.
• Tier 2 — 에이전트가 작성하지 않은 기준선(baseline)에 대한 통계적 신호. 출력물과 원래 작업 간의 임베딩 유사성. 길이 및 반복 분포. 차이가 실제로 무언가를 변경했습니까, 아니면 에이전트가 입력값을 그대로 돌려주었습니까? 에이전트는 기준선을 작성할 수 없으므로 비교를 조작할 수 없습니다.
• Tier 3 — 모델 기반 판단자(model-as-judge). 공유된 기질을 가진 _의견_입니다. 유용하지만, 결코 판결(verdict)은 아닙니다.

여기서 전체 파이프라인을 재구성하는 부분이 나옵니다: Tier 1과 Tier 2가 실시간 게이트(real-time gate)입니다. 이들은 결정론적(deterministic)이며, 사실상 비용이 들지 않고 빠르기 때문에 핵심 경로(hot path)에 배치되어 잘못된 실행이 배포되기 전에 차단할 수 있습니다. Tier 3은 정반대입니다 — 측정 기반(metered), 느리고, 비결정론적이므로 설계상 오프라인 전용입니다. 지연 시간이나 비용에 대해 거짓말을 하지 않는 한, 모델 판단자(model judge)를 핵심 경로에 배치할 수 없습니다.

그리고 Tier 3이 오프라인으로 유지되는 더 깊은 이유가 있습니다: 에이전트의 궤적(trajectory) — 즉 추론 과정과 중간 도구 호출 — 위에서 Tier 1+2는 실행될 수 있지만, 모델 판단자가 그 궤적을 판단하도록 할 수는 없습니다. 한 모델이 다른 모델의 추론을 평가하는 것은 **순환적(circular)**입니다: 판단자와 피판단자는 동일한 기반 구조를 공유하므로 독립적인 진실(independent ground truth)이 존재하지 않습니다. 따라서 판단자는 피판단 에이전트가 작성하지 못한 아티팩트를 검사할 수 있을 뿐입니다.

이제 샘플링 결정은 스스로 내려집니다

Tier 1+2가 게이트이고 Tier 3이 오프라인이라는 것을 받아들이면, 샘플링은 더 이상 커버리지(coverage)에 관한 것이 아닙니다. 당신의 커버리지는 이미 100%입니다 — 모든 실행이 결정론적 게이트를 통과하기 때문인데, 이는 비용이 약 $0이고 밀리초 단위로 실행됩니다. 프로덕션에서 발생하는 대부분의 실패는 지루하고 기계적인 문제입니다: 오래된 데이터, 충돌(crash), 잘못된 형식, 환각으로 생성된 파일 경로, 빈 응답 등입니다. Tier 1+2가 이들 대다수를 단독으로 포착합니다.

그렇다면 판단자에게 남는 것은 무엇일까요? 주관적인 영역입니다.

실제로는 이런 모습입니다:

type Run = {
  id: string;
  task: string;
...

판단자가 결코 볼 수 없는 것을 주목하세요. 바로 Tier 1+2가 이미 차단한 모든 실행(run)들과, 대부분의 깨끗하게 통과된 케이스들입니다. 판단자는 경계선에 있는 중간 영역만을 보게 되는데, 이는 증거(evidence)가 아닌 _의견(opinion)_으로 명시적으로 레이블링됩니다. 이 단일한 프레이밍 덕분에 녹색 대시보드는 정직함을 유지할 수 있습니다. 왜냐하면 7/10짜리 결과가 게이트 통과 결과인 것처럼 위장하도록 절대 허용하지 않기 때문입니다.

판단자는 당신이 제공하는 추적(trace)만큼만 좋습니다

여기에는 모든 것의 기반이 되는 가정이 있습니다. 즉, Tier 1+2가 점수를 매길 수 있는 실제 무언가를 가지고 있어야 하고, 실행 과정에 이상한 점이 있을 때 실제로 왜 그런지 재구성할 수 있다는 것입니다. 이것 또한 공짜는 아닙니다. 만약 당신의 유일한 결과물이 에이전트(agent)가 방출한 최종 문자열이라면, 당신의

“실행의 몇 퍼센트를 점수화해야 하나요?”라고 묻는 것을 멈추세요. 그것은 잘못된 질문입니다. Tier 1+2를 사용하여 **100%**를 점수화하세요. 왜냐하면 그것은 결정론적이고, 무료이며, 실제 게이트이기 때문입니다. 그런 다음 주관적인 나머지(tail) 부분만 오프라인 평가자(offline judge)로 샘플링하고, 그 출력물에 '의견'이라는 레이블을 붙이세요. 증명할 수 있는 80%를 배포하고; 논쟁거리밖에 없는 20%를 위해 측정된 모델 호출(metered model call)을 남겨두세요.

그것이 평가 전략과 지나치게 비싼 방식으로 커버리지를 확보하려는 것 사이의 차이입니다.