なぜ「検索して答える」だけでは足りないのか
社内マニュアル、規程、議事録、FAQ、設計書——企業には大量の文書があります。一方で「どこにあるか分からない」「似た説明が複数ある」「表や図の周辺文脈が切れる」といった理由で、検索しても実務に落ちないケースが少なくありません。
そこで使われるのが RAG（Retrieval-Augmented Generation）です。質問に関連する文書断片を検索し、その根拠を踏まえて LLM が回答を生成します。回答に出典を付けられるため、単なるチャットボットより検証しやすいのが利点です。
従来RAGと Agentic RAG の違い
従来のRAGは、おおむね次の一本道です。
- 質問を埋め込み（またはキーワード）に変換する
- ベクトルDB等から top-k を取得する
- 取得した文脈をもとに回答を生成する
これに対し Agentic RAG は、LLM をオーケストレータとして、検索そのものをループの中で制御します。典型的には次のような振る舞いを持ちます（Unstructured などによる解説、および Agentic RAG のサーベイ論文で整理されているパターン）。
- 計画（Planning）：質問を分解し、何を調べるべきかを決める
- ルーティング：社内KB、規程、FAQ、API など参照先を選ぶ
- クエリ書き換え：ヒットが弱い場合に言い換えて再検索する
- 根拠の検証：取得文脈が回答に足りるか判定し、不足なら再試行する
- ツール利用：必要に応じて検索以外のAPIや文書オープン操作を行う
つまり「検索するAI」から、「必要な情報を集め切ってから答える／次の行動につなげるAI」へ拡張する考え方です。
実務で効く場面・効きにくい場面
ACL Industry 系の比較研究では、Agentic RAG は意図理解やクエリ書き換えで検索品質を上げやすい一方、コスト（トークン・レイテンシ）が増え、最大で数倍程度のコスト差が出うると報告されています。万能ではありません。
- 向く：複数文書にまたがる調査、曖昧な業務質問、参照先が複数ある問い合わせ
- 向かない／過剰：定型FAQ、単一規程の事実確認、低レイテンシ必須の一次応答
デモクロでは、まず通常RAGで検索精度と評価セットを安定させ、複雑質問だけ Agentic に拡張する二段構えを推奨しています。
導入で最初に決める3点
- 対象データ：どの文書を入れるか、更新頻度、権限（部門・機密区分）
- 成功指標：Recall@k、根拠付き正答率、未回答率、平均応答時間
- 運用：誤回答時のエスカレーション、ナレッジ追加フロー、ログ監査
デモクロでの進め方
データ処理（OCR・構造化・メタデータ）→ ハイブリッド検索の通常RAG → 評価 → 必要箇所のみ Agentic 化、という順で、PoCで終わらせずに業務システムへ接続します。Dify での試作と、本番向け独自実装の両方から最適な構成を選べます。