[AI/ML] LLM as Judge를 통한 환각 제어 방법

LLM-as-Judge로 RAG 시스템의 환각을 탐지하되, Position Bias, Verbosity Bias 등 6가지 편향을 인식하고 Position Swapping, 다중 Judge 앙상블, 컨텍스트 직접 인용 등으로 평가 신뢰도를 높이는 실무 가이드입니다.

개요

LLM-as-Judge는 대규모 언어 모델을 평가자로 활용하여 다른 LLM의 출력을 자동으로 평가하는 방법론입니다. 인간 평가에 비해 확장성과 비용 효율성이 뛰어나지만, 다양한 편향(bias)으로 인해 신뢰도가 저하될 수 있습니다.

Faithfulness 평가는 RAG(Retrieval-Augmented Generation) 시스템에서 생성된 답변이 원본 컨텍스트에 충실한지 검증하는 핵심 지표입니다. Judge LLM은 주어진 컨텍스트 내에서 관련 근거를 직접 탐색하여, 답변이 컨텍스트에서 지원되는지(Supported), 모순되는지(Contradicted), 또는 판단할 정보가 부족한지(Not Enough Info)를 분류합니다.

이 문서는 매경AX의 생성형 AI 기반 오디오 팟캐스트 자동 생성 시스템 프로젝트에서 환각 탐지를 위한 LLM-as-Judge 구축 경험을 바탕으로 수행한 경험과 고도화할 내용들을 작성했습니다.

알려진 편향(Bias) 문제

LLM-as-Judge 수행도 사람이 평가하는 것처럼 다양한 편향으로 인해 정확도가 현저히 떨어질 수 있습니다. 편향을 경계하여 평가 정확도를 높히기 위해 논문을 통해 작성된 편향과 기술 블로그를 참고했습니다.

Position Bias

정의: LLM은 입력 순서에 따라 판단이 달라지는 편향입니다. 일반적으로 첫 번째 위치의 옵션을 선호하며, 동일한 입력의 순서만 바꿔도 약 40%의 불일치가 발생합니다.

영향: Faithfulness 평가에서 “Context → Claim” 순서로 제시하면 첫 번째 클레임에 대해 더 관대하게 SUPPORTED로 판정할 가능성이 높습니다. 실제 내용과 무관하게 순서에 의해 평가가 왜곡되는 심각한 문제입니다.

Verbosity Bias

정의: LLM은 긴 응답이나 상세한 설명에 더 높은 점수를 부여하는 편향입니다.

영향: 장황하게 서술된 답변이 실제 사실 관계와 무관하게 “Supported”로 분류될 가능성이 높습니다. 짧지만 정확한 답변보다 길고 그럴듯한 답변이 더 높은 평가를 받는 역설적 상황이 발생합니다.

Self-Enhancement Bias

정의: LLM은 자신이 생성한 출력을 선호하는 경향입니다. 연구에 따르면 GPT-4는 약 10%, Claude는 약 25%의 자기 선호 편향을 보입니다.

영향: 답변 생성 모델과 Judge 모델이 동일하면 객관적 평가가 불가능합니다. GPT-4가 생성한 답변을 GPT-4로 평가하면 실제보다 높은 점수가 나올 수 있습니다.

Authority Bias

정의: 인용, 참조, 출처 표시 등 권위를 나타내는 형식적 요소 텍스트를 더 신뢰하는 편향입니다.

영향: “연구에 따르면…”, “출처: …” 같은 표현이 있으면 실제 내용의 정확성과 무관하게 Supported로 판정될 가능성이 높습니다. 형식적 요소가 실질적 판단을 왜곡합니다.

Agreeableness Bias

정의: LLM Judge가 제시된 출력을 거부하기보다 동조하는 긍정 편향입니다. 올바른 출력 식별(TPR ~96%)에는 뛰어나지만, 잘못된 출력 거부(TNR <25%)에는 현저히 취약합니다.

영향: LLM Judge가 오류, 허위 정보, 논리적 결함이 포함된 응답도 “Supported” 또는 “Correct”로 판정할 가능성이 높습니다. 특히 응답이 그럴듯하게 작성되었거나 자신감 있는 어조를 사용할 경우, 실제 정확성과 무관하게 긍정 판정 경향이 강화됩니다.

편향 및 환각 완화 기법

편향을 줄이고 LLM 평가 정확도를 높히기 위한 방법입니다.

호출 회수가 늘어나거나, 서로 다른 AI 모델 사용으로 인한 제약사항 등이 발생할 수 있습니다. 따라서 가장 적합한 방식을 확인하고 현재 상황에 맞는 방법론을 선택하는 것이 좋습니다.

Position Swapping

[개념]

[방법]

[단점/문제]

다중 Judge 앙상블

[개념]

[방법]

[단점/문제]

생성-평가 모델 분리

[개념]

[방법]

[단점/문제]

컨텍스트 직접 인용 강제

[개념]

[방법]

[단점/문제]

Chain-of-Verification (CoVe)

[개념]

[방법]

[단점/문제]

Self-Consistency

[개념]

[방법]

[단점/문제]

Temperature 설정

[개념]

[방법]

[단점/문제]

Rubric/평가기준 설계

3-Class 분류 체계

클래스 의미 판정 기준
SUPPORTED 클레임이 컨텍스트에서 명시적으로 지원됨 모든 사실이 컨텍스트에 존재, 부분 지원은 해당 안 됨
CONTRADICTED 클레임이 컨텍스트와 직접 모순됨 숫자/날짜/이름 불일치 포함, 부분 모순도 해당
NOT_ENOUGH_INFO 판단할 정보가 컨텍스트에 없음 추론 필요 시 해당, 애매하면 보수적으로 선택

구현한 프로젝트에서는 SUPPORTED/CONTRADICTED 2-Class만 사용했습니다. NOT_ENOUGH_INFO 케이스는 CONTRADICTED로 처리하여 보수적으로 평가했습니다.

프로젝트 요구사항에 따라 2-Class 또는 3-Class를 선택할 수 있습니다.

상세 Rubric 설계 원칙

구체적인 판정 기준은 Judge의 일관성을 크게 향상시킵니다.

SUPPORTED 판정 조건:

CONTRADICTED 판정 조건:

NOT_ENOUGH_INFO 판정 조건:

Few-Shot 예시

연구에 따르면 1-shot 예시가 최적의 성능을 보입니다. 그 이상은 오히려 성능이 저하될 수 있습니다. 다만 Claude 모델의 모범 사례에 따르면 예시 사용 시 품질에 주의해야합니다.

잘못 된 예시를 설정한다면 그대로 따라할 수 있습니다. 예시의 품질이 중요합니다.

효과적인 예시 선정:

SUPPORTED 예시

구어체 변환 (허용):

근사치 변환 (일반 수치):

사실의 논리적 재구성:

CONTRADICTED 예시

잘못된 구어체 변환:

금융 지표 근사치 변환 (금지):

주관적 평가 추가:

NOT_ENOUGH_INFO 예시(가정)

부분 지원:

컨텍스트에 명시되지 않은 정보 가정:

전체 평가 파이프라인 정리

평가 흐름은 팟캐스트 대본 한 문장을 하나씩 평가를 수행합니다.

해당 문장이 주어진 기사(Context) 내에 존재하면 SUPPORTED, 아니라면 CONTRADICTED를 출력합니다. 이를 정리하면 다음과 같습니다.

전체 흐름

답변 → 클레임 분해 → 각 클레임 평가 (컨텍스트 인용) → 결과 집계 → 불확실성 처리

1단계: 클레임 분해 (Claim Extraction)

복잡한 답변을 atomic claim으로 분해하여 각각 평가하는 것이 정확도를 높입니다.

원자적 클레임 조건:

2단계: 클레임별 평가

추출된 각 클레임에서 원본 컨텍스트를 추출하여 독립적으로 평가합니다.

3단계: 결과 집계

개별 클레임 평가 결과를 종합하여 전체 답변의 Faithfulness를 계산합니다.

집계 방식:

환각 없는 운용을 위해 contradicted_contexts_count를 감지하여 재생성을 등록합니다.

{
  "evaluation": {
    "hallucination_metric": 0.0,
    "contradicted_contexts_count": 0,
    "total_contexts": 9,
    "details": [
      {
        "claim": "주장 내용",
        "verdict": "Supported",
        "reasoning": "판정 근거"
      }
    ]
  }
}

4단계: 불확실성 처리

Context 불일치나 낮은 신뢰도 케이스는 별도 처리가 필요합니다.

평가 결과를 기반으로 1회 재생성 합니다. 만약 재생성 → 평가하는 2차 평가에서도 문제가 발생하면 알림을 통해 사람이 개입하여 수정 가능하도록 Human-in-the-Loop 파이프라인을 구축했습니다.

Reference

관련 프로젝트

논문

프롬프트 가이드

평가 프레임워크

기타