RAG 평가 플레이북: 사용자가 신뢰를 잃기 전에 검색 품질을 측정하는 법
· 수정 4월 25일
먼저 검색 계층을 평가해야 한다
답변 품질을 보기 전에 시스템이 올바른 증거를 가져왔는지부터 봐야 합니다.
중요한 질문은 다음과 같습니다.
- 기대한 문서가 top-k 안에 들어왔는가
- 랭킹 순서가 실제로 유용한 청크를 위로 올렸는가
- 청킹 크기가 핵심 사실을 잘라 먹고 있지 않은가
- 메타데이터 필터가 필요한 문서를 잘 제외하거나 포함하는가
적절한 근거가 검색되지 않았다면, 답변 평가는 대부분 잡음이 됩니다.
평가셋은 실제 질문처럼 만들어야 한다
좋은 RAG 평가셋은 쉬운 사실 질문만 모아 두지 않습니다. 실제 트래픽에는 다음이 섞여 있습니다.
- 조건이 불명확한 질문
- 여러 문서를 이어야 하는 질문
- 오래된 문서에 속기 쉬운 질문
- 서로 충돌하는 문서가 있는 질문
- 정답이 “정보 부족”인 질문
결국 사용자의 신뢰를 결정하는 것은 이런 케이스입니다.
도움됨보다 근거됨을 봐야 한다
많은 팀이 답변이 그럴듯한지만 봅니다. 하지만 RAG에서 더 중요한 것은 답변이 검색된 근거로 뒷받침되는가입니다.
실무 지표 예시는 다음과 같습니다.
- retrieval hit rate
- answer grounding rate
- unsupported claim rate
- citation usefulness
- 근거가 약할 때의 적절한 거절 품질
실패 분석은 유형화해야 한다
품질이 떨어졌을 때는 무엇이 망가졌는지 유형을 나눠야 합니다.
- 검색이 올바른 문서를 놓쳤는가
- 청킹이 증거를 손상시켰는가
- reranking이 약한 컨텍스트를 위로 올렸는가
- 프롬프트가 과신하는 답변을 유도했는가
- 모델이 좋은 근거를 무시했는가
문제 유형이 다르면 수정 경로도 달라집니다.
릴리즈 게이트를 둬야 한다
샘플 몇 개가 좋아 보인다고 새 RAG 파이프라인을 바로 올리면 안 됩니다. 최소 기준을 먼저 정해야 합니다.
- 최소 검색 hit rate
- 최대 unsupported claim rate
- 목표 트래픽에서 안정적인 지연 시간과 비용
- 핵심 비즈니스 질문에 대한 회귀 없음
RAG 품질은 한 번의 벤치마크가 아니라 릴리즈 규율로 다룰 때 관리 가능해집니다.
Continue Reading
다음으로 읽기 좋은 글
🤖 AI / LLMOps
AI 평가 루브릭 실전 설계
프로덕션 AI 기능을 위해 품질 기준, 실패 유형, 릴리스 게이트를 어떻게 정의할지 정리한 실전 가이드입니다.
🤖 AI / LLMOps프롬프트 엔지니어링 운영 가이드: 버전 관리, 테스트, 실패 복구
프롬프트 계약, 구조화 출력, 버전 관리, 평가, 롤백, 팀 협업 흐름을 포함해 프롬프트 엔지니어링을 운영 관점으로 설명합니다.
📈 최신 동향소형 모델이 제품 아키텍처를 바꾸는 방식
최근 AI 제품 흐름에서 중요한 변화 중 하나는 더 큰 모델만이 아니라, 작은 모델을 어디에 배치할지에 대한 설계가 중요해지고 있다는 점입니다.
📈 최신 동향AI 코딩 에이전트의 다음 단계는 제한된 실행이다
최근 코딩 에이전트 흐름은 단순한 자동완성보다, 권한과 범위를 제한한 실행 환경으로 이동하고 있습니다.
다음 탐색