RAG 평가셋 만드는 법: 검색 품질과 답변 신뢰도를 회귀 테스트로 관리하기

RAG 평가셋은 챗봇이 그럴듯하게 답하는지 보는 감상평이 아니라, 검색과 답변이 이전보다 나빠졌는지 잡아내는 회귀 테스트다. Retrieval-Augmented Generation을 붙인 서비스는 모델을 바꾸고, chunk 크기를 바꾸고, reranker를 바꾸고, 문서를 업데이트할 때마다 결과가 달라진다. 테스트셋이 없으면 팀은 매번 “이번엔 좀 나아진 것 같다”는 vibe check로 배포한다.

Ragas는 이런 감상 평가를 systematic evaluation loop로 바꾸는 프레임워크라고 설명한다. LangSmith 문서도 offline evaluation과 online evaluation을 구분하고, 각 핵심 컴포넌트별로 “좋은 결과”를 보여주는 5~10개 예시부터 만들라고 권장한다. 실무에서는 이 작은 시작이 가장 중요하다. 500개 평가셋보다 잘 고른 20개 실패 케이스가 먼저다.

RAG에서 무엇을 평가해야 하나

RAG 품질은 하나의 점수로 끝나지 않는다. 최소 네 가지를 나눠 봐야 한다. 첫째, 질문 해석이다. 사용자가 “지난달 환불 정책 바뀐 거 알려줘”라고 했을 때 시간 범위와 문서 종류를 제대로 잡았는지 본다. 둘째, 검색 품질이다. 관련 문서가 top-k 안에 들어왔는지, 오래된 문서가 최신 문서를 밀어내지 않았는지 확인한다.

셋째, 답변 충실도다. 검색된 근거에 있는 내용만 사용했는지, 없는 내용을 상상하지 않았는지 본다. 넷째, 답변 형식이다. 고객지원 봇이면 짧고 실행 가능한 답을 줘야 하고, 내부 개발 문서 봇이면 명령어와 파일 경로를 정확히 표시해야 한다.

이 네 가지를 섞어 하나의 “좋음/나쁨”으로 평가하면 원인을 찾기 어렵다. 검색이 틀렸는데 모델을 바꾸거나, 답변 형식이 문제인데 vector DB를 튜닝하는 일이 생긴다. 평가셋은 문제를 분해하기 위한 도구다.

5~10개 예시로 시작하는 이유

LangSmith는 평가를 만들기 전에 각 핵심 컴포넌트마다 좋은 결과의 예시 5~10개를 수동으로 큐레이션하라고 설명한다. 이 숫자가 작은 이유는 대충 시작하라는 뜻이 아니다. 처음부터 대규모 자동 생성 평가셋을 만들면 팀이 기준에 합의하지 못한 채 숫자만 커진다.

좋은 첫 평가셋은 실제 운영 질문에서 뽑는다. 고객이 자주 묻는 질문, 내부 직원이 반복해서 검색하는 정책, 이전에 답변 오류가 났던 케이스, 문서가 비슷해 헷갈리는 케이스를 넣는다. 각 케이스에는 질문, 기대 문서, 기대 답변, 금지 답변, 중요 태그를 함께 적는다.

예를 들어 사내 HR 챗봇이라면 “육아휴직 급여 신청 절차” 질문에 최신 2026년 정책 문서가 검색돼야 하고, 2024년 문서는 금지 문서로 표시할 수 있다. 답변에는 신청 주체, 제출 서류, 기한이 포함돼야 하며, 법률 자문처럼 단정하는 문구는 금지할 수 있다.

offline evaluation과 online evaluation을 나눈다

offline evaluation은 배포 전 테스트다. 모델 버전, chunk 크기, embedding 모델, reranker, prompt를 바꿀 때 같은 평가셋으로 돌려 이전 버전과 비교한다. regression testing, unit testing, backtesting에 맞다. 기준 답변이 있는 curated dataset을 대상으로 하므로 correctness를 따지기 쉽다.

online evaluation은 운영 모니터링이다. 실제 사용자 질문에는 정답지가 없다. 대신 검색 실패 패턴, 답변 길이 이상치, 금지 문구, 낮은 신뢰도, 사용자의 재질문, thumbs down, 상담원 escalation을 본다. online에서 발견한 나쁜 케이스는 다시 offline 평가셋으로 편입한다.

이 루프가 중요하다. 배포 전 평가셋만 고정해두면 운영에서 새로 생긴 질문을 놓친다. 운영 로그만 보면 배포 전에 성능 저하를 막지 못한다. offline은 안전망이고, online은 레이더다. 둘을 연결해야 RAG가 시간이 지나며 좋아진다.

평가 항목은 점수보다 판정 기준이 먼저다

Ragas와 OpenAI evals처럼 LLM-driven metric이나 grader를 쓰면 점수를 만들 수 있다. 하지만 점수 설계 전에 사람이 판정 기준을 써야 한다. “정확해야 한다”는 기준은 너무 넓다. “근거 문서에 없는 환불 기간을 말하면 fail”, “최신 정책 문서가 top-3에 없으면 retrieval fail”, “사용자에게 개인정보를 요청하면 safety fail”처럼 구체적이어야 한다.

추천하는 최소 schema는 다음과 같다. id, question, required_sources, forbidden_sources, reference_answer, must_include, must_not_include, tags, severity. severity는 high, medium, low로 나눈다. high는 배포 차단 케이스다. 예를 들어 결제, 법무, 보안, 의료처럼 틀리면 피해가 큰 질문이다.

이 schema가 있으면 자동 평가와 수동 평가를 섞기 쉽다. 문자열 포함 여부는 규칙 기반으로 검사하고, 답변 충실도와 문장 품질은 LLM judge를 보조로 쓴다. 중요한 케이스는 사람이 최종 판정한다. LLM judge도 모델이므로 절대적인 심판으로 두면 안 된다.

팀에서 운영하는 평가 파이프라인 예시

작게 시작하려면 하루면 충분하다. 첫째, 최근 2주 운영 로그에서 질문 30개를 고른다. 둘째, 문서 담당자와 개발자가 함께 15개를 평가셋으로 정리한다. 셋째, 현재 production 설정을 baseline으로 돌려 점수를 저장한다. 넷째, 바꾸고 싶은 항목을 하나만 바꾼다. 예를 들어 chunk size를 800에서 1200으로 바꾼다. 다섯째, 같은 평가셋으로 돌려 retrieval fail과 answer fail이 어떻게 변했는지 본다.

CI에 붙일 때는 모든 평가를 매번 돌릴 필요가 없다. PR마다 smoke eval 10개를 돌리고, nightly로 전체 eval을 돌린다. 모델 교체나 embedding 교체처럼 영향이 큰 변경에는 high severity 전체를 통과 조건으로 둔다. 운영 로그에서 새로 들어온 실패 케이스는 매주 평가셋에 추가한다.

중요한 것은 점수를 올리는 게임을 만들지 않는 것이다. 평가셋이 너무 공개되어 프롬프트가 특정 케이스에만 맞춰지면 실제 운영 품질은 그대로다. 주기적으로 holdout set을 만들고, 사람이 임의 샘플을 검토해야 한다.

실행 체크리스트

• RAG 품질을 질문 해석, 검색 품질, 답변 충실도, 답변 형식으로 나눠 평가한다.
• 실제 운영 로그에서 5~10개 핵심 예시로 시작하고, 질문·기대 문서·금지 문서·기대 답변을 함께 저장한다.
• offline eval은 배포 전 회귀 테스트, online eval은 운영 모니터링으로 역할을 분리한다.
• high severity 케이스를 정하고 결제·보안·법무 질문은 배포 차단 기준으로 둔다.
• LLM judge는 보조로 쓰고, 중요한 실패 케이스는 사람이 최종 판정한다.
• PR에는 smoke eval, nightly에는 전체 eval, 모델 교체에는 high severity 전체 통과를 요구한다.
• online에서 발견한 실패 질문을 매주 offline 평가셋에 추가한다.

출처: Ragas 공식 문서, LangSmith Evaluation concepts, OpenAI evals guide.