RAG 평가셋은 어떻게 만들어야 할까라는 질문은 보통 데모가 잘 되는데 운영 만족도가 낮을 때 생깁니다. 많이 하는 실수는 보기 좋은 질문만 모아두고 그걸로만 성능을 확인하는 것입니다. 그러면 발표용 화면은 그럴듯해도 실제 사용자의 실패 패턴은 거의 안 잡힙니다.
즉 평가셋의 목적은 점수 예쁘게 만들기가 아니라, 운영에서 자주 깨지는 질문을 미리 잡아내는 것에 있어야 합니다.
왜 좋은 질문만 모으면 실패할까
좋은 질문은 대체로 의도가 분명하고, 문서에도 정답 단서가 잘 있고, 검색도 쉬운 편입니다. 하지만 실제 사용자 질문은 그렇지 않습니다. 애매하고, 길고, 여러 조건이 섞이고, 용어도 들쭉날쭉합니다.
- 질문 의도가 모호하다
- 문서에 표현이 조금 다르게 적혀 있다
- 정답이 하나가 아니라 조건부다
- 아예 답하면 안 되는 질문도 있다
그래서 평가셋이 예쁜 질문만 모여 있으면, 시스템은 쉬운 문제만 잘 푸는 상태로 남게 됩니다.
Anthropic의 agent 운영 글이나 OpenAI의 반복 개선 가이드를 봐도, 운영 품질은 한 번의 예쁜 데모보다 반복 점검 구조가 중요하다는 점이 드러납니다.
평가셋은 최소한 네 묶음으로 보는 편이 좋다
- 정상적으로 잘 풀어야 하는 positive set
- 헷갈리기 쉬운 negative set
- 경계 조건을 보는 boundary case
- 한 번 고친 뒤 다시 깨지지 않는지 보는 regression set
이 네 묶음이 있어야 단순 정답률이 아니라 실패 유형을 같이 볼 수 있습니다.
retrieval 실패 사례는 꼭 따로 모아야 한다
RAG 시스템은 생성 모델 자체보다 retrieval 단계에서 먼저 무너지는 경우가 많습니다. 문서가 있는데 못 찾거나, 비슷한 문서를 잘못 잡거나, 최신 문서를 놓치는 문제가 대표적입니다.
그래서 평가셋에는 “정답이 없는 질문”만이 아니라, 정답 문서가 있는데도 검색이 흔들리는 질문을 따로 넣어야 합니다.
regression set이 왜 특히 중요할까
RAG는 튜닝할수록 한쪽을 고치면 다른 쪽이 다시 깨질 수 있습니다. reranker를 바꾸고, chunking을 바꾸고, prompt를 바꾸고, metadata filter를 바꾸다 보면 예전 실패는 해결됐는데 기존 잘 되던 질문이 다시 흔들릴 수 있습니다.
그래서 regression set은 품질 관리의 안전장치입니다. 고친 뒤에도 이전 핵심 시나리오가 계속 살아 있는지를 보는 최소 장치라고 생각하면 됩니다.
실무에서 자주 놓치는 질문 유형
- 질문이 너무 길어서 핵심 의도가 흐려지는 경우
- 동의어와 조직 내부 용어가 섞이는 경우
- 문서에 없는 답을 그럴듯하게 지어내기 쉬운 경우
- 정책상 답변을 제한해야 하는 경우
이런 사례가 빠지면 데모 점수는 괜찮아 보여도 실제 만족도는 쉽게 무너집니다.
운영 품질 감각은 LLM 평가 글, 실패 패턴 감각은 RAG 한계 글과 함께 보면 더 잘 이어집니다.
마무리
RAG 평가셋은 예쁜 데모를 증명하는 질문 모음이 아니라, 실제 실패를 빨리 발견하는 장치에 가깝습니다. 그래서 positive set만으로는 부족하고 negative, boundary, retrieval fail, regression set이 같이 필요합니다.
즉 좋은 평가셋의 기준은 정답률 숫자 하나보다, 운영에서 어떤 종류의 실패를 미리 잡아낼 수 있는가에 있습니다.
