eval은 프롬프트의 단위 테스트다

예전엔 프롬프트 변경을 감으로 내보냈다. 예제 세 개 돌려 보고, 나아 보이면, 머지. 그러다 "문구 살짝 개선" 하나가 어느 파이프라인의 숫자 포맷을 나흘 동안 조용히 망가뜨렸다. 이제 프롬프트는 코드고, 코드는 테스트 없이 머지되지 않는다.

골든 세트는 상처에서 자란다

파이프라인마다 입력/기대값 쌍으로 된 라벨 세트가 있다. 누가 작정하고 앉아서 쓴 게 아니다. 사고 하나당 케이스 하나씩, 시스템이 한 번씩 창피를 당한 방식마다 테스트 하나씩 붙으며 쌓인 것이다. 우리 최대 텍스트 파이프라인은 지금 변경할 때마다 케이스 약 3,900개를 돌리고, 기대 실패 수는 정확히 0이다. 이 0은 타협 대상이 아니다. 실패 몇 개를 봐주는 스위트는 아무도 안 읽는 스위트다.

수갑 채운 LLM-as-judge

우리 케이스 절반은 정답이 하나로 딱 떨어지지 않아서, 모델이 채점한다. 모델 심판은 편향된 증인이고, 우리는 딱 그렇게 대한다.

Verdict rules:
- Compare A and B for the stated criteria only. Do not reward length.
- TIE is a valid verdict. Prefer TIE over a coin flip.
- Output exactly one line: WINNER: A | B | TIE, then one reason.

(Runner: every pair is judged twice with A and B swapped.
 Only a verdict that survives the swap is recorded. ~11% do not.)

• 위치 편향은 진짜다. 심판은 첫 번째 답을 편애한다. 위치를 바꿔 놓고도 같은 판정이 나와야 인정하는 방식은 이 부류의 노이즈를 통째로 지운다. 심판 호출이 두 배로 드는 대가를 치르지만, 그럴 값어치가 있다.
• 길이 편향은 진짜다. 제약 없는 심판은 단어 수에 점수를 준다. 루브릭에 대놓고 그러지 말라고 적어 두고, 채점 전에 출력 길이를 잘라 둔다.
• 자기 편애는 진짜다. 모델은 자기 계열을 후하게 준다. 그래서 판돈이 큰 곳에선 심판을 생성 모델과 다른 계열로 쓴다.

에이전트에는 더 높은 기준을

에이전트 작업에선 pass@k, 즉 k번 시도 중 하나라도 성공하는지를 재지 않는다. 우리는 정반대를 잰다. 같은 작업을 k번 돌려서 매번 다 성공해야 그 작업 부류에 대한 자율권을 준다. 다섯 번 중 네 번 성공하는 워크플로는 80% 완성이 아니다. 아직 편성만 안 해 둔 온콜 당직일 뿐이다.

그 대가는 가장 좋은 의미로 지루하다. 프롬프트 리팩터, 모델 교체, 프로바이더 이전이 red/green으로 답이 딱 나오는 일상적인 변경이 됐다. 눈 딱 감고 지르고 나서 일주일 동안 로그를 지켜보던 시절과 달리.