👽

【論文紹介】Agentic RAGのサーベイ

2025/01/31に公開

こんにちは。ZENKIGENデータサイエンスチームの勝田です。今回はAgentic RAGのサーベイ論文 “Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG“ を紹介します。自分が面白いと思ったところを紹介しましたので、気になる方は原文をあたってみてください。
チームでXアカウントを運用しており、AIに関する情報を発信していますのでご興味あれば覗いてみてください。

1. 概要

  • RAG(Retrieval-Augmented Generation)は、外部データソースから情報を検索・抽出してLLM応答を補強する技術であり、静的な学習データに依存するLLMを補完する技術である。
  • 従来のRAGの課題:ワークフローが(ほぼ)固定されており、複雑で柔軟性が求められるタスクには弱い。
  • Agentic RAGの利点:Agentic RAGはAIエージェントをRAGパイプラインに組み込み、動的な検索戦略、文脈理解、反復的な改善を可能にすることで、より複雑なタスクに対応できる。
  • Agentic RAGの課題:複雑なプロセスによる弊害(適切な連携の必要性、計算コスト、スケーラビリティ・レイテンシー)。

2. RAGの進化

RAGの登場から、課題とその解決策のための進化についてざざっと説明(RAGの基礎的な知識は既知として説明します)。

2-1. Naïve RAG

  • 説明:基本的なRAG。キーワードベースの検索と静的なデータセットを使用。
  • 良い点:実装が簡単。
  • 課題点:文脈理解やスケーラビリティ。

2-2. Advanced RAG

  • 説明:セマンティック理解と高度な検索技術(密ベクトル検索など)を導入。
  • 良い点:検索精度の向上。
  • 課題点:計算コストやスケーラビリティ。

2-3. Modular RAG

  • 説明:検索と生成のパイプラインを独立した再利用可能なコンポーネントに分解。
  • 良い点:ハイブリッド検索戦略や外部ツール統合により、柔軟性とカスタマイズ性が向上。
  • 課題点:論文には記述なし。

2-4. Graph RAG

  • 説明:グラフベースのデータ構造を統合し、関係性や階層を考慮した検索を可能にする。
  • 良い点:構造的データの複雑な関係性を理解するタスクに適している。
  • 課題点:スケーラビリティやデータ依存性。

3. Agentic RAG

2章で紹介された従来のRAGシステムの限界を克服するために考えられたのがAgenticRAGです。ざっくり言えば、自律的なAIエージェントをRAGパイプラインに組み込んだものになります。

3-1. Agentic RAGの概要

3-1-1. Agentの簡単な説明

  • LLM、短期および長期記憶、計画機能、ツール利用能力で構成。
  • 自律的な意思決定、反復的な推論、協調的なワークフローの実行ができることが特徴。
  • 構成要素
    • Reflection:出力を反復的に評価し改善する。
    • Planning:複雑なタスクをより小さなサブタスクに分解する。
    • Tool Use:外部ツールやAPIと対話して能力を拡張する。
    • Multi-Agent Collaboration:複数のエージェントが連携してタスクを完了する(単一のエージェントもある)。

3-1-2. Agentic RAGの主な特徴

上記特徴を持つAgentを組み込むことで、従来のRAGにはできないことができるようになります。

  • 動的な検索戦略: エージェントがクエリの複雑さに応じて、検索戦略を動的に管理・調整。
  • 反復的な改善: フィードバックループを取り入れ、検索精度と応答の関連性を向上させる。
  • ワークフローの最適化: タスクを動的に編成し効率性を上げる。
  • コンテキストの理解: 複数のエージェントが連携することで、より深く文脈を理解し、複雑なクエリに対応できる。

3-1-3. Agentic RAGの利点

  • 複雑なタスクへの対応: 従来のRAGシステムでは困難だった複数ステップの推論や動的な状況への適応。
  • 高い精度: 自律的なエージェントが情報をフィルタリングし、応答を洗練させることでより正確な情報を提供。
  • 柔軟性: モジュール化されたアーキテクチャにより、特定のドメインやタスクに合わせてシステムをカスタマイズ。
  • スケーラビリティ: 複数のエージェントが並行して処理を行うことで、大量のクエリを効率的に処理。
  • リアルタイムの適応: 変化する状況や新しい情報に動的に対応。

3-2. Agentic RAGの種類

以下に論文で紹介されたAgentic RAGの種類を書いていきます。論文にあるを読めばだいたいノリはわかるので紹介していきますね。

3-2-1. Single-Agent Agentic RAG

  • 単一のエージェントが情報の検索、ルーティング、統合を管理する中央集権的なシステム。
  • シンプルなので、設計、実装、保守が容易。リソースの最適化や多様なツールへの対応が可能。
  • 課題:複雑タスクには不向き。

例:カスタマーサポート

プロンプト
"注文の配送状況を教えてもらえますか?"

システムプロセス
1. クエリの送信と評価(Query Submission and Evaluation)
  - ユーザーがクエリを送信し、それがコーディネーティングエージェントによって受信される。
  - コーディネーティングエージェントがクエリを分析し、最も適切な情報源を特定する。
2. 知識ソースの選択(Knowledge Source Selection):
  - 注文管理データベースから追跡情報を取得する。
  - 配送業者のAPIからリアルタイムの更新情報を取得する。
  - 必要に応じて、天候や物流の遅延など、配送に影響を与える地域の状況を特定するためにウェブ検索を実行する。
3. データ統合とLLMによる合成(Data Integration and LLM Synthesis):
  - 関連データがLLMに渡され、情報が統合されて一貫した応答が生成される。
  - 出力の生成(Output Generation):
  - システムが、ライブトラッキングの更新情報や可能性のある代替案を提供しながら、実用的で簡潔な応答を生成。

レスポンス
"お客様の荷物は現在輸送中で、明日の夜に到着予定です。
UPSのライブトラッキングによると、現在、地域の配送センターにあります。"

上記のように、聞かれる状況がある程度決まっており、対応すべきデータ・タスクが決まってる場合はうまく動作しそうです。

3-2-2. Multi-Agent Agentic RAG

  • 複数の専門エージェントがタスクを分担し並行処理。
  • 複雑なワークフローと多様なクエリに対応し、モジュール性、スケーラビリティ、タスクの専門化、効率性が向上。
  • 課題:エージェント間の連携の複雑さや計算コストの増加。

例:マルチドメイン・リサーチアシスタント

プロンプト
"ヨーロッパにおける再生可能エネルギー導入の経済的および環境的影響は何ですか?"

システムプロセス(マルチエージェントワークフロー)
  - Agent1: SQLベースのクエリを使用して経済データベースから統計データを取得する。
  - Agent2: セマンティック検索ツールを使用して関連する学術論文を検索する。
  - Agent3: 再生可能エネルギーに関する最新のニュースや政策の更新をウェブ検索する。
  - Agent4: 推奨システムを利用して、レポートや専門家のコメントなどの関連コンテンツを提案する。

レスポンス
"ヨーロッパでの再生可能エネルギーの導入は、EUの政策報告によると、過去10年間で温室効果ガス
排出量を20%削減しました。経済的には、再生可能エネルギーへの投資により約120万人の雇用が創
出され、特に太陽光および風力分野で大きな成長が見られました。最近の学術研究では、電力網の安
定性やエネルギー貯蔵コストに関する潜在的なトレードオフも指摘されています。"

普通のLLMでも複数のペルソナを用意することで広範囲な視点が得られますが、ここでは別エージェントとして切り出しています。これによって、やってほしいタスクを明確化でき(汎用的な場合に比べ)コスト減も期待できそうです。

3-2-3. Hierarchical Agentic RAG

  • 階層構造のエージェントがタスクを管理し、戦略的な意思決定を可能にする。
  • 多段階の意思決定が可能になるため、戦略的な優先順位付け、スケーラビリティ、意思決定の強化が可能。
  • 課題:エージェント間の調整のオーバーヘッド。

例:金融分析システム


プロンプト
"現在の市場動向を考慮した場合、再生可能エネルギー分野における最適な投資オプションは何ですか?"

システムプロセス(階層型エージェントワークフロー)
1. 最上位エージェント(Top-Tier Agent)
  - クエリの複雑さを評価し、信頼できる金融データベースや経済指標を、信頼性の低いデータソースよりも優先して使用する。
2. 中間レベルエージェント(Mid-Level Agent)
  - 独自のAPIや構造化されたSQLデータベースから、リアルタイムの市場データ(例:株価、セクターの業績)を取得する。
3. 下位レベルエージェント(Lower-Level Agent(s))
  - 最近の政策発表に関するウェブ検索を実施し、専門家の意見やニュース分析を追跡する推奨システムを参照する。
4. 集約と統合(Aggregation and Synthesis)
  - 最上位エージェントが結果をまとめ、定量データと政策インサイトを統合する。

レスポンス
"現在の市場データによると、再生可能エネルギー関連株は過去四半期で15%の成長を示しており、
政府の支援政策や投資家の関心の高まりによって推進されています。アナリストによると、特に
風力および太陽光セクターは今後も勢いを維持する可能性が高い一方で、グリーン水素のような
新興技術は中程度のリスクがあるものの、高いリターンの可能性も秘めています。"

意思決定を行い、タスクを下位エージェントに振り分けていく。会社組織などを参考にしたものだろうか?多層化すると収集がつかなくなりそうな所も組織に似ているかも笑。

3-2-4. Agentic Corrective RAG

  • 検索結果を自己修正する仕組みを導入。文書利用の強化、応答生成の品質を向上。
  • 関連性評価エージェント、クエリ改善エージェント、外部知識検索エージェントの活用。

例:学術研究アシスタント

プロンプト
"生成AI研究における最新の発見は何ですか?"

システムプロセス(修正型RAGワークフロー)
1. クエリの送信(Query Submission)
  - ユーザーがクエリをシステムに送信する。
2. コンテキスト検索(Context Retrieval)
  - コンテキスト検索エージェントが、生成AIに関する公開論文のデータベースから初期ドキュメントを取得する。
  - 取得したドキュメントは次の評価ステップに渡される。
3. 関連性評価(Relevance Evaluation)
  - 関連性評価エージェントが、ドキュメントのクエリとの整合性を評価する。
  - ドキュメントは、関連・曖昧・無関係のカテゴリに分類される。無関係なドキュメントは修正処理の対象としてフラグが立てられる。
4. 修正処理(必要に応じて)(Corrective Actions (if needed))
  - クエリ精緻化エージェントが、クエリの明確性と関連性を向上させるために書き直す。
  - 外部知識検索エージェントが、追加の論文やレポートを取得するためにウェブ検索を実行する。
5. 応答の統合(Response Synthesis)
  - 応答統合エージェントが、検証されたドキュメントを統合し、首尾一貫した包括的な要約を作成する。

レスポンス
"生成AIに関する最近の研究では、拡散モデルの進化、テキストからビデオへのタスクにおける強化学習、
大規模モデルのトレーニング最適化技術の進展が強調されています。詳細については、NeurIPS 2024およびAAAI 2025で発表された研究を参照してください。"

タスクを限定することで、より適切な文章を探し・統合できるように工夫されている。タスクを適切な範囲に絞ることがRAGの肝なのかもしれない。

3-2-5. Adaptive Agentic RAG

  • 入力クエリの複雑さに基づいてクエリ処理戦略を動的に調整。
  • クエリを分類して、単一ステップ検索、複数ステップ推論、検索を省略するなど、最適アプローチを決定。
  • リソース効率・応答精度の最適化。

例:カスタマーサポートアシスタント

プロンプト
"なぜ私の荷物は遅延しているのですか?また、どのような代替策がありますか?"

システムプロセス(適応型RAGワークフロー)
1. クエリ分類(Query Classification)
  - クラス分類器がクエリを分析し、それが複雑であり、多段階の推論が必要であると判断する。
2. 動的戦略選択(Dynamic Strategy Selection)
  - システムが複雑性分類に基づいて、多段階の検索プロセスを起動する。
3. 多段階検索(Multi-Step Retrieval)
  - 注文データベースから追跡詳細を取得する。
  - 配送業者のAPIからリアルタイムのステータス更新を取得する。
  - 天候状況や地域の混乱などの外部要因を特定するためにウェブ検索を実行する。
4. 応答統合(Response Synthesis)
  - LLMが取得したすべての情報を統合し、包括的かつ実用的な応答を生成する。

レスポンス
"お客様の荷物は、地域の厳しい天候条件により遅延しています。現在、地域の配送センターにあり、
2日後に配達予定です。代替策として、施設からの直接受け取りを選択することも可能です。"

広範囲のクエリにも対応できるようになっており、より複雑で柔軟な対応が可能になりそう。人間の判断の振る舞いを参考にしてそうですね。

3-2-6. Graph-Based Agentic RAG

グラフ構造のデータを利用して、関係性に基づいた推論や検索を行い、より高度な情報処理を実現。

Agent-G: Agentic Framework for Graph RAG

  • グラフ知識ベースと非構造化ドキュメント検索を統合。
例:医療診断
プロンプト
"2型糖尿病の一般的な症状は何ですか?また、それらは心臓病とどのように関連していますか?"

システムプロセス(Agent-Gワークフロー)
1. クエリの受信と割り当て(Query Reception and Assignment)
  - システムがクエリを受信し、グラフ構造化データと非構造化データの両方が必要であることを特定し、包括的に回答する。
2. グラフ検索(Graph Retriever)
  - 医療知識グラフから2型糖尿病と心臓病の関係を抽出する。
  - グラフ階層と関係性を探索し、肥満や高血圧などの共通のリスク要因を特定する。
3. 文献検索(Document Retriever)
  - 医学文献から2型糖尿病の症状(例:口渇の増加、頻尿、倦怠感)の説明を取得する。
  - グラフに基づく知見を補完するための文脈情報を追加する。
4. 評価モジュール(Critic Module)
  - 取得したグラフデータおよび文献データの関連性と品質を評価する。
  - 信頼性の低い結果をフラグ付けし、修正または再検索を行う。
5. 応答の統合(Response Synthesis)
  - LLMが、グラフ検索および文献検索から検証されたデータを統合し、クエリの意図に沿った首尾一貫した応答を作成する。

レスポンス
"2型糖尿病の症状には、口渇の増加、頻尿、倦怠感などが含まれます。研究によると、糖尿病と心臓病には50%
の相関があり、主に肥満や高血圧などの共通のリスク要因を介して関係しています。"

グラフデータを効率的に取得できるモジュールが増設されたマルチエージェントのように見える。

GeAR: Graph-Enhanced Agent for Retrieval-Augmented Generation

  • グラフ拡張技術とエージェントベースアーキテクチャを活用。
例:マルチホップ質問応答
プロンプト
"J.K.ローリングのメンターに影響を与えた作家は誰ですか?"

システムプロセス(GeARワークフロー)
1. 最上位エージェント(Top-Tier Agent)
  - クエリのマルチホップの特性を評価し、グラフ拡張と文書検索の組み合わせが必要であると判断する。
2. グラフ拡張モジュール(Graph Expansion Module)
  - J.K.ローリングのメンターがクエリ内の主要なエンティティであることを特定する。
  - 文学関係に関するグラフ構造化データを探索し、そのメンターに影響を与えた作家を追跡する。
3. エージェントベース検索(Agent-Based Retrieval)
  - エージェントがグラフ拡張された検索パスを自律的に選択し、メンターの影響に関する関連情報を収集する。
  - テキストデータソースを照会し、メンターとその影響についての非構造化情報を統合する。
4. 応答の統合(Response Synthesis)
  - LLMを活用し、グラフデータと文書検索プロセスから得た知見を統合して、クエリ内の複雑な関係を正確に反映する応答を生成する。

レスポンス
"J.K.ローリングのメンターである [メンター名] は、[作家名] に大きな影響を受けました。
この作家は [代表作品またはジャンル] で知られています。この関係は文学史における重層的
なつながりを示しており、影響力のあるアイデアがしばしば複数世代の作家を通じて受け継がれ
ることを示しています。"

わからせる気があるのか?というくらい複雑な図ですね笑。これだけ複雑で適切に動くのか不安。マルチホップ質問とは、複数の情報ソースや中間的な推論ステップを経なければ答えが導き出せない質問です。複雑な推論では効果が出るかもしれません。

3-2-7. Agentic Document Workflows

  • ドキュメント解析、検索、推論、構造化された出力など、ドキュメント中心のプロセスの自動化。
  • 状態の維持、複数ステップのオーケストレーション、ドメイン固有のインテリジェンスを持つ。

例:請求書支払いワークフロー

プロンプト
"提出された請求書と関連するベンダー契約条件に基づいて、支払い推奨レポートを作成してください。"

システムプロセス(ADWワークフロー)
1. 請求書を解析し、請求書番号、日付、ベンダー情報、明細項目、および支払い条件などの主要な詳細を抽出する。
2. 対応するベンダー契約を取得し、支払い条件を確認し、適用可能な割引やコンプライアンス要件を特定する。
3. 支払い推奨レポートを作成し、元の支払額、早期支払い割引の可能性、予算への影響分析、および戦略的な支払いアクションを含める。

レスポンス
"請求書INV-2025-045($15,000.00)が処理されました。2025-04-10までに支払われた場合、2%の
早期支払い割引が適用され、支払額が$14,700.00に削減されます。また、合計額が$10,000.00を超え
たため、5%の一括注文割引が適用されました。今後のプロジェクトフェーズの適時な資金配分を確保する
ため、2%の早期支払いを承認することを推奨します。"

ドキュメントに特化することで必要なモジュール・タスクをリファインしているように見えます。

3-3. Agentic RAGの課題

  • エージェント間の連携の複雑さ
    • マルチエージェントアーキテクチャでは、エージェント間のコミュニケーションやタスクの委任を適切に管理する必要がある。
  • 計算コストの増加
    • 複数のエージェントを並行して処理するため、リソースの消費量が増加する可能性がある。
  • スケーラビリティとレイテンシー
    • 大量のクエリを処理する際に、システムのスケーラビリティと応答のレイテンシーを最適化する必要がある。
  • 倫理的な考慮事項
    • AIエージェントの意思決定における倫理的な側面を考慮する必要がある。
  • 評価の難しさ
    • Agentic RAG特有の能力(複数エージェントの連携や動的な適応など)を評価するための標準化されたベンチマークやデータセットの不足。

感想

いろいろな「俺のアーキテクチャ」が現れている段階で、初期のディープラーニングの時を思い起こさせますね笑。そのときと同じような課題として「結局本当に良くなったのか?」「どの程度良くなったのか?」の検証が難しそうです。色々なアイデアの「汎用的なAgenticな振る舞い」につい目を奪われますが、(少なくともビジネス活用するときは)タスク要件をしっかり決めて、適切な範囲に絞り開発していくことが大事かなと思いました。

お知らせ

少しでも弊社にご興味を持っていただけた方は、お気軽にご連絡頂けますと幸いです。まずはカジュアルにお話を、という形でも、副業を検討したいという形でも歓迎しています。

https://hrmos.co/pages/zenkigen/jobs?jobType=FULL
https://speakerdeck.com/zenkigenforrecruit/detailed-version-recruitment-materials-for-data-scientists

ZENKIGENテックブログ

Discussion