Google Research、Gemini Enterprise Agent Platform にアジェンティック RAG と多段クエリ対応の充分文脈エージェントを追加
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
MarkTechPost
Google Research チームは、企業検索の課題である複数ソース・多段クエリへの対応を目的とした新しいアジェンティック RAG 枠組みを Gemini Enterprise Agent Platform に実装し、クロスコーパス検索機能を公開プレビューとして提供開始した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Google Research チームは、新しいエージェント型 RAG（Retrieval-Augmented Generation）フレームワークを導入しました。これは Gemini Enterprise Agent Platform に組み込まれており、「Cross-Corpus Retrieval」と呼ばれる機能を駆動しています。この機能は現在、パブリックプレビュー段階にあります。
この取り組みの目標は、エンタープライズ検索における既知の失敗モードに対処することです。標準的な単一ステップの RAG は、複数ソース・多段ホップ型のクエリには対応していません。「Project X で使用されているサーバーの仕様は何ですか？」と尋ねた場合、システムはそのサーバー ID を記載した文書を見つけることはできても、その ID を取得して 2 つ目のデータベースで仕様の検索を行うべきだという判断は下せません。結果として回答は部分的なものになったり、「見つかりませんでした」と返されたりします。
Google の新しいエージェント型 RAG とは何か
エージェント型 RAG は、データソースに対して計画を立て、推論を行い、反復的に相互作用を行います。これにより、複雑なクエリへの対応が可能となり、信頼性と精度が向上します。Google の実装は、Gemini Enterprise Agent Platform でホストされる「Cross-Corpus Retrieval」であり、エージェント型 RAG によって駆動されています。他のマルチエージェント型 RAG フレームワークと同様に、連携して動作するエージェントを使用しますが、それらとは異なり、回答を生成する前に十分な文脈チェックを追加しています。標準的な RAG と比較すると、事実性データセットにおける精度が最大 34% 向上します。Google の研究チームはまた、独自内部データセットでもテストを行い、ドメイン固有のタスクにおいてより優れた根拠付けと推論精度の向上を確認しました。
マルチエージェントアーキテクチャの仕組み
これは検索エンジンではなく、組織化された研究部門と捉えてください。「バニラ」型の RAG システムは、単に質問を文書にマッチングさせるだけです。その後、LLM がそのマッチ結果に基づいて回答を生成します。一方、マルチエージェント・フレームワークはこの作業を専門的な役割に分けて処理します。
オーケストレーターが要求が単一ステップのタスクではないと判断し、委任を行います。プランナー・エージェントはデータソース間での情報経路をマッピングします。クエリ・ライター（Query Rewriter）は曖昧な要求を複数の精密な検索クエリに変換します。次に、Search Fanout エージェントがこれらのクエリを様々な検索ソースに送信します。最後に、LLM が収集されたコンテキストを集約して回答を生成します。
このフレームワークの決定的な違い
決定的な違いは「持続性」にあります。このフレームワークは情報が不足している状態を検知し、引き続き検索を続けます。これにより、最初の検索結果が空の場合にモデルが推測するのを防ぎます。また、「十分な情報を持っていません」という早すぎる回答も回避できます。
この持続性は、Google のフレームワークにおける新コンポーネントである「Sufficient Context Agent（十分な文脈エージェント）」によって実現されています。例えば、医師が患者の退院時の服用薬、食事制限、およびアレルギー反応を尋ねるケースを考えてみましょう。
フェーズ 1 のオーケストレーションでは、ルート・エージェントが要求を解析し委任を行います。プランナー・エージェントは薬剤情報、栄養記録、臨床ノートという対象領域を特定します。クエリ・ライターはこの長い要求を、単純で検索可能な質問に分解します。
フェーズ 2「検索」では、RAG エージェントはすべてのクエリの分岐を同時に実行します。薬剤や食事に関する情報は見つかりますが、アレルギーの言及はありません。バニラ RAG システムであれば、ここで不十分な回答で止まってしまう可能性があります。
フェーズ 3 では、Sufficient Context Agent（十分な文脈エージェント）が結果を検査します。データベースから取得したスニペットを読み込み、プロンプトとスニペットに対して中間ドラフトをレビューします。その後、不足している部分の分析を実行します。単に「文脈不十分」とフラグを立てるだけでなく、ギャップを特定する具体的な理由とフィードバックログを記述します。
フェーズ 4「反復」では、Query Rewriter（クエリ再作成器）が欠落した用語に対する新しい検索を作成します。RAG エージェントはこれまでスキップしていたファイルに深入りし、必要なデータを見つけ出します。
フェーズ 5「合成」では、エージェントが文脈が完全であることを確認します。その後、Synthesis Agent（合成エージェント）が明確で正確な要約を記述します。
新しいアジェンティック RAG フレームワークをご紹介します。Google Cloud との共同開発により、本多エージェント・ワークフローは、複雑なエンタープライズクエリを分解し、信頼性の高い回答を生成する前に十分な文脈を見つけるために反復的に検索を行うことで、標準的な RAG を超えるものです。
image→https://t.co/A8l499bLrj pic.twitter.com/5fZT49j8TL
— Google Research (@GoogleResearch) 2026 年 6 月 5 日
ベンチマークケース
Google チームは、FRAMES 研究論文に基づいた FramesQA システム上でこのシステムを評価しました。FramesQA は 824 のクエリと 2,676 の PDF ドキュメントからなるコーパスで構成されています。
「Vanilla」ベースラインには Google の RAG エンジン（Retrieval-Augmented Generation Engine）が使用されました。このエンジンには、高度な検索エンジン、LLM パーサー、および再ランク化器が含まれています。
Agentic RAG は 2 つの環境で実行されました。単一コーパス環境では FramesQA のドキュメントのみから検索を行います。一方、クロスコーパス環境では 3 つの紛らわしいデータセットを追加し、Planner Agent がどこから検索すべきかを選択する必要があります。これは、データベースが別々のチームによって管理されている企業の状況を模倣したものです。
精度評価には、正解データ（ground truth）に対して LLM-as-a-judge を用いました。
クロスコーパス環境において、システムは単一コーパス時の精度にほぼ匹敵する結果を示しました。4 つのコーパスから正しいものを選択しながら、90.1% の質問に正答しています。両環境間のレイテンシ（応答遅延）は平均で 3% 以内でした。
CapabilityVanilla RAG (RAG Engine)Standard agentic RAGGoogle Cross-Corpus Agentic RAG
Retrieval styleSingle-step matchMulti-agent, single passMulti-agent, iterative
Multiple agentsNoYesYes
Sufficient Context AgentNoNoYes
Iterative re-searchNoNoYes
Cross-corpus routingNoNoYes (Planner picks from 4)
Reported accuracyBaselineNot reported here90.1% cross-corpus; up to 34% factuality gain vs standard RAG
LatencyNot reported hereNot reported hereWithin 3% single vs cross
Use cases
このフレームワークは、多段階かつ複数ソースにわたる企業業務に適しています。医療チームは、個別の記録から薬剤、食事、アレルギーデータを統合できます。エンジニアリングチームは、サーバー ID を別のデータベース内の仕様まで追跡可能です。財務およびプロジェクトチームは、予算データとタイムラインログを結合できます。このクロスコーパス設計は、異なるチームが所有するデータベースを持つ組織に特に適しています。
主なポイント
Google のアジェンティック RAG は、コンテキストが完全になるまで再検索を行う「十分な文脈エージェント」を追加しました。
これは、Gemini Enterprise Agent Platform において「クロスコーパス検索」として公開プレビュー版で提供されています。
報告された成果として、標準的な RAG と比較して事実性の精度が最大 34%向上しています。
クロスコーパスルーティングは、4 つのコーパスから選択しながら FramesQA の質問に対して 90.1% を正しく回答しました。
単一コーパス実行とクロスコーパス実行の間で、レイテンシは 3% 以内にとどまりました。
原文を表示
Google Research team has introduced a new agentic RAG framework. It is built into the Gemini Enterprise Agent Platform. It powers a feature called Cross-Corpus Retrieval, now in public preview.
The target is a known failure mode in enterprise search. Standard single-step RAG was not built for multi-source, multi-hop queries. Ask “What are the specs of the server used in Project X?” The system may find a document naming a server ID. It will not know to take that ID and search a second database for specs. The answer comes back partial, or as “not found.”
What is Google’s New Agentic RAG
Agentic RAG plans, reasons, and iteratively interacts with data sources. It handles complex queries to increase dependability and accuracy. Google’s version is the Gemini Enterprise Agent Platform-hosted Cross-Corpus Retrieval powered by Agentic RAG. Like other multi-agent RAG frameworks, it uses agents that work together. Unlike them, it adds a sufficient context check before generating a response. Compared to standard RAG, it increases accuracy on factuality datasets by up to 34%. Google’s research team also tested it on proprietary internal datasets. It reports better grounding and improved reasoning accuracy on domain-specific tasks.
How the multi-agent architecture works
Think of it as an organized research department, not one search engine. A “Vanilla” RAG system just matches your question to documents. An LLM then generates a response from those matches. The multi-agent framework splits the job into specialized roles.
The Orchestrator decides the request is not a one-step job and delegates. The Planner Agent maps the information pathways across data sources. The Query Rewriter turns a vague request into several precise search queries. The Search Fanout Agent sends those queries to various retrieval sources. Finally, an LLM aggregates the collected context into a response.
What makes this framework different
The key difference is persistence. The framework knows when it is missing information and keeps searching. This stops the model from guessing when the first search is empty. It also avoids a premature “I don’t have enough information.”
That persistence comes from the Sufficient Context Agent, a new component in Google’s framework. Consider a doctor asking for a patient’s discharge medications, dietary restrictions, and allergic reactions.
In Phase 1, Orchestration, the Root Agent parses the request and delegates. The Planner Agent targets Pharmacy, Nutrition, and Clinical Notes. The Query Rewriter breaks the long request into simple, searchable questions.
In Phase 2, Search, the RAG Agent runs all query fanouts at once. It finds medications and diet, but no allergy mention. A Vanilla RAG system might stop here with an incomplete answer.
In Phase 3, the Sufficient Context Agent inspects the result. It reads the retrieved snippets pulled from the database. It reviews an intermediate draft against the prompt and snippets. Then it runs a missing pieces analysis. It does not just flag “insufficient context.” It writes a specific Reason and Feedback log naming the gap.
In Phase 4, Iteration, the Query Rewriter creates a new search for the missing term. The RAG Agent digs into files it skipped and finds the data.
In Phase 5, Synthesis, the agent confirms context is complete. The Synthesis Agent then writes a clean, accurate summary.
Introducing our new agentic RAG framework. A collab with Google Cloud, our multi-agent workflow goes beyond standard RAG by breaking down complex enterprise queries & iteratively searching for sufficient context before generating dependable responses.
image→https://t.co/A8l499bLrj pic.twitter.com/5fZT49j8TL
— Google Research (@GoogleResearch) June 5, 2026
The benchmark case
Google team evaluated the system on FramesQA, which is based on the FRAMES research paper. FramesQA has 824 queries and a corpus of 2,676 PDF documents. The “Vanilla” baseline used Google’s RAG Engine. That engine includes an advanced retrieval engine, LLM parser, and re-ranker.
Agentic RAG ran in two settings. Single-corpus retrieves from the FramesQA documents only. Cross-corpus adds three distracting datasets, so the Planner Agent must choose where to retrieve. This mimics companies whose databases are managed by separate teams. Accuracy used an LLM-as-a-judge against ground truth answers.
In cross-corpus, the system nearly matched its single-corpus accuracy. It answered 90.1% of questions correctly while selecting the right corpus from four. Latency stayed within 3% on average between the two settings.
CapabilityVanilla RAG (RAG Engine)Standard agentic RAGGoogle Cross-Corpus Agentic RAG
Retrieval styleSingle-step matchMulti-agent, single passMulti-agent, iterative
Multiple agentsNoYesYes
Sufficient Context AgentNoNoYes
Iterative re-searchNoNoYes
Cross-corpus routingNoNoYes (Planner picks from 4)
Reported accuracyBaselineNot reported here90.1% cross-corpus; up to 34% factuality gain vs standard RAG
LatencyNot reported hereNot reported hereWithin 3% single vs cross
Use cases
The framework fits multi-hop, multi-source enterprise work. Healthcare teams can compile medications, diet, and allergy data from separate records. Engineering teams can trace a server ID to specs in another database. Finance and project teams can join budget data with timeline logs. The cross-corpus design suits organizations with databases owned by different teams.
Key Takeaways
Google’s agentic RAG adds a Sufficient Context Agent that re-searches until context is complete.
It ships as Cross-Corpus Retrieval in Gemini Enterprise Agent Platform, in public preview.
Reported gain is up to 34% higher factuality accuracy versus standard RAG.
Cross-corpus routing answered 90.1% of FramesQA questions while picking from four corpora.
Latency stayed within 3% between single-corpus and cross-corpus runs.
Check out the Technical details. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us
The post Google Research Adds Agentic RAG to Gemini Enterprise Agent Platform with a Sufficient Context Agent for multi-hop queries appeared first on MarkTechPost.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み