누가 채점자를 채점하는가? 당신의 LLM Judge는 검증되지 않은 프로덕션 모델입니다

모든 사람의 평가 스택(eval stack)에는 아무도 감사(audit)하지 않는 동일한 핵심 가정이 깔려 있습니다. 그것은 바로 '판사 역할을 하는 모델(model-as-judge)이 진실을 말하고 있다'는 가정입니다.

당신은 스키마 유효성(schema valid), 개인정보(PII) 포함 여부, 예산 내 지연 시간(latency)과 같은 쉬운 문제들에 대해서는 결정론적 체크(deterministic checks)를 작성했습니다. 그러다 주관적인 문제들—"이 답변이 실제로 도움이 되는가", "에이전트가 사용자의 의도를 따랐는가", "이 요약이 원문에 충실한가"—에 직면했을 때, 당신은 LLM judge를 선택했습니다. 달리 무엇을 할 수 있겠습니까. 이제 한 모델이 당신의 모델을 채점합니다. 그리고 여기서 당신을 밤잠 설치게 만들 부분이 있습니다. 당신은 채점자(grader)를 한 번도 검증하지 않았다는 점입니다. 당신은 단 20분 만에 작성한 프롬프트에서 나온 0~10점 사이의 점수를 바탕으로 릴리스를 배포하거나 차단하고 있지만, 그 점수가 인간이 동의할 만한 어떤 것과 상관관계가 있는지 전혀 알지 못합니다.

저는 팀들이 몇 달 동안 초록색으로 빛나는 judge 대시보드를 신뢰하다가, 정작 judge가 사용자들이 싫어하는 답변에 8점을 주고 있었다는 사실을 발견하는 것을 목격해 왔습니다. judge가 명백하게 고장 난 것은 아니었습니다. 단지 보정되지 않았을(uncalibrated) 뿐이었고, 보정되지 않은 채점자는 조용히 실패합니다. 이는 가장 최악의 실패 방식입니다.

judge는 프로덕션 환경의 모델이므로, 모델처럼 취급하십시오

솔직하게 말해봅시다. 당신의 LLM judge는 릴리스 파이프라인에서 중대한 결정을 내리는 비결정론적(non-deterministic) 모델입니다. 그것은 바로 당신이 지난 1년 동안 신뢰하지 않는 법을 배웠던 바로 그 대상입니다. 왠지 모르게 그 모델이 실험실 가운을 입고 "평가자(evaluator)"라고 불리면, 사람들은 에이전트 자체에는 절대 부여하지 않을 권위를 부여하곤 합니다.

judge가 조용히 거짓말을 하는 세 가지 방식:

• 위치 편향 (Position bias). 두 후보 답변의 순서를 바꾸면 judge가 승자를 바꿉니다. 만약 A-vs-B와 B-vs-A의 결과가 약 10% 이상의 빈도로 다르다면, 당신의 쌍체 점수(pairwise scores)는 부분적으로 동전 던지기와 다를 바 없습니다.
• 장황함 편향 (Verbosity bias). 정답 여부와 상관없이 더 길고 자신감 넘치는 답변이 더 높은 점수를 받습니다. 당신의 judge는 진실이 아니라 산문을 채점하고 있는 것입니다.
• 자기 선호 (Self-preference). 에이전트와 동일한 모델 제품군(model family) 출신의 judge는 해당 제품군의 출력을 더 높게 평가합니다. 만약 GPT가 GPT를 채점한다면, 당신은 숫자가 붙은 이해 상충(conflict of interest) 상황에 놓인 것입니다.

평균 점수만을 그래프로 그리는 대시보드에서는 이러한 현상들이 전혀 나타나지 않습니다. 이것들은 당신이 직접 찾아 나설 때만 드러납니다. 그리고 대부분의 팀은 직접 찾아보지 않습니다. 왜냐하면 채점자(judge)가 깔끔한 지표(metric)를 생성하고, 깔끔한 지표는 마치 정답(ground truth)처럼 느껴지기 때문입니다.

채점자를 인간과 비교하여 교정(Calibrate)하고, 지속적으로 확인하세요

해결책은 "LLM 채점자 사용을 중단하는 것"이 아닙니다. LLM 채점자는 진정으로 유용하며, 모든 실행 결과에 대해 인간이 라벨링(labeling)을 할 수는 없습니다. 해결책은 채점자를 자체적인 정답 세트(ground-truth set)를 가진 테스트 대상 시스템으로 취급하는 것입니다. 당신은 신뢰할 수 있는 인간이 점수를 매긴 수백 개의 예시로 구성된 라벨링된 골든 세트(golden set)가 필요하며, 채점자가 해당 인간들과 얼마나 일치하는지 측정해야 합니다. 이때 단순 정확도(raw accuracy)가 아닌 코헨의 카파(Cohen's kappa) 계수를 사용해야 합니다. 대부분의 답변이 "괜찮음"으로 나올 경우 단순 일치도는 부풀려질 수 있기 때문입니다.

어떤 채점자도 무언가를 통과(gate)시키기 전에 제가 실행하는 교정(calibration) 체크는 다음과 같습니다:

import { judge } from "./llm-judge";

type Labeled = { input: string; output: string; humanScore: number };
...

이 작업은 단 한 번만 수행하는 것이 아니라, CI(지속적 통합) 환경에서 정기적으로 실행됩니다. 채점자는 에이전트(agent)와 마찬가지로 드리프트(drift) 현상이 발생합니다. 제공업체가 기반 모델을 업데이트하거나, 당신의 프롬프트 템플릿(prompt template)이 수정되거나, 데이터 분포가 변할 수 있습니다. 3월에 인간과 일치했던 채점자가 6월에는 조용히 어긋날 수 있습니다. 만약 시작할 때 단 한 번만 교정했다면, 당신은 교정된 채점자를 가진 것이 아니라 과거의 유물(historical artifact)을 가진 것입니다.

교정은 틀렸다는 것을 알려주지만, 트레이스(Traces)는 이유를 알려줍니다.

여기서 워크플로우의 두 부분이 결합됩니다. 카파(kappa) 계수 0.6은 화재 경보이지, 진단 결과가 아니기 때문입니다.

agent-eval은 점수 산정 및 게이트(gate)를 실행하는 도구입니다. 이는 결정론적 체크(deterministic checks), 모델 기반 채점자(model-as-judge), 골든 세트(golden set), 그리고 앞서 언급한 certifyJudge 단계를 보유하는 레이어입니다. 채점자 일치도가 0.85 미만으로 떨어졌음을 알리고 릴리스(release)를 거부하는 역할을 합니다. 그것이 바로 신호(signal)입니다. 하지만 맥락 없는 실패 수치는 논쟁을 불러일으킬 뿐입니다. "채점자가 틀렸다", "아니, 에이전트가 퇴보(regressed)한 것이다"라는 식의 논쟁이 벌어지며, 아무도 결론을 내릴 수 없게 됩니다.

그것이 바로 AgentLens:의 역할입니다. AgentLens는 모든 점수 뒤에 숨겨진 전체 트레이스(trace)를 캡처합니다. 즉, 채점자(judge)가 본 정확한 프롬프트(prompt), 후보 출력물(candidate output), 해결된 루브릭(rubric), 숫자를 파싱하기 전 채점자의 가공되지 않은 완성본(raw completion), 그리고 애초에 답변을 생성하는 데 사용된 에이전트 자체의 도구 및 모델 단계(tool-and-model steps)를 모두 보여줍니다. 따라서 agent-eval이 '인간은 3점을 준 답변에 대해 채점자가 9점을 주었다'라고 표시하면, AgentLens 트레이스를 열어 이를 직접 확인할 수 있습니다. 채점자가 핵심 주장에 대한 근거를 제시하지 못한 채, 자신감 있고 장황한(verbose) 답변에 보상을 주었다는 사실을 말이죠. 이제 이것은 단순한 느낌(vibe)이 아닙니다. 가공되지 않은 텍스트에서 장황함 편향(verbosity bias)을 확인할 수 있고, 인용(citation)을 요구하도록 루브릭을 수정하여 다시 인증(re-certify)할 수 있습니다.

이것이 바로 루프(loop)입니다. agent-eval은 점수를 매기고 게이트(gate) 역할을 하며, AgentLens는 점수를 디버깅할 수 있도록 트레이스를 보여줍니다. 트레이스가 없다면 잘못된 채점 점수는 반증 불가능(unfalsifiable)합니다. 채점자의 문제인지 에이전트의 문제인지 구분할 수 없으므로, 결국 심문해야 마땅할 숫자를 그대로 믿게 됩니다. 하지만 트레이스가 있다면, 채점자와 인간 사이의 모든 불일치는 회의를 소집해야 하는 문제가 아니라 구체적이고 검사 가능한 산출물(artifact)이 됩니다.

불편한 결론

만약 당신이 모델을 채점자(model-as-judge)로 사용하면서, 채점자의 결과가 인간의 레이블(human labels)과 얼마나 일치하는지를 수치로 나타낼 수 없다면, 당신은 평가(evals)를 수행하고 있는 것이 아닙니다. 당신은 불필요한 단계가 추가된 '느낌 확인(vibe check)'을 하고 있을 뿐이며, 잘못된 엄격함을 느끼고 있는 것입니다. 채점자는 당신의 전체 파이프라인에서 가장 신뢰받으면서도 가장 감사가 이루어지지 않는 구성 요소입니다. 그리고 "LLM이 좋다고 했다"라는 말은 당신의 출시 결정 과정에서 검증되지 않은 채 너무나 많은 역할을 수행하고 있습니다.

채점자를 인증하십시오. 정기적으로 재인증하십시오. 모든 점수에 이의를 제기할 수 있도록 트레이스를 보관하십시오. 검증되지 않은 채점자는 품질을 측정하는 것이 아닙니다. 그것은 의견을 지표(metric)로 세탁하는 것이며, 당신의 초록색 대시보드는 그 영수증일 뿐입니다.