LLM-as-a-Judge 101 – AI 평가 시스템 구축 가이드

by

요약

Arize의 ML 엔지니어 Elizabeth Hutton이 LLM-as-a-Judge 평가 시스템을 구축하는 방법을 처음부터 설명합니다. 데이터 분석, 메트릭 정의, 프롬프트 작성, 모델 선택, 메타 평가까지 4단계 프로세스를 통해 효과적인 AI 애플리케이션 평가 시스템을 만드는 실용적인 가이드를 제공합니다.

주요 내용

1. 평가(Evaluation)의 기본 개념

  • 평가의 정의: 시스템의 성능을 측정하는 프로세스로, AI 애플리케이션의 품질 개선과 반복 개발을 가능하게 함
  • 세 가지 평가 유형:
    • 코드 기반 평가: 정확도, 지연시간, 정밀도/재현율 같은 결정론적 메트릭 사용
    • 사람 기반 평가: 사용자 피드백(thumbs up/down)이나 전문 어노테이터의 라벨링
    • LLM 기반 평가: 사람 수준의 평가를 확장 가능한 방식으로 자동화
  • Andrew Ng의 조언: 불완전하고 부분적이며 노이즈가 있는 평가라도 평가가 없는 것보다 낫다

2. LLM-as-a-Judge의 구조

  • 두 가지 주요 유형:
    • Pairwise 평가: 두 개의 예시를 비교하여 어느 것이 더 나은지 판단 (스포츠 토너먼트 방식)
    • Direct Scoring: 개별 예시를 미리 정의된 기준에 따라 평가 (올림픽 체조 채점 방식)
  • LLM Judge의 구성 요소:
    • 프롬프트: 평가 기준과 가이드라인을 담은 재사용 가능한 템플릿
    • 평가 모델: 판정을 내리는 LLM (애플리케이션과 다른 모델 사용 필수)
    • 스코어링 스키마: 레이블 선택지와 점수, 그리고 판단 근거를 제공하는 설명

3. 4단계 구축 프로세스

Step 1: 데이터 분석 및 큐레이션

  • 좋은 평가는 좋은 데이터에서 시작: 가장 중요한 단계
  • 실제 애플리케이션 관찰: 실제 입력과 출력을 보고 직관을 개발
  • 데이터셋 큐레이션: 실제 데이터가 합성 데이터보다 우수하며, 다양성이 중요
  • Golden Dataset 생성:
    • 정의한 기준으로 데이터를 직접 라벨링
    • 가이드라인이 충분히 명확한지 검증 (사람이 라벨링하기 어려우면 LLM도 어려움)
    • 메타 평가 시 Judge 성능 정량화의 기준점 제공

Step 2: 메트릭 정의

  • 좋은 메트릭의 세 가지 특징:
    • Specific (구체적): 1-10 척도보다 Yes/No 또는 소수의 단어 레이블 사용
    • Answerable (답변 가능): 사람이 명확하게 답할 수 있어야 LLM도 가능
    • Actionable (실행 가능): 낮은 점수를 받았을 때 어떻게 개선할지 알 수 있어야 함
  • 피해야 할 함정:
    • 포괄적 메트릭: “품질” 같은 catch-all 메트릭은 너무 광범위하고 실행 불가능
    • 너무 많은 메트릭: 유창성, 스타일, 톤, 예의 등 중복되는 10개 이상의 메트릭은 인지 과부하 유발
    • 불필요한 메트릭: LLM은 기본적으로 유창하므로 문법성 측정은 대부분 불필요
  • 권장사항: 실제 비즈니스 크리티컬한 실패 모드와 연결된 소수의 메트릭에 집중

Step 3: 프롬프트 작성 및 모델 선택

  • 프롬프트 작성의 세 가지 원칙:
    • Simple (간단하게): 좋은 결과를 주는 최소한의 프롬프트 사용
    • Human-oriented (사람을 위한 글쓰기): 사람 어노테이터를 위한 가이드라인처럼 작성
    • 4K 토큰 제한: 컨텍스트 윈도우를 4,000토큰 이하로 유지 (Babylon 연구 기반)
  • 피해야 할 프롬프팅 함정:
    • “You are an AI evaluator” 같은 역할 설정 (AI가 AI처럼 행동하도록 유도)
    • 응답 형식 지시 (Structured Output으로 해결 가능)
    • Few-shot, Chain-of-thought 같은 고급 기법에 집착 (간단하게 시작)
  • 모델 선택 가이드:
    • 애플리케이션과 다른 모델 사용: GPT-4 mini 사용 시 Claude로 평가 (학생이 자신의 에세이를 채점하는 것과 같음)
    • 추론 모델은 권장하지 않음: O3나 DeepSeek R1 같은 모델은 과할 수 있음
    • 일반적으로 큰 모델이 더 나음: GPT-4O가 GPT-3.5보다, 독점 모델이 오픈소스보다 우수

Step 4: 메타 평가 (Evaluating Your Evaluator)

  • 목적: 평가자를 신뢰하고 개선하기 위해 평가자 자체를 평가
  • 프로세스:
    • Golden Dataset의 사람 라벨과 LLM 라벨 비교
    • 정확도(human alignment) 계산
    • 불일치 사례의 LLM 설명 분석
    • 공통 실패 패턴 파악 및 프롬프트/모델/기준 개선
  • 지속적인 순환 구조:
    • 애플리케이션 개선 루프: 관찰 → 어노테이션 → 평가 → 개선
    • 평가 최적화 루프: 관찰 → 평가 → 개선
    • 두 루프가 상호작용하며 선순환 생성

4. 고급 팁 및 인사이트

비결정적 특성 다루기

  • 변동성을 신호로 활용: 같은 데이터에 대해 10-50회 실행하여 응답 변동성 확인
  • 높은 변동성 = 어려운 예시 또는 개선 필요: 프롬프트나 기준 개선의 기회
  • 온도 설정: 평가 시 높은 온도(1-2) 사용하면 더 나은 탐색 가능

시각화 및 해석

  • Spider Plot 사용: 여러 메트릭을 한눈에 시각화
  • 가중 평균 지양: 모든 메트릭을 하나의 숫자로 축약하면 중요한 신호 손실
  • 독립적 분석: 각 메트릭을 개별적으로 분석하여 구체적인 개선점 파악

다국어 평가

  • 일관성 유지: 입력/출력이 독일어면 Judge 프롬프트도 독일어 사용 권장
  • 다국어 혼합 시: 동적으로 프롬프트 언어 조정 고려

Guardrails vs Evaluations

  • Guardrails: 추론 시점에 작동하여 문제 발생 방지 (실시간 보호)
  • Evaluations: 사후 분석 및 지속적 모니터링 (탐지 및 개선)
  • 악의적 프롬프트 주입: 평가로 탐지 가능하지만 예방은 불가능

핵심 인사이트

  • 데이터가 모든 것의 시작과 끝: 좋은 평가는 철저한 데이터 관찰, 큐레이션, 라벨링에서 시작되며, Golden Dataset은 신뢰할 수 있는 평가 시스템의 기반
  • LLM은 사람 판단을 대체하는 것이 아니라 확장하는 도구: 완전 자동화가 아닌 Human-in-the-loop 접근이 최상의 결과를 만들며, 사람이 이해하고 실행할 수 있는 기준이 핵심
  • 단순함의 힘과 점진적 개선: “완벽한” 평가 시스템을 처음부터 만들려 하지 말고, 최소한의 프롬프트로 시작하여 메타 평가 결과를 바탕으로 점진적으로 개선하는 것이 효과적
  • 구체성과 실행 가능성의 균형: 메트릭은 충분히 구체적이어서 명확한 답을 얻을 수 있으면서도, 낮은 점수 시 어떻게 개선할지 알 수 있을 만큼 실행 가능해야 함
  • 선순환 구조의 이해: 애플리케이션 개선과 평가 시스템 개선이 동시에 진행되는 이중 루프 구조를 이해하면, 더 나은 평가가 더 나은 애플리케이션으로, 다시 더 정교한 평가로 이어지는 virtuous cycle 생성

관련 자료

Leave a Comment