# Google 发布 Agentic RAG："质检 Agent"让系统知道没搜全，准确率提升 34%

- 来源：小互 (@xiaohu)
- 发布时间：2026-06-08 15:33
- AIHOT 分数：57
- AIHOT 链接：https://aihot.virxact.com/items/cmq4wco2q02amslt28bxxwvel
- 原文链接：https://x.com/xiaohu/status/2063887105508385205

## AI 摘要

Google 发布 Agentic RAG 框架，核心新增 Sufficient Context Agent，负责在生成答案前检查检索材料是否充分，若不充分则生成缺失分析并引导系统迭代搜索。在 FramesQA 多跳测试中准确率最高提升 34%，从 4 个数据库检索时正确率达 90.1%，速度仅慢 3% 以内。该设计基于前作发现：Gemini 1.5 Pro 判断“上下文充分性”准确率达 93%，且“相关≠够用”是幻觉关键原因。目前以公开预览在 Gemini Enterprise Agent Platform 开放。

## 正文

http://x.com/i/article/2063870567355400192

# Google 发布 Agentic RAG ：搜不全就接着搜的"质检 Agent" 准确率提升 34%

Agentic RAG 跨库检索 是 Google 给企业问答场景做的一套检索框架，靠多个 AI Agent 分工协作：让系统自己判断"搜到的资料够不够回答这个问题"，不够就带着线索回去接着搜，凑齐了再开口。

- 它针对一个老毛病：传统 RAG 搜一轮就回答，可信息往往分散在不同数据库里，结果要么给半截答案，要么干脆甩一句"没找到"。

- 真正的新东西是一个叫 Sufficient Context Agent 的"质检员"，专门检查信息够不够、到底缺哪一块，再让系统带着具体反馈回去补搜。

- 在 FramesQA 多跳问答测试里，准确率比传统 RAG 最高提升 34%；要从 4 个数据库里挑对地方检索时，仍能答对 90.1%，而且速度几乎没变慢（平均差距 3% 以内）。

一位医生在系统里输入：John Doe 做完膝盖手术，出院后用什么药、有什么饮食限制、住院期间有没有出现过敏反应？

系统转一圈回来：用药列在这里，低钠饮食列在这里。至于过敏，没找到。

麻烦就在这。过敏记录其实在档案里，只是没躺在最显眼的那几份文件里。系统第一遍没翻到，就当它不存在，干脆利落交了一份缺了一块的答案。对医生来说，"没查到过敏"和"没有过敏"是两回事，差这一点可能就是一次用药事故。

我们现在多少都在用"能查资料的 AI 助手"，也多半都遇过这种半个答案：问它一个稍微绕点的问题，它信心十足回你一段，看着挺像样，仔细一对，漏了关键一块，或者干脆编了一块。

Google Research 和 Google Cloud 在六月初联合发布了一套新框架，专门治这个毛病，名字叫智能体检索增强生成（Agentic RAG），目前在 Gemini Enterprise Agent Platform 上以公开预览（public preview）开放。它真正的新东西不是"搜得更强"，而是一个听起来很朴素的能力：让系统知道自己没找全。

## 先说清楚：RAG 是什么，为什么它会一本正经地胡说

大语言模型（Gemini、GPT、Claude）有个天生缺陷：知识是训练时"背"下来的，背完就定格了。你问它公司昨天的财报、病人上周的检查结果，它压根不知道。

检索增强生成（RAG）就是给模型外挂一个能随时翻阅的资料库。 你提问时，系统先去库里搜出相关片段，连同问题一起塞给模型，让它"看着资料回答"。企业查内部文档、客服查产品手册、医院查病例，全靠这套机制。

问题出在一个魔鬼细节上：模型答得好不好，全看塞给它的资料够不够。 资料齐全，它头头是道；资料缺了一块，它不会停下来说"我手上的材料不够"，而是拿着残缺资料继续编，把缺的那块用想象补上。这就是"幻觉"。更要命的一点后面会讲到：喂资料有时反而让它编得更凶。

传统的 RAG 是"一步到位"式的：看一眼问题，去库里捞一把相关文档，丢给模型，完事。应付简单问题没问题，但企业里的问题往往一步查不完。

Google 博客里的例子：你问"Project X 用的服务器是什么配置？"系统找到了 Project X 的文档，可里头只写了一个服务器编号（ID），真正的配置参数存在另一个数据库，得拿这个 ID 再去那边查一次。传统 RAG 不做这第二步--它捞到文档发现没配置，就给你"半个答案"或一句"没找到"，不知道手里那个 ID 是把钥匙，更不知道还有另一扇门要开。信息散落在一座座彼此不通的"数据孤岛"上，传统 RAG 只在第一座岛上找。

## 把多智能体系统想成一个有分工的研究部门

Google 这套框架的第一层改造，是不再让一个"搜索引擎"单打独斗，而是组一支有分工的研究团队。

传统 RAG 像个实习生：给他一个问题，他跑去档案室抓一把看着相关的文件就回来了。而这套多智能体（multi-agent）框架更像一个真正的研究部门，里面好几个角色各司其职：

- 编排者（Orchestrator）：部门主管。看一眼问题先做个判断"这不是一步能干完的活"，然后把任务拆开、分派下去。

- 规划智能体（Planner）：制定路线的人。你问一个项目的预算和进度，他会规划"先查财务库，再查项目管理日志"，哪个信息在哪儿、按什么顺序取，由他安排。

- 查询改写智能体（Query Rewriter）：翻译官。把含糊的话改成精确搜索词--你随口一句"Project X 怎么样了"，他拆成"Project X 第三季度状态报告"和"团队的关键阻塞"，机器照这种精确的词去搜，命中率高得多。

- 搜索扇出智能体（Search Fanout）：同时跑腿的人。把改写好的多条查询一次性并行发给多个资料源，把片段都收集回来。

- 综合智能体（Synthesis）：最后执笔的人。材料齐了，由他把所有片段整合成一份干净、准确的答案。

到这一步你可能觉得，多请几个人分工干活，也只是把传统 RAG 做得精细了点，市面上别家的"多智能体 RAG"也是这个路数。

Google 这套真正不一样的地方，是下面这个。

## 核心创新：一个站在流水线尽头的"质检员"

这个新角色叫充分上下文智能体（Sufficient Context Agent），是这套框架和别家最不一样的地方。

最直白的比喻：它是站在流水线尽头的质检员。 别的环节都在埋头搜资料、攒材料，只有它专管一件事：在答案生成之前，检查手里这堆材料到底够不够回答问题。

它和其他多智能体 RAG 的根本区别，Google 用一个词概括：持续性（persistence）--发现信息不够时，它会让系统回去接着搜，直到材料凑齐为止，而不是两种偷懒做法二选一：要么第一次没搜到就硬着头皮瞎编，要么干脆甩一句"我没有足够的信息"。

后面这句看着挺诚实，其实常常是另一种失职：信息明明就在库里，只是第一遍没翻到。该接着找的时候放弃，和该停的时候硬编，是同一个病的两种症状--系统不知道自己手里到底缺什么。

这位质检员具体查三件事：

第一，检查捞回来的资料片段。 它去读搜索智能体从库里实际拉出来的文本块，比如医生那例子里"出院小结"和"营养记录"的具体段落，一句句读，判断回答这个问题需要的信息到底在不在这些句子里。

第二，对照一份"粗稿"。 系统先用现有材料生成一份草稿答案，质检员把三样东西摆一起看：原始问题、这份粗稿、捞回来的资料片段。问题问了三件事（用药、饮食、过敏），材料里只有两件，它立刻标记"上下文不充分"。

第三，也是最关键的：缺失分析。 质检员不会只甩一句"材料不够"就完事，那等于没说。它会生成具体的原因和反馈，精确指出缺的是哪一块、回去该搜什么。还是医生那例子，它发现过敏记录缺失后，输出不是"信息不全"，而是这样一段：

> 已有的：用药清单和低钠饮食说明。
缺的：源文件里关于住院期间过敏反应或不良事件的信息。
怎么办：回去专门搜"皮疹"或"不良事件"。

有了这条精确反馈，查询改写智能体立刻据此造一条新搜索，搜索智能体回头深挖第一遍忽略掉的那些文件，这次找到了过敏记录。质检员再核一遍，确认用药、饮食、过敏三样齐了，才放行。

整个流程一共五个阶段：编排 → 搜索 → 充分上下文检查 → 迭代 → 综合。前两步别家也有，真正让它和"瞎猜"或"放弃"分道扬镳的，是中间那个会反复较真的质检员。

## 整套思路的起点：相关，不等于够用

这套思路背后，藏着一个非常出人意料、也非常容易被忽略的判断，它来自 Google 一年前的一篇前作研究。这才是整件事真正的思想源头。

过去人们衡量"搜来的资料好不好"，几乎只看一个指标：相不相关。资料跟问题沾边，就算搜得不错。但 Google 这帮研究者说，相关是个错的尺子，真正该问的是另一个问题：这些资料够不够回答问题？

相关，和够用，是两码事。

看一个例子就懂

问题是：404 报错（网页打不开时常见的"页面未找到"）这个编号，据说是以某个实验室里编号为 404 的房间命名的，那个存放着错误信息中央数据库的房间，在哪个著名实验室里？

来看两段都"相关"的资料：

第一段： 404 报错得名于 CERN（欧洲核子研究中心）的 404 号房间，那房间当年存放着错误信息的中央数据库。

第二段： 404 报错表示网页服务器找不到你请求的页面，原因可能有很多：网址打错了、页面被移动或删除了，或者网站临时出了点问题。

你看，第二段和这个问题极其相关，确实在讲 404 是什么，任何一个只看"相不相关"的系统都会觉得它是个好结果。但它回答不了那个问题：404 房间到底在哪个实验室？答案（CERN）压根不在这段话里。

这就是"相关但不够用"。系统失败，往往不是因为搜来的东西不相关，而是它把"相关"当成了"够用"，拿着一堆沾边但答不了题的资料，就大模大样地开始编答案了。

那篇前作还证明了一件挺关键的事：判断"上下文充不充分"，机器是能做到的，而且做得相当准。 他们造了个自动评分器（autorater），专门给"问题-资料"这一对打分，准确率至少有 93%。最有意思的是，效果最好的不是什么专门训练过的模型，而是直接拿 Gemini 1.5 Pro 写个提示词去问，连微调都不用。也就是说，"判断自己缺没缺信息"这件事，现成的大模型本来就会，只是过去没人专门让它去做。

## 最让人意料之外的发现：喂资料反而让它编得更凶

还挖出两个让人意外的发现，直接解释了 RAG 为什么这么不靠谱。

第一个：顶级大模型普遍"不会认怂"： 拿 Gemini、GPT、Claude 这几个最强的模型做测试，结论很一致：它们资料充足时答得非常好，却普遍缺乏"识别资料不够"的能力。该弃权时不弃权，材料明明残缺，照样信心满满给你一个答案。会答题，但不会说"我不知道"。

第二个，是全文最出人意料的数字：直觉上，多喂点资料总该答得更准，研究者发现恰恰相反：喂了不充分的资料，模型反而更容易胡说。 一个叫 Gemma 的模型，在完全不给资料时答错率是 10.2%，可一旦喂给它不充分的资料，答错率直接飙到 66.1%--翻了六倍多。

为什么？

研究者的解释是：额外的资料抬高了模型的"自信"。 它面前摆着一堆看起来相关的材料，于是更倾向于相信"我手上有料，能答"，更愿意去编一个答案，而不是老老实实承认"我不知道"。资料越多，它越敢编。

两个发现合在一起，把问题的本质点透了：RAG 不靠谱，真正的病根不是"搜得不够强"，而是系统不知道自己没找全。 它分不清"相关"和"够用"，又天生不会认怂，手里材料一残缺，第一反应不是回去补，而是自信地往下编。

## 实验：在 824 道刁钻题上，准确率最高提了 34%

光讲道理不够，看 Google 自己跑出来的数据。

他们用了一个叫 FramesQA 的评测集，专门挑那种"一步答不出来"的多跳问题，一共 824 道题，配一个装着 2676 份 PDF 文档的资料库。

题有多刁钻？看一道样例：

> 截至 2024 年 6 月，收视率最高的两个电视剧大结局里，哪一个时长更长，长多少？

人来答这道题得分三步：先认出"收视最高的两个大结局"是哪两部剧（《陆军野战医院》和《干杯酒吧》），再分别查到它们的时长，最后算差值。任何一步断了，整道题就废了。传统 RAG 碰上这种题常卡在中间，给一句"反复检索后，我没找到明确时长"。而 Google 这套靠着查询改写和那位质检员，会先搜出是哪两部剧，再发起一次专门针对时长的精确搜索，最后由 Gemini 算出"前者大结局 150 分钟，是两者中更长的，比后者长 52 分钟"。这就是"持续性"的价值：第一遍没查到不是终点，而是再搜一轮的起点。

放大到 824 道题的规模上，对比标准 RAG，这套框架在事实性数据集上的准确率最高提升了 34%。这里的"标准 RAG"不是个软柿子：它用的是 Google 自家的 Vertex AI RAG Engine，本身就带了高级检索、大模型解析和重排序。能在这么强的底子上再提 34%，说明这提升是充分性检查加反复补搜实打实挣来的，不是靠垫高弱对手刷出来的。

还有一个更能说明问题的设置：跨库检索。研究者故意往资料库里额外混进 3 个不相干的"干扰数据集"，逼着规划智能体必须先判断"这道题该去哪个库取料"，模拟的是真实企业里不同数据库分属不同团队、散落各处的常见局面。结果是：即便要从 4 个库里选对那一个，系统仍然答对了 90.1%，几乎追平了只在单一库里检索的成绩--多了一道"找对库"的难关，准确率几乎没掉。

## 另一面：有点贵，还有点慢

智能体 RAG 更准，是因为派了一支团队反复搜、反复查、反复迭代。

每多一个智能体、每多一轮迭代，都是实打实的算力和时间。综合行业经验，相比传统 RAG，它通常要多烧 3 到 10 倍的 token、延迟增加 2 到 5 倍。按每天 1 万次查询估算：

传统 RAG，每日成本约 $500，单次响应时间 1 - 2 秒智能体 RAG，每日成本约$1500 - $5000，单次响应时间，8 - 12 秒。

8 - 12 秒，对一个等答案的人已经到了怀疑系统是不是卡死的临界点；成本翻几倍，放到日查询百万次的业务上，就是按月几十万美元的差距。

这里有个数字特别要小心。Google 强调：跨库版本比单库版本，延迟只多 3%。听起来很漂亮，多查好几个库几乎不拖慢速度。

但这个 3% 是障眼法。它比的是「智能体 RAG 跑单库」和「智能体 RAG 跑跨库」，两边都是智能体 RAG，只是配置不同，差距当然小。真正该问的是另一件事：智能体 RAG 比传统 RAG 慢多少？答案就在上面那张表里，1-2 秒变成 8-12 秒，慢了好几倍。Google 用一个 3% 的小数字，把「比传统方案慢好几倍」这个大事实轻轻绕了过去。

另外，那些准确率数字（34%、90.1%）也是 Google 用自家「大模型当裁判」（LLM-as-a-judge）评出来的，是公开预览阶段的产品口径，不是中立第三方复现的结果，看的时候自己打个折。

## 谁能用、怎么用、还差什么

这个功能现在是 Gemini Enterprise Agent Platform 上的公开预览。Gemini Enterprise Agent Platform 是 Google 今年 4 月 22 日在 Cloud Next '26 上推出的平台，本质是 Vertex AI 的升级换代版，主打企业级 AI Agent 的搭建、治理和扩展。入口在 RAG Engine 的 Cross Corpus Retrieval（跨库检索）文档里。

值得用的场景：

- 多跳问题：答案散在多个数据源里，要查好几步、再做推理才能拼出来；

- 模糊查询：用户问得含糊，需要先改写、再澄清才知道到底在问什么；

- 高风险领域：法律、医疗、金融，答错的代价极高，慢一点、贵一点完全能接受，换来的是少出一次致命错误。

医生查病例那个开场例子，正落在这一类里：宁可多花八秒、多烧几倍 token，也不能漏掉一条过敏记录。

不值得用的场景：

- FAQ 机器人、单一事实查询：答案就在某一个自包含的资料块里，一步就能捞到；

- 速度或成本敏感的场景：用户等不起十秒，或者预算扛不住翻几倍，这时候传统 RAG 更快、更便宜，也更实际。

拿一支研究团队去回答一句 FAQ，是杀鸡用牛刀。

原文：https://research.google/blog/unlocking-dependable-responses-with-gemini-enterprise-agent-platforms-agentic-rag/