이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- RAG 품질을 어떻게 평가해야 하는가?
- retrieval eval과 answer eval은 왜 분리해야 하는가?
- 운영 신고와 장애를 eval dataset으로 어떻게 연결하는가?
개요
RAG 품질은 한 번의 수동 테스트로 판단하기 어렵다. 문서와 사용자 질문은 계속 변하고, prompt와 retrieval 설정도 바뀐다. 따라서 RAG는 평가 루프가 필요하다.
LangSmith와 LlamaIndex 등 공식 문서는 RAG 평가와 production RAG 최적화를 별도 주제로 다룬다. 그만큼 실전에서 중요하다.
Retrieval Eval
Retrieval eval은 질문에 대해 적절한 source를 찾았는지 평가한다.
확인 항목:
- expected source가 top-k 안에 있는가?
- 권한 없는 source가 없는가?
- 최신 source가 우선되는가?
- 중복 source가 token budget을 낭비하지 않는가?
Answer Eval
Answer eval은 검색된 context를 바탕으로 답변이 올바른지 평가한다.
확인 항목:
- 답변이 source에 근거하는가?
- 모르는 경우 추측하지 않는가?
- required term이 포함되는가?
- JSON schema를 지키는가?
- 위험하거나 금지된 내용을 생성하지 않는가?
코드로 이해하기
retrieval과 answer를 분리해 기록한다.
def evaluate_rag_case(case, rag_system):
trace = rag_system.run_with_trace(case.question, user=case.user)
retrieval_passed = case.expected_source_id in trace.retrieved_source_ids
answer_passed = all(term in trace.answer for term in case.must_contain)
return {
"case_id": case.case_id,
"retrieval_passed": retrieval_passed,
"answer_passed": answer_passed,
"retrieved_source_ids": trace.retrieved_source_ids,
"prompt_version": trace.prompt_version,
}최종 점수 하나보다 어느 단계가 실패했는지가 중요하다.
품질 개선 루프
- 운영 신고나 장애를 수집한다.
- 개인정보를 제거한다.
- eval case로 추가한다.
- retrieval과 answer 실패를 분류한다.
- chunking, query rewrite, reranker, prompt, model 중 하나를 조정한다.
- regression eval을 돌린다.
- 배포 후 trace를 확인한다.
장애 상황과 대응
품질 저하가 발생하면 최근 변경을 본다.
- 문서 색인 변경
- embedding 모델 변경
- chunk 크기 변경
- reranker 도입
- prompt 변경
- 모델 변경
- 권한 metadata 변경
각 변경은 eval 대상이다.
인프라 협업 포인트
eval도 리소스를 사용한다. 대량 RAG eval은 provider token과 vector DB query를 많이 쓸 수 있으므로 production quota와 분리한다.
개인 프로젝트 최소 기준
- 대표 질문 10개를 만든다.
- 기대 source id를 적는다.
- 답변 source 표시를 확인한다.
- 문서 삭제 후 검색되지 않는지 테스트한다.
기업 운영 수준 기준
- retrieval eval과 answer eval을 분리한다.
- 권한 경계 eval을 둔다.
- 문서 업데이트 후 eval을 돌린다.
- 운영 신고를 eval dataset으로 전환한다.
- prompt/retrieval profile별 결과를 기록한다.
실전 팁
- RAG 품질 개선은 한 번에 하나씩 바꾼다.
- chunking과 reranking 변경은 model 변경만큼 영향이 크다.
- eval dataset은 정상 케이스보다 실패 케이스가 더 가치 있을 때가 많다.
- answer groundedness를 사람이 샘플링 검토한다.
위험 신호!
- 최종 답변만 보고 검색 품질을 평가한다.
- source 없는 답변을 eval한다.
- prompt 변경 후 RAG eval을 돌리지 않는다.
- 운영 신고가 eval에 반영되지 않는다.
확인 질문
확인 질문
- retrieval eval과 answer eval을 분리해야 하는 이유는 무엇인가?
- 검색 실패와 생성 실패를 구분해야 개선 방향이 명확해지기 때문이다.
- 운영 신고를 eval case로 전환할 때 주의할 점은 무엇인가?
- 개인정보를 제거하고 재현 가능한 입력과 기대 source를 남겨야 한다.
Spring AI 적용 연결
- Spring AI 기반 RAG의 평가는 retriever 결과, context 조립, 최종 답변을 나눠 보아야 한다. 회귀 테스트 구조는 10. Evaluation Testing Regression에서 이어진다.
- 운영 가능한 고객지원 RAG로 묶는 판단은 13. 고객지원 RAG Capstone과 함께 확인한다.