Google 发布 Agentic RAG：“质检 Agent”让系统知道没搜全，准确率提升 34% · AI HOT
‹ 返回
小互 @xiaohu 57
2026-06-08 15:33 ·9天前
AI 摘要 Google 发布 Agentic RAG 框架，核心新增 Sufficient Context Agent，负责在生成答案前检查检索材料是否充分，若不充分则生成缺失分析并引导系统迭代搜索。在 FramesQA 多跳测试中准确率最高提升 34%，从 4 个数据库检索时正确率达 90.1%，速度仅慢 3% 以内。该设计基于前作发现：Gemini 1.5 Pro 判断“上下文充分性”准确率达 93%，且“相关≠够用”是幻觉关键原因。目前以公开预览在 Gemini Enterprise Agent Platform 开放。
智能体 Google 检索增强 产品更新
← 返回
小互 @xiaohu · X 57
2026-06-08 15:33 · 9天前
AI 摘要 Google 发布 Agentic RAG 框架，核心新增 Sufficient Context Agent，负责在生成答案前检查检索材料是否充分，若不充分则生成缺失分析并引导系统迭代搜索。在 FramesQA 多跳测试中准确率最高提升 34%，从 4 个数据库检索时正确率达 90.1%，速度仅慢 3% 以内。该设计基于前作发现：Gemini 1.5 Pro 判断“上下文充分性”准确率达 93%，且“相关≠够用”是幻觉关键原因。目前以公开预览在 Gemini Enterprise Agent Platform 开放。
传统 RAG 像个实习生：给他一个问题，他跑去档案室抓一把看着相关的文件就回来了。而这套多智能体（multi-agent）框架更像一个真正的研究部门，里面好几个角色各司其职：
- 编排者（Orchestrator）：部门主管。看一眼问题先做个判断"这不是一步能干完的活"，然后把任务拆开、分派下去。
- 规划智能体（Planner）：制定路线的人。你问一个项目的预算和进度，他会规划"先查财务库，再查项目管理日志"，哪个信息在哪儿、按什么顺序取，由他安排。
- 查询改写智能体（Query Rewriter）：翻译官。把含糊的话改成精确搜索词--你随口一句"Project X 怎么样了"，他拆成"Project X 第三季度状态报告"和"团队的关键阻塞"，机器照这种精确的词去搜，命中率高得多。
- 搜索扇出智能体（Search Fanout）：同时跑腿的人。把改写好的多条查询一次性并行发给多个资料源，把片段都收集回来。
- 综合智能体（Synthesis）：最后执笔的人。材料齐了，由他把所有片段整合成一份干净、准确的答案。
到这一步你可能觉得，多请几个人分工干活，也只是把传统 RAG 做得精细了点，市面上别家的"多智能体 RAG"也是这个路数。
这个新角色叫充分上下文智能体（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 更快、更便宜，也更实际。
原文：https：//research.google/blog/unlocking-dependable-responses-with-gemini-enterprise-agent-platforms-agentic-rag/
小互@xiaohu · X