지난달 저는 두 가지 프롬프트 변형(variant)의 순위를 매기는 평가(eval)를 출시했습니다. 변형 A가 4점 차로 승리했습니다. 다음 날 아침 한 팀원이 동일한 평가를 다시 실행했을 때, 이번에는 변형 B가 승리했습니다. 동일한 모델, 동일한 judge, 동일한 테스트 세트였습니다. 유일하게 바뀐 점은 두 답변이 judge 프롬프트에 붙여넣어진 순서뿐이었습니다.

이것은 일시적인 오류(flake)가 아닙니다. 이것은 위치 편향(position bias)이며, 3년 전 한 세심한 논문에서 문서화한 세 가지 편향 중 하나입니다. Lianmin Zheng과 공동 저자들은 "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" (NeurIPS 2023, arXiv:2306.05685)에서 이를 측정했습니다. 그들의 핵심 수치는 진정으로 고무적입니다. GPT-4와 같은 강력한 judge는 80% 이상의 시간 동안 인간의 선호도와 일치했으며, 이는 두 인간이 서로 일치하는 비율과 거의 비슷합니다. 그들의 두 번째 발견은 사람들이 덜 인용하는 내용입니다. 동일한 judge는 위치 편향(position bias), 장황함 편향(verbosity bias), 그리고 자기 강화 편향(self-enhancement bias)을 보입니다.

만약 이러한 요소들을 고려하지 않고 평가 점수를 보고한다면, 당신은 judge의 특성을 마치 당신의 모델의 특성인 것처럼 보고하는 것입니다.

편향은 노이즈가 아니므로, 평균을 내어 없앨 수 없습니다

통계학에서 가져온 습관 중 하나는, 측정이 노이즈(noisy)가 있다면 더 많은 측정값을 취함으로써 노이즈를 줄일 수 있다고 가정하는 것입니다. 이는 무작위 오차(random error)에는 적용됩니다. 평균의 표준 오차(standard error)는 표본 크기의 제곱근에 따라 감소하므로, 천 번의 judge 호출은 열 번의 호출보다 더 정밀한 추정치를 제공합니다.

문제는 위치, 장황함, 그리고 자기 선호(self-preference)는 무작위 오차가 아니라는 점입니다. 이것들은 체계적(systematic)입니다. 더 장황한 답변을 항상 B 슬롯에 두고 judge를 천 번 실행하면, 장황한 답변이 매번 실제보다 조금 더 자주 승리하게 됩니다. 편향은 분산(variance)이 아니라 기댓값(expected value)에 자리 잡고 있습니다. 더 많은 샘플은 편향된 수치를 더 정밀하게 추정하게 하므로, 결국 당신은 중심에서 벗어난 수치를 더 확신하게 될 뿐입니다.

이것이 나타나는 세 가지 구체적인 방식은 다음과 같습니다:

위치 (Position). 많은 판사(Judge)들은 모델에 따라 첫 번째로 읽은 답변이나 두 번째로 읽은 답변 중 하나를 선호합니다. 만약 당신의 테스트 프레임워크(Harness)가 항상 베이스라인(Baseline)을 첫 번째로, 후보(Candidate)를 두 번째로 배치한다면, 모든 비교는 동일한 기울어짐(Tilt)을 물려받게 됩니다.

장황함 (Verbosity). 판사들은 길이와 겉으로 보이는 철저함에 보상을 줍니다. 출력을 단순히 더 길게 만들기만 한 변경 사항이 정당하지 않은 대결(Bakeoff)에서 승리할 수 있으며, 당신은 내용을 채우기 위해 불필요한 수식어를 붙이는 프롬프트(Prompt)를 배포하게 될 것입니다.

자기 선호 (Self-preference). 판사는 자신이 속한 모델 제품군(Model family)의 출력을 더 높게 평가하는 경향이 있습니다. 이는 판사가 직접적으로든 혹은 제품군을 통해서든 참가자 중 하나인 모든 비교 상황을 조용히 오염시킵니다.

평가 도구들이 실제로 제공하는 것

저는 이 중 여러 가지를 사용하고 있으며, 그 지형은 마케팅에서 암시하는 것보다 훨씬 더 유사합니다. 거의 모든 도구가 LLM-as-a-judge (판사로서의 LLM) 기능을 포함하며, 대부분은 거기서 멈춥니다.

DeepEval은 여러 지표를 판사를 기반으로 구축하며, 그 중 G-Eval은 모델에게 루브릭(Rubric)에 따라 채점하도록 요청하는 사고 사슬 (Chain-of-thought) 채점 방식입니다. RAGAS 또한 판사를 사용하여 충실도 (Faithfulness)와 답변 관련성 (Answer relevancy)을 점수화합니다. OpenAI Evals는 정확히 일치 (Exact-match) 체크와 함께 모델이 채점하는 템플릿을 제공합니다. Langfuse는 추적된 프로덕션 데이터에 판사 평가기 (Judge evaluators)를 부착할 수 있게 해주는데, 이는 고정된 데이터 세트가 아니라 실제 트래픽에서 실행된다는 점에서 매우 유용합니다.

일부 소수 그룹은 먼저 실행할 수 있는 저렴한 결정론적 채점기 (Deterministic scorers)를 제공하며, 판사를 비용이 드는 두 번째 의견으로 취급하게 합니다. promptfoo는 동일한 테스트 내에서 결정론적 단언 (Deterministic assertions, 예: 일치 여부, 정규 표현식, JSON-schema)과 모델 채점 방식을 혼합합니다. Future AGI의 eval SDK도 같은 형태를 취하여, 하나의 evaluate() 함수 뒤에서 네트워크 호출 없이 로컬 지표를 실행하고 augment=True를 전달할 때만 판사를 추가합니다. Braintrust의 autoevals는 휴리스틱 채점기 (Heuristic scorers)와 LLM-judge 채점기를 모두 제공합니다. Langfuse와 Braintrust는 Future AGI와 마찬가지로 평가 전용이 아니라 트레이싱 (Tracing)에 평가를 부착하므로, 실제로 실행된 내용을 점수화할 수 있습니다.

이 중 어느 것도 그들을 비난하거나 순위를 매기는 것이 아닙니다. 일부 도구들은 단순히 도구를 건네주는 것 이상의 기능을 제공합니다. Langfuse의 점수 분석(score analytics) 기능은 인간의 주석(human annotations)을 Judge 점수와 대조하여 Cohen's kappa, 상관관계(correlation), 일치율(percent agreement)을 보고하며, 수치 옆에는 해석 범위(interpretation bands)가 함께 출력됩니다. Braintrust는 인간의 점수와 자동화된 점수를 동일한 트레이스(traces) 상에 나란히 배치하여, 두 점수가 얼마나 자주 일치하는지 관찰하고 점수 산출 도구(scorer)가 편향(drift)될 때 이를 개선할 수 있도록 합니다. 이것이 진짜이며, 여러분이 사용해야 할 방식입니다. 하지만 이것이 작업의 전부는 아닙니다. 도구는 Judge가 여러분의 레이블(labels)과 얼마나 자주 일치하는지는 계산할 수 있습니다. 하지만 여러분의 태스크를 위한 레이블을 직접 생성할 수는 없으며, 여러분이 내리려는 결정에 있어 어느 정도의 일치도가 충분한지를 결정할 수도 없습니다. 어떤 도구를 선택하든 이 두 가지는 여전히 여러분의 몫으로 남습니다.

대신 무엇을 측정해야 하는가

Judge를 여러분이 직접 만들지 않은 다른 도구처럼 취급하세요. 먼저 교정(Calibrate)한 다음, 사용하십시오.

인간이 레이블링한 샘플을 기준으로 교정하십시오. 수백 개의 예시를 수동으로 레이블링하고, 동일한 세트에 대해 Judge를 실행한 뒤 일치도를 계산하십시오. Cohen's kappa는 우연히 발생할 수 있는 일치도를 제외하기 때문에 가장 정직한 방식입니다. 이 계산은 단 한 번의 함수 호출로 이루어지며, 앞서 언급했듯이 몇몇 플랫폼에서는 이를 대신 실행해 주기도 합니다. 하지만 어떤 플랫폼도 여러분의 데이터를 레이블링하거나 여러분이 수용할 임계값(threshold)을 대신 정해줄 수는 없습니다.

from sklearn.metrics import cohen_kappa_score

# human_labels와 judge_labels는 동일한 레이블의 리스트입니다. 예: "pass"/"fail" 또는 "A"/"B"
...

위치를 바꾸어 일관성을 확인하십시오. 만약 순서를 바꿨을 때 승자가 뒤바뀐다면, 그 점수는 답변의 속성이 아니라 순서에 의존하는 것입니다. 이는 여러분이 이미 사용 중인 Judge 호출 코드 주변에 몇 줄만 추가하면 됩니다.

def judge(question, answer_a, answer_b):
    """'A' 또는 'B'를 반환합니다. 여기에 여러분의 LLM-as-judge 호출을 래핑(wrap)하세요."""
    ...
...

저렴한 방식으로 분류(Triage)하세요. 로컬 메트릭(local metric)이나 결정론적 체크(deterministic check)를 사용하면 명확한 사례들을 비용 없이 해결할 수 있으며, 이는 편향된 판사(judge)에 의존하는 횟수를 줄여줍니다. 판사는 정말로 불확실한 꼬리 부분(tail)을 위해서만 남겨두세요. 이것이 도구 선택이 도움이 되는 유일한 지점입니다. 로컬 스코어러(local scorer)를 제공하는 도구들을 사용하면 분류(triage) 과정이 코드 재작성이 아닌 설정 플래그(config flag) 하나로 해결되기 때문입니다.

점수 옆에 일치도(agreement)를 보고하세요. "통과율 94%"라는 말은 그 자체로는 큰 의미가 없습니다. "통과율 94%, 300개 예시의 캘리브레이션 세트(calibration set)에서 판사-인간 카파(kappa) 계수 0.71, 양방향 순서로 채점됨"은 검토자가 신뢰할 수 있는 수치이며, 이를 출력하는 데 드는 작업량은 동일합니다.

이 중 어떤 것도 판사를 편향되지 않게 만들지는 않습니다. 다만 편향을 가시화하고 그 편향이 얼마나 큰지에 대한 수치를 제공할 뿐입니다. 이는 여러분이 직접 만들지 않은 도구에 대해 정직하게 주장할 수 있는 최선입니다.

FAQ

GPT-4는 80% 이상의 확률로 인간과 일치합니다. 그것만으로 충분하지 않나요?
그것은 불일치하는 나머지 20%가 무엇과 상관관계(correlate)를 갖느냐에 전적으로 달려 있습니다. 만약 그 사례들이 무작위(random)라면 평균을 내어 상쇄할 수 있을 것입니다. 하지만 그것들은 무작위가 아닙니다. 그것들은 길이 및 위치와 일치하며, 따라서 오류에는 구조(structure)가 있고, 구조는 평균화해도 살아남습니다. 총체적인 일치도는 괜찮아 보일 수 있지만, 모든 아슬아슬한 판단이 동일한 방향으로 기울어질 수 있습니다.

쌍체 비교(Pairwise)인가요, 아니면 점수제(Pointwise)인가요?
쌍체 비교(A 대 B)는 절대적인 1~10점 척도를 요구하는 것보다 일반적으로 더 안정적입니다. 모델이 상대적인 판단을 일관되게 내리는 것이 더 쉽기 때문입니다. 하지만 쌍체 비교는 위치 편향(position bias)이 발생하는 바로 그 지점입니다. 따라서 쌍체 비교를 선택한다면 두 가지 순서로 모두 채점한 뒤 평균을 내야 합니다. 점수제(Pointwise)는 위치 편향을 피할 수 있지만, 대신 스케일 드리프트(scale drift, 판사의 "10점 만점에 7점"이라는 개념이 실행할 때마다 변하는 현상)와 맞바꾸게 됩니다.

인간의 라벨(human labels)이 영원히 필요한가요?
아니요, 캘리브레이션 샘플(calibration sample)이 필요할 뿐입니다. 수백 개의 예시를 한 번 라벨링하고, 판사-인간 일치도를 측정하십시오. 그리고 새로운 판사 모델, 새로운 프롬프트, 혹은 입력 데이터의 유형 변화와 같이 무언가 변했을 때 다시 확인하십시오. 라벨링은 정기적인 감사(audit)이지, 지속적으로 지불해야 하는 세금이 아닙니다.

더 큰 judge 모델을 사용하면 이 문제가 해결될까요?
더 큰 모델은 원시 일치도(raw agreement)를 높여주기 때문에, 사람들은 자신이 감당할 수 있는 가장 강력한 모델을 찾으려 합니다. 하지만 이는 자기 선호(self-preference)를 악화시킬 수도 있습니다. 더 강력한 judge 모델은 종종 여러분이 테스트 중인 강력한 모델들과 동일한 제품군(family)에 속하는 경우가 많기 때문입니다. 저렴한 방어책은 테스트 대상 모델들과 다른 제품군의 judge를 선택하는 것입니다.

미해결 질문 (Open question)

제가 명확한 답을 내놓지 못하는 문제는 드리프트(drift)입니다. 7월에 인간 라벨(human labels)을 기준으로 보정(calibrate)을 마쳤는데, 9월에 서비스 제공업체가 호스팅된 judge 모델을 조용히 업데이트한다면, 여러분의 카파(kappa) 계수는 이제 검증했던 도구가 아닌 다른 도구를 설명하게 됩니다. 제가 아는 사람 중 누구도 훈련 의존성(training dependency)을 고정(pin)하는 것처럼 judge의 버전을 고정(version-pin)하지 않으며, 대부분의 호스팅된 judge들은 고정할 수 있는 안정적인 버전을 노출하지 않습니다. 그렇다면 얼마나 자주 재보정(recalibrate)하는 것이 충분할까요? 그리고 judge 모델을 자체 변경 이력(changelog)을 가진 고정된 의존성(pinned dependency)으로 취급해야 할까요? 저는 아직 정착된 관행을 보지 못했으며, 효과적인 관행을 가진 분이 있다면 조언을 구하고 싶습니다.