Agentic RAGシステムの設計パターンと構成要素を体系化したもの。ルーター型・マルチエージェント型・グラフ型など、ユースケースに応じた複数のアーキテクチャパターンが存在する。
Agentic RAGアーキテクチャは、自律的なRAGシステムを構築するための設計パターンと構成原則を指す。単純なパイプライン型のRAGとは異なり、エージェントの判断・ループ・状態管理を中心に据えたアーキテクチャ設計が求められる。
1つのLLMエージェントが計画・検索・評価・生成のすべてを担当する最もシンプルな形態。ReActパターンやTool-Useパターンを用いて、エージェントが必要に応じてツール（検索API、SQL実行など）を呼び出す。
メリット: 実装がシンプル、状態管理が容易、デバッグしやすい デメリット: 複雑なタスクでコンテキストウィンドウが逼迫、単一障害点
役割ごとに特化した複数のエージェントが協調してタスクを遂行する。例えば、プランナーエージェント・リサーチャーエージェント・検証エージェント・ライターエージェントがそれぞれの専門性を発揮する。
メリット: 各エージェントのプロンプトを最適化可能、並列処理が容易、障害隔離 デメリット: エージェント間通信のオーバーヘッド、全体の整合性管理が複雑
ワークフローを有向グラフとして定義し、ノード（処理ステップ）とエッジ（遷移条件）で構成する。LangGraphやLlamaIndex Workflowsがこのパターンを採用している。
メリット: 明示的な制御フロー、条件分岐が自然、可視化が容易 デメリット: 事前にフローを定義する必要があり柔軟性にやや欠ける
| パターン | 複雑度 | スケーラビリティ | デバッグ容易性 | 推奨ユースケース |
|---|---|---|---|---|
| シングルエージェント | 低 | 低〜中 | 高 | プロトタイプ、単純な検索タスク |
| マルチエージェント | 高 | 高 | 低 | 大規模システム、専門領域混在 |
| グラフ型 | 中 | 中〜高 | 中 | 定型的だが複雑なワークフロー |
| ハイブリッド型 | 高 | 高 | 中 | 本番環境、エンタープライズ |
Agentic RAGでは、エージェントのループ処理に伴い状態管理が重要になる。以下の状態を適切に管理する必要がある。
ユーザーとのやり取りの履歴。マルチターン対話でのコンテキスト維持に使用する。
これまでに実行した検索クエリ、取得したドキュメント、各ドキュメントの評価結果。重複検索の回避と検索戦略の最適化に使用する。
エージェントの推論チェーン。サブクエリの分解結果、中間的な結論、残りのタスクリスト。
長時間のタスクで中断・再開を可能にするためのスナップショット。LangGraphでは組み込みのチェックポイント機能が提供されている。
エージェントの記憶をどのように構造化するかは、回答品質に直結する重要な設計判断である。
Agentic RAGの本番運用では、エージェントの行動を詳細に追跡する可観測性基盤が不可欠である。
A1: ワークフローが比較的定型的で分岐条件を事前に定義できる場合はグラフ型が適しています。タスクの性質が動的で、エージェント間の即興的な協調が必要な場合はマルチエージェント型が有効です。多くの本番システムでは両者を組み合わせたハイブリッド型を採用しています。
A2: 短期的な状態にはインメモリ（Redis等）、長期記憶にはベクトルDB（Qdrant、Pinecone等）、チェックポイントにはPostgreSQLやSQLiteが一般的です。LangGraphではSQLiteベースのチェックポイントが標準搭載されています。
A3: 最大ステップ数の設定（通常10〜20ステップ）、累積コストの上限設定、同一クエリの再実行検出、タイムアウトの4つのガードレールを組み合わせるのが標準的です。加えて、エバリュエーターが「これ以上の情報収集は不要」と判断する停止条件を明示的に定義することが重要です。