기업용 RAG 정확도, 어떻게 평가하나: 우리 문서로 평가셋 만드는 법

작성 올거나이즈코리아 마케팅팀 · 최종 갱신 2026년 10월 23일

기업용 RAG의 정확도는 공개 벤치마크 점수로는 알 수 없고, 우리 회사 문서로 만든 평가셋으로 문서 읽기·검색·답변 생성 세 단계를 나눠 재야 알 수 있습니다. 평가셋은 업무 분야마다 실제 질문 60개 안팎과 정답, 정답 근거 문서로 만들고, 같은 사실이 여러 문서에 들어 있으면 그 문서들을 모두 정답으로 인정해야 점수가 틀어지지 않습니다. 만든 평가셋은 문서 개정, 모델 교체, 파서 업그레이드 때마다 다시 돌려 품질이 떨어진 지점을 찾는 데 씁니다. 여기서 평가셋은 질문, 정답, 정답이 들어 있는 문서 목록을 한 묶음으로 정리한 시험지를 말합니다.

RAG 정확도는 무엇을 나눠서 재야 하나요?

RAG 정확도는 문서를 제대로 읽었는지, 맞는 문서를 찾았는지, 찾은 문서로 맞는 답을 썼는지를 따로 재야 합니다. 최종 답의 정답률 하나만 보면 어느 단계에서 틀렸는지 알 수 없고, 개선 작업도 엉뚱한 곳에서 하게 됩니다.

올거나이즈가 2024년 공개한 한국어 RAG 리더보드도 RAG를 파서(문서에서 글자·표·그림을 추출), 리트리버(질문에 맞는 문서 검색), 답변 생성 세 요소로 나눠 평가했습니다[1].

단계	여기서 생기는 오류	대표 지표	재는 방법
문서 읽기(파싱)	표가 깨짐, 스캔본 글자 누락, HWP 본문 일부 빠짐, 머리글·각주가 본문에 섞임	표·문단 추출 정확도, 누락 페이지 수	표가 많은 문서와 스캔본 10~20개를 골라 추출 결과를 원문과 대조
검색	맞는 문서를 못 찾음, 비슷한 다른 문서를 가져옴, 권한 없는 문서가 섞임	Recall@k(상위 k개 안에 정답 문서가 있는 비율), MRR, nDCG	평가셋의 정답 문서 목록과 검색 결과 상위 k개를 비교
답변 생성	찾은 문서와 다른 내용을 씀, 근거 없는 숫자를 만듦, 답이 없는데 지어냄	정답 일치도, 근거 충실도(faithfulness), 답 없음 처리율	정답과 비교 채점, 답의 문장마다 근거 문서에 있는지 확인

세 단계를 나눠 보면 대응이 달라집니다. 검색 Recall@10이 낮으면 임베딩 모델, 검색 방식, 문서 분할 단위를 손봐야 하고, 검색은 맞는데 답이 틀리면 프롬프트나 LLM을 바꿔야 합니다. 파싱 단계에서 표가 깨져 있으면 검색과 답변을 아무리 손봐도 표 안의 숫자를 묻는 질문은 계속 틀립니다. 문서 형식별 파싱 점검은 HWP 문서를 AI가 읽게 하려면에 정리했습니다.

공개 벤치마크 점수는 왜 우리 회사 정확도와 다른가요?

공개 벤치마크는 문서마다 내용이 뚜렷이 다른 위키피디아 같은 자료로 만들어졌고, 기업 문서는 서로 닮은 문서가 대부분이기 때문입니다. 분기마다 구조가 같은 보고서, 비슷한 조항이 반복되는 규정집과 약관, 같은 기술을 다른 각도로 쓴 특허 문서가 그런 예입니다.

올거나이즈가 ACL 2026 본회의에 발표한 RARE 연구는 이 차이를 수치로 보여 줍니다. 위키피디아 환경에서 검색 정확도(PerfRecall@10) 77.9%를 기록한 검색 모델이 금융 문서에서는 8.5%, 법률 문서에서는 5.0%까지 떨어졌습니다[2]. 2026년 1월 RARE 기능을 알리에 넣을 때도 표준 벤치마크에서 80점을 받는 시스템이 실제 고객 문서에서는 10%대로 떨어지는 경우가 흔하다고 안내했습니다[3].

그래서 공급사가 제시하는 벤치마크 점수는 참고로만 보고, 도입 판단과 운영 점검은 우리 문서로 만든 평가셋으로 해야 합니다. 후보 솔루션을 비교할 때 볼 기준 전체는 기업용 RAG 솔루션 비교 기준 9가지와 PoC 점검표에 정리했습니다.

우리 문서로 평가셋은 어떻게 만드나요?

평가셋은 업무 범위를 정하고, 질문 유형을 섞어 질문을 모으고, 질문마다 정답과 정답 근거 문서를 붙이는 순서로 만듭니다.

1. 업무 범위와 문서 묶음을 정합니다. "인사 규정 문의", "상품 약관 상담"처럼 실제로 쓸 업무 하나를 고르고, 그 업무에 쓰는 문서를 모읍니다. 개정 전후 문서, 분기별 보고서처럼 서로 닮은 문서도 빼지 말고 넣습니다.
2. 실제 질문을 모읍니다. 헬프데스크 문의 기록, 상담 기록, 현업 담당자 인터뷰에서 실제로 나온 질문을 우선 씁니다. 모자라면 LLM으로 질문을 만들고 담당자가 고릅니다.
3. 질문 유형을 섞습니다. 아래 표의 유형이 고루 들어가야 약점이 드러납니다.
4. 정답과 근거 문서를 붙입니다. 질문마다 정답 문장, 정답이 들어 있는 문서와 쪽(또는 조항)을 적습니다. 같은 사실이 여러 문서에 있으면 그 문서들을 모두 적습니다.
5. 현업 담당자가 검토합니다. 정답이 맞는지, 질문이 실제 업무 표현과 같은지 확인합니다. 정답이 애매한 질문은 빼거나 고칩니다.
6. 버전을 붙여 보관합니다. 평가셋에도 작성일과 기준 문서 버전을 적어 두어야 문서가 바뀐 뒤 어느 질문을 고쳐야 하는지 알 수 있습니다.

질문 유형	예시	무엇을 드러내나
단순 사실 확인	"출장비 일비 한도는 얼마인가요?"	기본 검색·답변 품질
표 안의 숫자	"2분기 지역별 매출 중 가장 높은 곳은?"	파싱 단계 표 처리
여러 문서 종합	"개정 전후 휴가 규정에서 달라진 점은?"	여러 문서를 함께 찾는 능력
비슷한 문서 구분	"2025년 3분기 보고서 기준 부채비율은?"	닮은 문서 사이에서 맞는 판을 고르는지
답이 없는 질문	문서에 없는 제도나 다른 회사 상품 질문	모르는 것을 지어내지 않는지
권한이 다른 질문	다른 부서 전용 문서에만 답이 있는 질문	권한 없는 문서가 근거로 쓰이지 않는지

규모는 업무 분야마다 질문 60개 안팎이 다루기 좋습니다. 올거나이즈 한국어 RAG 리더보드는 금융·공공·의료·법률·커머스 분야마다 200~300쪽 문서를 올리고 분야별로 질문 60개를 만들었습니다[1]. 60개면 담당자 한두 명이 하루 이틀 안에 정답을 검토할 수 있고, 유형별로 10개 안팎씩 배분할 수 있습니다. 운영 범위가 넓으면 업무 분야를 늘리고 분야마다 같은 규모로 만듭니다.

같은 내용이 여러 문서에 있으면 정답은 어떻게 정하나요?

같은 사실이 들어 있는 문서를 모두 찾아 전부 정답으로 인정해야 합니다. 질문마다 정답 문서를 하나만 정해 두면, 검색기가 같은 문장이 들어 있는 다른 문서를 찾아와도 오답으로 처리되어 점수가 실제보다 낮게 나옵니다.

예를 들어 "법인카드 분실 시 신고 기한"이 2024년 규정과 2025년 개정 규정에 똑같이 들어 있다면, 어느 쪽을 가져와도 맞는 근거입니다. 반대로 개정으로 기한이 바뀌었다면 최신 판만 정답이어야 합니다. 이 구분을 사람이 문서마다 하기는 어렵기 때문에 평가셋 규모가 커지면 자동화가 필요합니다.

RARE는 이 작업을 세 단계로 자동화합니다[2].

1. 사실 단위 분해: 문서를 더 나눌 수 없는 사실 단위로 쪼개고, 같은 사실이 어느 문서들에 들어 있는지 문서 사이 대응표를 만듭니다.
2. 중복 인지 정답 표시: 같은 사실이 여러 문서에 있으면 그 문서들을 모두 정답으로 표시합니다. 맞는 근거를 찾은 검색기가 불이익을 받지 않습니다.
3. 평가 질문 품질 안정화(CRRF): LLM이 만든 평가 질문을 품질 기준별로 따로 평가한 뒤 순위를 합산해 고릅니다. 논문에서는 이 방식으로 평가 데이터 품질 점수(NDCG@3)를 0.419에서 0.463으로 높였습니다.

이 방법은 금융·법률·특허 세 분야의 평가셋(RedQA)으로 검증했고, 국내에서는 "고유사·중복 말뭉치를 위한 중복 인지 검색평가 데이터셋 구축 방법 및 시스템"으로 특허(제10-3031382호, 2026년 10월 7일 등록)를 받았습니다[4].

직접 평가셋을 만들 때도 같은 원칙을 적용할 수 있습니다. 정답 문서를 적을 때 "같은 문장이 다른 문서에도 있는가"를 한 번 더 검색해 보고, 있으면 함께 적습니다. 개정으로 내용이 달라진 문서는 판을 구분해 최신 판만 정답으로 둡니다.

자동 채점은 어디까지 믿을 수 있나요?

LLM 자동 채점은 많은 질문을 빠르게 채점하는 데 쓰고, 채점 도구 여러 개의 다수결과 사람 표본 검토를 함께 써야 믿을 수 있습니다. LLM 채점에는 먼저 제시된 답, 긴 답, 자기가 만든 답에 점수를 더 주는 경향이 보고되어 있습니다[5]. OpenAI 평가 가이드도 자동 채점을 쓰기 전에 사람이 매긴 점수와 얼마나 일치하는지 확인하라고 권하고, Anthropic 가이드는 답을 만든 모델과 다른 모델로 채점하라고 권합니다[6].

방법	장점	주의할 점
정답 문자열 비교	빠르고 결과가 일정함	표현이 다르면 맞는 답도 오답 처리
LLM 채점 도구 1개	의미가 같은 답을 맞게 처리	채점 모델의 편향이 점수에 그대로 들어감
LLM 채점 도구 여러 개 다수결	도구 하나의 편향을 줄임	비용과 시간이 늘어남
사람 채점	업무 맥락까지 판단	느리고 사람마다 기준이 다름

올거나이즈 한국어 RAG 리더보드는 채점 도구 5개(RAGAS, TonicAI, MLflow 두 지표, 자체 채점)를 쓰고, 3개 이상이 맞다고 판정한 답만 정답으로 인정했습니다[1]. 실무에서는 자동 채점 결과 가운데 일부(예: 10~20%)를 담당자가 다시 채점해 자동 채점과 얼마나 일치하는지 확인하고, 일치율이 낮은 질문 유형은 채점 기준을 고칩니다. 숫자·날짜·금액이 들어간 답은 의미 비교보다 값 비교로 채점하는 편이 정확합니다.

운영 중에는 언제 다시 재야 하나요?

문서, 모델, 설정 가운데 하나라도 바뀌면 같은 평가셋으로 다시 재야 합니다. RAG의 품질 저하는 에러 로그 없이 일어나는 경우가 많아, 시스템 모니터링(가동률, 응답 시간, 에러율)만으로는 답이 맞는지 알 수 없습니다.

다시 잴 때	왜 필요한가	함께 볼 것
문서 추가·개정	새 문서가 기존 정답 문서를 밀어내거나, 개정 전 판이 계속 검색될 수 있음	평가셋 정답 문서 목록 갱신
임베딩 모델·검색 설정 변경	인덱스 설정이 함께 바뀌지 않으면 검색 품질만 조용히 떨어질 수 있음	검색 Recall@k 변화
LLM 교체·업그레이드	같은 근거로도 답의 형식·정확도가 달라짐	답변 정답률, 답 없음 처리율
파서 업그레이드	표·스캔본 처리 결과가 바뀜	표 질문 유형 정답률
권한 정책 변경	권한 없는 문서가 근거로 섞일 수 있음	권한 질문 유형, 다른 계정으로 교차 확인
정기 점검(분기 1회 등)	위 변경이 기록 없이 쌓였을 때를 대비	지난 결과와 단계별 비교

결과는 단계별 점수를 지난 회차와 나란히 놓고 봅니다. 최종 정답률이 같아도 검색 점수가 내려가고 답변 점수가 올라갔다면 다음 문서 개정 때 문제가 드러날 수 있습니다. 숫자로 기록해 두면 현업과도 "좋아진 것 같다" 대신 "정확도가 62%에서 71%로 올랐다"처럼 이야기할 수 있습니다[3].

평가 결과는 어떻게 보고하나요?

평가 결과는 단계별 점수, 질문 유형별 점수, 틀린 질문 목록 세 가지로 보고합니다. 전체 정답률 하나만 보고하면 무엇을 고칠지 정할 수 없습니다.

보고 항목	내용	쓰는 곳
단계별 점수	파싱 점검 결과, 검색 Recall@k, 답변 정답률	개선 작업 우선순위
질문 유형별 점수	표 숫자, 비슷한 문서 구분, 답 없는 질문 등 유형별 정답률	약한 유형 집중 개선
틀린 질문 목록	질문, 기대 정답, 실제 답, 검색된 문서, 틀린 단계	원인 분석, 다음 회차 비교
지난 회차 비교	회차별 점수 변화와 그 사이 바뀐 것(문서·모델·설정)	변경 영향 확인

PoC에서 여러 솔루션을 비교할 때도 같은 평가셋과 같은 보고 형식을 모든 후보에 적용해야 공정합니다.

올거나이즈는 RAG 평가를 어떻게 지원하나요?

올거나이즈는 고객 문서로 평가셋을 자동으로 만들고 정확도를 재는 RARE 평가 기능을 알리에 넣어 제공합니다. 같은 방법론을 ACL 2026 본회의 논문으로 발표했고 국내 특허를 받았습니다.

• 우리 문서로 평가셋 자동 생성: 업로드한 문서에서 평가 질문과 정답을 만들고, 문서가 추가·변경될 때마다 새 평가셋을 만들 수 있습니다. RARE 기능 소개
• 비슷한 문서가 많은 환경의 공정한 채점: 같은 사실이 여러 문서에 있으면 모두 정답으로 인정하는 방식으로 금융·법률 문서의 검색 정확도를 잽니다. ACL 2026 논문 소개
• 한국어 평가 데이터 공개: 금융·공공·의료·법률·커머스 분야 한국어 RAG 평가 데이터셋을 리더보드와 함께 공개했습니다. RAG 리더보드
• 망분리 환경 평가: 평가 기능을 포함한 플랫폼을 사내 서버에 설치해 외부 연결 없이 운영할 수 있습니다. 알리 웍스 온프레미스

우리 문서로 PoC 평가셋을 함께 설계해 보려면 도입 상담으로 문의해 주세요.

자주 묻는 질문

Q. RAG 평가셋은 몇 문항이 적당한가요?
업무 분야마다 60개 안팎이 다루기 좋습니다. 질문 유형(단순 사실, 표 숫자, 여러 문서, 비슷한 문서 구분, 답 없는 질문, 권한)마다 10개 안팎씩 배분하고, 운영 범위가 넓으면 분야를 늘립니다.

Q. 평가 질문을 LLM으로 만들어도 되나요?
됩니다. 다만 LLM이 만든 질문은 실제 업무 표현과 다르거나 정답이 애매한 경우가 있어 현업 담당자가 골라야 합니다. 실제 문의 기록에서 나온 질문을 먼저 쓰고 모자란 유형을 LLM으로 채우는 순서가 좋습니다.

Q. 검색 정확도와 답변 정확도 중 무엇을 먼저 봐야 하나요?
검색을 먼저 봅니다. 맞는 문서를 찾지 못하면 어떤 LLM을 써도 맞는 답을 쓸 수 없습니다. 검색 Recall@10이 충분한데 답이 틀릴 때 프롬프트와 LLM을 손봅니다.

Q. RAGAS 같은 공개 평가 도구만 쓰면 되나요?
채점 도구로는 쓸 수 있습니다. 다만 도구가 평가셋을 대신 만들어 주지는 않고, 같은 내용이 여러 문서에 있는 경우의 정답 처리도 평가셋을 만들 때 정해야 합니다. 채점 도구 여러 개를 함께 쓰고 일부는 사람이 다시 채점하세요.

Q. 운영 중 정확도는 얼마나 자주 다시 재나요?
문서 개정, 모델 교체, 파서 업그레이드, 권한 정책 변경이 있을 때마다 다시 재고, 변경이 없어도 분기 1회 정도 정기적으로 잽니다.

출처

1. 올거나이즈, "RAG 리더보드 공개: 금융, 공공, 의료, 법률, 커머스 한국어 RAG 성능 평가"(2024년 5월 29일). 블로그
2. 올거나이즈, "RARE: Redundancy-Aware Retrieval Evaluation Framework for High-Similarity Corpora", ACL 2026 Main Conference. 올거나이즈 블로그 소개글
3. 올거나이즈, "RARE: 고객 문서 기반으로 RAG 정확도를 직접 측정합니다"(2026년 1월 21일). 블로그
4. 대한민국 특허 제10-3031382호 "고유사·중복 말뭉치를 위한 중복 인지 검색평가 데이터셋 구축 방법 및 시스템", 특허권자 올거나이즈코리아, 2026년 10월 7일 등록
5. Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena", NeurIPS 2023(arXiv 2306.05685) 원문
6. OpenAI, Evaluation best practices; Anthropic, Define success criteria and build evaluations(공식 개발 문서, 2026년 10월 확인) OpenAI · Anthropic