RAG 평가셋, 직접 만들면 뭐가 가장 먼저 무너지나?

가장 먼저 무너지는 건 "정답 하나"로는 검색 실패와 생성 실패를 구분할 수 없다는 점이다. 질문-정답 쌍만 만들고 근거 청크를 라벨링하지 않으면, 모델이 틀렸을 때 임베딩 문제인지 프롬프트 문제인지 알 방법이 없다. 2026년 기준 공개 RAG 벤치마크들은 이 문제를 질문·정답·근거 청크 3종 세트로 해결한다.

핵심 정리

  • 평가셋은 질문-정답-근거 청크 3종 세트가 최소 단위다. 출처
  • 검색 평가(Recall@k, MRR, NDCG)와 생성 평가(충실도, 정확성)는 반드시 분리해서 측정한다.
  • 청크 크기·하이브리드 검색·리랭킹은 질문 유형별로 따로 비교해야 한다.
  • 표·수치 질문은 별도 평가셋으로 빼지 않으면 전체 점수가 왜곡된다.
  • 1,000회 질의 기준 비용과 p95 지연시간을 처음부터 기준선에 넣어야 나중에 비교가 가능하다.

가장 흔한 함정은 "질문-정답 100개 정도 빠르게 만들어서 돌려보자"는 접근이다. 처음엔 빠르게 결과가 나오는 것 같지만, 멀티홉 질문이나 무응답형 질문이 빠진 평가셋은 모델이 실제로 얼마나 틀리는지 보여주지 못한다. 공개 벤치마크들이 질문 1,000개, 검색 청크 5,000개 규모로 유형·난이도·도메인을 함께 기록하는 이유다. 출처

질문 유형을 몇 개로 나눠야 실패가 보이나?

최소한 사실 확인, 분석, 비교, 시간 조건, 멀티홉, 무응답형 6가지로 나눠야 실패 지점이 드러난다. 사실 확인 질문만 100개 모아서 평가하면 점수는 높게 나오지만, 실제 사용자는 "A와 B 문서를 비교하면"이나 "작년 대비 이번 분기는"처럼 복합 조건을 묻는다. 공개 벤치마크들은 단순 사실 질문만으로는 실제 문서 QA의 실패를 포착하기 어렵다고 보고, 멀티홉 질문을 별도 범주로 둔다. 출처

실제로 유형별 성능 격차는 작지 않다. 한 공개 벤치마크 분석에서 멀티홉 질문의 답변 충실도는 62%, 사실형 질문은 89%로 보고됐다. 출처 이 수치는 해당 벤치마크 설정에 한정된 값이라 그대로 가져다 쓸 순 없지만, "사실형만 테스트하면 멀티홉 실패를 놓친다"는 구조적 함정은 재현 가능성이 높다. 무응답형 질문도 필수다. 문서에 없는 정보를 억지로 생성하는지 확인하려면 정답이 없는 질문과, 비슷해 보이지만 답이 다른 문서에 있는 질문을 함께 넣어야 한다.

검색 점수와 생성 점수를 같이 매기면 뭐가 안 보이나?

검색과 생성을 한 점수로 묶으면 어느 쪽을 고쳐야 할지 전혀 알 수 없다. Recall@k, MRR, NDCG@10은 검색기가 정답 근거를 얼마나 위에 올렸는지를 보는 지표이고, 충실도·정확성·완전성은 그 뒤 생성 답변을 보는 지표다. 출처 정답 문서가 애초에 검색되지 않은 경우와, 정답 문서는 검색됐지만 모델이 잘못 답한 경우를 같은 "오답"으로 처리하면 임베딩·청크·리랭커 문제와 프롬프트·생성 모델 문제를 구분할 수 없다. 모듈별로 임베딩, 인덱싱, 검색, 생성을 분리해 측정하는 RASB 방식이 이 목적에 맞다. 출처

초기 기준선은 Recall@5, MRR, NDCG@10, 답변 충실도, 인용 정확도, p95 지연시간, 1,000회 질의 비용 조합으로 잡는 게 실용적이다. 이 조합이면 검색 품질, 생성 품질, 운영 비용을 한 번에 비교할 수 있다. 관련도 라벨은 0~3점처럼 단계화한다. 0=무관, 1=간접 관련, 2=부분적으로 답변, 3=직접 답변으로 사람이 직접 매긴 라벨이 있어야 검색 품질 지표가 의미를 가진다. 출처

청크 크기 하나로 고정하면 어떤 질문에서 틀리나?

사실 확인 질문과 분석형 질문은 선호하는 청크 크기가 다르다. 한 2026년 벤치마크 분석에서는 사실 질문에서 256~512토큰에 50토큰 오버랩이 유리했고, 분석형 질문에서는 768토큰 이상 청크가 더 적합했다고 보고했다. 출처 이 수치는 특정 코퍼스와 임베딩 모델 조합의 결과이므로, 문서 형식이 다르면 재검증이 필요하다. 그런데도 "일단 512토큰으로 통일하자"는 선택이 흔한 함정이다. 평가셋 단계에서 청크 크기를 질문 유형별로 나눠 테스트하지 않으면, 이후에 어느 쪽 질문 때문에 점수가 낮은지 영영 알 수 없다.

검색 방식도 마찬가지다. 임베딩 검색만 평가하지 말고 BM25 또는 하이브리드 검색을 기준선에 포함해야 한다. 텍스트와 표가 섞인 7,318개 금융 문서, 23,088개 질문-문맥-정답 트리플을 사용한 T²-RAGBench에서는 BM25와 밀집 검색을 결합한 하이브리드 방식이 밀집 검색 단독보다 강한 결과를 보였다. 출처 리랭킹도 독립 실험 조건으로 둬야 한다. dense only, dense+sparse, dense+sparse+rerank를 비교한 분석에서는 리랭킹이 검색 품질 개선의 주요 요인으로 나타났지만, 개선률 자체는 공개 데이터셋 결과이므로 실제 문서군에서 별도 측정이 필요하다. 출처

관련도 라벨만 있으면 평가가 끝난 걸까?

아니다. 관련도 라벨은 검색 품질을 보는 절반일 뿐이고, 생성 답변이 실제로 숫자를 맞혔는지는 완전히 다른 문제다. 이 오해가 특히 잘 드러나는 영역이 표·수치 질문이다. T²-RAGBench는 금융 문서의 텍스트와 표를 함께 다루며 생성 답변의 수치 일치 여부를 Number Match로 평가하는데, Llama 3.3-70B 생성 조건에서 하이브리드 BM25의 평균 Number Match는 40.9%, Recall@3는 49.4%였다. 정답 문서를 직접 제공하는 Oracle 조건에서도 Number Match는 약 73%에 그쳤다. 출처

즉 정답 문서를 정확히 찾아줘도 모델이 표에서 숫자를 옮기는 과정에서 또 틀린다는 뜻이다. 검색 점수가 높다고 생성 답변의 수치 정확성을 보장하지 않는다. 표·수치·계산 질문은 일반 텍스트 QA와 섞지 말고 별도 평가셋으로 분리해서 Number Match 같은 전용 지표를 둬야 한다. 관련도 라벨 0~3점을 다 매겼다고 "평가 끝"이라고 판단하면, 이런 생성 단계 실패를 놓친 채 지표만 좋아 보이는 상태로 넘어가게 된다.

평가셋 운영할 때 비용은 어디서 새나?

비용은 평가 자체보다 재현성 관리에서 조용히 샌다. 비용 비교는 모델명만으로 쓰지 말고 질의 수, 입력·출력 토큰 수, 임베딩 대상 문서량, 재색인 횟수, 리랭킹 호출 횟수, 캐시 사용 여부를 함께 기록해야 실제 비교가 가능하다. 출처 프롬프트도 평가셋에 고정해 버전 관리해야 한다. 모델별 실행 결과와 사용한 프롬프트 템플릿을 함께 저장하지 않으면, 다음 번 점수가 올라갔을 때 모델이 좋아진 건지 프롬프트를 바꾼 건지 구분할 수 없다.

버전 표기도 빠뜨리기 쉬운 비용 요소다. 임베딩 모델, 벡터 DB, BM25 구현체, 리랭커, 생성 모델, 프롬프트, 문서 수집일, 가격 기준일, 라이브러리 버전을 함께 저장해야 몇 달 뒤에도 같은 실험을 재현할 수 있다. 이걸 빼먹으면 "지난번엔 됐는데 지금은 안 된다"는 상황에서 원인을 찾는 데 평가셋을 새로 만드는 것보다 더 오래 걸린다. 최소 실험 매트릭스는 임베딩 모델명·버전, 검색 방식(dense/BM25/hybrid), 리랭킹 유무, 청크 크기(256/512/768), 오버랩(0/50), top_k(3/5/10), 생성 모델·온도·최대 토큰, 그리고 Recall@k·MRR·NDCG·정확성·충실도·완전성·인용 정확도·지연시간·비용 측정값으로 구성하는 게 실용적이다.

핵심 정리

  • 평가셋의 최소 단위는 질문-정답-근거 청크 3종 세트이며, 질문 유형은 사실 확인·분석·비교·시간 조건·멀티홉·무응답형 6가지를 포함해야 한다.
  • 검색 지표(Recall@k, MRR, NDCG)와 생성 지표(충실도, 정확성, 인용 정확도)는 분리해서 측정해야 원인을 구분할 수 있다.
  • 청크 크기와 검색 방식(dense/BM25/hybrid)은 하나로 고정하지 말고 질문 유형별로 비교한다.
  • 표·수치 질문은 별도 평가셋과 전용 지표(Number Match 등)로 분리해야 하며, 검색이 정확해도 생성 단계에서 수치가 틀릴 수 있다.
  • 비용 비교와 재현성은 모델명만으로는 불가능하며, 실행 조건과 버전 메타데이터를 함께 기록해야 한다.