論文解説: Agentic Retrieval-Augmented Generation — エージェント型RAGアーキテクチャの体系的分類

本記事は arXiv:2501.09136 “Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG” の解説記事です。

論文概要（Abstract）

大規模言語モデル（LLM）は静的な訓練データに依存するため、動的なリアルタイムクエリへの対応に限界がある。従来のRetrieval-Augmented Generation（RAG）はライブデータ取得を組み込むことでこの課題を改善するが、固定的なワークフローという制約が残る。本論文では、RAGパイプラインに自律的なAIエージェントを埋め込むことで適応的な検索戦略と反復的なコンテキスト精製を実現するAgentic RAGを体系的に整理している。

この記事は Zenn記事: LangGraph×Claude Sonnet 4.6でSQL統合Agentic RAGを実装するの深掘りです。

情報源

arXiv ID: 2501.09136
URL: https://arxiv.org/abs/2501.09136
著者: Aditi Singh, Abul Ehtesham, Saket Kumar, Tala Talaei Khoei
発表年: 2025（v3: 2025年2月4日）
分野: cs.AI, cs.CL, cs.IR

背景と動機（Background & Motivation）

従来のRAGは「Retrieve → Augment → Generate」の固定パイプラインで動作する。この方式は単純なファクトイド質問には有効だが、複数のデータソースを横断する複合クエリや、中間結果に基づいて検索戦略を動的に切り替える必要があるタスクには対応が難しい。

例えば、Zenn記事で扱ったようなSQL検索とベクトル検索の統合シナリオでは、クエリの意図に応じて検索先を動的にルーティングする必要がある。著者らは、この動的なルーティングと反復的な精製を実現するために、RAGパイプラインにエージェントを導入する「Agentic RAG」パラダイムが不可欠であると主張している。

主要な貢献（Key Contributions）

貢献1: Agentic RAGの定義と、従来RAG（Naive/Advanced）からの進化を体系化
貢献2: Single-Agent、Multi-Agent、Hierarchical RAGの3アーキテクチャ分類を提案
貢献3: 医療・金融・教育など6分野以上の応用事例と、それぞれの課題・解決策を整理
貢献4: デプロイメント戦略（スケーラビリティ、倫理的配慮、性能最適化）の実践的ガイドライン

技術的詳細（Technical Details）

RAGの進化: Naive → Advanced → Agentic

著者らは、RAGの発展を3世代に分類している。

世代	特徴	制約
Naive RAG	チャンキング→埋め込み→検索→生成	固定パイプライン、単一検索パス
Advanced RAG	クエリ書き換え、再ランキング、圧縮	検索戦略は事前定義、動的切替不可
Agentic RAG	エージェントが検索・推論・精製を自律制御	計算コスト増、制御の複雑さ

Agentic RAGでは、エージェントが以下の4つのパターンを組み合わせて動作すると論文で述べられている:

Reflection（反省）: 検索結果の品質を自己評価し、不十分なら再検索
Planning（計画）: 複合クエリをサブタスクに分解し、実行順序を決定
Tool Use（ツール利用）: SQL検索、ベクトル検索、API呼び出し等を動的に選択
Multi-Agent Collaboration（マルチエージェント協調）: 専門エージェント間で情報を共有

3つのアーキテクチャ分類

Single-Agent RAG

1つのエージェントがすべての検索・推論・生成を担当する。

\[a_t = \pi(s_t; \theta)\]

ここで、

$a_t$: 時刻$t$のエージェントアクション（検索、生成、ツール呼び出し等）
$s_t$: 現在の状態（クエリ、中間結果、対話履歴）
$\pi$: ポリシー関数（LLMが担当）
$\theta$: LLMのパラメータ

実装パターン: ReActフレームワーク（Thought→Action→Observation→…のループ）が代表的である。LangChainのcreate_react_agentやLlamaIndexのReActAgentWorkerが直接対応する。

適用場面: 単一データソースへのクエリ、FAQ応答、シンプルなドキュメント検索。

Multi-Agent RAG

複数の専門エージェントが協調して動作する。論文では、検索エージェント・SQL生成エージェント・回答生成エージェントを分離する構成が挙げられている。

\[A = \{a_1^{(1)}, a_2^{(2)}, \ldots, a_T^{(k)}\}\]

ここで、

$a_t^{(k)}$: エージェント$k$が時刻$t$に実行するアクション
$A$: 全エージェントのアクション系列

実装パターン: Zenn記事のLangGraph StateGraphによるSQL+ベクトル検索統合は、このMulti-Agent RAGの具体的な実装例に相当する。ルーターノードがクエリを分類し、SQL検索ノードとベクトル検索ノードがそれぞれ専門的な検索を担当する構成である。

適用場面: 構造化データと非構造化データの横断検索、複合クエリの処理。

Hierarchical RAG

タスクを階層的に分解し、上位エージェントが下位エージェントにサブタスクを委譲する。

\[\text{Orchestrator} \rightarrow \{(\text{SubTask}_i, \text{Agent}_i)\}_{i=1}^{n}\]

実装パターン: LangGraphのSend() APIによる並列ノード実行や、CrewAIの階層的プロセスが対応する。

適用場面: 大規模な知識ベース検索、複数ステップの推論が必要なタスク。

クエリルーティングの形式化

論文では、クエリルーティングを以下のように形式化している:

\[r^* = \arg\max_{r \in \mathcal{R}} P(r \mid q, \mathcal{S}; \theta)\]

ここで、

$r^*$: 最適なルーティング先
$\mathcal{R}$: ルーティング先の集合（例: ${\text{sql}, \text{vector}, \text{both}}$）
$q$: ユーザークエリ
$\mathcal{S}$: 利用可能なデータソースのメタデータ
$P(r \mid q, \mathcal{S}; \theta)$: LLMによるルーティング確率

Zenn記事のClaude Sonnet 4.6 with_structured_outputによるルーティングは、この$P(r \mid q, \mathcal{S}; \theta)$をPydanticモデルで型安全に実装したものと位置づけられる。

アルゴリズム

著者らが論文で提示しているAgentic RAGの基本的な動作フローを擬似コードで表現すると以下のようになる:

  
from typing import Protocol, TypedDict

class AgenticRAGState(TypedDict):
    """Agentic RAGの状態"""
    query: str
    retrieved_docs: list[str]
    route: str
    answer: str
    iteration: int

class RetrievalTool(Protocol):
    """検索ツールのインターフェース"""
    async def search(self, query: str) -> list[str]: ...

async def agentic_rag_loop(
    state: AgenticRAGState,
    tools: dict[str, RetrievalTool],
    max_iterations: int = 3,
) -> str:
    """Agentic RAGのメインループ

    Args:
        state: 現在の状態
        tools: 利用可能な検索ツール（sql, vector等）
        max_iterations: 最大反復回数

    Returns:
        最終回答
    """
    for i in range(max_iterations):
        # Step 1: Route - クエリの意図に基づくルーティング
        route = await classify_query(state["query"])

        # Step 2: Retrieve - 選択されたツールで検索
        tool = tools[route]
        docs = await tool.search(state["query"])

        # Step 3: Evaluate - 検索結果の品質評価
        quality = await evaluate_relevance(state["query"], docs)

        if quality >= THRESHOLD:
            # Step 4: Generate - 十分な品質なら回答生成
            return await generate_answer(state["query"], docs)
        else:
            # Step 5: Refine - 不十分なら検索戦略を修正
            state["query"] = await refine_query(state["query"], docs)

    return await generate_answer(state["query"], state["retrieved_docs"])

実装のポイント（Implementation）

ルーティング精度の向上

論文では、ルーティングの精度がシステム全体の性能を左右すると強調されている。著者らが推奨するアプローチは以下の通りである:

Few-shot例の追加: ルータープロンプトにドメイン固有の分類例を5-10件追加することで、分類精度が向上する
構造化出力の活用: Pydanticモデルやfunction callingで出力形式を強制し、パース失敗を防止する
フォールバック戦略: ルーティング判定の確信度が低い場合は、複数の検索パスを並列実行する

エージェント間の状態共有

Multi-Agent構成では、エージェント間で状態を正しく共有する設計が必要である。LangGraphのStateGraphは、型付きの状態辞書を通じてノード間のデータ受け渡しを保証する。これは論文で述べられている「Shared Memory」パターンに対応する。

反復的精製の停止条件

無限ループを防ぐために、以下の停止条件を組み合わせることが論文で推奨されている:

最大反復回数: 3-5回で打ち切り
品質閾値: 検索結果の関連性スコアが閾値を超えたら停止
コスト上限: LLM APIコールの累積コストが上限に達したら停止

実験結果（Results）

本論文はサーベイであるため、独自の実験結果は含まれていない。ただし、著者らは既存研究の性能を以下のように整理している（論文Section 4より）:

アーキテクチャ	代表手法	主な評価ベンチマーク	報告されている改善
Single-Agent RAG	ReAct + ツール呼び出し	HotpotQA, MMLU	Naive RAG比で精度5-15%向上
Multi-Agent RAG	専門エージェント協調	Spider, BIRD, MultiHop	複合クエリで精度20-30%向上
Hierarchical RAG	オーケストレーター+ワーカー	大規模KB検索	スループット2-5倍向上

著者らは、Multi-Agent RAGが構造化+非構造化データの横断検索において特に高い改善を示すと述べているが、これらの数値は個別の論文からの引用であり、統一的な条件での比較ではない点に注意が必要である。

実運用への応用（Practical Applications）

Zenn記事のSQL統合Agentic RAGは、本論文の分類ではMulti-Agent RAGに位置づけられる。具体的な対応関係は以下の通り:

論文の概念	Zenn記事の実装
Route（ルーティング）	`router_node` + Claude `with_structured_output`
Retrieve（検索）	`sql_search_node` / `vector_search_node`
Generate（生成）	`generate_answer_node`
Tool Use（ツール利用）	`SQLDatabaseToolkit` / ChromaDB
State Management（状態管理）	LangGraph `AgentState` TypedDict

プロダクション視点での考慮事項:

スケーリング: Hierarchical RAGへの移行で大規模データベース対応が可能になるが、エージェント間通信のオーバーヘッドが発生する
レイテンシ: Single-Agent RAGは低レイテンシだが柔軟性に欠け、Multi-Agent RAGは柔軟だがレイテンシが増加する。ユースケースに応じた選択が必要である
コスト: エージェント数が増えるほどLLM APIコールが増加するため、ルーティングの精度を高めて不要なAPIコールを削減する設計が重要になる
制約: 著者らは、Agentic RAGの主要な課題として「ハルシネーション制御」「マルチホップ推論の信頼性」「大規模デプロイ時の計算コスト」を挙げている

まとめと今後の展望

本論文は、Agentic RAGを3つのアーキテクチャ（Single/Multi/Hierarchical）に体系的に分類し、各パターンの適用場面と実装上の考慮事項を整理した包括的なサーベイである。SQL統合Agentic RAGのようなMulti-Agent構成は、構造化データと非構造化データを横断する検索ニーズに対して有効なアプローチであると論文は示唆している。

著者らは今後の研究方向として、(1) エージェント間の協調プロトコルの標準化、(2) ハルシネーション検出と修正の自動化、(3) 大規模デプロイ時のコスト最適化の3点を挙げている。

参考文献

arXiv: https://arxiv.org/abs/2501.09136
Related Zenn article: https://zenn.dev/0h_n0/articles/58dc3076d2ffba
Self-RAG: https://arxiv.org/abs/2310.11511
Adaptive RAG: https://arxiv.org/abs/2403.14403

:::message 本記事はAI（Claude Code）により自動生成された、arXiv論文の解説記事です。論文の内容を正確に伝えることを目指していますが、解釈に誤りがある可能性があります。必ず原論文をご確認ください。 :::

📄 論文解説: Agentic Retrieval-Augmented Generation — エージェント型RAGアーキテクチャの体系的分類

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

RAGの進化: Naive → Advanced → Agentic

3つのアーキテクチャ分類

Single-Agent RAG

Multi-Agent RAG

Hierarchical RAG

クエリルーティングの形式化

アルゴリズム

実装のポイント（Implementation）

ルーティング精度の向上

エージェント間の状態共有

反復的精製の停止条件

実験結果（Results）

実運用への応用（Practical Applications）

関連研究（Related Work）

まとめと今後の展望

参考文献

📄 論文解説: Agentic Retrieval-Augmented Generation — エージェント型RAGアーキテクチャの体系的分類

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

RAGの進化: Naive → Advanced → Agentic

3つのアーキテクチャ分類

Single-Agent RAG

Multi-Agent RAG

Hierarchical RAG

クエリルーティングの形式化

アルゴリズム

実装のポイント（Implementation）

ルーティング精度の向上

エージェント間の状態共有

反復的精製の停止条件

実験結果（Results）

実運用への応用（Practical Applications）

関連研究（Related Work）

まとめと今後の展望

参考文献

関連記事

📄 論文解説: Agentic RAG — 自律エージェントによる検索拡張生成の包括的サーベイ

📄 論文解説: Corrective Retrieval Augmented Generation (CRAG)

✍️ サーベイ解説: Agentic RAG — エージェント型検索拡張生成の体系的分類と設計パターン