Data Eng Wiki

LLM-as-Judge

18 min read

LLM-as-Judge

LLM을 평가자로 활용하여 검색 관련성, 콘텐츠 품질 등을 대규모로 판정하는 기법

핵심 개념

LLM-as-Judge는 사람 평가자 대신 LLM이 품질 판정을 수행하는 패턴이다. 검색 결과 관련성, 생성 텍스트 품질, 데이터 정확성 등 다양한 평가 작업에 적용된다. 수천~수만 건의 평가를 수 시간 내에 저비용으로 수행할 수 있어, 새로운 시장 진출이나 모델 전환 시 특히 유용하다.

프로덕션 사례

Zalando — 검색 품질 보증

신규 시장 출시 전 검색 품질을 사전 검증한 사례:

  • NER 태그 기반 검색 쿼리 클러스터링 → LLM으로 다국어 번역 → GPT-4o가 멀티모달(메타데이터+이미지) 평가
  • 0~4 관련성 척도로 1,500 검색 세그먼트(37,500 결과) 평가
  • 3~5시간, $250 비용으로 3개 신규 시장(룩셈부르크, 포르투갈, 그리스) 검증
  • NER 레머타이제이션 오류, 누락된 용어, 잘못된 상품 데이터 등 사전 발견

Dropbox Dash — DSPy 프롬프트 최적화

관련성 판정 프롬프트를 체계적으로 최적화한 사례:

  • NMSE(Normalized Mean Squared Error)로 사람 판정과의 차이를 측정
  • DSPy GEPA 옵티마이저로 프롬프트 자동 개선 루프
  • 결과: 관련성 오류 45% 감소, JSON 형식 오류 97% 감소
  • 모델 전환(o3 → gpt-oss-120b) 소요 시간: 12주 → 12일
  • 10~100배 더 많은 데이터를 같은 비용으로 레이블링 가능

LinkedIn MUSE Teacher — Judge를 임베딩으로 증류

LLM-as-Judge의 판정을 임베딩 모델의 학습 신호로 쓰는 한 단계 진화:

  • “qualified”의 product policy(relevance 정의 + Responsible AI)를 prompt에 encode → constitution. Expert Judge(proprietary LLM)가 gold-standard + seed 라벨 생성
  • teacher 확장: Expert Judge는 비용·지연으로 수십만 라벨에 그침 → open-weight reasoning 모델을 prompt-engineering으로 Expert Judge 판정을 수백만 건으로 복제(MUSE Teacher). 이 라벨로 dual-tower 임베딩을 contrastive 학습
  • chain-of-thought가 정확도 좌우: 명시적 추론 후 판정하는 모델이 바로 답하는 모델보다 systematically 정확(같은 파라미터 수에서도). teacher prompt 반복으로 +24% Kappa(role 컨텍스트 추가, over/under-qualified worked example, scratchpad, constitution encode)
  • 놀라운 발견: 고신뢰 LLM이 human 라벨러보다 정확(knowledge-intensive 라벨링에서 5건 중 4건은 human이 틀림). “human 라벨을 ceiling이 아닌 noisy signal로 취급”
  • 선택 메트릭: weighted Cohen’s Kappa(chance 보정 + 불일치 심각도)

Shopify Sidekick — Judge Consensus로 학습 데이터 curate

LLM judge를 학습 데이터 큐레이션 엔진으로 활용한 사례. 문제: 프로덕션 로그는 성공 쿼리만 담아 모델이 “거절”(불가능한 요청 거부)을 못 배움:

  • 작은 seed(Toloka ~600 standard + 602 refusal)로 4개 frontier LLM을 few-shot calibrate(human 주석에 anchor) → 전체 corpus 평가 + conflict resolver
  • strict consensus over confidence: 4개 모두 decision + reasoning 일치할 때만 라벨 통과(불일치는 arbitrate 아닌 filter). precision > recall(“4개가 동의 못하면 human이 결정”)
  • mutually exclusive taxonomy 필수(모호하면 judge 불일치 → 라벨 불일치 전파)
  • data flywheel: 개선 모델 배포 → production 트래픽이 다음 샘플 → judge가 새 패턴 라벨 → corpus 추가 → 다음 fine-tune이 더 크고 깨끗한 baseline
  • 성과: segmentation eval +28.9%, judge ensemble Cohen’s kappa > 0.75. 교훈: “작은 고품질 seed가 큰 역할”, “초기엔 consensus > confidence”, “refusal은 실패가 아닌 제품 기능”

Netflix — judge의 라이프사이클 (RART + 드리프트 밴드)

앞선 사례들이 “judge를 어떻게 잘 만드는가”에 집중한다면, Netflix의 추천 설명(recommendation explanation) 사례는 judge를 정적 아티팩트가 아니라 라이프사이클을 가진 시스템으로 다룬 것이 기여다.

LLM judge는 절대 홀로 작동해서는 안 된다. 인간 판단에 anchor되어야 한다.

네 단계: Birth(벤치마크 생성) → Training(정렬) → Deployment(gate + critic) → Monitoring(드리프트). 각 단계에 사람 오너가 있다.

실패 모드 — “맞는 답, 틀린 이유”

라벨 일치 지표에 전혀 나타나지 않는 실패 모드가 있다. judge가 사람과 라벨은 일치하면서 틀린 이유로 옳은 판정에 도달하는 것이다.

대시보드에서는 완벽히 정렬된 것으로 보인다. 하지만 self-revision을 이끌기 위해 거부를 설명하라고 하는 순간 오도하는 가이던스를 반환한다.

judge를 critic으로도 쓰는 순간(아래 참조) 이것이 실제 손해가 된다.

RART (Reasoning-Aligned Rubric Tuning)

네 컴포넌트의 분업이 핵심 설계다:

컴포넌트역할
Judgerubric에 대해 점수화 → 라벨 + rationale 반환
Meta-Judgejudge의 rationale을 인간의 rationale과 비교
Reflectorrubric 텍스트 자체를 수정. 설명을 직접 평가하지 않는다
Human raters라벨 그리고 서술형 rationale 제공

모든 Judge가 rubric으로 파라미터화된 고정 프롬프트 템플릿이므로 튜닝이 기저 모델 재학습을 뜻하지 않는다 — rubric 텍스트만 반복 수정한다.

표준 self-improvement 루프와의 차이는 “실수”의 정의다. focus set이 두 오류 클래스의 합집합이다:

  1. 라벨 불일치 (보통의 루프가 보는 것)
  2. 맞는 라벨, 틀린 이유 — judge와 사람이 둘 다 FAIL이라 했는데 Meta-Judge가 두 rationale이 어긋난다고 판정한 경우

ablation 결과가 이것이 장식이 아님을 보여준다: 시작 rubric이 ceiling 근처였던 두 기준에서는 vanilla(라벨 전용)와 RART가 동률이었지만, 여지가 있던 세 번째 기준에서 vanilla는 rubric을 degenerate한 형태로 다시 써서 specificity와 reasoning agreement가 매 반복 하락, 결국 시작 rubric보다 나빠졌다. RART는 안정적으로 유지하며 둘 다 끌어올렸다.

라벨 전용 optimizer는 불건전한 추론을 통해 옳은 라벨에 도달할 수 있고, 불건전한 추론은 새 데이터에 일반화되지 않는다.

⚠️ Meta-Judge도 LLM이므로 먼저 사람에 대해 검증해야 한다. Netflix는 훈련된 rater가 agreed-fail rationale 쌍을 라벨링하게 해 Meta-Judge가 거의 전부에서 일치함을 확인한 뒤에야 썼다.

기준별 세 지표

기준마다 별도 judge를 두고 per-criterion으로 측정한다:

지표의미
Specificity (fail-recall)나쁜 출력을 올바르게 거부하는 비율. 가장 중요 — gate를 빠져나간 나쁜 출력은 신뢰 위험
Recall (pass-recall)좋은 출력을 올바르게 통과시키는 비율. 커버리지↑, 수정 비용↓
Reasoning agreement둘 다 거부한 것에 대해 같은 이유로 거부하는 비율

하나가 건강한데 다른 하나가 미끄러질 수 있다. 그래서 gate도 엄격하다 — 모든 must-have 기준을 통과해야 서빙 대상이 된다.

하나의 judge, 두 역할 — gate + critic

정렬이 비싼 부분이니 judge 하나를 제대로 만들어 한 번 이상 써라.

  • gate — 실패하는 것을 거부
  • critic — judge의 free-text 이유를 Generator 프롬프트에 추가해 재시도 → generate → judge → revise 루프

재시도는 제한한다. 1,000개 출력을 4개 generator로 최대 12회 수정한 실험에서 모든 곡선이 오르지만 가파른 부분은 초기이고 generator 간 격차가 명백했다:

수정은 약한 generator를 구조하는 게 아니라 유능한 generator를 증폭한다.

Netflix는 가장 강한 generator + 재시도 3회를 쓰고, 그 뒤에도 실패하면 서빙하지 않고 드롭한다.

두 결과가 대칭적이지 않다 — 나쁜 출력은 신뢰 위험이고, 없는 출력은 기회를 포기할 뿐이다. 의심스러우면 아무것도 안 보여주는 쪽을 택한다.

⭐ 드리프트 임계를 인간 불일치로 정하기

이 사례의 가장 이전 가능한 아이디어다. 고정 임계 대신 그 주 사람 rater들의 spread를 밴드로 쓴다.

  • 매주 약 300개 출력을 뽑아 리뷰. judge의 결정(served/revised/dropped)에 걸쳐 층화하고 드리프트가 가장 일어나기 쉬운 신규 항목에 가중. 층화를 주마다 고정해 주 간 비교 가능하게
  • 최소 3명 rater 패널, 다수 라벨이 ground truth
  • judge와 각 rater를 같은 다수 라벨에 대해 점수화하고, judge가 평균 rater보다 2 표준편차 아래보다 나쁘지 않을 것을 요구
  • 어려운 주는 인간 불일치를 넓히고 밴드도 함께 넓어지므로, judge가 사람들도 느낀 난이도로 벌받지 않는다

밴드 아래로 떨어지면 drift event → 증강된 벤치마크로 재튜닝(Training 단계로 복귀). ⚠️ 재튜닝된 rubric은 절대 자동으로 라이브에 가지 않는다 — 사람이 제안된 변경을 읽고 서명하고, 즉시 롤백을 위해 이전 rubric을 보관한다.

드리프트 탐지만으로는 부족하다

주간 인간 리뷰가 judge-rater 일치에 나타나지 않는 것을 잡는다:

  • 정확한 속성을 쓰면서도 유사도를 과장
  • 모호한 형용사 하나(“exciting”, “fun”)가 기술적으로 rubric을 만족시키면서 거의 아무것도 말하지 않음
  • 참조 자체가 부적절 — 속성이 아무리 맞아도 사용자에게 이상하게 착지
  • 모든 기준을 만족하면서 일반적 “word soup”

드리프트 탐지는 judge를 현재 rubric에 정렬시킨다. 지속적 인간 리뷰는 rubric을 실제로 작동하는 것에 정렬시킨다. 둘 다 필요하다.

패턴이 반복되면 Phase I 가이드라인을 갱신하고, 그것이 rater 지침과 judge rubric을 동시에 seed하므로 한 번의 수정이 양쪽을 갱신한다.

오프라인 정렬은 필요하지만 충분하지 않다

judge 통과는 우리 기준으로 좋다는 증명이지 사용자에게 유용하다는 증명이 아니다. Netflix는 약 한 달간 설명 vs 설명 없음 온라인 A/B를 별도로 돌려 회원 행동 변화(미시청 타이틀로의 이동, 의미 있는 재생 증가)를 확인했다.

오프라인 rater 일치는 필요했지만 회원에게 도움이 됨을 보이기에는 결코 충분하지 않았다. → A-B Testing and Experimentation

핵심 설계 원칙

  1. rationale을 라벨과 함께 수집하라: 적당한 크기의 rationale 주석 벤치마크가 큰 라벨 전용 벤치마크를 이긴다. 인간의 이유를 적어두지 않으면 judge의 추론을 교정할 수 없다
  2. 측정 가능한 목적 함수 정의: NMSE 등 사람 판정과의 정량적 비교 메트릭 필수
  3. 구조적 신뢰성: JSON 파싱 실패 등 형식 오류는 평가 불능으로 직결
  4. 체계적 프롬프트 최적화: 수동 튜닝보다 DSPy 같은 자동화 프레임워크가 효과적
  5. 과적합 방지: 학습 예시의 특정 키워드가 프롬프트에 복사되지 않도록 가드레일 필요
  6. 점진적 개선: 프로덕션 judge는 전면 재작성보다 instruction bullet 추가 방식이 안전

한계와 주의사항

  • Judge 편향: LLM 자체의 편향이 존재하며, 특정 토큰/패턴에 과적합 가능
  • Judge 드리프트: 시간 경과에 따라 판정 기준이 미묘하게 변할 수 있음 — 주기적 사람 평가자 교차 검증 필요. 드리프트가 조용히 진행되면 다운스트림의 어떤 것도 그것을 플래그하지 않는다 → Silent Failures and Data Integrity
  • “맞는 답, 틀린 이유”는 라벨 지표에 안 보인다 — judge를 critic으로도 쓸 계획이라면 rationale 정렬을 반드시 측정하라
  • 비용 비교: LLM judge 비용은 사람 대비 10~100배 저렴하나, 정밀도가 필요한 도메인(의료, 법률)에서는 사람 검증 필수
  • 합성 벤치마크보다 실제 프로덕션 데이터 기반 평가가 신뢰도 높음
  • 도메인 전문가가 평가 기준을 정의하고, LLM은 실행만 담당하는 구조가 이상적
  • 오프라인 judge 일치는 사용자 가치의 대리 지표가 아니다 — 온라인 실험으로 별도 확인 필요

자동 평가를 도입하는 것은 그에 대한 책임을 위임하는 것과 같지 않다. 아무도 감사하지 않는 자동 평가자는 자신이 내리는 결정에 대해 아무 보증도 제공하지 않는다.

연관 개념

Source: Search Quality Assurance with LLM Judge, Optimizing Dropbox Dash Relevance Judge with DSPy, MUSE - Semantic Search for LinkedIn Hiring Assistant, Teaching Sidekick to Say No - LLM Judge Consensus at Shopify, The Lifecycle of LLM-as-a-Judge - Building Aligning and Monitoring at Scale

그래프 뷰

백링크