LLM-as-judge는 잘못된 기본값입니다. 효과적인 대안을 소개합니다
LLM-as-judge is the wrong default. Here's what works
핵심 요약
에이전트 평가 시 LLM-as-judge의 한계를 지적하고, 궤적 스냅샷과 단계별 재현을 활용한 대안적 평가 방식을 제안함.
- 평가 방식의 한계 — LLM-as-judge는 결과물만 평가하여 에이전트의 잘못된 추론 과정을 놓치고 확률적 변동성으로 인해 신뢰도가 낮음.
- 궤적 스냅샷 활용 — 자연어 출력 대신 도구 호출 순서와 구조적 인자를 기록하여 회귀 테스트의 정확도를 높임.
- 단계별 재현 테스트 — 도구 출력을 고정하고 특정 단계부터 에이전트의 추론을 다시 실행하여 결정론적 테스트 환경을 구축함.
- 행동 패턴 분석 — 프로덕션 트레이스를 궤적 모양별로 클러스터링하여 프롬프트 변경 후 발생하는 행동 드리프트를 감지함.
제가 함께 일하는 대부분의 내부 에이전트 팀들은 똑같은 평가 설정으로 시작합니다. 기대 답변을 작성하고, LLM이 에이전트의 응답이 일치하는지 채점하게 하는 것이죠. 당연히 해야 할 일처럼 보입니다. 하지만 제가 본 거의 모든 워크플로우 에이전트에게는 잘못된 방식입니다.
두 가지 문제가 복합적으로 작용합니다.
첫째, 잘못된 것을 평가하고 있습니다. 에이전트의 최종 답변은 그 아래의 궤적(trajectory)이 망가졌을 때도 올바르게 보일 수 있습니다. 잘못된 도구 사용, 잘못된 인자, 운 좋은 복구 등이 원인이죠. 반대의 경우도 발생합니다. 완벽하게 괜찮은 궤적이 나왔는데도 판정자가 문구 때문에 점수를 깎는 경우입니다. 결과물은 우리가 실제로 신경 써야 할 것의 하위 단계일 뿐입니다.
둘째, 확률적 시스템 위에 확률적 채점자를 올리고 있습니다. 같은 입력이라도 실행할 때마다 판정이 달라집니다. 재실행 시 통과율이 5-10 포인트씩 흔들립니다. 엔지니어들은 한 달도 안 되어 테스트 스위트를 신뢰하지 않게 되며, 솔직히 그들의 판단이 맞습니다.
도구를 사용하는 에이전트를 위해 제가 계속 돌아오는 방식은 다음과 같습니다:
- 결과물이 아닌 궤적을 스냅샷으로 남기세요. (도구, 구조적 인자) 튜플의 시퀀스가 실제로 비교하고 싶은 대상입니다. 도구 호출은 자연어보다 훨씬 안정적입니다. 거의 제로에 가까운 불안정성으로 대부분의 실제 회귀를 잡아냅니다.
- 고정된 도구 출력으로 단계별 재현을 수행하세요. 각 도구의 응답을 기록된 값으로 고정하고, 에이전트가 어떤 단계에서든 다시 추론하게 하세요. "이 정확한 상태에서 내 에이전트는 무엇을 하는가"라는 질문은 더 이상 확률적인 문제가 아니게 됩니다. 이것이 단순한 엔드투엔드 스모크 테스트가 아닌, 실제 타겟팅된 회귀 테스트를 가능하게 하는 열쇠입니다.
- 프로덕션 트레이스를 궤적 모양별로 클러스터링하세요. 엔드투엔드 평가는 행동 드리프트(behavioral drift)를 놓치는데, 이는 제가 본 사람들 중 가장 큰 피해를 입히는 실패 모드입니다. 아무것도 에러가 나지 않고, 테스트 실패도 없습니다. 에이전트는 프롬프트 변경 후 3배 더 자주 다른 경로를 타기 시작할 뿐입니다. 라이브 트레이스 스트림에서 이상치 탐지를 하지 않으면 이를 알 수 없습니다.
LLM-as-judge는 일부 상황에서는 괜찮습니다. 창의적인 결과물을 스모크 테스트하거나, 질적인 현장 점검을 할 때 말이죠. 신호가 아예 없는 것보다 노이즈가 있는 신호라도 있는 편이 나은 경우라면 어디든 좋습니다. 하지만 도구를 호출하는 에이전트의 CI 게이트로서는, 여러 단계를 거치는 동전 던지기에 불과합니다.
진지한 질문입니다: 다들 특히 의사결정 지점의 회귀 사례를 위해 무엇을 사용하고 계신가요? 엔드투엔드는 너무 거칠고, 확률적 시스템에 대한 단위 테스트는 어색하게 느껴집니다. 저는 아직 깔끔한 해결책을 찾지 못했고, 업계도 마찬가지라고 생각합니다.
