Agentic RAG（エージェンティックラグ）
LLMエージェントが自律的に検索・推論・検証を繰り返しながら回答を生成するRAGの発展形態。従来の単発検索型RAGと異なり、複数ステップの動的な情報収集と自己修正を行う。
Agentic RAGとは
Agentic RAG（エージェンティックRAG）は、従来のRetrieval-Augmented Generation（RAG）を大幅に拡張し、LLMエージェントが自律的に検索戦略を立案・実行・評価するアーキテクチャである。単純な「検索→生成」の1ステップではなく、エージェントが問い合わせの意図を分析し、必要な情報を複数のソースから段階的に収集し、取得した情報の品質を自己評価しながら最終回答を構成する。
従来のRAGでは、ユーザークエリをそのままベクトル検索に渡し、上位k件のチャンクをコンテキストとして生成モデルに入力するという固定パイプラインが一般的だった。しかしこのアプローチでは、複雑な質問や多段階の推論が必要な質問に対して十分な情報を取得できないことが多い。Agentic RAGはこの限界を、エージェントの自律的な判断能力によって克服する。
従来RAGとの本質的な違い
| 比較項目 | 従来型RAG | Agentic RAG |
|---|---|---|
| 検索回数 | 1回固定 | 動的に複数回 |
| クエリ生成 | ユーザー入力をそのまま使用 | エージェントが最適化・分解 |
| 情報源 | 単一ベクトルDB | 複数ソース（DB・API・Web） |
| 検証プロセス | なし | 自己検証・矛盾チェック |
| 回答戦略 | 固定テンプレート | 動的に構成 |
| エラー回復 | 不可 | 再検索・代替戦略 |
| コスト | 低（1回のLLM呼び出し） | 高（複数回のLLM呼び出し） |
| レイテンシ | 低（1-3秒） | 中〜高（5-30秒） |
従来型RAGが「受動的な検索」であるのに対し、Agentic RAGは「能動的な調査」に近い。人間の研究者が文献を調べる際に、最初の検索結果から新たな検索キーワードを見出し、矛盾する情報を再確認し、複数の情報源を突き合わせて結論を出すプロセスと本質的に同じである。
Agentic RAGの主要コンポーネント
Agentic RAGシステムは以下の主要コンポーネントで構成される。
プランナー（Planner）
ユーザーのクエリを分析し、回答に必要な情報収集の計画を立案する。複合的な質問は複数のサブクエリに分解され、それぞれの依存関係と実行順序が決定される。
リトリーバー（Retriever）
計画に基づいて実際の情報検索を実行する。ベクトル検索、キーワード検索、SQL クエリ、API呼び出しなど、複数の検索手段を状況に応じて使い分ける。
エバリュエーター（Evaluator）
取得した情報の関連性、信頼性、網羅性を評価する。不十分と判断された場合、プランナーにフィードバックして追加検索を要求する。
シンセサイザー（Synthesizer）
収集・検証された情報を統合し、最終的な回答を生成する。情報間の矛盾がある場合はその旨を明示し、確信度に基づいた回答を構成する。
代表的なフレームワークと実装
| フレームワーク | 開発元 | 特徴 |
|---|---|---|
| LangGraph | LangChain | グラフベースのワークフロー定義、状態管理が強力 |
| AutoGen | Microsoft | マルチエージェント会話型、役割分担が明確 |
| CrewAI | CrewAI | タスク指向のエージェント協調、直感的なAPI |
| LlamaIndex Workflows | LlamaIndex | イベント駆動型、データコネクタが豊富 |
| Semantic Kernel | Microsoft | エンタープライズ向け、.NET/Python/Java対応 |
| DSPy | Stanford NLP | プログラマティックな最適化、自動プロンプトチューニング |
これらのフレームワークはいずれも、エージェントのループ処理（計画→実行→評価→再計画）を構造的に記述するための仕組みを提供している。
ユースケースと適用領域
Agentic RAGが特に効果を発揮する領域は以下の通りである。
- 法律文書調査: 判例・条文・学説を横断的に検索し、矛盾する見解を整理して法的分析を提供
- 医療情報検索: 症状・薬剤・治療法のエビデンスを複数のデータベースから収集し、信頼度付きで提示
- 技術調査レポート: 論文・特許・製品仕様を統合した包括的な技術動向分析
- カスタマーサポート: 製品マニュアル・FAQ・過去の問い合わせ履歴を横断検索し、最適な回答を構成
- 金融分析: 決算書・市場データ・ニュースを統合した投資判断支援
パフォーマンスとコストのトレードオフ
Agentic RAGは回答品質を大幅に向上させるが、複数回のLLM呼び出しによるコスト増とレイテンシ増加が課題となる。実運用では以下の最適化が重要である。
- 適応的複雑度制御: 単純な質問には従来型RAGで即座に回答し、複雑な質問のみAgentic RAGを起動する
- キャッシュ戦略: 中間結果のキャッシュにより、類似クエリの再処理コストを削減
- 並列実行: 独立したサブクエリを並列に検索することでレイテンシを短縮
- 早期停止: 十分な情報が得られた時点でループを打ち切る
よくある質問（FAQ）
Q1: Agentic RAGと通常のRAGはどちらを使うべきですか？
A1: 質問の複雑さによって使い分けるのが最適です。単純な事実確認や定義の検索には従来型RAGで十分です。複数の情報源を横断する必要がある質問、比較分析、多段階の推論が必要な質問にはAgentic RAGが有効です。多くの本番システムでは、クエリの複雑度を判定するルーターを設置し、動的に切り替えています。
Q2: Agentic RAGのコストはどの程度増加しますか？
A2: 一般的に従来型RAGの3〜10倍のLLMトークン消費が見込まれます。ただし、回答品質の向上により再質問が減少するため、ユーザー体験全体でのコスト効率は改善する場合があります。適応的複雑度制御により、実際にAgentic RAGが起動するのは全クエリの20〜30%程度に抑えることが可能です。
Q3: Agentic RAGでハルシネーションは減りますか？
A3: 自己検証ステップがあるため、従来型RAGと比較してハルシネーション率は大幅に低下します。ただし完全には排除できません。エバリュエーターが矛盾を検出した場合に「確信度が低い」と明示する設計が重要です。実験的には、Self-RAGやCRAGなどの検証メカニズムを組み込むことで、ハルシネーション率を40〜60%削減できるとの報告があります。