Unlocking Dependable Responses with Gemini Enterprise Agent Platform’s Agentic RAG
來源： Google Research Blog（google-research-blog） 日期： 2026-06-05 作者： Bo Li, Zhongjie Mao, Tiger Jin, Yuhong Kan, Mohd Abdullah (Obito), Chun-Sung Ferng, Pooneh Mortazavi, Roger (Peng) Yu, Eran Lewis, Ivan Kuznetsov
背景
傳統的單步 RAG（檢索增強生成）無法處理現代企業的多來源、多跳查詢。例如查詢「Project X 所用的伺服器規格是什麼？」— 系統可能找到 Project X 的文件，但文件只提到了伺服器 ID，無法進一步查詢另一個資料庫來取得規格。因此回傳部分答案或「找不到」的回應。
Agentic RAG 架構
多代理 RAG 將系統拆分為專門角色：
| 角色 | 功能 |
|---|---|
| Orchestrator | 評估複雜請求，拆分任務給各代理 |
| Planner Agent | 規劃資訊路徑（先查哪個資料庫，再查哪個） |
| Query Rewriter | 將原始查詢轉換為多個精確搜索查詢 |
| Search Fanout Agent | 將查詢發送至不同檢索來源 |
| RAG Agent | 執行實際檢索 |
| Sufficient Context Agent | 檢查上下文完整性，產生缺失分析與迭代指令（核心創新） |
| Synthesis Agent | 整合所有資訊，產出最終答案 |
核心創新：Sufficient Context Agent
與其他多代理 RAG 框架的關鍵差異在於 持續性（persistence） — 系統知道何時資訊不足，並持續搜索直到上下文完整。
三個檢查面向：
- Retrieved snippets — 評估實際從資料庫檢索到的文字片段
- Intermediate draft — 檢視草稿回應，比對提示詞與檢索片段
- Missing pieces analysis — 生成具體的 Reason 與 Feedback 日誌，指出「缺少什麼」並指引下一次搜索方向
五階段流程
Phase 1: Orchestration
Root Agent 解析請求（如醫師查詢病人用藥、飲食限制與過敏記錄），委派任務給子代理。Planner Agent 識別需要查詢三個領域（Pharmacy、Nutrition、Clinical Notes）。
Phase 2: Search
RAG Agent 同時搜索所有查詢。找到用藥與飲食資訊，但未找到過敏記錄。
Phase 3: Sufficient Context Check
Sufficient Context Agent 指出：
- Found: 用藥清單、低鈉飲食指示
- Gap: 缺少過敏反應或不良事件記錄
Phase 4: Iteration
Query Rewriter 產生新的搜索查詢（如「rashes」、「adverse events」），RAG Agent 深入搜索原本忽略的文件。
Phase 5: Synthesis
資訊補齊後，Synthesis Agent 產出完整回答。
實驗結果
- 數據集：FramesQA（824 條查詢，2,676 份 PDF 文件）
- 跨語料庫設定（4 個干擾資料集）：90.1% 準確率
- 與標準 RAG 比較：準確率提升最高 34%
- 延遲差異：單一語料庫 vs 跨語料庫差異 < 3%
結論
透過結合進階查詢規劃、路由與充分上下文檢查，確保 AI 生成回應的可審計性、可追溯性與可引用性（auditable, traceable, and grounded）。此功能以公開預覽形式提供於 Gemini Enterprise Agent Platform。
包含的關鍵概念
- agentic-rag-cross-corpus — Agentic RAG 與跨語料庫檢索概念詳解
- google-research-blog — Google Research Blog 來源頁面