Agentic RAG：AIエージェントが検索拡張生成をどう変革しているか
- Name
- Soren Atelier
Updated on
標準的なRAG（Retrieval-Augmented Generation）には根本的な制限があります：一度検索して一度生成するだけです。システムはベクトルデータベースを検索し、Top-Kのチャンクを取得してプロンプトに詰め込み、回答がそのチャンクに含まれていることを期待します。関連情報が複数のドキュメントに分散していたり、多段階の推論が必要だったり、検索前に明確化が必要な場合、基本的なRAGは静かに失敗します——不完全なコンテキストに基づいて、もっともらしく聞こえる回答を返してしまいます。
Agentic RAGは、静的な検索・生成パイプラインを、計画、反復検索、結果評価、十分な情報が集まったかの判断ができる自律型AIエージェントに置き換えることでこの問題を解決します。エージェントはドキュメントを取得するだけでなく、何を検索すべきか推論し、取得したコンテンツが十分かを判断し、不十分な場合は追加のアクションを取ります。
基本RAG vs Agentic RAG
基本RAGパイプライン
ユーザークエリ → クエリの埋め込み → ベクトル検索 → Top-Kチャンク → LLM → 回答このアプローチの問題点：
- 一度きりの検索：最初の検索が関連ドキュメントを見逃した場合、回復手段がない
- 何を検索すべきかの推論がない：クエリはそのまま埋め込まれ、分解されない
- 評価がない：取得したチャンクが実際に質問に答えているか判断できない
- 多段階検索がない：最初の結果が次のクエリに情報を提供するような検索のチェーンができない
Agentic RAGパイプライン
ユーザークエリ → エージェントが計画 → 検索ツール → 結果を評価 →
→ 更に情報が必要？ → クエリを改善 → 再検索 →
→ 十分なコンテキスト？ → 統合 → 回答エージェントはインテリジェントなオーケストレーターとして機能し：
- 複雑なクエリをサブクエスチョンに分解できる
- ツールを選択できる：ベクトル検索、Web検索、SQLクエリ、API呼び出し
- 取得したコンテキストが十分かを評価できる
- 確信が持てるまで改善されたクエリで反復できる
- 複数の検索ラウンドからの情報を統合できる
Agentic RAGの仕組み
コアアーキテクチャ
| コンポーネント | 基本RAG | Agentic RAG |
|---|---|---|
| クエリ処理 | 直接的な埋め込み | クエリの分解と計画 |
| 検索 | 単一のベクトル検索 | 複数ツール、反復検索 |
| 評価 | なし | 取得コンテキストの自己評価 |
| 推論 | 単一のLLM呼び出し | ツール使用を伴う多段階推論 |
| エラー回復 | なし | 改善されたクエリでの再試行 |
| データソース | 通常1つのベクトルDB | 複数ソース（DB、Web、API） |
エージェントの意思決定フロー
Agentic RAGシステムは通常、この意思決定パターンに従います：
- 質問を分析：シンプル（単一検索）か複雑（分解が必要）か？
- 検索戦略を計画：どのソースに問い合わせるか？どの順序で？
- 検索を実行：最初のソースを検索
- 結果を評価：これらのチャンクに回答が含まれているか？
- 次のアクションを決定：回答する、クエリを改善する、別のソースを検索する
- 統合：すべての検索ステップからの情報を組み合わせる
# 概念的なAgentic RAGループ（疑似コード）
def agentic_rag(query, tools, max_iterations=5):
context = []
plan = agent.plan(query) # サブクエスチョンに分解
for step in plan:
# エージェントがどのツールを使うか決定
tool = agent.select_tool(step, tools)
results = tool.execute(step.query)
context.extend(results)
# エージェントが十分な情報があるか評価
if agent.has_sufficient_context(query, context):
break
# エージェントが学んだことに基づいてクエリを改善
step.query = agent.refine_query(step, results)
return agent.synthesize(query, context)Agentic RAGの主要パターン
1. クエリ分解
複雑な質問をよりシンプルなサブクエリに分割：
元の質問："AppleとMicrosoftの2025年第3四半期の売上成長を比較し、
どちらの企業の営業利益率が高かったか説明してください"
分解後：
1. "Apple 2025年Q3 売上成長"
2. "Microsoft 2025年Q3 売上成長"
3. "Apple 2025年Q3 営業利益率"
4. "Microsoft 2025年Q3 営業利益率"各サブクエリは、単一の広範な検索がすべての必要な情報を返すことを期待するのではなく、焦点を絞った関連ドキュメントを取得します。
2. 適応型検索
エージェントはクエリタイプに基づいて検索方法を決定：
| クエリタイプ | 検索戦略 |
|---|---|
| 事実確認 | 単一のベクトル検索 |
| 比較 | 各エンティティの並列検索 |
| 多段階推論 | 前の結果に基づく逐次検索 |
| 時間的 | 日付でフィルタ後、セマンティック検索 |
| 集約 | SQLクエリ + ドキュメント検索 |
3. 自己評価
各検索ステップ後、エージェントは以下を評価：
- 関連性：取得したチャンクは正しいトピックについてか？
- 完全性：回答に十分な情報が含まれているか？
- 一貫性：複数のソースが一致しているか？
- 鮮度：情報は十分に新しいか？
4. ツール選択
Agentic RAGはベクトル検索に限定されません：
| ツール | 使用するタイミング |
|---|---|
| ベクトル検索 | セマンティック類似性クエリ |
| キーワード検索（BM25） | 正確な用語一致、技術的なクエリ |
| Web検索 | 最新のイベント、最近の情報 |
| SQLクエリ | 構造化データ、集約 |
| API呼び出し | リアルタイムデータ（価格、天気） |
| コード実行 | 計算、データ変換 |
実装アプローチ
LangChainエージェント
from langchain.agents import create_react_agent
from langchain_openai import ChatOpenAI
from langchain.tools import Tool
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings
# 検索ツールを作成
vectorstore = FAISS.from_texts(documents, OpenAIEmbeddings())
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
def search_docs(query: str) -> str:
results = retriever.invoke(query)
return "\n".join([doc.page_content for doc in results])
tools = [
Tool(
name="SearchDocuments",
func=search_docs,
description="Search the knowledge base for relevant information"
),
]
llm = ChatOpenAI(model="gpt-4o", temperature=0)
agent = create_react_agent(llm, tools, prompt_template)LlamaIndexエージェント
from llama_index.core.agent import ReActAgent
from llama_index.core.tools import QueryEngineTool
from llama_index.core import VectorStoreIndex
# クエリエンジンツールを作成
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine(similarity_top_k=5)
tools = [
QueryEngineTool.from_defaults(
query_engine=query_engine,
name="knowledge_base",
description="Search the company knowledge base"
),
]
agent = ReActAgent.from_tools(tools, llm=llm, verbose=True)
response = agent.chat("What were our Q3 results?")Agentic RAGを使うべき時
| シナリオ | 基本RAG | Agentic RAG |
|---|---|---|
| 単一ソースからのシンプルなQ&A | 最適 | 過剰 |
| 複数ドキュメントの推論 | 苦手 | 得意 |
| 計算が必要な質問 | 不可能 | コードツールを使用 |
| 動的データ（API、データベース） | 限定的 | 自然な適合 |
| 曖昧なクエリ | 低品質な結果 | 明確化と反復が可能 |
| コスト重視 | 安価（1回のLLM呼び出し） | 高価（複数回の呼び出し） |
| レイテンシ要件 | 高速 | 低速（反復的） |
トレードオフ
| メリット | デメリット |
|---|---|
| 高い回答品質 | 高いレイテンシ（複数のLLM呼び出し） |
| 複雑なクエリに対応 | クエリあたりのコストが高い |
| 自己修正型の検索 | 構築とデバッグが複雑 |
| マルチソース統合 | エージェントがループに陥る可能性 |
| 曖昧なクエリに強い | 動作の予測が困難 |
Agentic RAGのデータパイプライン構築
Agentic RAGのデータパイプライン設定——ドキュメントのチャンク化、埋め込みの作成、ベクトルインデックスの構築——は反復的な実験作業です。RunCell (opens in a new tab)は、AIアシスタンス付きでRAGパイプラインをプロトタイプし、検索品質をインタラクティブにデバッグし、チャンキング戦略を反復改善できるAI搭載Jupyter環境を提供します。
検索評価メトリクス（関連性スコア、レイテンシ分布、回答品質）の可視化には、PyGWalker (opens in a new tab)でRAG評価データセットをJupyterでインタラクティブに探索できます。
FAQ
Agentic RAGとは何ですか？
Agentic RAGは検索拡張生成と自律型AIエージェントを組み合わせたものです。静的な検索・生成パイプラインの代わりに、AIエージェントが検索戦略を計画し、複数の検索を実行し、結果を評価し、正確に回答するのに十分なコンテキストが集まるまで反復します。
Agentic RAGは基本RAGとどう違いますか？
基本RAGは一度検索して一つの回答を生成します。Agentic RAGはクエリを分解し、異なるツール（ベクトル検索、Web検索、SQL）を選択し、取得したコンテキストが十分かを評価し、改善されたクエリで反復できるAIエージェントを使用します。基本RAGでは対応できない複雑で多段階の質問を処理します。
Agentic RAGは基本RAGより高価ですか？
はい、Agentic RAGは通常、複数のLLM呼び出し（計画、評価、統合）と複数の検索操作を行うため、クエリあたりのコストが高くなります。トレードオフとして、複雑なクエリに対する回答品質が大幅に向上します。シンプルな事実確認には、基本RAGの方がコスト効率が良いです。
どのフレームワークがAgentic RAGをサポートしていますか？
LangChain、LlamaIndex、Haystackのすべてがagentic RAGパターンをサポートしています。LangChainはツール使用を伴うReActエージェント、LlamaIndexはクエリ計画エージェント、Haystackはパイプラインベースのエージェントアーキテクチャを提供しています。OpenAIまたはAnthropicのfunction calling APIを直接使用してカスタムエージェントを構築することもできます。
Agentic RAGと基本RAGのどちらを使うべきですか？
単一のナレッジベースからのシンプルな事実Q&Aには基本RAGを使用してください。クエリが複数ドキュメントにまたがる推論を必要とする場合、比較を含む場合、リアルタイムデータが必要な場合、または基本RAGが一貫して不完全な回答を返す場合はAgentic RAGを使用してください。
まとめ
Agentic RAGは、静的パイプラインを計画、反復検索、自己結果評価を行うインテリジェントなエージェントに置き換えることで、基本RAGの核心的な制限に対処します。複数ドキュメントにまたがり、推論を必要とし、複数ソースからのデータが必要な複雑なクエリを処理します。トレードオフはクエリあたりのコストとレイテンシの増加です。ほとんどのアプリケーションでは、シンプルなクエリには基本RAGから始め、複雑な質問をAgentic RAGにルーティングする——シンプルなシステムでは対応が難しい場合にのみエージェントを使用するのが最善のアプローチです。