블로그 목록으로

[AI 에이전트] 5주차 RAG 평가와 Ragas 핵심 메트릭

원문 보기
#AI Agent

RAG 평가 데이터셋과 Golden Dataset의 필요성을 살펴보고, LLM-as-a-Judge와 Ragas 핵심 메트릭을 활용해 검색·생성 단계의 품질과 오류 원인을 진단하는 방법을 정리했습니다.

이번 시간에는 AI Agent와 RAG 파이프라인의 성능을 객관적으로 평가하기 위한 방법을 정리합니다.

일반적인 소프트웨어는 입력과 예상 출력이 명확하므로 테스트의 성공 여부를 비교적 쉽게 판단할 수 있습니다. 하지만 LLM은 같은 질문에도 서로 다른 표현의 답변을 생성할 수 있어 단순한 문자열 비교만으로는 품질을 정확히 평가하기 어렵습니다.

따라서 실제 서비스에서 발생할 수 있는 질문과 기준 답안을 포함한 평가 데이터셋을 구성하고, 검색 단계와 생성 단계를 구분하여 평가할 수 있는 체계적인 지표가 필요합니다.

이번 글에서는 평가 데이터셋과 Golden Dataset이 필요한 이유를 살펴보고, LLM을 평가자로 활용하는 LLM-as-a-Judge의 원리와 한계를 정리합니다. 또한 Ragas에서 제공하는 Context Precision, Context Recall, Faithfulness, Answer Relevancy, Answer Correctness를 통해 RAG 파이프라인의 문제를 어떻게 진단할 수 있는지 알아보겠습니다.

평가 데이터셋

1. 정의

평가 데이터셋은 AI 시스템의 성능을 측정하고 테스트하기 위해 사용하는 데이터 모음을 의미합니다.

실제 사용자가 입력할 수 있는 질문과 기준 답안, 검색 문서, 생성된 답변 등을 데이터셋으로 구성하고 이를 바탕으로 AI의 검색 성능과 답변 품질을 평가합니다.

2. 평가 데이터셋이 필요한 이유

AI의 신뢰도를 측정하려면 실제로 발생할 수 있는 다양한 시나리오와 통계적으로 의미 있는 데이터를 이용해 반복적으로 테스트해야 합니다.

몇 개의 질문에 정상적으로 답변했다는 사실만으로는 AI 시스템의 전체 성능을 판단하기 어렵습니다.

평가 데이터셋을 활용하면 다음 항목을 확인할 수 있습니다.

  • 다양한 질문 유형에서도 안정적으로 답변하는지
  • 프롬프트나 모델 변경 후 기존 성능이 유지되는지
  • 검색과 생성 단계 중 어느 부분에서 문제가 발생하는지
  • 특정 유형의 질문에서 반복적으로 실패하는지
  • 서비스에 적용할 수 있을 만큼 신뢰할 수 있는지

3. 필수 스키마(v0.2+)

Ragas 평가 데이터셋에는 일반적으로 다음과 같은 필드가 사용됩니다.

  • user_input

    • 사용자가 시스템에 전달하는 질문이나 프롬프트

  • response

    • AI 시스템이 생성한 실제 답변

  • reference

    • 평가의 기준이 되는 실제 정답 또는 모범 답안

  • retrieved_contexts

    • AI가 답변을 생성하기 위해 데이터베이스(Vector DB 등)에서 검색한 참고 문서

평가 목적에 따라 다음과 같은 필드를 추가로 사용할 수 있습니다.

  • reference_contexts

    • 질문에 답하기 위해 반드시 검색되어야 하는 기준 문서

  • rubrics

    • 답변을 평가하기 위한 기준과 조건

예시는 다음과 같습니다.

{
    "user_input": "RAG에서 Re-ranking을 사용하는 이유는 무엇인가요?",
    "response": "검색된 후보 문서의 순위를 다시 계산해 관련성이 높은 문서를 상단에 배치하기 위해 사용합니다.",
    "reference": "Re-ranking은 1차 검색 결과를 다시 평가해 질문과 관련성이 높은 문서를 상위에 배치하는 과정입니다.",
    "retrieved_contexts": [
        "Re-ranking은 Retrieval과 Generation 사이에서 검색 문서의 순위를 재조정합니다."
    ]
}

4. 권장 데이터셋 규모

단계권장 개수근거
초기(PoC)20~50개핵심 기능을 검증하고 주요 실패 사례를 식별하기 위한 최소 규모
성숙(Production)100~300개다양한 사용자 시나리오와 질문 유형을 평가하기 위한 규모
대규모(Scale)500개 이상기능 변경과 모델 교체에 따른 회귀 테스트를 지속적으로 수행하기 위한 규모

데이터셋의 적절한 크기는 서비스의 복잡도와 질문 유형에 따라 달라질 수 있습니다.

초기에는 적은 수의 고품질 데이터로 시작하고, 실제 운영 중 발견된 실패 사례를 지속적으로 추가하는 방식이 효과적입니다.

5. 양보다 질: 좋은 데이터셋의 조건

평가 데이터셋은 단순히 데이터 수가 많다고 해서 좋은 것은 아닙니다.

좋은 평가 데이터셋은 다음 조건을 만족해야 합니다.

  • 품질이 높은 질문과 기준 답안을 포함해야 한다.
  • 실제 서비스에서 발생할 수 있는 여러 시나리오를 포함해야 한다.
  • 정상적인 질문뿐만 아니라 예외 상황과 실패 사례도 포함해야 한다.
  • 쉬운 질문과 어려운 질문이 균형 있게 구성되어야 한다.
  • 데이터가 중복되지 않아야 한다.
  • 서비스와 데이터 변경에 맞춰 지속적으로 업데이트해야 한다.

특히 운영 과정에서 발견된 실패 질문을 데이터셋에 추가하면 동일한 문제가 다시 발생하는지 회귀 테스트를 통해 확인할 수 있습니다.

6. ground_truth_contexts 수동 어노테이션이 필요한 이유

ground_truth_contexts는 질문의 정답이 실제로 포함된 문서를 사람이 직접 지정한 데이터입니다.

어떤 문서가 정답을 포함하고 있는지 미리 정의해야 검색기가 올바른 문서를 가져왔는지 객관적으로 평가할 수 있습니다.

이를 통해 다음 항목을 확인할 수 있습니다.

  • 검색기가 정답 문서를 실제로 검색했는지
  • 필요한 문서를 빠짐없이 가져왔는지
  • 관련 없는 문서가 상위 검색 결과에 포함되었는지
  • 검색 실패로 인해 잘못된 답변이 생성되었는지
  • 검색 문서와 무관한 환각이 발생했는지

관련 메트릭

  • Context Precision

    • 검색된 문서 중 정답과 관련된 문서가 상위에 배치되었는지 평가

  • Context Recall

    • 답변에 필요한 정보를 포함한 문서를 충분히 검색했는지 평가

  • Faithfulness

    • 생성된 답변의 주장이 검색된 컨텍스트를 통해 뒷받침되는지 평가

참고 자료

평가의 필요성과 LLM-as-a-Judge

2-1. 왜 체계적인 평가가 필요한가

AI Agent나 RAG 파이프라인을 구축한 후에는 해당 AI가 실제로 잘 작동하는지 객관적으로 확인해야 합니다.

일부 질문에 대한 결과만 보고 “답변이 괜찮다”라고 판단하면 시스템의 전반적인 성능을 정확하게 파악하기 어렵습니다.

따라서 단순한 감에 의존하는 것이 아니라 일관된 평가 데이터와 체계적인 지표를 사용해야 합니다.

회귀 탐지의 어려움

프롬프트를 수정하거나 모델을 변경하면 특정 답변의 품질은 좋아질 수 있지만, 기존에 정상적으로 처리하던 답변의 품질이 낮아질 수도 있습니다.

평가 데이터셋이 없다면 이러한 성능 저하를 발견하기 어렵습니다.

디버깅 지점의 모호성

RAG 파이프라인에서 오답이 생성되더라도 다음 중 어느 단계에서 문제가 발생했는지 바로 파악하기 어렵습니다.

사용자 질문
→ 검색
→ 문서 정렬
→ 컨텍스트 구성
→ 답변 생성

검색 단계와 생성 단계를 각각 평가할 수 있는 지표가 있어야 문제의 원인을 추적할 수 있습니다.

비교 기준의 부재

여러 LLM, 임베딩 모델, 검색 방식, 프롬프트를 객관적으로 비교하려면 동일한 데이터셋과 평가 기준이 필요합니다.

운영 도입 기준

AI 시스템의 가장 큰 특징 중 하나는 결과의 불확실성입니다.

정확도와 품질을 나타내는 기준이 없다면 서비스 출시 여부를 결정하기 어렵고, 출시 이후 발생하는 품질 저하에도 체계적으로 대응하기 어렵습니다.

소프트웨어 테스트와 LLM 평가 비교

구분일반 소프트웨어 테스트(Unit/Integration)LLM 평가(Evaluation)
입력과 출력입력에 따른 출력이 명확함같은 입력에도 출력이 달라질 수 있음
성공 여부true와 false로 명확하게 구분 가능의미, 유사도, 정확성 등의 정도를 측정
검증 방식코드 로직과 반환값 검증언어적 맥락과 지식의 타당성 검증
정답 형태하나의 명확한 결과가 존재하는 경우가 많음여러 표현이 모두 정답이 될 수 있음
주요 평가 방법Assert, Unit Test, Integration Test의미적 유사도, LLM Judge, 사람 평가

일반 소프트웨어는 예상 결과와 실제 결과가 일치하는지 비교할 수 있습니다.

반면 LLM의 답변은 표현이 매번 달라질 수 있으므로 단순 문자열 일치만으로 정답 여부를 판단하기 어렵습니다.

회귀 테스트와 Golden Dataset의 연결

전통적인 개발에서 회귀 테스트는 기존 기능이 변경 이후에도 정상적으로 동작하는지 확인하는 과정입니다.

LLM 시스템에서는 이를 위해 Golden Dataset을 사용할 수 있습니다.

Golden Dataset은 일반적으로 다음과 같이 구성됩니다.

질문
+ 기준 답안
+ 기준 문서
+ 평가 기준

프롬프트, 모델, 임베딩 모델, 청킹 전략 또는 검색 방식을 변경할 때마다 동일한 질문 세트를 실행해 이전 결과와 비교합니다.

이를 통해 다음과 같은 문제를 발견할 수 있습니다.

  • 새로운 프롬프트가 기존 질문의 성능을 낮춤
  • 모델 교체 후 특정 도메인의 정확도가 감소함
  • 청킹 전략 변경 후 검색 Recall이 낮아짐
  • Re-ranking 적용 후 일부 질문의 정답 문서가 하위로 이동함

참고 자료

자동 평가와 사람 평가의 Trade-off

평가 방식은 크게 세 가지로 나눌 수 있으며, 비용·시간·신뢰성 사이에 상충 관계가 존재합니다.

전통적인 지표(BLEU, ROUGE)
  • 단어 또는 n-gram의 중첩 정도를 계산
  • 빠르고 저렴함
  • 동일하거나 유사한 표현을 평가하는 데 유용함
  • 의미가 같지만 표현이 다른 답변을 낮게 평가할 수 있음
  • 창의적인 답변과 긴 설명을 평가하는 데 한계가 있음
사람 평가(Human Evaluation)
  • 사람이 직접 답변의 정확성, 관련성, 자연스러움을 평가
  • 복잡한 맥락을 이해할 수 있음
  • 평가 품질이 높음
  • 비용과 시간이 많이 소요됨
  • 평가자마다 판단 기준이 달라질 수 있음
LLM-as-a-Judge
  • LLM에 평가 기준과 답변을 제공하고 점수와 평가 근거를 생성
  • 사람 평가보다 빠르고 저렴함
  • 전통적인 문자열 기반 지표보다 의미와 맥락을 잘 평가함
  • 대규모 데이터셋을 자동으로 평가할 수 있음
  • 평가 모델 자체의 편향과 오류가 결과에 반영될 수 있음
평가 방식비용속도의미 이해확장성
BLEU·ROUGE낮음매우 빠름낮음높음
Human Evaluation높음느림높음낮음
LLM-as-a-Judge중간빠름높음높음

참고 자료

2-2. LLM-as-a-Judge

등장 배경

전통적인 평가 지표의 한계

기존 텍스트 생성 평가에서는 BLEU나 ROUGE와 같이 참조 답안과의 n-gram 중첩을 계산하는 자동 평가 지표를 사용했습니다.

하지만 같은 의미를 가진 문장이라도 표현 방식이 다르면 낮은 점수를 받을 수 있습니다.

특히 창의성과 다양성이 필요한 작업에서는 문자열 중첩만으로 실제 답변 품질을 정확히 판단하기 어렵습니다.

사람 평가의 비용적인 한계

수많은 LLM 답변을 사람이 직접 평가하려면 많은 비용과 시간이 필요합니다.

평가 데이터가 증가할수록 사람 평가만으로 지속적인 회귀 테스트를 수행하기 어려워집니다.

이러한 문제를 해결하기 위해 LLM을 평가자로 사용하는 LLM-as-a-Judge 방식이 등장했습니다.

작동 원리

LLM-as-a-Judge는 평가 대상과 평가 기준을 LLM에 제공하고, 이를 바탕으로 점수와 평가 근거를 출력하게 하는 방식입니다.

질문
+ 검색 컨텍스트
+ 생성된 답변
+ 기준 답안
+ 평가 루브릭
        ↓
   Judge LLM
        ↓
점수 + 평가 근거

평가 항목에 따라 필요한 입력 정보는 달라질 수 있습니다.

예를 들어 Faithfulness를 평가하려면 생성된 답변과 검색된 컨텍스트가 필요하고, Answer Correctness를 평가하려면 생성된 답변과 기준 답안이 필요합니다.

사람 평가와의 일치율

LLM을 평가자로 사용했을 때 사람의 선호도 평가와 높은 일치율을 보인 연구 결과가 있습니다.

특히 GPT-4와 같은 모델을 평가자로 사용할 경우 사람의 판단과 높은 수준의 일치도를 보였다고 보고되었습니다.

다만 평가 대상, 평가 기준, 데이터의 특성에 따라 결과가 달라질 수 있으므로 사람 평가를 완전히 대체하기보다는 보조 평가 수단으로 활용하는 것이 적절합니다.

루브릭 설계 원칙

LLM Judge의 신뢰도를 높이려면 평가 기준인 루브릭을 명확하게 설계해야 합니다.

명확성과 구체성

평가 기준과 원하는 출력 형식을 구체적으로 명시해야 합니다.

좋지 않은 예시는 다음과 같습니다.

알 수 없는 내용이면 예측하지 마세요.

이 지시는 무엇을 예측으로 판단할지, 어떤 형식으로 응답해야 할지 명확하지 않습니다.

개선된 예시는 다음과 같습니다.

제공된 문서에서 답을 찾을 수 없다면 “질문에 대한 답을 찾을 수 없습니다.”라고 답변하세요.

이 기준은 결과를 Yes 또는 No로 평가할 수 있을 만큼 구체적입니다.

부정문보다 긍정적인 지시 사용

“무엇을 하지 말아야 하는지”보다 “어떻게 행동해야 하는지”를 구체적으로 지시하는 것이 좋습니다.

나쁜 지시
→ 모르는 내용을 추측하지 마세요.

개선된 지시
→ 제공된 컨텍스트에 근거가 없으면
  "제공된 정보만으로 답변할 수 없습니다."라고 답변하세요.
평가 단계를 분리

여러 기준을 한 번에 평가하게 하면 판단이 불안정해질 수 있습니다.

정확성, 관련성, 충실도, 표현 품질 등을 별도의 항목으로 분리하는 것이 좋습니다.

출력 형식 고정

평가 결과를 일정한 JSON 형태로 출력하게 하면 자동화된 평가 파이프라인에서 처리하기 쉽습니다.

{
  "score": 4,
  "reason": "답변은 검색된 문서의 핵심 내용을 포함하고 있으며 외부 정보가 추가되지 않았습니다."
}

한계와 신뢰성

LLM을 평가자로 사용하는 방식에도 여러 한계가 존재합니다.

위치 편향(Position Bias)

두 답변을 순서대로 제공하면 먼저 제시된 답변이나 특정 위치의 답변을 선호할 수 있습니다.

장황함 편향(Verbosity Bias)

핵심 내용이 같더라도 길고 상세한 답변을 더 높은 품질로 평가할 수 있습니다.

자기 선호 편향(Self-preference Bias)

평가 모델이 자신과 유사한 모델이 생성한 답변이나 자신의 문체와 유사한 답변을 더 높게 평가할 수 있습니다.

추론 능력의 한계

복잡한 수학 문제, 전문 지식 또는 다단계 추론이 필요한 문제에서는 평가 모델 자체의 추론 오류가 평가 결과에 영향을 줄 수 있습니다.

평가 결과의 비결정성

동일한 평가 입력을 제공해도 모델 설정이나 샘플링에 따라 결과가 달라질 수 있습니다.

이러한 한계를 줄이려면 다음 방법을 사용할 수 있습니다.

  • 평가 순서를 바꾸어 여러 번 평가
  • 여러 Judge 모델의 결과를 종합
  • 낮은 Temperature 사용
  • 평가 기준을 구체적인 루브릭으로 작성
  • 평가 근거를 함께 출력
  • 일부 데이터는 사람이 다시 검토
  • 동일 평가를 여러 번 수행해 평균값 사용

참고 자료

Ragas와의 관계

Ragas는 RAG 시스템의 검색 및 생성 품질을 평가하기 위해 다양한 메트릭을 제공합니다.

Ragas의 평가 방식은 크게 LLM Judge 기반과 규칙 기반으로 구분할 수 있습니다.

LLM Judge 기반 메트릭

  • Faithfulness

    • 생성된 답변이 검색된 컨텍스트에 근거하는지 평가

  • Answer Relevancy

    • 답변이 사용자의 질문 의도와 관련 있는지 평가

  • Answer Correctness

    • 생성된 답변과 기준 답안이 얼마나 일치하는지 평가

  • Context Precision

    • 검색된 컨텍스트 중 관련 문서가 상위에 배치되었는지 평가
규칙 기반 메트릭
  • 텍스트 일치율
  • 토큰 중첩률
  • 문자열 비교
  • 검색 결과 순위 기반 계산
  • 임베딩 유사도 계산

메트릭마다 LLM, 임베딩 모델 또는 규칙 기반 계산 방식의 사용 여부가 다르므로 평가 비용과 실행 시간을 함께 고려해야 합니다.

Ragas 핵심 메트릭

RAG 파이프라인은 크게 검색 단계와 생성 단계로 구분할 수 있습니다.

질문
→ 검색(Retrieval)
→ 컨텍스트
→ 생성(Generation)
→ 답변

각 단계에서 발생하는 문제를 구분하기 위해 서로 다른 메트릭을 사용합니다.

단계주요 메트릭
검색 단계Context Precision, Context Recall
생성 단계Faithfulness, Answer Relevancy
전체 파이프라인Answer Correctness

Context Precision: 컨텍스트 정밀도

1. 정의

Context Precision은 Retriever가 검색한 문서 중 질문과 관련된 문서가 검색 결과의 앞쪽에 얼마나 잘 배치되었는지를 측정하는 지표입니다.

즉, 관련 있는 정보가 상위 검색 결과에 집중되어 있는지를 평가합니다.

2. 계산 방식

관련 문서가 상위 k번째에 위치할수록 높은 점수를 받도록 계산합니다.

예를 들어 관련 문서가 검색 결과의 1위와 2위에 있다면 높은 점수를 받을 수 있지만, 8위와 10위에 있다면 상대적으로 낮은 점수를 받습니다.

검색 결과

1위: 관련 문서
2위: 관련 문서
3위: 관련 없는 문서
4위: 관련 없는 문서

→ Context Precision이 높음
검색 결과

1위: 관련 없는 문서
2위: 관련 없는 문서
3위: 관련 없는 문서
8위: 관련 문서

→ Context Precision이 낮음

3. 점수가 낮을 때 의심할 점

필요한 문서를 검색하기는 했지만 중요한 정보가 하위 순위로 밀려 있는지 확인해야 합니다.

LLM에 상위 문서만 전달하는 경우 정답 문서가 검색되었더라도 순위가 낮으면 실제 답변 생성에 사용되지 않을 수 있습니다.

4. 개선 방법

  • Re-ranker 도입
  • 검색 쿼리 최적화
  • Hybrid Search 적용
  • 임베딩 모델 변경
  • 문서 메타데이터 활용
  • 중복 문서 제거

Context Recall: 컨텍스트 재현율

1. 정의

Context Recall은 질문에 답하기 위해 필요한 정보 중 얼마나 많은 정보가 검색된 컨텍스트에 포함되었는지를 측정하는 지표입니다.

즉, 답변에 필요한 내용을 빠짐없이 검색했는지를 평가합니다.

2. 계산 방식

기준 정답을 여러 개의 독립적인 주장(Claim)으로 나누고, 각 주장이 검색된 컨텍스트에 포함되어 있는지 확인합니다.

Context Recall
= 검색된 컨텍스트에 포함된 기준 정답의 주장 수
  ÷ 기준 정답의 전체 주장 수

예를 들어 기준 정답이 세 개의 주장으로 구성되어 있고 검색된 문서가 그중 두 개를 포함한다면 Recall은 낮아질 수 있습니다.

3. 점수가 낮을 때 의심할 점

검색기가 답변의 핵심 단서가 되는 정보를 검색 결과에 포함하지 못하고 있는지 확인해야 합니다.

4. 개선 방법

  • Top-k 값 증가
  • 청킹 전략 개선
  • Chunk Overlap 조정
  • Query Rewriting 적용
  • Multi-query Retrieval 적용
  • Hybrid Search 적용
  • 데이터 인덱싱 상태 확인

Faithfulness: 충실도

1. 정의

Faithfulness는 생성된 답변이 검색된 컨텍스트에 근거하여 작성되었는지를 측정하는 지표입니다.

답변의 내용이 사실적으로 맞는지를 외부 지식과 비교하기보다는, 제공된 컨텍스트가 해당 답변을 뒷받침하는지를 평가합니다.

2. 계산 방식

답변을 여러 주장으로 분리한 후 각 주장이 검색된 컨텍스트로 뒷받침되는지 확인합니다.

Faithfulness
= 검색된 컨텍스트로 뒷받침되는 답변의 주장 수
  ÷ 답변의 전체 주장 수

3. 점수가 낮을 때 의심할 점

검색된 문서에 없는 정보를 LLM이 임의로 추가하는 환각이 발생하고 있는지 확인해야 합니다.

4. 개선 방법

  • 프롬프트 지시사항 개선
  • 컨텍스트에 없는 내용은 답하지 않도록 제한
  • 관련 없는 문서 제거
  • Re-ranking 적용
  • 컨텍스트 압축 적용
  • 답변에 근거와 출처 표시

Answer Relevancy: 답변 관련성

1. 정의

Answer Relevancy는 생성된 답변이 사용자의 질문 의도에 얼마나 부합하는지를 측정하는 지표입니다.

즉, 사용자가 질문한 주제에 집중해 답변했는지를 평가합니다.

2. 계산 방식

생성된 답변을 바탕으로 여러 개의 역질문을 생성하고, 원래 질문과 역질문 사이의 코사인 유사도 평균을 계산하는 방식이 사용될 수 있습니다.

생성된 답변
→ 답변으로부터 질문 생성
→ 원래 질문과 생성된 질문 임베딩
→ 코사인 유사도 계산
→ 평균 점수 산출

3. 점수가 낮을 때 의심할 점

  • 답변에 질문과 관련 없는 내용이 섞여 있음
  • 질문의 핵심 의도를 잘못 이해함
  • 지나치게 일반적인 답변을 생성함
  • 핵심 내용 대신 주변 설명에 집중함

4. 개선 방법

  • 프롬프트 지시사항 개선
  • 질문의 핵심 의도를 먼저 분석
  • 답변 형식 지정
  • 불필요한 컨텍스트 제거
  • Query Rewriting 적용

Answer Correctness: 답변 정확성

1. 정의

Answer Correctness는 생성된 답변과 기준 정답을 비교하여 답변의 정확도를 측정하는 지표입니다.

일반적으로 0에서 1 사이의 점수로 표현하며, 1에 가까울수록 기준 정답과 일치하는 답변으로 평가합니다.

2. 계산 방식

Answer Correctness는 사실적 유사도와 의미적 유사도를 결합하여 계산할 수 있습니다.

Answer Correctness
= 사실적 유사도
+ 의미적 유사도

각 요소에는 별도의 가중치를 적용할 수 있습니다.

3. 사실적 유사도

생성된 답변과 기준 정답을 각각 독립적인 Statement 단위로 분리한 후 공통된 사실과 누락되거나 잘못 추가된 사실을 비교합니다.

  • TP(True Positive)

    • 답변과 기준 정답에 모두 존재하는 사실

  • FP(False Positive)

    • 생성된 답변에만 존재하는 잘못된 사실

  • FN(False Negative)

    • 기준 정답에는 있지만 생성된 답변에서 누락된 사실

이 값을 이용해 Precision, Recall, F1 Score를 계산합니다.

4. 의미적 유사도

생성된 답변과 기준 정답을 임베딩 벡터로 변환하고 벡터 사이의 거리를 측정합니다.

표현은 다르지만 의미가 같은 답변을 평가할 때 활용할 수 있습니다.

5. 기준 정답 품질 의존성

Answer Correctness의 품질은 기준 정답인 reference가 얼마나 정확하게 작성되었는지에 크게 의존합니다.

기준 정답에 잘못된 내용이 있거나 중요한 정보가 누락되어 있다면 올바른 답변도 낮게 평가될 수 있습니다.

따라서 기준 정답은 다음 조건을 만족해야 합니다.

  • 사실적으로 정확해야 한다.
  • 질문에 필요한 핵심 정보를 포함해야 한다.
  • 불필요하게 장황하지 않아야 한다.
  • 여러 평가자가 보더라도 해석이 크게 달라지지 않아야 한다.
  • 정기적으로 검토하고 업데이트해야 한다.

6. Answer Correctness만으로 부족한 이유

Answer Correctness가 낮다는 사실만으로는 답변이 왜 틀렸는지 정확히 파악하기 어렵습니다.

다음과 같은 원인이 모두 가능하기 때문입니다.

  • 검색기가 정답 문서를 찾지 못함
  • 정답 문서는 검색했지만 순위가 낮음
  • 올바른 문서를 제공했지만 LLM이 내용을 잘못 해석함
  • 검색 문서에 없는 정보를 추가함
  • 질문의 의도를 잘못 이해함

따라서 Answer Correctness와 함께 Context Precision, Context Recall, Faithfulness, Answer Relevancy를 확인해야 합니다.

메트릭 간 관계

시나리오낮아지는 메트릭원인대응 방법
정답 청크 자체를 검색에서 놓침Context Recall검색 엔진이 답변의 핵심 정보를 찾지 못함Top-k 증가, 청킹 전략 개선, Query Rewriting 적용
정답 청크는 검색됐지만 8~10위로 밀림Context Precision관련 문서의 검색 순위가 낮음Re-ranker 도입, 검색 쿼리 최적화
검색 결과는 맞지만 LLM이 외부 정보를 추가함Faithfulness컨텍스트에 없는 정보를 생성하는 환각 발생프롬프트 개선, 노이즈 문서 제거
LLM이 질문의 의도를 잘못 이해함Answer Relevancy질문 의도와 답변 내용이 불일치프롬프트 개선, Query Rewriting
답변이 기준 정답과 다름Answer Correctness검색 또는 생성 단계의 복합적인 문제다른 메트릭을 함께 확인하여 원인 추적
답은 맞지만 지나치게 장황함별도의 간결성 메트릭 필요불필요한 설명이 포함됨답변 길이와 형식을 프롬프트로 제한

평가 결과를 이용한 문제 진단

RAG 평가에서는 하나의 점수만 확인하는 것보다 여러 메트릭의 조합을 통해 문제를 진단해야 합니다.

Context Recall 낮음
→ 필요한 문서를 검색하지 못함

Context Precision 낮음
→ 필요한 문서는 있지만 검색 순위가 낮음

Faithfulness 낮음
→ 검색 문서에 없는 내용을 생성함

Answer Relevancy 낮음
→ 질문 의도와 다른 답변을 생성함

Answer Correctness 낮음
→ 최종 답변이 기준 정답과 다름

예를 들어 Answer Correctness가 낮으면서 Context Recall도 낮다면 검색 단계에서 정답 문서를 가져오지 못했을 가능성이 큽니다.

반대로 Context Precision과 Context Recall은 높지만 Faithfulness가 낮다면 검색 결과는 정상적이지만 생성 단계에서 환각이 발생했을 가능성이 높습니다.

핵심 정리

  1. 평가 데이터셋은 AI 시스템의 성능을 반복적이고 객관적으로 검증하기 위한 질문, 답변, 기준 정답 및 검색 컨텍스트의 모음입니다.

  2. Golden Dataset을 사용하면 프롬프트, 모델, 임베딩 및 검색 전략을 변경했을 때 기존 성능이 저하되는 회귀 문제를 탐지할 수 있습니다.

  3. 일반 소프트웨어는 명확한 입력과 출력으로 평가할 수 있지만, LLM은 표현이 매번 달라질 수 있으므로 의미와 맥락을 평가하는 방식이 필요합니다.

  4. LLM-as-a-Judge는 LLM에 평가 기준을 제공하고 답변의 점수와 근거를 생성하게 하는 방식으로, 사람 평가보다 빠르고 전통적인 지표보다 문맥 이해 능력이 뛰어납니다.

  5. LLM Judge는 위치 편향, 장황함 편향, 자기 선호 편향과 같은 한계가 있으므로 명확한 루브릭과 사람의 검토를 함께 활용해야 합니다.

  6. Context Precision과 Context Recall은 검색 단계를 평가하고, Faithfulness와 Answer Relevancy는 생성 단계를 평가합니다.

  7. Answer Correctness는 최종 답변과 기준 정답의 일치도를 평가하지만, 문제의 발생 지점을 찾으려면 다른 메트릭과 함께 분석해야 합니다.

  8. RAG 시스템의 품질은 하나의 점수가 아니라 검색과 생성 단계의 여러 메트릭을 종합적으로 확인해야 정확하게 진단할 수 있습니다.

출처

Velog
GitHub