RAG 시스템은 단순히 정답을 맞추는지만 보는 것이 아니라,
검색이 잘 되었는지와 최종 답변이 적절한지를 각각 평가해야 합니다.
그래서 보통 평가 방법은 크게 두 가지로 나뉩니다.


핵심은 간단합니다.
검색 단계와 생성 단계를 나눠서 볼 것인가, 전체 결과만 볼 것인가의 차이
의미
RAG의 각 구성 요소를 따로따로 평가하는 방식입니다.
즉,
이렇게 분리해서 분석합니다.
대표 지표:
예시 질문:
정답 문서를 Top-5 안에 가져왔는가?
핵심 포인트
한 줄 정리
검색과 생성 성능을 각각 따로 평가하는 방식
대표 지표:
최근 많이 사용하는 방식:
예시 평가 항목:
한 줄 정리
답변 자체의 품질을 평가하는 방식
RAG 시스템을 하나의 시스템으로 보고 전체 결과만 평가하는 방식입니다.
즉,
질문 → 검색 → 생성 → 최종 답변
이 전체 과정을 한 번에 평가
예시:
질문
→ "대한민국 수도는?"
정답
→ "서울"
모델 답변
→ "서울"
이 경우:
예시 지표:
실무 서비스에서는 이 지표가 매우 중요합니다.
한 줄 정리
전체 시스템 결과만 평가하는 방식
| 구분 | 독립 평가 | 종단간 평가 |
| 평가 대상 | 개별 구성 요소 | 전체 시스템 |
| 목적 | 문제 원인 분석 | 실제 성능 확인 |
| 예시 | Recall, MRR | Accuracy, User Satisfaction |
| 활용 단계 | 개발 / 튜닝 | 서비스 운영 |
| 장점 | 디버깅 쉬움 | 현실 반영 |
| 단점 | 사용자 경험 반영 어려움 | 원인 분석 어려움 |
RAG 평가에서는 두 가지를 반드시 함께 사용합니다.
이유:
즉,
튜닝할 때는 독립 평가, 서비스 품질 확인은 종단간 평가
| Docker 이미지와 컨테이너, Docker Compose, Kubernetes 개념 정리 (0) | 2026.06.12 |
|---|---|
| RAG 시스템 'Agent' 개념 및 구현 방법 (3) | 2026.05.02 |
| LangChain으로 RAG 시스템 구축 시 필요한 주요 구성 요소와 역할 (0) | 2026.05.02 |
| PEFT가 필요한 이유 (0) | 2026.04.25 |
| 모델 크기를 키우는 것만으로는 성능이 일정 시점 이후 둔화되는 이유 (0) | 2026.04.25 |