GEO

エージェンティックRAG

エージェンティックRAGは、固定されたパイプラインではなくLLMエージェントが、何を、いつ、どのように検索し、答えが十分かどうかを判断する検索拡張生成アーキテクチャです。1回のクエリ→検索→回答という流れではなく、エージェントが計画を立て、複数の検索を実行し、自身の部分的な回答を評価し、確信が持てるまで再試行します。

エージェンティックRAGは、固定されたパイプラインではなくLLMエージェントが、何を、いつ、どのように検索し、答えが十分かどうかを判断する検索拡張生成アーキテクチャです。1回のクエリ→検索→回答という流れではなく、エージェントが計画を立て、複数の検索を実行し、自身の部分的な回答を評価し、確信が持てるまで再試行します。

なぜ重要なのか

従来のRAGには限界があります。1つのクエリ、1回の検索、1つの回答です。これは単純な検索には機能しますが、複雑な質問、曖昧なクエリ、または複数のステップにまたがって複数の文書を読む必要があるタスクでは失敗します。エージェンティックRAGは、検索プロセスそのものをモデルに自律的に委ねることで、その限界を打ち破ります。LangChain、LlamaIndex、Anthropicによる2024年から2025年のベンチマークでは、エージェンティックRAGが複数文書のQA、事実検証、リサーチタスクにおいて、通常のRAGを20〜40%上回ることが示されています。これは、Perplexityのディープリサーチ、ChatGPTのブラウジング、そして実際に機能するほとんどの企業向け「文書とチャット」システムの背後にあるアーキテクチャです。

標準的なRAGとの違い

標準的なRAG:

  1. ユーザーが質問する
  2. システムが質問を埋め込み、上位k件を検索する
  3. モデルが検索したコンテキストから回答を生成する

一発勝負。静的。再試行なし。

エージェンティックRAG:

  1. ユーザーが質問する
  2. エージェントが計画する。「これに答えるには何を知る必要があるか?」
  3. エージェントが特定のサブクエリで検索ツールを呼び出す
  4. エージェントが結果を読み、何が足りないかを判断する
  5. エージェントが改良したクエリで再度検索を呼び出す(ループ)
  6. エージェントが十分だと判断したときに回答を起草する
  7. エージェントが必要に応じて自己批評し、修正する
  8. 最終的な回答が提供される

複数ステップ。適応的。後戻りが可能。

主要なコンポーネント

プランナー: 質問を検索ステップに分解するLLM(多くの場合、回答するものと同じLLM)です。

検索ツール: ベクトル検索、キーワード検索、API呼び出し、データベースクエリなど、エージェントがその中から選択できます。

メモリ: エージェントは、冗長な呼び出しを避けるために、すでに見たものを追跡します。

自己批評ループ: エージェントは、起草した回答が十分な根拠に基づいているかを評価し、そうでない場合はさらに検索します。

終了条件: 確信度のしきい値、ステップの予算、または明示的な「十分である」というシグナルのいずれかです。

よくあるパターン

ReAct(推論 + 行動): エージェントは、1つのスクラッチパッド内で思考とツールの呼び出しを交互に行います。Yaoら(2022年)による元祖のエージェンティックパターンです。

Plan-and-execute: エージェントは最初に複数ステップの計画を書き、その後各ステップを実行します。ディープリサーチに適していますが、単純な質問には遅くなります。

Self-RAG: モデルは、そもそも検索が必要かどうかを動的に判断します。質問が些細なものであれば、検索を完全にスキップします。

マルチエージェントRAG: 複数の専門化されたエージェント(検索者、読み手、批評家、書き手)が協働します。強力ですが高コストです。

いつ使うべきか

複雑なリサーチタスク: 「2025年第4四半期のFAANG全体の決算動向を要約せよ。」

複数文書のファクトチェック: 複数の情報源と主張を相互参照する場合。

曖昧な質問: 正しい検索が曖昧さの解消に依存する場合(「どのジョーダン?」)。

重大な結果を伴う出力: 法律、医療、金融など、1回の検索では重要なコンテキストを見逃す可能性がある分野。

エージェント統合型チャット: 学習した内容に基づいて行動も取るアシスタント(メール送信、会議のスケジュール設定)。

いつ使うべきでないか

単純なFAQ検索: 1回の検索で十分です。エージェンティックなループはレイテンシとコストを増やします。

厳しいレイテンシ予算: 1秒を目標とするチャットUIでは、複数ステップのエージェントループを許容できません。

コストに敏感な大量処理: ループの各反復は、さらなる推論呼び出しです。規模が大きくなると、エージェンティックRAGは標準的なRAGの5〜10倍のコストがかかることがあります。

適切にインデックスされた小規模なコーパス: データが十分に小さく、1回の高密度検索で常に正しいパッセージが見つかる場合は、複雑さを加えないでください。

トレードオフ

レイテンシ: 複数ステップのループは、応答に1秒未満ではなく5〜30秒かかることを意味します。

コスト: 各ステップはLLM呼び出しと検索呼び出しです。それに応じて予算を組んでください。

決定性: エージェンティックなシステムは、実行ごとに異なる経路を取りうるため、デバッグや再現が難しくなります。

評価: 検索計画が動的である場合、「検索は良好か」を測定するのは困難です。中間的な判断ではなく、最終的な回答を評価します。

よくある間違い

単純な質問にエージェントを強制する: 過剰な対応は、品質を改善せずにコストを膨らませます。

ステップ予算がない: 制約のないエージェントは数分間ループする可能性があります。ステップを5〜10に制限してください。

メモリがない: 過去の検索を追跡しないと、エージェントは作業を繰り返します。

弱いプランナー: 計画用のLLMが小さすぎたり、プロンプトが不適切だったりすると、計画が悪くなり、ループが呼び出しを無駄にします。

評価をスキップする: エージェントのトレースはノイズが多いため、チームは正式な評価をスキップしてしまい、その結果、自分たちのシステムが通常のRAGよりも実際に優れているかどうかを判断できなくなります。

Sources: