元論文: AgenticRAG: Agentic Retrieval for Enterprise Knowledge Bases
このページは、おい丸(AI)による要約・構成案をもとに、人間が確認・加筆した合作です。内容を正確に確認したい場合は、元論文もあわせて参照してください。
これは何の論文か
この論文の良さは、RAGの改善を埋め込みモデルや再ランキングだけに閉じず、LLMがどう検索結果を読み、次の検索行動を選び、文脈を維持するかというハーネス設計へ引き戻しているところにある。
企業ナレッジベースでは、質問が短くても、答えは複数の長文、表、節、ファイル名、用語の揺れにまたがることが多い。そこで検索器に最終精度まで背負わせるより、検索器は広く、LLMは深く読むという責務分担がかなり自然に見える。
実務に引きつけるなら、社内wiki、仕様書、ログ、財務資料、サポート記事を扱うAIアシスタントで、検索APIだけを足すのではなく、検索 / find / open / summarize のような小さな読み取り道具をどう設計するかの参考になる。
通常のRAGは、検索スタックが先に候補集合を固定し、LLMはその中だけで回答する。この設計は、短いキーワード検索や高リコールな候補生成には強いが、企業内の長い文書、複数文書、状況依存、分析的な問いには弱い。
AgenticRAGは、検索エンジンそのものを置き換えない。既存の企業検索基盤を候補発見に使い、その上に推論LLMが検索、find、open、summarize を使う軽量ハーネスを重ねる。
検索器は広く候補を出し、LLMは候補文書の中を探し、必要な範囲を開き、証拠が足りなければ検索を変える。文脈が膨らめば、重要な参照IDを保ったまま要約して続行する。
評価では、BRIGHT、WixQA、FinanceBench で強い結果を報告している。一方でトークンコストは増えるため、単純な質問は従来RAG、複雑な質問は AgenticRAG へ流すハイブリッド設計が実運用では重要になる。
AgenticRAGは、企業内の大規模ファイルシステムやナレッジベースに対して、推論LLMが反復的に証拠を集めて回答するためのエージェント型RAGハーネスである。
中心の問題意識は、従来のRAGでは検索過程の深いところで候補集合が固定され、LLMがその外へ探索し直せないこと。これにより、複数文書をまたぐ問い、長文内のピンポイント情報、分析的な質問で失敗しやすくなる。
著者らは、追加学習、専用埋め込み、知識グラフ構築、コーパス固有の前処理を前提にせず、既存の企業検索基盤へ推論時の道具ハーネスを重ねる。
何が問題だったのか
企業ナレッジベースのRAGでは、検索結果を一度LLMへ渡すだけだと答えに届かないことがある。文書が長く、同じ概念が別名で書かれ、表や節やファイル名に根拠が分散しているため、最初の候補集合だけで完結しにくい。
特に問題なのは、検索のあとに探索し直せないことだ。通常のRAGでは、検索スタックが候補文書を固定し、LLMは渡された文脈の中で答える。候補が浅かったり、スニペットだけでは判断できなかったり、別の語で文書内を探す必要があったりしても、LLM側に十分な読み取り行動がない。
一方で、LLMに自由な探索を許せばよいわけでもない。企業検索では、アクセス制御、監査、引用、トークンコスト、遅延が重要になる。何度でも検索できるエージェントにすると、探索が重くなり、根拠の追跡も難しくなる。
AgenticRAG が扱う問題は、固定的な一回検索と、自由すぎる探索エージェントの間をどう設計するかである。既存の企業検索基盤を活かしつつ、LLMが必要な時だけ文書内検索、範囲読み、文脈圧縮を使って深掘りできるようにする。
提案手法の中身
ユーザー質問を会話状態へ追加し、ハーネスが履歴、トークン使用量、参照IDマッピングを保持する。
LLMは回答に自信がない場合、検索を使って企業検索基盤から候補文書を取得する。標準構成では1回の呼び出しで最大5個のクエリ書き換えを出せる。
候補のスニペットだけでは足りない場合、LLMは find で文書内の語句や概念を探す。収益指標、専門語、節名のように探す対象が見えている時に効く。
文書の文脈を広く読みたい場合、LLMは open で行番号付きの固定窓を読む。既定では1,800行単位で、必要なら開始行を変えて長い文書を移動する。
取得結果が増えて文脈が膨らむと、summarize が発火する。重要な参照IDを残し、それ以外の重い道具出力を落として、推論チェーンを続ける。
最大反復数に達するか、LLMが最終回答を出すとループが終わる。回答には根拠文書への引用を含める。
どうやって確かめたのか
評価は BRIGHT、WixQA、FinanceBench などで行われる。見る指標は、BRIGHT では再現率@1、WixQA では事実性、FinanceBench では回答の正しさである。単発検索や埋め込みベースライン、推論強化ベースラインと比較する。
また、単に精度を見るだけでなく、道具呼び出し回数、トークン使用量、複数クエリ検索の効果、モデルごとの探索行動も見る。Claude Sonnet 4.5と GPT-5-mini で探索戦略が違う点も、エージェント型 RAG がモデル依存のハーネスであることを示している。
この評価から、AgenticRAG は複雑な検索では強いが、単発検索よりかなり高コストになり得ることも分かる。したがって、性能とコストを一緒に読む必要がある。
結果はどうだったのか
BRIGHT
Claude Sonnet 4.5 で平均再現率@1 49.6%、GPT-5-miniで 43.5%。最良の埋め込みベースライン Qwen 27.8%、最良の推論強化ベースライン ReDI 26.0% を大きく上回る。
WixQA
専門家作成の分割で GPT-5-miniが事実性 0.96。E5 検索の 0.85、BM25の 0.83 を上回る。シミュレーション分割でも 0.94 を報告している。
FinanceBench
GPT-5-miniで 92.00%、Claude Sonnet 4.5で 91.78% の回答正解率。正解証拠を与えた GPT-5-mini の 94.00% に近い。
単発検索との比較
BRIGHT では単発検索の再現率@1 8.41% から、Claude Sonnet 4.5の AgenticRAGで 49.59% へ上がり、5.9倍の改善になる。
コスト。BRIGHT 平均では 52.3K トークン/クエリで、単発検索の 20.4K に対して 2.6倍。FinanceBench では 114.8K トークン/クエリで、単発検索比 7.8倍になる。
マルチクエリ検索
1回の検索で複数クエリを出せる標準構成は、同程度の再現率を少ない道具呼び出しで達成し、w/o Multi-クエリ Search より平均ツール呼び出しを 6.79から 4.79 へ減らす。
限界・注意点
- 品質改善の代わりにトークンコストと遅延が増える。単純な質問まで全部 AgenticRAG に流す設計は重く、ルーティングが必要になる。
- 多数の関連文書を広く集める問いは苦手。BRIGHTの Pony 分割のように正解文書数が多い場合、少数の高価値証拠を深掘りする戦略だけでは足りない。
- モデルごとに探索戦略が違う。Claude Sonnet 4.5 は検索が少なく open / 意味的 find が多い深掘り型、GPT-5-mini は検索が多い広め探索型として観察されている。
- 企業検索基盤の具体的な実装、アクセス制御、監査、データ漏洩対策の詳細は論文だけでは十分に分からない。実運用ではハーネス周辺の権限設計が別途必要になる。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、wiki、ブログ、コード、外部資料をまたいで調べることが多い。AgenticRAG の見方を入れるなら、検索を一発で終わらせるのではなく、検索、find、open、summarize のように役割を分けた道具列として設計する。
ただし、すべての質問をエージェント型検索に流すと重い。短い事実確認は単純検索、曖昧な調査や複数根拠が必要な問いだけエージェント型にする、といったルーティングが必要になる。
また、個人向けエージェントでも権限と引用は重要である。どの資料を開いたか、どの根拠から結論を出したかを残せるハーネスにしておくと、後から説明しやすく、誤検索の修正もしやすい。
Q&A
普通のRAGと何が違う？
普通のRAGは検索結果を一度渡して答えさせることが多い。AgenticRAGは、LLMが検索、find、open、summarize を反復して、足りない証拠を自分で取りに行く。
検索エンジンを置き換えるの？
置き換えない。既存の企業検索基盤を候補発見に使い、その上に推論LLMの道具利用ハーネスを重ねる設計になっている。
一番効いているのはどこ？
除去実験では、単発検索からエージェント型道具利用へ移ることが最も大きい。BRIGHT では再現率@1が 8.41% から 49.59% へ上がる。
findと open はどう使い分ける？
find は文書内で探す語句や概念が見えている時に使う。open は節や表の周辺など、文脈を広く読みたい時に行番号付きの窓として使う。
summarize は常に重要？
BRIGHT の除去実験では影響は小さい。ただし長い金融文書や長時間会話では、参照IDを残して重い道具出力を落とす仕組みとして重要になる。
どんな結果が出ている？
BRIGHT で平均再現率@1 49.6%、WixQAで事実性 0.96、FinanceBenchで回答正解率 92.00% を報告している。
コストはどれくらい重い？
BRIGHT 平均で単発検索の 2.6倍、FinanceBenchで 7.8倍のトークンを使う。複雑な質問には効くが、単純質問へ常時使うには重い。
苦手なケースは？
多数の関連文書を広く集めるケース。少数の高価値証拠を深掘りする設計なので、広範囲証拠収集が必要な問いでは探索方針の切り替えが必要になる。
実務ではどう使えばいい？
単純な質問は従来RAG、複雑・多意図・長文証拠が必要な質問は AgenticRAG へ流す。検索結果にはメタデータを出し、open は行番号付きにするとLLMが次の行動を選びやすい。
個人向けAIアシスタント運用に引くなら？
wiki やリポジトリ検索に検索 API を足すだけでなく、検索、文書内探索、部分読み、文脈圧縮、参照 ID 保持をハーネスの道具として分ける発想が使える。
関連する記事
- エージェント型RAGは本当に割に合うのか は、エージェント型 RAG の効果、コスト、遅延を比較する記事である。AgenticRAG の設計を、実際にどこまで割に合うかという視点で見直せる。
- コーパスを直接歩く検索エージェント は、検索器の候補を受け取るだけでなく、コーパス内を操作しながら証拠を探す記事である。企業知識ベースでの反復探索とつながる。
- 検索エージェントは情報検索をどこまで伸ばせるか と 深掘り調査を証拠グラフで進める は、検索と証拠組み立てを分けて見る記事である。AgenticRAG の検索ループを、証拠の管理まで含めて考えやすくなる。
- grepだけで十分なのか は、検索器単体ではなく、ツール結果の渡し方やハーネス設計で性能が変わることを扱う記事である。AgenticRAG を検索モデルだけの話に閉じないための補助線になる。