LLM-as-a-Judge는 기본값으로 사용하기에는 너무 비쌉니다

LLM-as-a-judge(판사로서의 LLM)가 기본값이 된 이유는 편리하기 때문입니다. 평가 기준(rubric)을 작성하고, 모델에게 두 개의 답변을 건네준 뒤, 어느 것이 더 나은지 묻기만 하면 됩니다. 프로토타입(prototype) 단계에서는 이보다 더 좋은 방법은 없습니다. 하지만 프로덕션 평가(production evals) 단계로 넘어가면, 이는 조용히 일반적인 문제들을 모두 안고 있는 또 다른 추론 파이프라인(inference pipeline)으로 변질됩니다.

속도가 느립니다. 샘플당 비용이 발생합니다. 답변이 틀려 보일 때 검사하기가 어렵습니다. 그리고 에이전트(agent) 실행에 20개의 도구 호출(tool calls), 5개의 파일, 3개의 숨겨진 실패 모드가 포함되어 있을 때, 다른 모델에게 그 기록을 자세히 살펴보라고 요청하는 것은 엔지니어링이라기보다 혼란을 외주 주는 것처럼 느껴지기 시작합니다.

그렇기 때문에 새로운 논문인 Codifying the Judge에 주목할 가치가 있습니다. 유용한 아이디어는 더 큰 판사 모델을 만드는 것이 아닙니다. 오히려 더 작고, 가장 좋은 의미에서 더 번거로운 방식입니다. 평가 시점에 LLM을 호출하는 대신, 판사의 일부 기능을 프로그램으로 증류(distill)합니다.

논문에서는 이 시스템을 PAJAMA라고 부릅니다. 이 시스템은 프로그램 방식의 판사 위원회(committee of programmatic judges)를 합성하고, 그들의 평결을 집계하며, 프로그램이 불확실할 때만 LLM으로 넘어갑니다. 쉽게 말해, 비싼 모델이 채점 기계(grading machinery)를 작성하는 것을 돕고, 채점 기계가 지루한 케이스들을 직접 처리하는 방식입니다.

이것이 에이전트 평가(agent evaluation)를 위한 올바른 방향처럼 느껴집니다.

모델 판사의 문제점

LLM 판사가 쓸모없는 것은 아닙니다. 저도 이 패턴을 사용합니다. 에이전트를 구축하는 대부분의 사람들은 이 패턴의 어떤 버전을 사용하는데, 간단한 단위 테스트(unit test)로는 잡아낼 수 없는 실패 사례가 많기 때문입니다.

코딩 에이전트(coding agent)는 마이그레이션 노트를 조용히 삭제하면서도 테스트 스위트(test suite)를 통과할 수 있습니다. 리서치 에이전트(research agent)는 올바른 출처를 인용하면서도 질문에 잘못된 답을 할 수 있습니다. 고객 지원 에이전트(support agent)는 예의 바르고 근거가 확실하면서도, 사용자가 중요하게 생각한 단 하나의 제약 조건을 무시할 수 있습니다.

이것들은 판단(judgment)의 문제이므로, 우리는 판사 모델(judge model)에 의존하게 됩니다.

문제는 모델 판사(model judges)의 확장성(scale)이 좋지 않다는 점입니다. 모든 후보 답변, 검색 결과(retrieval result), 도구 실행 흔적(tool trace), 또는 에이전트 궤적(agent trajectory)마다 별도의 모델 호출이 필요하다면, 평가는 제품의 비용 구조의 일부가 되어 버립니다. 설상가상으로, 판사는 대개 또 다른 블랙박스(black box)입니다. 판사가 특정 응답이 더 낫다고 말할 때, 당신은 여전히 '왜' 그런지 물어야 하며, 그 설명을 신뢰할지 여부를 결정해야 합니다.

어느 시점에 이르면 평가 스택(eval stack)이 측정하려는 대상과 닮아가는 현상이 발생합니다.

지루한 판단에는 프로그램이 더 나은 기본값입니다

PAJAMA의 접근 방식은 간단합니다. 루브릭(rubric, 평가 기준)을 가져와 판사의 행동을 실행 가능한 체크(executable checks)로 추출하는 것입니다. 하나의 거대하고 취약한 규칙이 아니라, 결정의 각 부분을 포착하는 프로그램 위원회(committee of programs)를 구성합니다. 그런 다음 시스템은 이러한 프로그램의 출력값들을 결합하여 평결(verdict)을 내리고, 신뢰도가 낮은 사례는 다시 LLM으로 보냅니다.

수치가 핵심입니다. 논문에 따르면 독립적인 프로그램 기반 판사(programmatic judges)는 OLMo-2-13B-Instruct 판사의 정확도와 대등한 수준을 유지하면서도 47.25배 더 빠르게 작동할 수 있습니다. 하이브리드 모드에서 PAJAMA는 정확도와 처리량(throughput) 사이의 트레이드오프(tradeoff)를 개선하며, OLMo-2-7B-Instruct와 결합했을 때 2.9배의 처리량에서 5.0%의 정확도 향상을 기록했다고 보고되었습니다.

더 중요한 부분은 운영 측면입니다. 프로그램은 검사할 수 있습니다. 프로그램은 수정할 수 있습니다. 프로그램은 평가 대상인 에이전트와 동일한 리포지토리(repo)에서 버전 관리(versioning)를 할 수 있습니다. 만약 판사가 최종 답변에 필수 필드가 누락되어 실행이 실패했다고 말한다면, 저는 모델의 신뢰도에 대한 긴 문단을 읽기보다 해당 체크 로직을 직접 확인하는 쪽을 택하겠습니다.

이것은 화려하지 않습니다. 바로 그것이 핵심입니다.

에이전트 평가의 CI 형태

명백한 반론은 프로그램이 모든 것을 판단할 수는 없다는 것입니다. 맞습니다. 그래서 그러면 안 됩니다.

프로그램은 답변이 요청된 형식을 사용했는지 확인할 수 있습니다. 주장이 제기되기 전에 도구가 호출되었는지 확인할 수 있습니다. 인용(citations)이 검색된 문서(retrieved documents)를 가리키는지 확인할 수 있습니다. 패치(patch)가 허용된 디렉토리 외부의 파일을 건드렸는지 확인할 수 있습니다. 최종 응답에 지원되지 않는 약속(unsupported promise)이 포함되어 있는지 확인할 수 있습니다.

프로그램은 취향, 모호함, 그리고 진정으로 개방적인 추론 (open-ended reasoning)을 판단하는 데에는 더 서툽니다. 따라서 프로그램에게 그러한 것들만 판단하게 하지 마세요. 첫 번째 단계 (first pass)로 사용하세요. 지루한 실패 사례들을 저렴하게 잡아내게 한 다음, 이상한 사례들은 모델이나 사람에게 넘기세요 (escalate).

이것이 일반적인 CI (지속적 통합)가 작동하는 방식에 훨씬 더 가깝습니다. 단위 테스트 (Unit tests)가 소프트웨어가 훌륭하다는 것을 증명하지는 않습니다. 다만 일반적인 실패 사례들을 매번 잡아낼 수 있을 만큼 저렴하게 만들어 줄 뿐입니다.

에이전트 평가 (Agent evaluation)도 동일한 분리가 필요합니다. 이름을 붙일 수 있는 부분에는 결정론적 검사 (Deterministic checks)를 사용하세요. 아직 축약할 수 없는 부분에는 모델의 판단 (Model judgment)을 사용하세요. 틀렸을 때 비용이 많이 발생하는 부분에는 사람의 검토 (Human review)를 사용하세요.

이 논문에서 내가 가져오고 싶은 것

만약 내가 이것을 에이전트 스택 (agent stack)에 연결한다면, PAJAMA를 처음부터 끝까지 재현하려고 시도하며 시작하지는 않을 것입니다. 대신 그 형태 (shape)를 가져올 것입니다.

평가 기준 (rubric)을 작은 주장 (claims)들로 나누는 것부터 시작하세요. "좋은 답변"은 검사 항목이 아닙니다. "모든 사실적 주장 (factual claim)에 대해 검색된 소스를 사용함"이 더 가깝습니다. "요청된 패키지 외부의 파일을 수정하지 않음"이 더 좋습니다.

그런 다음 이러한 주장들을 위한 아주 작은 판단기 (tiny judges)들을 작성하거나 합성하세요. 어떤 것들은 단순한 Python 코드일 것입니다. 어떤 것들은 AST (추상 구문 트리) 검사일 것입니다. 어떤 것들은 스키마 (schema) 검사일 것입니다. 어떤 것들은 여전히 작은 모델을 사용할 수도 있지만, 경계선에서 정말로 언어 이해가 필요한 경우에만 그렇게 할 것입니다.

불일치 로그 (disagreement logs)를 유지하세요. 프로그램 판단기와 LLM 판단기가 서로 의견이 다르다면, 그것은 노이즈가 아닙니다. 그것은 평가 시스템 자체를 위한 학습 데이터입니다.

폴백 (fallback)을 명시적으로 만드세요. 목표는 LLM 판단기를 금지하는 것이 아닙니다. 모든 샘플에 대해 LLM을 첫 번째 도구로 사용하는 것을 멈추는 것이 목표입니다. 좋은 폴백 임계값 (threshold)은 지루한 인프라와 같으며, 바로 그렇기 때문에 중요합니다.

실질적인 승리는 단순히 비용 절감에 그치지 않습니다. 평가가 여러분이 디버깅할 수 있는 산출물 (artifact)이 된다는 점에 있습니다.

지루한 미래가 아마도 맞을 것이다

AI 툴링에는 반복되는 패턴이 있습니다. 우리는 일단 움직이기 위해 거대한 모델이 모든 것을 수행하는 것으로 시작합니다. 그러고 나서 유용한 부분들이 더 작고, 저렴하며, 더 읽기 쉬운 시스템들로 분리되어 나갑니다.

RAG (Retrieval-Augmented Generation)가 이를 수행했습니다. 라우팅 (Routing)이 이를 수행하고 있습니다. 에이전트 오케스트레이션 (Agent orchestration)이 이를 수행하고 있습니다. 다음은 평가 (Evaluation)입니다.

LLM-as-a-judge (판사로서의 LLM)는 사라지지 않을 것입니다. 복잡하고 지저분한 케이스들에는 너무나 유용하기 때문입니다. 하지만 모든 평가의 기본값으로 이를 사용하는 것은, 마치 모든 린트 (lint) 에러에 대해 전체 통합 테스트 스위트 (integration suite)를 실행하는 것과 같습니다. 때로는 정답이 이름, 테스트, 그리고 실패 메시지를 갖춘 Python 함수여야 할 때도 있습니다.

그것은 마법 같은 느낌은 덜하지만, 좋습니다.

당신의 에이전트 스택 (agent stack)에서는 경계선을 어디에 긋겠습니까? 모델 판사 (model judge)를 먼저 도입하시겠습니까, 아니면 프로그램 판사 (program judge)를 먼저 도입하시겠습니까?