深度解读 · Google Research Blog · 2026-06-05

Google Agentic RAG：不再"差不多"的企业级 RAG

当 RAG 学会说"我不确定，让我再查查"——深度拆解 Google 的 Sufficient Context Agent 如何把检索准确率提升 34%

+34%相比 Vanilla RAG 准确率提升
90.1%Cross-Corpus（4 数据源）准确率
~3%单库 vs 跨库延迟差异
93%+上下文充分性分类准确率

为什么 Vanilla RAG 不够用了

传统 RAG 的致命缺陷不是"检索不到"，而是检索到了但不自知还缺什么

传统 RAG（Retrieval-Augmented Generation）的工作方式很直接：用户提问 → 检索文档 → LLM 生成回答。一条流水线，一次机会。

这在简单问答场景（"公司的退货政策是什么？"）没问题。但企业现实中的查询往往是多源、多跳的：

例子："Project X 用的那台服务器配置是什么？"

→ 文档 A 提到 Project X 和一个 Server ID
→ 但 Server ID 对应的配置在数据库 B 里
→ Vanilla RAG 找到 A 就停了，回答"没找到"或编一个

这就是 "信息孤岛" 问题——信息分散在不同数据源，单步检索根本串不起来。

核心矛盾：Vanilla RAG 的致命缺陷不是"检索不到"，而是检索到了但不自知还缺什么。它没有"自知之明"——不知道自己不知道什么。

Google Agentic RAG 架构拆解

Google 的方案用一个词概括：持久性（Persistence）。系统知道自己缺少什么，会反复搜索直到信息充分

五阶段流水线

Phase 1

Orchestration

Root Agent 解析用户请求，分解为子任务

Phase 2

Search

RAG Agent 并行检索多个数据源

Phase 3

Sufficient Context

核心创新——充分性检查，判断信息是否足够

Phase 4

Iteration

针对缺失信息，Query Rewriter 生成新搜索 query 补检索

Phase 5

Synthesis

所有上下文充分后，整合生成最终回答

多 Agent 角色分工

Agent角色类比
Root Agent解析请求，委派任务项目总监
Planner Agent规划信息路径，决定查哪些数据源调研策略师
Query Rewriter将复杂请求拆成多个精确搜索 query搜索优化师
Search Fanout Agent并行发送检索请求到多个数据源一线调研员
Sufficient Context Agent检查检索结果是否充分（核心创新）质检官
Synthesis Agent整合所有上下文生成最终回答报告撰写师

核心创新：Sufficient Context Agent

这是整个架构的灵魂。它不是一个简单的"有/没有"判断，而是一个三重质量检查：

检查 1

Retrieved Snippets 评估

直接检查检索到的文本片段是否包含回答所需的信息

检查 2

Intermediate Draft 审查

先让模型生成草稿，然后检查草稿是否完整回答了所有子问题

检查 3

Missing Pieces 分析

精确输出缺失内容和补救建议："你找到了药物和饮食信息，但缺失过敏记录。回去搜索'皮疹'或'不良反应'。"

这个机制的背后是一篇 ICLR 2025 论文 "Sufficient Context: A New Lens on RAG Systems"。关键发现：

实战案例：医疗场景

文章给了一个极其复杂的医疗查询：

查询："John Doe 膝盖手术后的出院药物、饮食限制、住院期间有无过敏反应？不要包括住院/急诊期间用的药（肝素 IV 滴注和 Tenecteplase 除外）。"

Vanilla RAG 的做法

  • 搜索一次 → 找到药物 + 饮食
  • 过敏信息不在最明显的文档里
  • 模型猜测或回答"信息不足"
  • 结果：不完整或错误

Agentic RAG 的做法

  • 搜索一次 → 找到药物 + 饮食
  • Sufficient Context Agent 检测到"过敏信息缺失"
  • 反馈 → Query Rewriter 新搜索"皮疹/不良反应"
  • 二次检索 → 找到过敏记录
  • 再次充分性检查 → 通过 → 生成最终回答

硬核数据：FramesQA Benchmark

824 个查询 + 2,676 篇 PDF 文档，基于 FRAMES 论文的多跳推理 benchmark

最关键的发现

Cross-corpus 准确率几乎和 Single-corpus 持平

Cross-corpus（跨 4 个数据源）的准确率几乎和 Single-corpus（单数据源）持平。这意味着 Planner Agent 在 4 个选项中正确路由搜索的能力极强，且额外延迟仅 ~3%。

这对企业场景意义重大：不同团队管理不同数据库，Agentic RAG 能自动定位正确的数据源。

一个经典多跳问题示例：

问题："收视率最高的两部电视剧最终集（截至 2024.6），哪个更长，长多少？"

需要的推理步骤：

1. 识别收视率 Top 2 → M*A*S*H 和 Cheers
2. 查找各自最终集时长
3. 计算差值

Vanilla RAG："尽管多次扫描，未找到 M*A*S*H 或 Cheers 的明确时长信息。"

Agentic RAG："M*A*S*H 最终集 150 分钟，比 Cheers 的 98 分钟长 52 分钟。"

竞品对比：Agentic RAG 江湖 2026

Google 的 Agentic RAG 不是唯一玩家，2026 年 Agentic 框架生态已经非常拥挤

框架核心定位月下载量与 Google Agentic RAG 对比
LangGraph 有状态多 Agent 工作流 7.1M 通用编排框架，需自建充分性检查逻辑
CrewAI 角色扮演多 Agent 快速原型 14 亿自动化任务 快速但不具备持久检索循环
Microsoft Agent Framework AutoGen + Semantic Kernel 合并 Azure 原生 企业安全特性强（PII 检测、Prompt Shield），RAG 专精度不如 Google
LlamaIndex RAG + 数据索引 — 检索索引生态最丰富，但多 Agent 协作弱
Google ADK 开源多 Agent 开发套件 — 底层框架，Agentic RAG 是其上的垂直解决方案
Claude Agent SDK 自主工具调用 Agent — 通用 Agent 而非 RAG 专精，沙箱执行能力强
差异化护城河

Sufficient Context Agent 是独门武器

Sufficient Context Agent 是独门武器。其他框架（LangGraph、CrewAI）提供了编排能力，但没有内建的"上下文充分性检查"概念。Google 把 ICLR 2025 的学术成果直接产品化了。

另一个护城河：Cross-Corpus Retrieval——跨多个无关数据源的智能路由，这是企业真实痛点，其他方案大多只处理单源场景。

设计哲学：为什么"不猜"比"答对"更重要

这个系统的设计哲学值得所有 RAG 从业者思考

原则 1

诚实 > 自信

传统 LLM 倾向于"有话要说"，即使信息不足也会编一个。Agentic RAG 反过来——宁可多搜一轮，也不在信息不足时给出答案。

原则 2

从"相关性"到"充分性"

传统 RAG 评估检索质量看 relevance（相关性）。Google 引入 sufficiency（充分性）——返回的文档足以回答问题吗？相关性不等于充分性。

原则 3

选择性生成

结合"上下文充分性信号"和"模型自信度"，训练逻辑回归来决定是否应该拒绝回答。某些场景下能将准确率提升 10%。

相关性 ≠ 充分性。一个关于 404 错误码的文档可能高度相关，但如果它不提"Room 404 at CERN"，就无法回答"404 错误码以哪个实验室的房间命名？"

局限与批判思考

不是银弹——延迟、成本、评估基准和生态锁定都是现实问题

延迟成本

多轮检索循环的响应时间

多轮检索循环意味着更长的响应时间。文章没给出绝对延迟数据，只说 cross-corpus 和 single-corpus 差异 ~3%。但对于实时对话场景，这可能不可接受。

成本爆炸

每个查询 5-10 次 LLM 调用

每个 Phase 都有 LLM 调用（Planner + Rewriter + RAG Agent + Sufficient Context Agent + Synthesis），一个查询可能消耗 5-10 次 LLM 调用。

评估基准局限

FramesQA 的 824 个查询够吗？

FramesQA 的 824 个查询是否足够代表企业场景？Multi-hop QA 和企业文档检索的难度分布差异很大。

生态锁定

GCP 深度绑定

这个方案运行在 Gemini Enterprise Agent Platform 上，深度绑定 Google Cloud 生态。公开数据也有限——文章提到"内部数据集也有提升"但没有给出具体数字。

对从业者的影响

角色影响建议
RAG 工程师 Sufficient Context 概念可独立使用 即使不用 Google 平台，也能在自己的 RAG pipeline 中加入充分性检查
架构师 Cross-Corpus Routing 是企业级刚需 重新评估"单一知识库"假设，多数企业数据天然是多源分布
产品经理 "不回答"比"回答错"的用户体验更好 在产品设计中明确"信息不足"的处理策略，而非追求 100% 回答率
研究者 FRAMES + Sufficient Context 是新的研究范式 关注"充分性"而非"相关性"作为检索质量指标

Vanilla RAG 就像一个只看第一页搜索结果就写报告的人；Agentic RAG 像一个知道"我还需要再查查"的靠谱研究员。

Vanilla RAG writes a report after scanning the first page of results. Agentic RAG is the researcher who says "let me dig deeper before I commit to an answer."