Data Eng Wiki

LLM-as-Judge

7 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은 실패가 아닌 제품 기능”

핵심 설계 원칙

  1. 측정 가능한 목적 함수 정의: NMSE 등 사람 판정과의 정량적 비교 메트릭 필수
  2. 구조적 신뢰성: JSON 파싱 실패 등 형식 오류는 평가 불능으로 직결
  3. 체계적 프롬프트 최적화: 수동 튜닝보다 DSPy 같은 자동화 프레임워크가 효과적
  4. 과적합 방지: 학습 예시의 특정 키워드가 프롬프트에 복사되지 않도록 가드레일 필요
  5. 점진적 개선: 프로덕션 judge는 전면 재작성보다 instruction bullet 추가 방식이 안전

한계와 주의사항

  • Judge 편향: LLM 자체의 편향이 존재하며, 특정 토큰/패턴에 과적합 가능
  • Judge 드리프트: 시간 경과에 따라 판정 기준이 미묘하게 변할 수 있음 — 주기적 사람 평가자 교차 검증 필요
  • 비용 비교: LLM judge 비용은 사람 대비 10~100배 저렴하나, 정밀도가 필요한 도메인(의료, 법률)에서는 사람 검증 필수
  • 합성 벤치마크보다 실제 프로덕션 데이터 기반 평가가 신뢰도 높음
  • 도메인 전문가가 평가 기준을 정의하고, LLM은 실행만 담당하는 구조가 이상적

연관 개념

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

그래프 뷰

백링크