Agentic RAGとは
エージェンティックRAG
検索・生成の各ステップをAIエージェントが自律的に計画・実行・検証しながら進めるRAGの設計パターン
ひとことで言うと
1回検索して終わりではなく、AIが自分で「もっと調べるべきか」を判断しながら答えを作っていくRAG。
概要
Agentic RAGは、あらかじめ決められた「検索してから生成する」という固定的な一連の流れの代わりに、AIエージェントが質問の内容に応じて検索クエリの立案・検索の実行・取得結果の評価・追加検索の要否判断といった各ステップを自律的に制御しながら進めるRAGの設計パターン。 最初の検索結果だけでは質問に答えるための情報が不十分と判断した場合、エージェントはクエリを言い換えたり、別の情報源を検索したりといった追加のアクションを自ら選択できる。 複数の情報源(社内文書・Web検索・データベースなど)を状況に応じて使い分けたり、取得した情報を要約・検証してから次のステップに進んだりと、単純な1回検索型のRAGでは対応しにくい複雑な質問への対応力を高められる。 AIエージェントとRAGという2つの潮流が組み合わさることで、より柔軟で精度の高い知識活用システムを構築する設計思想として、2024年頃から実務での採用が広がっている。
背景
従来のRAGは、検索と生成の順序があらかじめ固定されており、最初の検索結果が不十分だった場合でも、その場で検索戦略を修正する仕組みを持たなかった。 Agentic RAGは、AIエージェントの持つ計画・判断・ツール利用の能力をRAGパイプラインに組み込むことで、状況に応じて柔軟に検索戦略を調整できるようにする狙いで生まれた。
アーキテクチャ
検索を単なる前処理ではなく、エージェントが呼び出せる「ツール」の1つとして位置づける構成を取る。 エージェントは質問を受けて検索クエリを計画するプランナー、検索ツールを実行するツール実行部、取得結果が質問に十分答えられる情報かどうかを判定する評価部から構成され、これらを1つのループとして必要な回数だけ繰り返す。 複数の情報源(ベクトル検索・Web検索・API等)を個別のツールとして持たせ、状況に応じてエージェントがどのツールを使うかを選択できる構成も一般的。
ワークフロー
質問を受け取ったエージェントが、必要な検索クエリと情報源を計画する。 検索ツールを呼び出して結果を取得し、その内容で質問に答えられるかを評価する。 不十分と判断した場合はクエリを修正したり別の情報源を検索したりして情報を補い、十分な情報が集まった時点で最終的な回答を生成する。
コード例
検索評価を含むAgentic RAGループの概念コード
def agentic_rag(question, retriever, llm, max_steps=3):
context = []
for _ in range(max_steps):
query = llm.plan_query(question, context)
docs = retriever.search(query)
context.extend(docs)
if llm.is_sufficient(question, context):
break
return llm.generate_answer(question, context)利点
- 複数回の検索や複数の情報源を組み合わせた、複雑な質問への対応力が高い
- 検索結果が不十分な場合に自律的に検索戦略を調整でき、回答の精度を高めやすい
- 検索と生成の間に検証ステップを挟めるため、誤った情報に基づく回答を減らしやすい
欠点
- 複数回のLLM呼び出しと検索が発生するため、単純なRAGよりレイテンシとコストが増加する
- エージェントの判断ロジックが複雑になり、動作の予測やデバッグの難易度が上がる
- 検索戦略の制御を誤ると、不要な検索を繰り返すなど非効率な動作に陥る場合がある
比較
関連用語
よくある質問
Agentic RAGと通常のRAGの違いは?
通常のRAGは検索と生成の流れが固定されているのに対し、Agentic RAGはエージェントが検索クエリの立案や追加検索の要否をその場で判断しながら進める点が異なる。
Agentic RAGはどんな場面で有効?
1回の検索だけでは答えにくい複雑な質問や、複数の情報源を組み合わせる必要がある調査タスクなどで、通常のRAGより高い回答精度が期待できる。