An Open Benchmark for Testing RAG on Realistic Company-Internal Data

우리는 실제 회사의 시뮬레이션을 위한 50 만 개의 문서 코퍼스를 구축하고, RAG 시스템이 어느 것이 가장 좋은지 경쟁하게 했습니다.

EnterpriseRAG-Bench, 불완전한 기업 규모의 내부 지식에 대해 RAG 시스템이 얼마나 잘 작동하는지를 테스트하기 위한 벤치마크를 소개합니다.

대부분의 RAG 벤치마크는 공개 데이터를 기반으로 구축됩니다: 위키백과, 웹 페이지, 논문, 포럼 등. 이는 유용하지만, 실제로 많은 사람들이 대항하고 있는 것과 맞지 않습니다: Slack 스레드, 이메일 체인, 티켓, 회의 전사, PRs, CRM 노트, 문서, 위키 등.

그래서 우리는 실제 회사와 더 유사한 행동을 하는 합성 회사를 구축하려고 했습니다.

발행된 데이터셋은 Redwood Inference라는 회사의 시뮬레이션을 포함하며 약 50 만 개의 문서를 다음과 같이 포함합니다:

• Slack
• Gmail
• Linear
• Google Drive
• HubSpot
• Fireflies
• GitHub
• Jira
• Confluence

우리가 가장 많은 시간을 투자한 부분은 "많은 문서를 생성"하는 것이 아니라, 문서를 같은 회사에 속한다는 느낌을 주는 방법론이었습니다.

높은 수준에서, 생성 파이프라인은 다음과 같이 작동합니다:

1. 회사 먼저 생성 우리는 회사의 정의 (무엇을 하는지, 제품, 비즈니스 모델, 팀, 프로젝트, 시장, 내부 용어 등) 를 정의하기 위해 인간-인-루프 프로세스를 시작합니다.
2. 공유 스프레드 생성 거기서 우리는 상위 수준의 프로젝트, 직원 디렉터리, 소스별 폴더 구조, 각 영역의 문서가 어떻게 보일지 설명하는 agents.md 파일 등을 생성합니다. 예를 들어, 발행된 코퍼스의 GitHub 문서는 랜덤 GitHub 이슈가 아닌 풀 리퀘스트와 리뷰 코멘트입니다.
3. 고충실도 프로젝트 문서 생성 우리는 회사의 프로젝트를 더 작은 프로젝트/워크스트림으로 분할합니다. 각 프로젝트는 소스별 관련 문서 세트 (PRDs, Slack 토론, 회의 전사, 티켓, PRs, 고객 노트 등) 를 받습니다. 이러한 문서는 서로에 대한 인식을 가지고 생성되므로, 현실적인 교차 문서 링크와 의존성을 얻습니다.
4. 고용량 문서 더 저렴하게 생성 코퍼스의 대부분을 위해, 우리는 소스 유형별 주제 스프레드를 사용합니다. 이는 LLM 이 같은 몇 가지 테마를 반복적으로 붕괴시키지 않도록 방지합니다. 단순한 실험에서, 우리는 회사 개요만 사용하여 100 개의 회사 문서를 요청했을 때, 40% 이상이 매우 가까운 복제/형제였습니다. 주제 스프레드는 이를 우회하는 방법입니다.
5. 현실적인 노이즈 추가 실제 기업 데이터는 깨끗하지 않으므로, 우리는 의도적으로 다음을 추가합니다:
   • 랜덤으로 잘못 배치된 문서
   • LLM-합리적 잘못 파일링 문서
   • 사실 변경된 유사 복제본
   • 미인용/혼재 파일 (메모, 해커톤 노트, 랜덤 자산 등)
   • 충돌/오류 정보
6. 검색 실패 모드를 중심으로 설계된 질문 생성 벤치마크는 10 개의 범주에 걸쳐 500 개의 질문을 포함하며:
   • 단순 단일 문서 조회
   • 의미론적/키워드 중첩 질문
   • 하나의 긴 문서에 대한 추론이 필요한 질문
   • 다중 문서 프로젝트 질문
   • 오해의 소지가 있는 제한된 쿼리
   • 충돌 정보 질문
   • 모든 관련 문서를 필요로 하는 완전성 질문
   • miscellaneous/off-topic 문서
   • 상위 수준 종합 질문
   • 답변할 수 없는 질문
7. 교정 인식 평가 사용 50 만 개의 문서에서, 원래 골드 문서 세트가 완벽하다고 보장하는 것은 어렵습니다. 따라서 평가 허니는 후보 검색 문서를 고려하고, 그들이 필요/유효/무효인지 판단하며, 증거를 지원할 때 골드 세트를 업데이트합니다.

이 논문에서 얻은 기초적인 발견점 몇 가지를 정리해 드립니다:

• BM25는 놀랍도록 강력했습니다, 전체 정확도와 문서 회귀 (document recall) 측면에서 벡터 검색을 압도했습니다.
• 벡터 검색은 의미론적 질문에서도 성능이 저조했습니다. 이는 이러한 질문들이 키워드 중복을 줄이기 위해 설계되었기 때문에 흥미로운 점입니다.
• 에지 기반/바시 스타일의 검색은 관련 파일을 탐색해야 하는 질문에서 특히 가장 높은 완전성 (completeness) 을 보였으나, 속도와 비용 측면에서는 훨씬 느리고 비쌌습니다.
• 일반적으로 맥락에 올바른 문서를 제공하는 것이 매우 중요했습니다. 관련 증거가 검색된 후에는 현재 LLMs 는 대체로 좋은 답변을 생성할 수 있었습니다.

저희 리포지토리는 데이터셋, 생성 프레임워크, 평가 도구 및 리더보드를 포함합니다:

https://github.com/onyx-dot-app/EnterpriseRAG-Bench

내부 회사 데이터를 기반으로 RAG/검색 시스템을 구축하는 다른 분들의 피드백을 원합니다. 특히, 어떤 검색 설정이 가장 효과적이라고 생각하시는지 궁금합니다: 하이브리드 검색, 리랭커 (rerankers), 에이전트 (agents), 메타데이터 필터링, 쿼리 재작성, 그래프 스타일 트래버스 등.