LLM-as-a-Judge

LLM-as-a-Judge

LLM-as-a-Judge는 다른 LLM 애플리케이션이 만든 출력의 품질을 LLM으로 평가하는 평가 방법론입니다. 이 문서는 동작 원리, 사용 이유, Observations/Experiments 평가 대상 선택, 설정 방법, 그리고 FAQ를 다룹니다. 인간 심사자나 단순 휴리스틱 메트릭에만 의존하는 대신, 능력 있는 모델(판사)에 프롬프트를 주고 정의된 기준에 따라 출력에 점수와 근거를 매기게 합니다.

출처: 문서

본문

LLM-as-a-Judge는 다른 LLM 애플리케이션이 만든 출력의 품질을 LLM이 평가하는 평가 방법론입니다. 인간 심사자나 단순 휴리스틱 메트릭에만 의존하는 대신, 능력 있는 모델("판사")에 프롬프트를 주어 정의된 기준에 따라 애플리케이션 출력에 점수를 매기고 근거를 제시하게 합니다.

이 접근법은 인간 판단의 미묘함과 자동 평가의 확장성을 결합하기 때문에 LLM 애플리케이션을 평가하는 가장 인기 있는 방법 중 하나가 되었습니다.

평가자와 룰로 실시간 프로덕션 trace에 점수를 매기려면 Evaluate Production Traffic 으로 시작하세요.

LLM-as-a-Judge 동작 방식

핵심 아이디어는 간단합니다. LLM에 입력, 애플리케이션의 출력, 채점 루브릭을 제시하고 출력을 평가하라고 요청합니다. 판사 모델은 자신의 평가를 설명하는 근거와 함께 score 를 생성합니다.

일반적인 LLM-as-a-Judge 프롬프트는 다음을 포함합니다:

• 평가 기준 — "좋음"이 무엇인지 정의하는 루브릭 (예: "답변이 사실적으로 틀리면 1점, 완전히 정확하고 출처가 잘 되어 있으면 5점")
• 입력 컨텍스트 — 원래 사용자 쿼리 또는 프롬프트
• 평가할 출력 — 애플리케이션의 응답
• 선택적 참조 — 비교용 ground truth 또는 expected output

판사 모델은 시간에 따라 추적·집계·분석할 수 있는 구조화된 점수와 근거를 반환합니다. Langfuse에서 그 점수는 숫자형, 범주형, 또는 불리언일 수 있습니다. 숫자 점수는 유용성을 0에서 1로 평가하는 같은 연속적 판단에 사용하세요. correct, partially_correct, incorrect 같은 명시적 라벨이 필요할 때는 범주형 점수를 사용하세요. 사용자가 어시스턴트와 의견이 다른지, 요청이 범위 밖인지, 답변이 정책을 위반하는지 같은 이진 결정은 불리언 점수를 사용하세요. 프로덕션 모니터링 예시는 LLM-as-a-Judge for Production Monitoring 을 참고하세요.

왜 LLM-as-a-Judge를 사용하나요?

• 확장 가능(Scalable): 인간 주석자 대비 수천 개의 출력을 빠르게 평가
• 인간과 유사(Human-like): 단순 메트릭보다 미묘함(예: 유용성, 유해성, 관련성)을 더 잘 포착. 특히 루브릭으로 안내될 때
• 반복 가능(Repeatable): 고정된 루브릭으로 같은 프롬프트를 다시 실행해 일관된 점수 확보

어떻게 사용하나요?

LLM-as-a-Judge 평가자는 Observations(개별 작업) 또는 Experiments(통제된 테스트 데이터셋)에서 실행할 수 있습니다. Observation-level 평가자는 실시간 프로덕션 데이터의 권장 대상이며, trace-level 평가자는 deprecated입니다(아래 참고). 선택은 개발에서 테스트하는지 프로덕션을 모니터링하는지, 어떤 세분화 수준이 필요한지에 따라 달라집니다.

결정 트리(Decision Tree)

어떤 데이터를 평가해야 하나요?

• 실시간 프로덕션 데이터 (실시간 트래픽 모니터링) → Observations (개별 작업: LLM 호출, 검색, 툴 호출)
• 오프라인 실험 데이터 (통제된 환경에서 테스트) → Experiments (데이터셋이 있는 통제된 테스트 케이스)

프로덕션 패턴: 팀은 보통 개발 중에는 Experiments로 변경 사항을 검증한 뒤, 확장 가능하고 정밀한 모니터링을 위해 프로덕션에는 Observation-level 평가자를 배포합니다.

각 평가 대상 이해

실시간 프로덕션 트래픽을 평가해 내 LLM 애플리케이션 성능을 실시간으로 모니터링하세요. trace 내 개별 observations(LLM 호출, 검색 작업, 임베딩 생성, 툴 호출 같은)에 평가자를 실행하세요.

Observation-level 평가자에게 제공되는 데이터: observation-level 평가자는 매칭된 observation에서 변수를 매핑합니다. input, output, metadata, 또는 tool calls를 선택할 수 있습니다. expected output과 experiment item metadata는 프롬프트 실험에서만 사용할 수 있습니다.

같은 trace의 형제(sibling)나 자식 observations는 로드하지 않습니다. 평가자가 애플리케이션/에이전트 호출의 전체 요청과 응답을 필요로 한다면, 그 전체 입력과 출력을 기록하는 논리적 루트 observation을 대상으로 하세요. 논리적 루트는 물리적 부모가 없거나 SDK가 애플리케이션 루트로 명시적으로 표시한 observation입니다. 따라서 물리적 부모가 있을 수 있습니다. 평가자는 여전히 그 루트 observation의 데이터만 봅니다. 애플리케이션이 필요한 요약이나 컨텍스트를 루트 observation에 쓰지 않는 한 자식 observation의 데이터를 자동으로 포함하지 않습니다.

룰 의 Is Root Observation 필터를 사용해 논리적 루트를 대상으로 하세요. 이는 물리적 부모가 없는 것만 선택하는 빈 물리적 부모 필터링과 다릅니다.

Observations를 대상으로 하는 이유

• 훨씬 빠른 실행: 평가가 분 단위가 아니라 초 단위로 완료됩니다. 평가 지연과 백로그를 제거합니다. 비동기 아키텍처가 분당 수천 건의 평가를 처리합니다.
• 작업 수준 정밀도: observation 유형으로 필터링해 전체 워크플로우가 아니라 최종 LLM 응답이나 검색 단계만 평가합니다. 특정 작업을 대상으로 해 평가 볼륨과 비용을 줄입니다.
• 합성 평가(Compositional evaluation): 하나의 trace 안의 다른 작업에 다른 평가자를 실행합니다. 유해성은 LLM 출력에, 관련성은 검색에, 정확성은 generation에 — 동시에.
• 결합 필터링: observation 필터(유형, 이름, metadata)를 trace 필터(userId, sessionId, tags, version)와 결합합니다. 예: "프리미엄 사용자를 위한 'customer-support' 태그의 대화에 있는 모든 LLM generation"

데이터 흐름: 들어오는 observation이 룰의 필터와 일치하면 룰이 연결된 평가자를 트리거합니다. 점수는 특정 observation에 연결되며, 평가자당 observation당 하나의 점수가 됩니다. 같은 trace의 여러 observation이 각각 점수를 받을 수 있습니다.

예시 사용 사례

• 사용자에게 보이는 최종 챗봇 응답의 유용성만 평가
• 모든 고객 대상 LLM generation의 유해성 점수 모니터링
• 문서 검색 observation을 대상으로 RAG 시스템의 검색 관련성 추적

통제된 테스트 데이터셋에 평가자를 실행해 재현 가능한 환경에서 모델 버전, 프롬프트 변형, 시스템 구성을 비교하세요.

Experiments를 대상으로 하는 이유

• 의사결정을 위한 재현 가능한 벤치마크가 필요할 때
• 여러 프롬프트 버전이나 모델 구성을 비교할 때
• expected output(ground truth)이 있는 데이터셋이 있을 때

데이터 흐름: 각 실험 실행은 선택한 평가자가 자동으로 점수를 매기는 traces를 생성합니다. 각 실험 아이템을 테스트 케이스로 생각하세요: input → 실행 → output → 평가.

• 테스트 입력과 (선택적으로) expected output으로 데이터셋을 만듭니다. 테스트 데이터를 로컬에 정의할 수도 있습니다.
• UI 또는 SDK로 실험을 실행합니다 — 각 데이터셋 아이템에 대해 내 애플리케이션 코드를 실행합니다. Experiments via UI 또는 Experiments via SDK 를 참고하세요.
• 선택한 평가자가 생성된 출력에 자동으로 점수를 매깁니다
• 실험 실행 간 결과를 비교해 데이터 기반 결정을 내립니다

예시 사용 사례

• 50개의 고객 지원 질문에서 GPT-4와 Claude Opus를 비교하고, 둘 다 정확성과 유용성으로 평가한 뒤 더 나은 모델을 배포

단계별 설정

LLM 연결 설정

LLM-as-a-Judge 평가자를 사용하려면 LLM Connection 을 설정해야 합니다.

LLM-as-a-Judge 평가자 만들기

Evaluators 페이지로 가서 New evaluator를 클릭하세요. 템플릿 갤러리에서 LLM-as-a-Judge를 선택해 빈 프롬프트로 시작하거나, Langfuse가 제공하는 템플릿을 선택하세요. 템플릿은 새 평가자를 미리 채우며, 원본을 바꾸지 않고 편집할 수 있습니다.

평가자 정의

평가자는 데이터가 어떻게 점수 매겨지는지 정의합니다. 판사 프롬프트, 모델, 점수 정의, 기본 변수 매핑입니다. 룰 은 평가자가 실행될 들어오는 observations를 선택합니다.

• 사용할 모델을 선택하세요. 프로젝트 기본 모델 을 사용하거나 이 평가자 전용 모델을 설정하세요.
• 판사가 필요로 하는 데이터를 위한 {{variables}}로 평가 프롬프트를 작성·편집하세요. 예: {{input}}, {{output}}, {{ground_truth}}.
• 점수 유형 을 선택하세요. 0~1 유용성 같은 값에는 Numeric, 라벨에는 Categorical, true/false 결정에는 Boolean. Categorical 점수의 경우 허용 카테고리를 정의하세요. 여러 카테고리가 적용될 수 있을 때 다중 일치를 허용할 수 있습니다.

변수 매핑

사용하려는 데이터를 클릭해 각 프롬프트 변수를 매핑하세요. 온라인 평가의 경우 observation의 input, output, metadata, tool calls를 선택할 수 있습니다. 프롬프트 실험에서 평가자를 사용하려면 Expected Output과 Experiment Item Metadata도 매핑하세요.

평가자 테스트

오른쪽에서 대표 샘플 observations로 필터링하고 하나를 선택해 평가자를 실행하세요. 점수와 근거를 검사하고, 결과가 유용할 때까지 모델, 프롬프트, 점수 정의, 매핑을 반복하세요.

평가자 저장

저장한 뒤 다음을 할 수 있습니다:

• 테스트 샘플을 선택하는 데 사용한 필터로 룰 을 만들거나, 기존 룰에 평가자를 연결해 들어오는 observation에 실행
• 룰 없이 계속. 배치 평가 나 프롬프트 실험 에서 평가자 사용 가능

✨ 완료! 평가자를 만들고 샘플 observations로 테스트했으며, 룰로 온라인에서 실행할 수 있습니다.

결정적인 커스텀 로직이 필요하다면 코드 평가자 를 사용하거나 외부 평가 파이프라인 에서 점수를 수집하세요. 모든 observation에 대해 비용의 일부로 타입이 정해진 판정(라벨, 루브릭 수준, 예/아니오)이 필요하다면 Jev as a judge 를 사용하세요.

Trace-level 평가자 폐지(deprecation): Trace-level 평가자는 이전의 trace 중심 데이터 모델에 기반하며 Langfuse v4 의 일부로 deprecated입니다. Langfuse Cloud에서 기존 trace-level 평가자는 2026년 11월 16일(2026-11-16) v4 컷오버까지 계속 실행되고 이후 결과 생산을 중단합니다. 셀프 호스팅 Langfuse v4에서 events_only 모드로 실행하면 더 이상 결과를 만들지 않습니다. Multi-span 평가는 새 observations-first 데이터 모델 위에 구축될 것입니다. 기존 trace-level 평가자를 옮기려면 업그레이드 가이드 를 따르세요.

프롬프트 메시지 역할 선택

메시지는 순서대로 LLM-as-a-Judge 모델로 전송됩니다. 모든 역할이 필요하지는 않습니다. 단일 User 메시지만으로도 단순 평가자에는 충분합니다.

역할	사용 시점	예
System	모든 케이스에 적용되는 안정적인 평가자 지침, 루브릭, 제약을 설정. system 메시지는 첫 메시지여야 함	You are a strict evaluator. Check whether the answer is grounded.
User	매핑된 변수를 통해 평가 작업과 변화하는 데이터 제공	Evaluate {{output}} against {{ground_truth}}.
Assistant	LLM-as-a-Judge 평가자가 어떻게 응답해야 하는지에 대한 few-shot 예시를 추가하거나, 멀티턴 대화에서 후속 user 메시지 앞의 어시스턴트 턴을 나타냄	The answer is not grounded because it contradicts the reference text.

멀티모달 평가

LLM-as-a-Judge 평가자는 이미지, 오디오, 문서 등 미디어를 포함하는 observations에 점수를 매길 수 있습니다. {{input}}이나 {{output}} 같은 변수를 평가자 프롬프트에 추가한 뒤, Langfuse media 를 포함하는 observation 필드에 매핑하세요. Langfuse가 미디어 참조를 해석하고 주변 텍스트와 함께 첨부 파일을 LLM-as-a-Judge 모델로 보냅니다.

예를 들어 멀티모달 평가자를 사용해:

• 이미지 설명을 원본 이미지와 비교
• 음성 에이전트 응답을 원본 오디오와 평가
• 답변이 첨부된 PDF에 근거하는지 확인

선택한 LLM-as-a-Judge 모델과 제공자가 미디어 유형을 지원해야 합니다. 그 모델로 미디어를 보낼 수 없으면 Langfuse는 평가자 오류를 반환합니다. 셀프 호스터는 LANGFUSE_EVALUATOR_MEDIA_* 환경 변수 로 미디어 전달과 첨부 크기 제한을 구성할 수 있습니다.

프로젝트 기본 모델(Project default model)

프로젝트 기본 모델은 평가자별 전용 모델을 선택하지 않으면 평가자에 사용됩니다. 평가자마다 모델을 설정하는 대신 프로젝트 전반에서 하나의 모델 구성을 사용할 수 있게 해줍니다.

프로젝트 기본 모델을 업데이트하면 이를 사용하는 모든 평가자가 자동으로 새 모델로 실행됩니다. 프로젝트 전반에서 평가 모델을 일관되게 업데이트하기 쉽게 해줍니다.

API를 통한 프로그래매틱 설정

UI 외에도 공개 API를 통해 LLM-as-a-Judge 평가를 프로그래매틱하게 설정·관리할 수 있습니다. 이는 평가 설정을 버전 관리하고, 프로젝트 간에 복제하고, 배포 파이프라인에서 롤아웃을 자동화하는 데 유용합니다.

설정은 두 리소스로 나뉩니다:

• Evaluators는 데이터를 어떻게 점수 매길지 정의합니다: 판사 프롬프트, {{variables}}, 기본 변수 매핑, 구조화된 출력 정의(숫자, 불리언, 범주형), 선택적 모델 구성. 각 평가자에는 안정적인 ID가 있습니다. 정의를 업데이트하면 새 버전이 생성되고 활성 룰이 자동으로 최신 버전을 사용합니다.
• Evaluation rules는 어떤 실시간 observations를 어떤 것에서 평가할지 정의합니다: 필터, 샘플링 레이트, 하나 이상의 평가자 할당. 할당은 평가자의 기본 매핑을 사용하거나 그 룰에 대해 덮어쓸 수 있습니다. tool_calls 매핑 소스는 observation 데이터에 사용할 수 있습니다.

일반적인 흐름은 평가자를 만들고, 그 안정적인 ID, 변수, 출력 정의를 읽어온 뒤, 룰을 만들고 하나 이상의 평가자를 연결하는 것입니다.

엔드포인트는 코딩 에이전트가 탐색·소비하도록 설계되었습니다. 평가자를 프로그래매틱하게 설정하는 권장 방법은 에이전트를 API 참조로 가리켜 평가자를 만들고 평가 룰을 구성하게 하는 것입니다.

Observation evaluation rules는 =와 <> 연산자를 가진 불리언 isRootObservation 필터를 지원합니다. 논리적 루트를 대상으로 하려면 룰에 이 필터를 포함하세요:

{
  "type": "boolean",
  "column": "isRootObservation",
  "operator": "=",
  "value": true
}

전체 요청/응답 스키마는 안정적인 Evaluators 및 Evaluation Rules API 참조를 참고하세요.

고급 주제(Advanced Topics)

고급 점수 구성

Advanced에서 score description과 score reasoning 필드를 사용해 모델이 반환해야 하는 구조화된 출력에 대해 더 많은 세부 정보를 주세요. 이는 판사가 의도한 점수와 설명을 반환하도록 돕습니다.

Trace-Level에서 Observation-Level 평가자로 마이그레이션

traces에서 실행되는 기존 평가자가 있고 더 나은 성능과 안정성을 위해 observations에서 실행하도록 업그레이드하려면, 종합적인 Evaluator Migration Guide 를 확인하세요.

Observation-Level 평가자 트러블슈팅

observation-level 평가자가 실행되지 않으면 Why is my observation-level evaluator not executing? 에서 일반적인 원인과 해결책을 확인하세요.

과거 observation 점수 backfill

배치 평가 를 사용해 선택한 과거 observations에 LLM-as-a-Judge 평가자를 실행하세요.

LLM-as-a-Judge 실행 디버깅

모든 LLM-as-a-Judge 평가자 실행은 전체 trace를 만들어 평가 과정에 대한 완전한 가시성을 제공합니다. 이를 통해 프롬프트 문제를 디버깅하고, 모델 응답을 검사하고, 토큰 사용량을 모니터링하며, 평가 이력을 추적할 수 있습니다.

tracing 테이블에서 환경 langfuse-llm-as-a-judge로 필터링해 LLM-as-a-Judge 실행 trace를 표시할 수 있습니다.

LLM-as-a-Judge 실행 상태:

• Completed: 평가가 성공적으로 완료됨
• Error: 평가 실패 (세부 사항은 실행 trace ID 클릭)
• Delayed: 평가가 LLM 제공자의 rate limit에 걸려 지수 백오프로 재시도 중
• Pending: 평가가 큐에 대기 중

FAQ

LLM-as-a-Judge 평가란 무엇인가요?

LLM-as-a-Judge는 대형 언어 모델(판사)이 다른 LLM 애플리케이션의 출력 품질을 평가하는 방법론입니다. 판사 모델에 입력, 애플리케이션 출력, 채점 루브릭을 주고 근거와 함께 점수를 만들게 합니다. 인간과 유사한 미묘함과 자동화된 확장성을 결합하기 때문에 LLM 애플리케이션 평가에서 가장 인기 있는 접근법 중 하나입니다.

인간 평가와 비교해 LLM-as-a-Judge는 얼마나 정확한가요?

연구에 따르면 강한 LLM 판사(GPT-5급 모델 같은)는 많은 품질 차원에서 인간 평가자와 80~90% 일치를 달성하며, 이는 인간 간 annotator 일치에 필적합니다. 잘 설계된 루브릭과 명확한 평가 기준으로 정확도가 크게 향상됩니다. 최상의 결과를 위해 LLM-as-a-Judge 설정을 소수의 인간 주석 예시로 보정하세요.

어떤 모델이 LLM 판사로 가장 잘 작동하나요?

가장 능력 있는 모델이 일반적으로 최고의 평가를 만듭니다. 지시 따르기와 추론 능력이 강한 모델(GPT-4o, Claude Sonnet, Gemini Pro 같은)이 흔히 사용됩니다. 판사 모델은 점수를 안정적으로 파싱할 수 있도록 구조화된 출력을 지원해야 합니다. Langfuse에서 판사 모델은 LLM Connections 로 구성합니다.

LLM-as-a-Judge 비용은 얼마인가요?

비용은 판사 모델과 평가되는 입력의 크기에 따라 달라집니다. 일반적인 평가는 평가당 $0.01~0.10입니다. (1) 샘플링으로 일정 비율의 trace만 평가, (2) 전체 trace 대신 특정 observations를 대상, (3) 단순한 평가에는 비용 효율적인 판사 모델 선택으로 비용을 관리할 수 있습니다.

RAG 평가에 LLM-as-a-Judge를 사용할 수 있나요?

네. LLM-as-a-Judge는 RAG 파이프라인에 특히 효과적입니다. 충실도(faithfulness, 답변이 검색된 컨텍스트에 근거하는가), 관련성(relevance, 답변이 질문을 다루는가), 완성도(completeness, 답변이 모든 관련 정보를 다루는가)를 평가할 수 있습니다. Langfuse는 특화된 RAG 평가 메트릭을 위해 RAGAS 와도 통합됩니다.

관련 자료(Related Resources)

• Langfuse Academy: Evaluation — LLM-as-a-judge가 수동 검토와 코드 평가자와 어떻게 맞는지 다룸
• Writing good evaluators — 신뢰할 수 있는 판사 프롬프트를 설계하는 방법
• Choosing what to evaluate — 어떤 품질 검사를 자동화할 가치가 있는지 결정을 돕
• Calibrate your LLM-as-a-judge — 내 판사가 케이스를 라벨링하는 방식과 동의하는지 확인

더 알아보기 (Learn more)

• 출처 문서: LLM-as-a-Judge