実在に近い社内データでRAGを検証するためのオープンベンチマーク

実際の企業をシミュレートする50万件の文書から成るコーパスを構築し、そのうえでRAGシステム同士を競わせて「どれが最も優れているか」を調べました。

EnterpriseRAG-Bench を紹介します。企業規模の社内ナレッジにありがちな、混沌とした状況でRAGシステムがどれだけうまく機能するかを検証するためのベンチマークです。

多くのRAGベンチマークは公開データに基づいています。Wikipedia、Webページ、論文、フォーラムなどです。それは有用ですが、現場で多くの人が対しているものとは実際にはあまり一致していません。Slackスレッド、メールの連鎖、チケット、会議の議事録、PR（プルリクエスト）、CRMのメモ、ドキュメント、そしてWikiです。

そこで、より実在の企業に近い挙動をする合成企業を生成することを試みました。

公開されたデータセットは Redwood Inference という企業をシミュレートしており、以下にまたがって約50万件の文書を含みます：

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

私たちが最も時間をかけたのは、「大量のドキュメントを生成すること」ではありませんでした。文書が同じ企業に属しているように感じられるための方法論（手順）です。

大まかに言うと、生成パイプラインは次のように機能します：

1. まず企業を作る 人間が関与するプロセスを用いて、企業を定義します。企業が何をするのか、製品は何か、ビジネスモデル、チーム、取り組み（イニシアチブ）、市場、社内の用語などを決めます。
2. 共有の土台（スキャフォールド）を生成する そこから、高レベルのイニシアチブ、従業員ディレクトリ、ソース固有のフォルダ構造、そして各領域の文書がどのような見た目／内容であるべきかを説明するagents.mdファイルなどを生成します。たとえば、公開コーパス内のGitHubドキュメントは、ランダムなGitHubのイシューではなく、プルリクエストとレビューコメントです。
3. 高い忠実度のプロジェクト文書を生成する 企業のイニシアチブを、より小さなプロジェクト／ワークストリームに分解します。各プロジェクトには、複数のソースにまたがって関連する一連の文書を割り当てます。PRD、Slackでの議論、会議メモ、チケット、PR、顧客メモなどです。これらの文書は互いを意識して生成されるため、現実的な文書間のリンクや依存関係が得られます。
4. 高ボリュームの文書をより低コストで生成する コーパスの大部分では、ソース種別ごとのトピックス・スキャフォールドを使います。これにより、LLMが同じ少数のテーマに何度も収束してしまうのを防ぎます。単純な実験として、企業の概要だけを与えてLLMに企業ドキュメント100件を生成させると、40％を超えるものが非常に近い重複／兄弟（同系統）でした。トピックス・スキャフォールドは、その問題への対処です。
5. 現実的なノイズを追加する 実際の企業データはきれいではありません。そのため意図的に次を追加します：
   • ランダムに誤配置された文書
   • LLM的に尤もらしい誤った格納（ファイル）
   • 事実が変更された近い重複
   • ミームやハッカソンのメモ、ランダムなアセットなどの、インフォーマル／その他のファイル
   • 矛盾する／古い情報
6. 検索失敗モードに基づいて設計された質問を生成する ベンチマークには、10カテゴリにまたがる500問があります。例えば：
   • 単純な単一文書の参照
   • 意味ベース／キーワードの一致が控えめな質問
   • 1つの長い文書にまたがって推論が必要な質問
   • 複数文書にまたがるプロジェクト質問
   • 気をそらす情報（distractors）付きの制約されたクエリ
   • 矛盾する情報に関する質問
   • 関連する文書をすべて揃える必要がある網羅性の質問
   • その他／話題から外れた文書
   • 高レベルの統合（シンセシス）に関する質問
   • 答えられない質問（unanswerable questions）
7. 修正（コレクション）を踏まえた評価を行う 50万件規模の文書では、元の「正解（gold）文書セット」が完全であることを保証するのは難しいです。そこで、評価用ハーネスは、候補として取得された文書を考慮し、それが必要／妥当／不適切のどれかを判定し、根拠が支持する場合にはgoldセットを更新できます。

論文から得られたいくつかのベースライン結果：

• BM25が意外なほど強かった。ベクター検索を、全体的な正確性と文書リコールの両面で上回りました。
• ベクター検索は意味的な質問でも（さらに）振るわなかった。それらはキーワードの重なりを減らすように設計されていたので、興味深い結果でした。
• エージェント／bashスタイルの検索は網羅性が最も良かった。特に、関連ファイルを探索する必要がある質問では有利でしたが、その分ずっと遅く、コストも高くなりました。
• 一般に、正しい文書をコンテキストに入れられるかが非常に重要だった。関連する根拠が取得できさえすれば、当時の現在のLLMはたいてい良い回答を生成できました。

リポジトリには、データセット、生成フレームワーク、評価ハーネス、リーダーボードが含まれています：

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

社内データを対象にRAG／検索システムを作っている他の方からのフィードバックが欲しいです。特に、ここでうまくいきそうだと思う検索のセットアップは何かを知りたいです。ハイブリッド検索、リランカ、エージェント、メタデータフィルタ、クエリ書き換え、グラフ風のトラバーサルなど。