RAGからAgentic RAGへ
RAG、Retrieval-Augmented Generationは、AIが回答を生成する前に関連する文書や記録を検索する設計です。モデルの記憶だけで答えるのではなく、会社の資料に基づいて回答したい場合に使われます。
Agentic RAGでは、ここにエージェント的な動きが加わります。1回検索して答えるだけでなく、何を探すべきかを決め、質問を分解し、ツールを呼び出し、情報源を比較し、根拠が不足していれば止まる設計です。
社内ナレッジ検索では、この違いが重要です。実際の業務質問は、方針確認、最新契約の確認、過去提案の比較、根拠文書の提示など、複数の手順を含むことが多いためです。
実際の社内質問から設計する
Agentic RAGは、文書リポジトリ全体から始めるより、繰り返し発生する質問から始める方が現実的です。営業提案書検索、サポート方針確認、オンボーディング、社内承認ルール、技術運用マニュアルなどが候補になります。
質問タイプごとに、使ってよい情報源、回答形式、情報源の責任者、答えてはいけない条件を定義します。
これにより、便利そうに見えるだけで意思決定には使いにくい、広すぎるチャット画面になることを避けられます。
権限と引用の設計
社内検索では、業務権限を守る必要があります。元システムで閲覧できない記録を、AIの要約を通じて見えてしまう設計にしてはいけません。
引用も装飾ではなく、プロダクトの一部です。回答がどの文書、どのセクション、どの記録、どの時点の情報に基づくのかを見せる必要があります。顧客対応、価格、契約、セキュリティ、コンプライアンスに関わる場合は特に重要です。
Agentic RAGでは、取得した情報源、ツール呼び出し、回答の版、人による確認点をログとして残します。これにより、検索品質の改善や、問題が起きた回答の検証が可能になります。
実装の順番
最初は、高頻度の1業務と、承認済みの小さな情報源から始めます。まず検索品質を作り込み、単純な検索では足りない場所にだけ、エージェント的な計画やツール利用を足します。
次に、現場の実際の質問で評価します。回答が根拠に基づいているか、引用が役立つか、答えない判断ができるか、利用者が再び使うかを確認します。
Agentic RAGは、管理されたナレッジワークフローとして扱うと価値が出ます。情報源の所有者、権限設計、評価データ、文書更新の運用が必要です。
参考文献・参照元
RAGの考え方は、検索拡張生成に関する研究をもとに、社内ナレッジ検索の実務設計へ読み替えています。