RAG 품질이 흔들릴 때 바로 쓰는 평가 플레이북

상황

RAG를 도입하면 처음엔 품질이 좋아지지만, 시간이 지나면 다음 문제가 자주 발생합니다.

• “근거가 있는 것처럼” 보이지만 출처가 약함
• 질문 유형이 바뀌면 정확도가 급락
• 운영 데이터가 늘수록 응답이 길고 느려짐

이때 필요한 것은 모델 교체가 아니라 평가 체계입니다.

1단계: 문제를 분리해서 측정

RAG 품질을 한 지표로 보지 말고 최소 3개로 분리합니다.

1. 검색 품질

• 정답 문서가 검색 상위 K개 안에 들어오는가 (Recall@K)

2. 생성 품질

• 검색된 문서를 근거로 답을 구성하는가 (Faithfulness)

3. 사용성

• 답이 간결하고 실행 가능한가 (Helpfulness)

2단계: 실패 유형 라벨링

최근 실패 사례 50건을 수집해 아래처럼 라벨링합니다.

• Retrieval miss: 정답 문서 검색 실패
• Context overload: 관련 없는 문서 과다 포함
• Grounding failure: 문서와 다른 주장 생성
• Prompt mismatch: 질문 의도와 프롬프트 정책 불일치

라벨 비율만 봐도 우선순위가 나옵니다.

3단계: 개선 순서

A. 검색 계층 먼저 개선

• 청크 크기/오버랩 재조정
• 임베딩 모델 교체 테스트
• 하이브리드 검색(BM25 + 벡터) 적용

B. 컨텍스트 구성 개선

• 상위 K를 무작정 늘리지 말고, 점수 임계값 기반 선택
• 중복 문서 제거 및 문서 다양성 제어

C. 생성 정책 개선

• “근거 없는 답변 금지” 정책 명시
• 답변에 출처 인용 포맷 강제

4단계: 배포 기준 설정

개선 실험을 프로덕션에 반영할 때는 다음 조건을 동시에 만족해야 합니다.

1. Faithfulness +5%p 이상
2. P95 응답시간 악화 10% 이내
3. 토큰 비용 증가 15% 이내

빠른 운영 템플릿

매주 1회 아래 표를 업데이트하세요.

지표	이번 주	지난 주	변화
Recall@5
Faithfulness
P95 응답시간
평균 토큰 비용

RAG 운영의 핵심은 “한 번 잘 만드는 것”이 아니라 매주 같은 방식으로 진단하고 개선하는 루프를 만드는 것입니다.

참고 링크

• RAG 원 논문: https://arxiv.org/abs/2005.11401
• RAGAS 논문: https://arxiv.org/abs/2309.15217
• LangSmith Evaluation 문서: https://docs.smith.langchain.com/evaluation
• Pinecone RAG 가이드: https://www.pinecone.io/learn/retrieval-augmented-generation/