# 社内情報管理のためのRAG構築 ー どのように検証していくべきか
こんにちは AI事業本部の市田拓馬です！
今後、検索だけでなく、情報管理にもRAGが使われるようになってくるのではないか。という想定のもと、このブログを書きました。
はじめに
生成AIの活用は、文章生成や要約から、検索と推論を組み合わせた使い方へと広がってきました。中でも、検索結果を根拠として大規模言語モデルに回答させる仕組み、RAG（Retrieval-Augmented Generation）は、生成AIの推論精度と回答の信頼性を引き上げる方法として広く使われるようになっています。
一方で、社内情報の管理という用途に視野を広げると、RAGの実用化はまだ道半ばです。FAQ応答のような限定的なタスクでは動いても、複数の業務システムに散らばった社内情報を横断的に取得し、業務判断に使える回答を返す、という水準には届いていません。
社内RAGを実用水準に引き上げるには、検索モデルや生成AIモデルの性能を上げるだけでなく、散らかった社内情報を相手にしたときの性能を正しく測れる評価環境 が必要です。既存のRAG評価は公開Webを対象に作られているため、そこで高得点を取れても、メール・チャット・チケット・議事録などにまたがる本番の社内情報でどこまで使えるかは判断できません。改善の方向も、改善できたかどうかも測れない状態が、社内RAGの実用化を遠ざけています。
本記事では、企業内ナレッジを対象にしたRAG評価ベンチマーク EnterpriseRAG-Bench を題材に、次の流れで議論を進めます。
- 背景 — 生成AIとRAGがいまどこまで来ているか
- 課題 — 社内情報管理という用途が、なぜ既存のRAG評価で測れないか
- EnterpriseRAG-Bench — その課題に答えるベンチマークが何を提示しているか
- 学び — そこから、社内RAGを検証するときに意識すべきこと
本記事の主張を一言で言うと、次の通りです。
社内RAGの評価は、検索モデルを比較する前に、仮データベースと質問セットをどれだけ現実の業務に近づけられるかで決まる。
そのうえで、本記事で特に共有したいのは、次の2点です。
- 仮データベースの作り方 — どの情報源を、どんな比率で、どんなノイズを含めて用意するか
- 質問セットの作り方 — どんな種類の質問を入れれば、本番導入時に業務上危ない失敗を見つけられるか
評価指標の見方や、検証結果の読み方も後半で取り上げますが、それらは仮データベースと質問セットが正しく設計されて初めて意味を持ちます。
EnterpriseRAG-Benchは、社内情報を対象にしたRAG評価ベンチマークを提案する論文です。本記事では、その中から、社内情報管理でRAGを使えるようにしていくうえで、どのように検証すべきか、評価環境をどう作るかを考える際に参考になる観点を取り出して紹介します。
1. 背景：生成AIとRAGはどこまで来たか
生成AIは、ここ数年で「文章を生成する」段階から、「検索結果や業務データを取り込み、根拠を示しながら回答する」段階に進みました。その中心にあるのがRAGです。
RAGは、ユーザーの質問に対して、まず関連する文書を検索し、その検索結果を大規模言語モデル（ChatGPT、Claude、Geminiのような文章生成AI）に渡して回答させる仕組みです。これにより、次の2つが同時に得られます。
- 推論精度の向上 — モデル単体の記憶に頼らず、外部の最新情報を根拠にできる
- 検索能力の向上 — 単なるキーワードマッチではなく、自然文の質問に対して意味的に関連する文書を返せる
公開情報を対象にした質問応答（製品マニュアルQ&A、Wikipediaベースのチャットボット、調査支援ツールなど）では、RAGは既に一定の実用水準に到達しています。
問題は、この成功体験を 社内情報管理 に持ち込んだときに起こります。
2. 課題：社内情報管理という用途の特殊性
社内RAGがうまくいかないとき、その原因は「検索エンジンが弱い」「モデルが小さい」のような技術選定の問題に見えがちです。しかし、もっと手前に本質的な課題があります。
2-1. 社内情報管理は「単一文書の検索＋推論」では足りない
社内情報の検索は、特定の文書を1つ見つけてその中で完結する質問とは構造が違います。
たとえば「この顧客との合意済みの仕様変更は何か」という業務質問の根拠は、次のように分散しています。
- Slackでの初期相談
- Gmailでの正式やり取り
- HubSpotの商談ステータス
- JiraやLinearのチケット
- Firefliesの議事録
- Confluenceにまとめられた最終方針
1つの文書を上手に検索できても、業務の流れを復元できなければ意味がありません。社内情報管理でRAGを使えるようにしていくには、複数の情報源に散らばったデータから、関係する情報を体系的に集めて回答を組み立てる能力 が必要になります。
2-2. 「それっぽく答えた」だけでは見えない失敗が多い
加えて、社内情報には次のような癖があります。
- 古い情報と最新情報が混在している
- 文書間で内容が矛盾している
- 社内だけで通じる略語・コードネームが使われている
- 似ているが内容が違う文書がある
- 誤ったフォルダに保存された文書が混じる
- 答えがそもそも存在しない領域がある
このような環境では、回答文の自然さだけを見ても、社内RAGが本番で起こす失敗は見えません。実際に見るべきなのは、次のような点です。
- 必要な根拠文書を拾えているか
- 古い情報を最新情報のように扱っていないか
- 矛盾する情報を無視して断定していないか
- 全件取得が必要な質問で漏れが出ていないか
- 答えが存在しないときに、存在しないと言えているか
- 社内用語や略語でも探せているか
文章生成の流暢さだけは、根拠が薄くても成立してしまいます。社内RAGを使うユーザーから見ると、間違った回答であっても自信ありげに読めてしまう ということが起こり得ます。
2-3. 既存のRAG評価は、公開Web寄りに作られている
既存のRAG評価ベンチマークの多くは、WikipediaやWebページのような公開情報を対象に設計されています。そのため、企業内データに特有の「散らばり方」「矛盾」「内部用語」「ノイズ」をほとんど含みません。
つまり、社内RAGに本当に必要な能力は、既存ベンチマークで高得点を取っても担保されない、という状況になっています。
2-4. だから、評価環境を先に作る必要がある
ここまで整理すると、社内RAG実用化の手前にある課題は、こう言い換えられます。
社内情報管理でRAGを使えるようにしていくためには、検索手法や生成AIモデルを比較する前に、社内情報の散らかり方を再現した評価環境 を作る必要がある。
評価環境は、大きく次の2つで構成されます。
- 仮データベース — 評価のための社内文書コーパス
- 質問セット — 業務上の代表的な質問と、その正解・根拠文書
この2つをどう作るかを決めないまま検索手法だけを比較しても、本番導入で起こる失敗は見つかりません。
この章の結論： 社内RAGの実用化には検索性能や生成精度の改善も欠かせないが、その手前に「社内情報の散らかり方を再現した評価環境がない」という課題がある。ここを埋めない限り、性能の改善方向も、改善できたかどうかも判断できない。
3. EnterpriseRAG-Bench：社内情報管理RAGの評価環境をどう作るか
ここで登場するのが EnterpriseRAG-Bench です。論文の正式タイトルは「EnterpriseRAG-Bench: A RAG Benchmark for Company Internal Knowledge」で、企業内ナレッジを対象にしたRAG評価ベンチマークとして2026年に公開されました。
論文の構成を最小限だけ整理すると、次の通りです。
- 約50万件の合成企業内文書
- 9種類の企業内情報源
- 500問の評価質問
- 10種類の質問カテゴリ
- データセット、コード、評価ハーネス、リーダーボードがすべて公開されている
含まれる情報源は、以下の9種類です。
- Slack
- Gmail
- Linear
- Google Drive
- HubSpot
- Fireflies
- GitHub
- Jira
- Confluence
10種類の質問カテゴリは、Basic / Semantic / Intra-Document Reasoning / Project Related / Constrained / Conflicting Info / Completeness / Miscellaneous / High Level / Info Not Found です。本記事の後半では、このうち社内RAG検証で特に意識したいカテゴリを取り上げて掘り下げます。
ここで重要なのは、情報源の 数の多さそのもの ではありません。
論文が前提にしているのは、「社内情報は、公式文書だけではなく、チャット、メール、チケット、営業記録、議事録、社内Wikiに分散している」という現実です。したがって、社内RAGの評価では、複数の業務情報源をまたいで情報を探す能力を見なければならない、という発想がベースにあります。
本記事では、EnterpriseRAG-Benchを「企業内RAGの新しいベンチマーク」として紹介するのではなく、社内RAGの評価環境を設計するための材料 として扱います。論文の設計には、社内情報管理でRAGを使えるようにしていくうえで参考にできる観点が、データ・質問・指標の3つの層に含まれています。
この章の結論： EnterpriseRAG-Benchは、社内RAGの評価対象を「きれいな文書検索」から「複数の業務情報源を横断する検索」へ広げているベンチマークである。
4. 論文から読み取れる、評価設計の5つの思想
ここからは、EnterpriseRAG-Benchの設計を見ていきます。論文の設計を細かく見ていくと、社内RAGを評価するときに データ側で何を再現する必要があるか が分かります。論文の設計思想は、大きく次の5点に整理できます。
- 文書同士のつながり
- 情報源ごとの現実的な分布
- 現実的なノイズ
- 社内用語・略語・コードネーム
- 業界・企業規模に応じた変化
4-1. 文書同士のつながり
論文では、cross-document coherence（文書間の一貫したつながり）が重視されています。同じプロジェクト、人物、意思決定、顧客、施策を通じて、複数の文書が関係する形でコーパスが設計されています。
実務でも、ある案件の経緯は1つの文書では完結しません。Slackでの相談、Gmailでの正式やり取り、HubSpotの商談ステータス、Jira/Linearのチケット、Firefliesの議事録、Confluenceの最終方針、というように分散します。
4-2. 情報源ごとの現実的な分布
論文のコーパスでは、SlackやGmailのような日常的なコミュニケーション情報が大きな比率を占め、Confluenceのような整備されたナレッジベースは相対的に少ない構成になっています。実際にAppendix Dでは、Slackが285,605件、Gmailが121,390件、Confluenceが5,189件、合計511,962件と示されています。
これは、企業において非公式なコミュニケーションチャネルの方が、整備されたナレッジベースより多くの文書を生みやすいという現実を反映しています。
4-3. 現実的なノイズ
論文では、社内で実際に起きる「散らかり方」を再現するために、ノイズを次の4種類で意図的に混ぜています。
- Random shuffle（無作為の誤配置） — 文書を、本来あるべき場所と同じ情報源タイプ内で、ランダムに別の場所へ動かします。たとえば、営業部のConfluenceスペースにあるべき提案資料が、人事部のスペースに紛れ込んでいるような状態です。整理が行き届いていない、現実の社内文書管理に近い状況を作ります。
- LLM-based shuffle（もっともらしい誤配置） — 上記のランダム移動と違い、LLMを使って「ぱっと見では違和感のない場所」へ文書を動かします。たとえば、財務戦略チームの議事録が、テーマの近い経営企画チームのスペースに置かれている、といった状態です。検索結果に「内容は近いが本来の根拠ではない文書」が混ざる状況を再現します。
- Near-duplicates（似ているが事実が違う文書） — ベースの文書から、数値・日付・担当者などの特定の事実だけを書き換えた類似文書を作ります。旧版と最新版が混在している、同じ案件について2系統の記述が残っている、といった状況の再現です。
- Miscellaneous files（雑多なファイル） — 本筋から外れた、アドホックに作成されたファイルを散在させます。個人メモ、過去の没企画、関係ない作業ログなど、業務でよく見る「とりあえず保存された雑多なファイル」が含まれる状況を作ります。
このうち、Near-duplicatesで作られた「事実が食い違うペア」は、そのままConflicting Infoカテゴリの質問生成にも使われます。つまり矛盾情報は、独立した5つ目のノイズ手法というより、Near-duplicatesと質問カテゴリの両方にまたがる設計として組み込まれています。
整えられすぎたデータセットでは、本番で起こる失敗を再現できない。これが、ノイズを意図的に混ぜる論文の前提にある考え方です。
4-4. 社内用語・略語・コードネーム
論文は、企業内データの特徴として、プロジェクトコードネーム、製品固有の略語、組織内ジャーゴンを扱っています。
実際のユーザーは、文書内の正式名称を知らずに質問することが多く、ここを再現できていない評価データでは、現場で使えるかどうかは判断できません。
4-5. 業界・企業規模に応じた変化
EnterpriseRAG-Benchはあくまで合成データであり、すべての企業に当てはまる「絶対のデータセット」を作ろうとしているわけではありません。むしろ、業界や規模に応じて作り変えられる前提で、評価データの作り方そのものを示しているとも読めます。
この章の結論： 社内RAGの評価環境は、文書量ではなく、ここで挙げた5つの観点 — 文書同士のつながり、情報源ごとの分布、現実的なノイズ、社内用語、業界・規模への適応性 — で、社内情報の散らかり方をどこまで再現できているかで判断すべきである。
5. 仮データベースを作る時に意識すること
ここからは、論文の設計思想を踏まえて、社内RAG検証用の 仮データベース をどう作るべきかを整理します。
この章の大主張はシンプルです。
仮データベースは、きれいな文書集ではなく、社内情報の散らかり方を再現するために作る。
5-1. FAQやマニュアルだけで構成しない
主張： 仮データベースをFAQ、マニュアル、社内規程、Wikiだけで作ると、社内RAGの本当の難しさを再現できません。
検証時のポイント： 評価用データには、少なくとも次のような種類を含めましょう。
- 公式文書
- 社内Wiki
- メール
- チャット
- 議事録
- チケット
- 営業記録
- 共有ドキュメント
情報源ごとに役割が違うことも意識すべきです。たとえば、顧客との合意はメールに残っているかもしれない。仕様変更の経緯はチケットに残っているかもしれない。暫定対応はSlackにしか残っていないかもしれない。最終方針はConfluenceにまとまっているかもしれない。これらを混ぜなければ、業務の流れを横断する検索能力は測れません。
論文との接続： EnterpriseRAG-Benchは、Slack、Gmail、Linear、Google Drive、HubSpot、Fireflies、GitHub、Jira、Confluenceという9種類の情報源を扱っています。企業内の情報が単一の文書管理システムだけに存在するわけではない、という前提です。
5-2. 情報源ごとの量に偏りを持たせる
主張： 仮データベースでは、各情報源の件数を均等にしない方がよいです。
検証時のポイント： 仮データベースを作る時は、次の考え方が有効です。
- 日常的に発生する情報源は多めにする
- 公式に整理された文書は相対的に少なめにする
- ただし、公式文書は件数が少なくても、情報源としての重要度は高く扱う可能性がある
- 件数の多さと信頼度は別物として考える
社内RAGの難しさは、まさに「大量の雑多な情報の中から、信頼できる根拠を見つけられるか」にあります。件数を揃えたデータでは、この難しさが消えてしまいます。
論文との接続： §4-2 で見たとおり、論文では日常的なコミュニケーション情報源（SlackやGmail）が多く、整備されたナレッジベース（Confluence）は少ない構成になっています。
5-3. 文書同士につながりを持たせる
主張： 仮データベースは、孤立した文書の集まりではなく、同じ顧客・同じ案件・同じプロジェクトを軸につながっている必要があります。
検証時のポイント： 仮データベースを作る時は、以下の軸で文書をつなげましょう。
- 顧客 / プロジェクト / 問い合わせ / 商談
- 仕様変更 / 障害対応 / 社内承認 / 部署間連携
- 担当者
そのうえで、1文書では答えられない質問（後述の「複数文書をまたぐ質問」）を成立させる土台を作ります。
論文との接続： §4-1 で触れた cross-document coherence を、自分の仮データベースでも再現する、ということです。
5-4. あえてノイズを入れる
主張： 評価用データは、きれいに整えすぎてはいけません。
検証時のポイント： 仮データベースには、あえて次のような文書を含めます。
- 古い情報
- 矛盾する情報
- 似ているが事実が違う文書
- 誤分類された文書
- 一見関係ありそうだが根拠にならない文書
- 正式決定ではない暫定メモ
- 旧版資料
- 更新日が古いが検索では上位に来やすい文書
ノイズを取り除いた評価データでは、実際の社内RAGで起こる失敗を検出できません。
論文との接続： §4-3 で見た4種類のノイズ（Random shuffle / LLM-based shuffle / Near-duplicates / Miscellaneous files）と、Near-duplicates から派生する矛盾情報を、自分の仮データベースでも意図的に混ぜる、ということです。
5-5. 社内用語・略語・コードネームを入れる
主張： 評価用データには、正式名称だけでなく、社内で実際に使われる略語・コードネームを含める必要があります。
検証時のポイント： たとえば、正式名称が「法人向け請求書照合自動化プロジェクト」であっても、社内では「請求照合」「Invoice AI」「A案件」「照合自動化」「経理AI」などと呼ばれるかもしれません。文書内では正式名称、Slackでは略称、というように表記が分かれることもあります。
仮データベースには、次の表現を意識的に混在させます。
- 正式名称 / 略称 / 旧名称
- 部署内の呼び方 / コードネーム
- 顧客名やシステム名の略称
- 英語名と日本語名
- 表記揺れ
論文との接続： §4-4 で触れたとおり、論文は project codenames / product-specific acronyms / organizational jargon を扱っています。これらを自分の仮データベースでも再現します。
5-6. 答えが存在しない領域を作る
主張： 評価用データには、あえて「答えが存在しない質問」を作れる余白を残すべきです。
検証時のポイント： 社内RAGで本当に危険なのは、情報がない時に「それらしい答え」を作ってしまうことです。次のようなケースは、業務判断を誤らせる可能性があります。
- 存在しない社内規程を説明する
- 未合意の契約条件を合意済みのように答える
- 未決定の仕様を決定事項のように答える
- 似た顧客の情報を別顧客の情報として答える
これは単なる検索ミスではなく、業務リスクそのものです。
論文との接続： EnterpriseRAG-Benchには Info Not Found という質問カテゴリがあり、答えがコーパス内に存在しない場合を評価対象に含めています。
この章の結論： 仮データベースは「きれいに整える」のではなく、「社内情報の散らかり方を再現する」ために作る。
6. 評価質問を作る時に意識すること
仮データベースが整ったら、次は 質問セット の設計です。
この章の大主張は、次の通りです。
質問セットは、平均点を出すためではなく、本番導入時に危ない失敗を見つけるために作る。
EnterpriseRAG-Benchは10種類の質問カテゴリを持ち、それぞれ異なる能力を評価しています。これをそのまま社内RAGの質問設計のチェックリストとして読み替えていきます。
6-1. 単純な一問一答だけにしない
主張： 単純な質問だけでは、社内RAGの本当の弱点は見えません。
検証時のポイント： 評価質問は、最低限次のように分けます。
- 1文書で答えられる質問
- 言い換えを含む質問
- 長い文書内の複数箇所を読む質問
- 複数文書をまたぐ質問
- 条件付き質問
- 矛盾情報を扱う質問
- 全件取得が必要な質問
- 答えが存在しない質問
論文との接続： EnterpriseRAG-Benchでは、Basicカテゴリ以外に、Semantic、Intra-Document Reasoning、Project Related、Constrained、Conflicting Info、Completeness、Miscellaneous、High Level、Info Not Foundなど、合計10種類のカテゴリが用意されています。
6-2. 言い換え・曖昧表現を含める
主張： 質問文と文書内の表現が一致しなくても、必要な情報を探せるかを見る必要があります。
検証時のポイント： 実際のユーザーは、文書内の正確な表現を知りません。たとえば、文書には「顧客解約率」と書かれていても、質問では「お客さんが離れている割合」と聞くかもしれません。
質問には、次のような表現を含めます。
- 正式名称ではなく略称で聞く
- 抽象的な言い方で聞く
- 部署内の呼び方で聞く
- 文書内の単語とは違う言い方で聞く
- 誤字や表記揺れを含める
- 「あの件」「前回の障害」のような曖昧な表現も一部入れる
論文との接続： EnterpriseRAG-Benchの Semantic カテゴリは、意味的な対応を問うもので、単純なキーワード一致では答えにくい質問を含みます。
6-3. 複数文書をまたぐ質問を入れる
主張： 社内RAGでは、1文書で答えられる質問よりも、複数文書をまたいで答える質問が重要になります。
検証時のポイント： 質問例としては次のようなものです。
- このプロジェクトの経緯は何か
- この顧客対応で未解決の論点は何か
- この仕様変更はなぜ決まったのか
- この障害対応で誰が何を判断したのか
- この商談で顧客が懸念していた点は何か
- この問い合わせに関連するチケットと議事録はどれか
1つの文書だけを検索できても、業務の流れは復元できません。
論文との接続： EnterpriseRAG-Benchの Project Related カテゴリは、同じプロジェクトに関係する複数文書から情報を集める能力を評価します。
6-4. 条件付き質問を入れる
主張： 業務上の質問には、日付・顧客・部署・ステータスなどの条件が付くことがほとんどです。
検証時のポイント： 質問には、次のような条件を含めましょう。
- 今月の／2026年5月以降の
- A社に関する／東京拠点の
- openステータスの／法務確認済みの／顧客承認済みの
- 最新版の／期限が来週までの
- 自部署に関係する
意味的に近い文書を拾えるかだけでなく、条件に合う情報だけを選べるかを見ます。
論文との接続： EnterpriseRAG-Benchの Constrained カテゴリは、条件を満たす文書や情報を見つける能力を評価します。
6-5. 矛盾情報を扱う質問を入れる
主張： 社内RAGでは、矛盾する情報をどう扱うかが特に重要です。
検証時のポイント： 社内では次のような矛盾が普通に起きます。
- 古いメールと最新CRMの内容が違う
- Slack上の暫定発言と正式文書が違う
- 旧版資料と最新版資料が混在している
- 議事録とチケットのステータスが違う
- 営業担当のメモと契約書の内容が違う
評価時には、次の観点を見るべきです。
- 矛盾を検出できるか
- どの情報が新しいかを判断できるか
- どの情報源を優先すべきかを扱えるか
- 一方の情報だけを根拠に断定していないか
- 不確実な場合に保留できるか
論文との接続： EnterpriseRAG-Benchの Conflicting Info カテゴリは、矛盾する文書を前提にした質問カテゴリです。
6-6. 全件取得が必要な質問を入れる
主張： 「1つ見つける」と「全部見つける」は、まったく別の能力です。
検証時のポイント： 業務には、1件でも漏れると困る質問があります。
- 未対応の問い合わせをすべて出して
- 契約更新対象をすべて挙げて
- この障害の影響顧客をすべて出して
- このプロジェクトの未解決論点をすべて挙げて
- 今月中に対応が必要なタスクをすべて出して
このタイプの質問では、top-k検索（関連度が高そうな上位k件だけを取得する検索方式）に依存していると、上位10件に入らない正解文書が漏れる可能性があります。代表的な文書を拾えるかだけでなく、必要な情報を 漏れなく 拾えるかを別軸で評価する必要があります。
論文との接続： EnterpriseRAG-Benchの Completeness カテゴリは、関連情報を網羅的に取得する能力を評価します。
6-7. 情報が存在しない質問を入れる
主張： 社内RAGでは、答えがない時に答えない能力が必要です。
検証時のポイント： 評価には、次のような質問を入れます。
- 存在しない規程について聞く
- 未合意の顧客条件について聞く
- まだ決まっていない仕様について聞く
- 似た別案件の情報を混ぜて聞く
- 存在しない承認者を聞く
- まだ作成されていない資料について聞く
「根拠が見つかりません」と言えるかどうかは、社内RAGの実用性を分ける本質的な能力です。
論文との接続： EnterpriseRAG-Benchの Info Not Found カテゴリは、答えがコーパス内に存在しない場合を評価対象にしています。
この章の結論： 質問セットは、業務上の失敗パターンを再現するために作る。
7. 評価の仕方と結果の見方
仮データベースと質問セットができたら、その上でどの指標を見るか、結果をどう読むかを決める必要があります。
7-1. 4つの指標を分けて見る
EnterpriseRAG-Benchは、主に次の4指標を分けて評価しています。
- Correctness（正確性） — 回答が正しいか。ただし、根拠文書が不十分でも、たまたまモデルが知っていて正答するケースがあるため、これだけでは検索の質まで分かりません。
- Completeness（網羅性） — 必要な事実を漏らしていないか。回答の一部が正しくても、重要項目が漏れていれば業務上は不十分です。全件取得が必要な質問では特に重要になります。
- Document Recall（文書再現率） — 期待文書IDを持つ質問に対して、gold documentsが取得結果に含まれている割合。ここが落ちていると、生成モデルを改善しても限界があります。失敗の原因切り分けで最初に見るべき指標です。
- Invalid Extra Documents（余計な文書） — goldでもvalidでもない文書をどれだけ余計に拾ったか。検索のリコールを上げると、その代償としてこの指標が悪化することがあるため、両方を同時に見る必要があります。
正答率（Correctness）だけでは、失敗の原因が「検索なのか／生成なのか／網羅性なのか」を切り分けられません。
7-2. 結果は平均ではなく、失敗の種類で読む
ここからは論文の直接の主張ではなく、論文の設計から本記事として導く実務上の示唆です。
EnterpriseRAG-Benchは、質問カテゴリを10種類に分け、4指標を分けて評価しています（一方でリーダーボード自体は単一のaggregate scoreでランキングしています）。この設計は、回答品質と検索性能を分けて見るための手がかりになります。本記事では、社内RAG検証でも、平均スコアだけでなく どの種類の質問で失敗しているか を見るべきだと解釈します。
特に、誤答の業務リスクは質問によって大きく異なります。社内イベントの日程を間違えるのと、契約更新対象を漏らすのとでは、業務上の重みが違います。すべての質問を同じ「1問の失点」として平均すると、この差が見えなくなります。質問を業務リスクごとに分類し、リスクの高いカテゴリに弱点がある場合は、人間の確認プロセスを必須にするなどの運用設計を行います。
この章の結論： 4指標で失敗の所在を切り分け、平均ではなくカテゴリ別・業務リスク別に結果を読む。
8. まとめ
本記事では、社内情報管理でRAGを使えるようにしていく時の検証で意識すべきポイントを、EnterpriseRAG-Benchの設計を手がかりに整理しました。
中心となるのは、次の2つです。
- 仮データベースの作り方 — メール・チャット・議事録・チケット・営業記録・社内Wikiなど多様な情報源を含め、情報源ごとの量の偏り、文書同士のつながり、現実的なノイズ、社内用語、答えが存在しない領域を意図的に組み込む。
- 質問セットの作り方 — 単純な一問一答だけでなく、言い換え、複数文書横断、条件付き検索、矛盾情報、全件取得、情報不存在を含める。
加えて、これらを評価する時には、Correctness／Completeness／Document Recall／Invalid Extra Documents の4指標で失敗の所在を切り分け、平均ではなくカテゴリ別・業務リスク別に結果を読みます。
これらを押さえずに検索手法やモデルを比較しても、社内RAGとして本当に使えるかは判断できません。社内RAG検証は、評価環境の設計から始めるのが現実的だと考えます。
参考文献
- Yuhong Sun, Joachim Rahmfeld, Chris Weaver, Weijia Chen, Roshan Desai, Wenxi Huang, Mark H. Butler. EnterpriseRAG-Bench: A RAG Benchmark for Company Internal Knowledge. arXiv:2605.05253, 2026. https://arxiv.org/abs/2605.05253
- データセット（Hugging Face）：https://huggingface.co/datasets/onyx-dot-app/EnterpriseRAG-Bench
- コードとリーダーボード（GitHub）：https://github.com/onyx-dot-app/EnterpriseRAG-Bench
