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

論文概要（Abstract）

本論文は、従来のRAG（Retrieval-Augmented Generation）パイプラインにLLMエージェントの自律的推論能力を統合した「Agentic RAG」を体系的にサーベイした包括的論文である。Single-Agent、Multi-Agent、Hierarchical Agentの3つのアーキテクチャパターンを分類し、ReAct・CRAG・Self-RAGなど17種以上のエージェント型RAG手法を整理している。2025年1月に公開された本サーベイは、100本超の先行研究をレビューし、Agentic RAGの設計選択肢と実装上の課題を明確にしている。

この記事は Zenn記事: LlamaIndex v0.14実践ガイド：AgentWorkflowで本番RAGを構築するの深掘りです。

情報源

arXiv ID: 2501.15228
URL: https://arxiv.org/abs/2501.15228
著者: Aditi Singh, Abul Ehtesham, Saket Kumar, Tala Talaei Khoei
発表年: 2025
分野: cs.AI, cs.IR

背景と動機（Background & Motivation）

RAGは大規模言語モデル（LLM）の幻覚問題を緩和する手法として急速に普及したが、従来のNaive RAGには根本的な制約がある。ユーザーのクエリに対して一度だけ検索し、そのまま生成するという単線的パイプラインでは、複数文書を横断するマルチホップ推論、クエリの曖昧性への対応、検索結果の品質評価と再検索の判断ができない。

Zenn記事で紹介されているLlamaIndexのAgentic Retrievalは、まさにこの問題を解決するためのフレームワーク設計であり、本サーベイ論文はその理論的基盤を提供する。エージェントが「いつ検索するか」「何を検索するか」「検索結果が十分か」を自律的に判断できるようにすることで、RAGの性能を質的に向上させる。

主要な貢献（Key Contributions）

貢献1: Agentic RAGの包括的タクソノミーを初めて提示。Router Agent、Retriever Agent、Grader Agent、Planner Agent、Orchestrator Agentの5つの役割分類と、Single/Multi/Hierarchicalの3つのシステム構成を体系化
貢献2: ReAct、CRAG、Self-RAG、Adaptive RAGなど17種以上のAgentic RAG手法を統一的なフレームワークで比較分析
貢献3: 各アーキテクチャパターンのベンチマーク結果を集約し、Multi-AgentがHotpotQAで+18% F1向上など、定量的なエビデンスを整理
貢献4: メモリシステム、ツール統合、推論フレームワークの設計空間を明確化し、実装者向けのガイドラインを提示

技術的詳細（Technical Details）

Agentic RAGのアーキテクチャ分類

本論文の核心は、Agentic RAGを以下の階層で分類するタクソノミーである。

エージェントの役割別分類:

役割	機能	LlamaIndex対応
Router Agent	クエリ解析→適切な知識ベース/ツールへルーティング	`AgentWorkflow.from_tools_or_functions`
Retriever Agent	動的な検索戦略選択・実行	Agentic Retrieval (Stage 1-3)
Grader Agent	検索結果の品質評価・フィルタリング	Rerankerとの組み合わせ
Planner Agent	複雑タスクのサブタスク分解	`FunctionAgent` + `can_handoff_to`
Orchestrator Agent	複数エージェントの協調制御	`AgentWorkflow` (root_agent)

システム構成別分類:

Single-Agent RAG: 1つのエージェントが全役割を兼任。シンプルだがスケーラビリティに制約
Multi-Agent RAG: 専門エージェントが分業。Zenn記事のResearchAgent + AnalysisAgentパターンに対応
Hierarchical Multi-Agent: Supervisor + Worker構造。大規模企業ユースケース向け

ReActループ — Agentic RAGの中核メカニズム

Agentic RAGの多くの実装はReAct（Reasoning + Acting）パターンに基づく。エージェントが思考→行動→観察のループを繰り返し、十分な情報が集まった時点で最終回答を生成する。

Thought: ユーザーのクエリを分析。検索が必要と判断
Action: search_documents("LlamaIndex AgentWorkflow")
Observation: 3件のドキュメントを取得
Thought: 取得結果の品質を評価。追加情報が必要
Action: search_documents("multi-agent RAG orchestration")
Observation: 5件のドキュメントを取得
Thought: 十分な情報が集まった。回答を生成
Final Answer: ...

このループ構造は、LlamaIndexのAgentWorkflowが内部的に実装しているものと同一のパターンである。

Corrective RAG（CRAG）— 検索品質の自己評価

CRAGはGrader Agentの代表的実装である。検索結果を3段階で評価する。

評価フロー:

検索ドキュメントをGrader Agentが評価
- Relevant: そのまま使用
- Ambiguous: 知識精製（Knowledge Refinement）を適用
- Irrelevant: クエリを書き直してWeb再検索
知識精製ステップでは、取得チャンクを細分化し、関連性の高い部分のみを抽出
精製済み情報でLLMが最終回答生成

  
def corrective_rag_evaluate(query: str, documents: list[Document]) -> str:
    """CRAGの評価フロー"""
    graded_docs = []
    for doc in documents:
        # Grader Agentによる関連性評価
        relevance = grade_document(query, doc)  # "relevant" | "ambiguous" | "irrelevant"

        if relevance == "relevant":
            graded_docs.append(doc)
        elif relevance == "ambiguous":
            refined = knowledge_refinement(query, doc)
            graded_docs.append(refined)
        else:
            # Irrelevant: Web検索でフォールバック
            web_results = web_search(rewrite_query(query))
            graded_docs.extend(web_results)

    return generate_answer(query, graded_docs)

Self-RAG — 自己反省型トークン生成

Self-RAGはLLM自体が特殊トークンを出力して検索の要否と品質を自己評価する。

\[p(y, \mathbf{r} | x) = \prod_{t=1}^{T} p(y_t | x, y_{<t}, \mathbf{r}_t) \cdot p(\mathbf{r}_t | x, y_{<t})\]

ここで、

$x$: 入力クエリ
$y$: 出力系列
$\mathbf{r}_t$: 反省トークン（[Retrieve], [IsREL], [IsSUP], [IsUSE]）
$T$: 系列長

反省トークンの種類:

トークン	機能	判定値
[Retrieve]	検索が必要か	yes / no / continue
[IsREL]	検索結果がクエリに関連するか	relevant / irrelevant
[IsSUP]	生成内容が検索結果に裏付けられるか	fully / partially / no
[IsUSE]	最終回答が有用か	5段階 (1-5)

Adaptive RAG — クエリ複雑度に応じた戦略切替

Adaptive RAGはクエリの難易度を動的に評価し、最適な検索戦略を選択する。

\[\text{strategy}(q) = \begin{cases} \text{Direct Generation} & \text{if } c(q) < \tau_1 \\ \text{Single-hop RAG} & \text{if } \tau_1 \leq c(q) < \tau_2 \\ \text{Iterative RAG} & \text{if } c(q) \geq \tau_2 \end{cases}\]

ここで、$c(q)$はクエリ$q$の複雑度スコア、$\tau_1, \tau_2$は閾値パラメータ。

この設計はLlamaIndexのAgentic Retrievalにおける3段階（Auto-Routed Single Index → Multi-Index Routing → PropertyGraphIndex）と思想的に一致する。

メモリシステム

Agentic RAGにおけるメモリは4層構造で設計される。

メモリ層	対応概念	実装例
Sensory Memory	コンテキストウィンドウ内の短期バッファ	LLMの入力トークン
Short-term Memory	会話履歴	`Context`オブジェクト
Long-term Memory	外部ベクトルDB・グラフDB	VectorStoreIndex, PropertyGraphIndex
Episodic Memory	過去タスクのトレース記録	エージェントの行動ログ

LlamaIndexのContextオブジェクト（ctx.store）はShort-term Memoryに対応し、VectorStoreIndexやPropertyGraphIndexはLong-term Memoryに対応する。

実装のポイント（Implementation）

フレームワーク選択マトリクス

ユースケース	推奨フレームワーク	理由
データ取り込み+検索特化	LlamaIndex	Retriever単位の差し替えが容易
汎用エージェントワークフロー	LangGraph	グラフベースの状態管理
Multi-Agent対話	AutoGen	エージェント間通信プロトコル
役割ベースMulti-Agent	CrewAI	宣言的なロール定義

実装時の推奨パラメータ

チャンクサイズ: 256-512トークン（精度とコンテキストのバランス）
検索戦略: BM25 + Embedding Hybrid → Cross-Encoder Rerankerの2段階
最大反復回数: 3-5回（無限ループ防止の安全弁）
クエリ複雑度分類: 簡単→直接生成、普通→Single-hop RAG、難→Agentic Loop

LlamaIndexでのAgentic RAG実装例

  
from llama_index.core.agent.workflow import AgentWorkflow, FunctionAgent
from llama_index.core.tools import QueryEngineTool
from llama_index.core import VectorStoreIndex

# Retriever Agent: 複数インデックスからの検索
tools = [
    QueryEngineTool.from_defaults(
        query_engine=tech_index.as_query_engine(),
        name="tech_search",
        description="技術文書を検索する",
    ),
    QueryEngineTool.from_defaults(
        query_engine=finance_index.as_query_engine(),
        name="finance_search",
        description="財務文書を検索する",
    ),
]

# Grader Agent: 検索結果の品質評価
grader_agent = FunctionAgent(
    name="GraderAgent",
    description="検索結果の関連性を評価し、不十分なら再検索を指示",
    tools=[evaluate_relevance, request_requery],
    system_prompt="検索結果を3段階(relevant/ambiguous/irrelevant)で評価してください。",
    can_handoff_to=["RetrieverAgent"],
)

# Retriever Agent: 動的検索
retriever_agent = FunctionAgent(
    name="RetrieverAgent",
    description="クエリに最適な検索ツールを選択して実行する",
    tools=tools,
    system_prompt="質問に最も関連するデータソースを選んで検索してください。",
    can_handoff_to=["GraderAgent", "SynthesizerAgent"],
)

# Synthesizer Agent: 回答生成
synthesizer_agent = FunctionAgent(
    name="SynthesizerAgent",
    description="評価済みの検索結果から最終回答を生成する",
    tools=[generate_answer],
    can_handoff_to=[],
)

# Agentic RAG Workflow
workflow = AgentWorkflow(
    agents=[retriever_agent, grader_agent, synthesizer_agent],
    root_agent="RetrieverAgent",
)

実験結果（Results）

本論文はサーベイのため独自実験は含まないが、引用論文の結果を体系的に集約している。

手法	ベンチマーク	標準RAG比改善	特筆事項
Self-RAG	PopQA	+4.3% accuracy	反省トークンによる自己評価
Self-RAG	FactScore	+5.1%	事実性スコアの大幅改善
CRAG	SingleHop QA	+7-12%	検索品質の自己評価が効果的
CRAG	MultiHop QA	+15-22%	複数ホップ推論で特に効果大
Adaptive RAG	全体レイテンシ	-30-40%	不要な反復を省略
Multi-Agent	HotpotQA	+18% F1	マルチホップ推論で顕著
Multi-Agent	2WikiMultiHopQA	+23% F1	分業による精度向上

分析ポイント:

Multi-Agent RAGはマルチホップ推論タスクで最大の改善を示す（+18-23% F1）
CRAGの検索品質評価メカニズムはSingleHopよりMultiHopで効果が大きい
Adaptive RAGはレイテンシ削減に効果的だが、精度改善は限定的

実運用への応用（Practical Applications）

LlamaIndex v0.14との対応関係

Zenn記事で紹介されているLlamaIndex v0.14の機能は、本サーベイのAgentic RAGタクソノミーに直接マッピングできる。

Agentic RAG概念	LlamaIndex v0.14実装
Router Agent	`AgentWorkflow.from_tools_or_functions`
Multi-Index Routing	Stage 2: `QueryEngineTool` の複数登録
Knowledge Graph RAG	Stage 3: `PropertyGraphIndex`
Multi-Agent Orchestration	`AgentWorkflow` + `FunctionAgent`
Memory System	`Context` + `VectorStoreIndex`

プロダクション適用の注意点

レイテンシバジェット: Agentic RAGは反復検索のため、Naive RAGの3-10倍のレイテンシが発生する。リアルタイムチャットにはmax_iterations制限が必須
コスト管理: Multi-Agentは単純RAGの3-10倍のAPIコストが発生。Adaptive RAGでクエリ複雑度に応じた戦略切替が有効
エラー伝播: マルチエージェントでは上流エージェントのエラーが下流に波及する。各ステージでの品質ゲートを設計すること

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

トラフィック量別の推奨構成:

規模	月間リクエスト	推奨構成	月額コスト	主要サービス
Small	~3,000 (100/日)	Serverless	$50-150	Lambda + Bedrock + DynamoDB
Medium	~30,000 (1,000/日)	Hybrid	$300-800	Lambda + ECS Fargate + ElastiCache
Large	300,000+ (10,000/日)	Container	$2,000-5,000	EKS + Karpenter + EC2 Spot

Small構成の詳細 (月額$50-150):

Lambda: 1GB RAM, 60秒タイムアウト ($20/月) — Agentic RAGの反復ループに対応
Bedrock: Claude 3.5 Haiku, Prompt Caching有効 ($80/月)
DynamoDB: On-Demand ($10/月) — エージェントの会話履歴・中間状態保存
CloudWatch: 基本監視 ($5/月)

コスト削減テクニック:

Adaptive RAGパターンでクエリ複雑度に応じてモデルを切替（Haiku/Sonnet）
Prompt Caching有効化で30-90%削減（システムプロンプト固定部分）
Bedrock Batch API使用で50%削減（非リアルタイム処理）

コスト試算の注意事項:

上記は2026年2月時点のAWS ap-northeast-1（東京）リージョン料金に基づく概算値
Agentic RAGの反復回数（平均2-5回）によりBedrock使用量が変動
最新料金は AWS料金計算ツールで確認してください

Terraformインフラコード

Small構成 (Serverless): Lambda + Bedrock + DynamoDB

  
# --- IAMロール（最小権限: Bedrock + DynamoDB） ---
resource "aws_iam_role" "agentic_rag_lambda" {
  name = "agentic-rag-lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy" "bedrock_dynamodb" {
  role = aws_iam_role.agentic_rag_lambda.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"]
        Resource = "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-*"
      },
      {
        Effect = "Allow"
        Action = ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:Query"]
        Resource = aws_dynamodb_table.agent_state.arn
      }
    ]
  })
}

# --- Lambda関数（Agentic RAGハンドラ） ---
resource "aws_lambda_function" "agentic_rag" {
  filename      = "agentic_rag.zip"
  function_name = "agentic-rag-handler"
  role          = aws_iam_role.agentic_rag_lambda.arn
  handler       = "index.handler"
  runtime       = "python3.12"
  timeout       = 120  # Agentic RAGの反復ループに対応
  memory_size   = 1024

  environment {
    variables = {
      BEDROCK_MODEL_ID    = "anthropic.claude-3-5-haiku-20241022-v1:0"
      DYNAMODB_TABLE      = aws_dynamodb_table.agent_state.name
      MAX_ITERATIONS      = "5"  # 安全弁: 無限ループ防止
      ENABLE_PROMPT_CACHE = "true"
    }
  }
}

# --- DynamoDB（エージェント状態管理） ---
resource "aws_dynamodb_table" "agent_state" {
  name         = "agentic-rag-state"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "session_id"
  range_key    = "step_number"

  attribute {
    name = "session_id"
    type = "S"
  }
  attribute {
    name = "step_number"
    type = "N"
  }

  ttl {
    attribute_name = "expire_at"
    enabled        = true
  }
}

# --- CloudWatch アラーム（反復回数監視） ---
resource "aws_cloudwatch_metric_alarm" "iteration_spike" {
  alarm_name          = "agentic-rag-iteration-spike"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name         = "Duration"
  namespace           = "AWS/Lambda"
  period              = 3600
  statistic           = "Average"
  threshold           = 60000  # 平均60秒超過でアラート
  alarm_description   = "Agentic RAGの反復回数が異常（コスト急増の可能性）"

  dimensions = {
    FunctionName = aws_lambda_function.agentic_rag.function_name
  }
}

運用・監視設定

CloudWatch Logs Insights — エージェント反復回数の監視:

  
fields @timestamp, session_id, iteration_count, total_tokens
| stats avg(iteration_count) as avg_iterations,
        max(iteration_count) as max_iterations,
        sum(total_tokens) as total_tokens_used
  by bin(1h)
| filter max_iterations > 5

コスト異常検知アラーム（Python）:

  
import boto3

cloudwatch = boto3.client('cloudwatch')
cloudwatch.put_metric_alarm(
    AlarmName='agentic-rag-token-spike',
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=1,
    MetricName='TokenUsage',
    Namespace='Custom/AgenticRAG',
    Period=3600,
    Statistic='Sum',
    Threshold=500000,
    AlarmDescription='Agentic RAGトークン使用量異常'
)

コスト最適化チェックリスト

Adaptive RAGパターン適用（簡単なクエリはHaiku、複雑なクエリはSonnet）
max_iterations設定（3-5回、無限ループ防止）
Prompt Caching有効化（システムプロンプト部分で30-90%削減）
Bedrock Batch API活用（非リアルタイム処理で50%削減）
DynamoDB TTL設定（不要なセッション状態を自動削除）
CloudWatch Logs Insightsで反復回数の傾向分析
AWS Budgets月額予算設定（80%警告、100%アラート）

まとめと今後の展望

本サーベイ論文は、Agentic RAGの設計空間を体系的に整理した重要な一歩である。LlamaIndex v0.14のAgentWorkflowやAgentic Retrievalは、本論文が分類するMulti-Agent RAGアーキテクチャの実践的実装と位置づけられる。

今後の課題として、(1) エージェント的振る舞いを評価する標準ベンチマークの整備、(2) 反復検索のレイテンシ削減（Long-context LLMによるchunking削減）、(3) Federated RAGによるプライバシー保護が挙げられている。

参考文献

arXiv: https://arxiv.org/abs/2501.15228
Related Zenn article: https://zenn.dev/0h_n0/articles/62e946539206db
LlamaIndex AgentWorkflow: https://www.llamaindex.ai/blog/introducing-agentworkflow-a-powerful-system-for-building-ai-agent-systems
LlamaIndex Agentic Retrieval: https://www.llamaindex.ai/blog/rag-is-dead-long-live-agentic-retrieval

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

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

Agentic RAGのアーキテクチャ分類

ReActループ — Agentic RAGの中核メカニズム

Corrective RAG（CRAG）— 検索品質の自己評価

Self-RAG — 自己反省型トークン生成

Adaptive RAG — クエリ複雑度に応じた戦略切替

メモリシステム

実装のポイント（Implementation）

フレームワーク選択マトリクス

実装時の推奨パラメータ

LlamaIndexでのAgentic RAG実装例

実験結果（Results）

実運用への応用（Practical Applications）

LlamaIndex v0.14との対応関係

プロダクション適用の注意点

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

Terraformインフラコード

運用・監視設定

コスト最適化チェックリスト

関連研究（Related Work）

まとめと今後の展望

参考文献

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

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

Agentic RAGのアーキテクチャ分類

ReActループ — Agentic RAGの中核メカニズム

Corrective RAG（CRAG）— 検索品質の自己評価

Self-RAG — 自己反省型トークン生成

Adaptive RAG — クエリ複雑度に応じた戦略切替

メモリシステム

実装のポイント（Implementation）

フレームワーク選択マトリクス

実装時の推奨パラメータ

LlamaIndexでのAgentic RAG実装例

実験結果（Results）

実運用への応用（Practical Applications）

LlamaIndex v0.14との対応関係

プロダクション適用の注意点

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

Terraformインフラコード

運用・監視設定

コスト最適化チェックリスト

関連研究（Related Work）

まとめと今後の展望

参考文献

関連記事

📄 ACL 2025論文解説: MAIN-RAG — マルチエージェント協調フィルタリングでRAGの検索ノイズを解消する

📄 論文解説: GraphRAG — ナレッジグラフとコミュニティ構造でRAGをグローバルに拡張する

📄 論文解説: LightRAG — デュアルレベル検索とインクリメンタル更新で実現する軽量グラフRAG