这篇文章要聊的是谷歌新推出的一套 agentic RAG智能体检索增强生成框架。它由 Google Research 和 Google Cloud 联手打造核心思路是先把复杂的企业级问题拆开然后一遍遍地去找上下文确认信息够了再动手生成答案。说白了就是让模型别急着回答先把上下文功课做扎实。老一套的 RAG为啥不够用了笔者先把问题摆出来。现在主流的那种一步到位的 RAG 系统压根就不是为今天这种跨多个数据源、要绕好几道弯的查询设计的。举个例子。假设有人问X 项目用的那台服务器具体参数是什么“系统大概能翻到一堆跟 X 项目相关的文档但这些文档里可能只写了个服务器编号。它不知道下一步该拿着这个编号再去另一个数据库里查一遍才能找到真正的参数。结果呢要么给个残缺的答案要么干脆甩一句没找到”。问题就出在这儿——信息散落在一个个彼此孤立的数据孤岛上得一层层往里挖才能把事实凑齐。而老一套的 RAG 没这个本事。于是就有了 agentic RAG。它会规划、会推理还会反复地跟各个数据源打交道专门对付这种复杂查询让回答更可靠、更准确。这次谷歌正式拿出来的是托管在 Gemini 企业级智能体平台上的**跨语料库检索Cross-Corpus Retrieval**功能背后跑的就是 agentic RAG。和市面上其他的多智能体 RAG 框架一样它也是靠一群分工明确的智能体协同作战来回答难题。但不一样的地方在于谷歌这套引入了一个叫充分上下文sufficient context的机制专门用来判断手头的信息到底够不够给出一个准确的答案。效果上跟标准 RAG 比这套框架在事实性数据集上的准确率最高能提升 34%。谷歌还拿自家内部的私有数据集做了测试结果是在多个特定领域的任务里模型的接地气程度grounding和推理准确率都更好了。多智能体架构是怎么干活的规划、改写、路由理解多智能体 RAG最好别把它当成一个搜索引擎而是当成一个组织有序的研究部门。老式的单体 RAG也有人叫它 “Vanilla RAG”也就是最朴素的那种干活很直白检索模块看一眼你的问题找出匹配的文档然后交给大模型生成回答完事。而在多智能体框架里这活儿被拆成了好几个专门的角色各司其职。最前面坐镇的是编排器Orchestrator它先掂量一下你的问题判断出这事儿一步搞不定然后把任务分派下去。接着是规划智能体Planner Agent负责画出信息的获取路线图——比如你同时问了某个项目的预算和时间线它就会盘算“得先查财务数据库再去翻项目管理日志。”然后轮到**查询改写器Query Rewriter登场它把你那句口语化的提问翻译成几条更精准的检索语句。比如X 项目最近咋样了“这种含糊的话会被改写成X 项目 Q3 状态报告和X 项目团队的主要阻碍”。改写完并行搜索智能体Search Fanout Agent**接手把这几条提炼过的查询分发到各个检索源去捞信息片段。最后大模型把所有上下文汇总到一起吐出最终答案。“注原文这里配有一段演示视频展示的是一套标准的 agentic RAG 系统。它虽然用了多个智能体但没有迭代检索的能力也不支持专门的跨语料库检索。谷歌这套和别家的到底差在哪关键就两个字坚持。跟其他 RAG 方案比谷歌这套的厉害之处在于——它知道自己什么时候信息不够然后会接着找一直找到上下文凑齐为止。这就避免了两种尴尬情况一种是第一次没搜到模型就开始瞎猜另一种是动不动就摆烂回一句我信息不够。当然有时候确实是真没有那这么回答没毛病。但很多时候信息明明就在那儿只是还没被翻出来而已。笔者拿一个医疗场景来说明。设想一位医生在问诊系统里这么问““John Doe 做完膝盖手术后的出院用药和饮食禁忌分别是什么他住院期间有没有出现过过敏反应注意只在住院或急诊期间临时用的药就别列了——但肝素静脉滴注和替奈普酶这两种除外。”这问题够刁钻吧。面对这种提问谷歌的框架会一口气派出好几个专门的智能体来处理。下面笔者先给个整体流程图再一步步拆开讲。“上图包含了一个充分上下文智能体并且能在回答问题之前反复迭代、检索更多信息。第一阶段编排根智能体Root Agent先把医生这段话拆解开分派给下面的子智能体。规划智能体一看发现要查的其实是三块互不相干的领域药房用药、营养科饮食、临床记录过敏史。查询改写器则把这一长串问题切成一个个简单、好搜的小问题这样检索器才能更精准地找到对应内容。第二阶段检索这是标准动作RAG 智能体把改写后的那一批查询同时丢进患者档案里搜。它顺利找到了用药信息和饮食信息但在那些最显眼的文件里怎么都翻不到过敏的记录。要是换成普通的朴素 RAG 系统故事到这儿可能就结束了——交一个不完整的答案上去交差。第三阶段充分上下文智能体这才是新研究的亮点可以把这个充分上下文智能体Sufficient Context Agent想象成流水线尽头那位质检员。在放行、允许生成回答之前它会盯着三样东西反复审查。第一样是检索到的原始片段。它会逐字逐句去看 RAG 智能体从数据库里捞出来的那些文本块。放在医生那个例子里可能就是出院小结和营养记录里的具体段落。它读这些内容就是为了确认回答问题所需要的信息到底在不在这些句子里。第二样是一份中间草稿。系统会先攒出一份草稿版回答然后充分上下文智能体把原始提问、这份草稿、外加检索到的片段三者放一块儿对照评估模型手里的料够不够写出一个全面又站得住脚的答案。如果问题问了三件事用药、饮食、过敏可片段里只覆盖了两件它当场就会判定上下文不充分。第三样也是最关键的一步——缺口分析。这个智能体不光说一句信息不够就完事它会精确地指出到底缺了什么生成一份带原因Reason和反馈Feedback的日志。比如它会这么记录已找到有了用药清单也有了低钠饮食的医嘱。缺口源文档里缺少关于过敏反应或住院期间不良事件的信息。它会拿手头找到的东西去对照最初的问题然后追问一句过敏这个问题咱们回答了吗如果没有它就发出上下文不充分的信号并给出明确的指引用药和饮食都找到了但过敏漏了。回去专门搜一下’皮疹’或者’不良事件’。要是碰上多数据源的情况它还能主动要求补充更多信息或者判断某个数据源跟问题压根不相关直接跳过。第四阶段迭代收到充分上下文智能体的反馈后查询改写器立马新建一条针对皮疹的检索。RAG 智能体这回钻进了头一次被它忽略掉的那些文件里把缺的信息给挖了出来。第五阶段综合生成最终答案充分上下文智能体再做最后一次检查。这下用药、饮食、过敏三样齐了它判定可以收工、不用再搜了。最后由综合智能体Synthesis Agent出马给医生写出一份干净、准确的总结。实验和结果谷歌在 FramesQA 上测了这套 agentic RAG这个数据集源自 FRAMES 那篇论文。里头有个典型的多跳问题长这样““在收视率最高的前两部电视剧季终集里截至 2024 年 6 月哪一部时长最长长出多少”要答对这题RAG 系统得分好几步走。首先得搞清楚收视最高的这两部季终集分别来自《陆军野战医院》M*A*S*H和《干杯酒吧》Cheers然后得查到它们各自的播放时长最后还得算出时间差。换成很多 RAG 的设定下不管是朴素 RAG还是没带充分上下文的 agentic RAG模型很可能就这么回了““翻了好几遍没找到 M*A*S*H 或 Cheers 的明确时长。文档里有收视数据但没写具体多少分钟或者多少小时。”这等于没回答。而谷歌的 agentic RAG 能搞定它先搜出这两部剧再靠查询改写器和充分上下文智能体发起一次专门针对时长的精确检索。料齐了之后Gemini 轻松就能判断出谁更长、长多少““M*A*S*H 的季终集时长 150 分钟是这前两名里最长的比 Cheers 的季终集长了 52 分钟——后者大约 98 分钟。”为了在更大规模上验证这个能力谷歌跑了一组实验。FramesQA 总共有 824 个查询外加一个含 2676 份 PDF 文档的语料库。在朴素 RAG 这一组里用的是谷歌自家的 RAG Engine它本身就配了一套先进的检索引擎、大模型解析器和重排器。然后拿它跟 agentic RAG 在两种设定下对比一种是单语料库设定只从 FramesQA 的文档里检索另一种是跨语料库设定额外掺进了三个用来捣乱的干扰数据集逼着规划智能体自己判断该去哪儿检索。这个跨语料库的场景其实就是在模拟企业里那种数据库由不同团队各管一摊的真实情况。准确率的算法是用大模型当裁判LLM-as-a-judge把系统给出的回答和数据集里的标准答案做比对。结果挺亮眼在跨语料库设定下系统的准确率几乎追平了单语料库。哪怕规划智能体得从 4 个候选语料库里挑出对的那个它依然能把查询正确路由过去答对了其中 90.1% 的问题。而且单语料库和跨语料库两个版本的延迟基本没差别平均也就差 3% 以内。这说明谷歌的 agentic RAG 系统确实能在多个互不相干的数据源上做推理也给更灵活的检索场景打开了想象空间。跨语料库 vs 单语料库 vs 朴素 RAG 的准确率对比“上图在 FramesQA 上对比跨语料库检索、单语料库检索和朴素 RAG 的表现可以看到谷歌这套 agentic 方案的准确率确实很高。写在最后把高级的查询规划、路由和充分上下文这几样捏到一起谷歌这套 agentic RAG 系统让 AI 生成的回答变得可审计、可追溯、有据可依。接下来就看机器学习社区会怎么用上这些新的智能体能力去搭出下一代靠谱的 AI 系统了。目前这个功能已经在 Gemini 企业级智能体平台上以公开预览public preview的形式开放。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
RAG 还在说“我信息不够“?谷歌Gemini这套 Agentic RAG 直接逼它接着搜
发布时间：2026/6/8 23:43:11
这篇文章要聊的是谷歌新推出的一套 agentic RAG智能体检索增强生成框架。它由 Google Research 和 Google Cloud 联手打造核心思路是先把复杂的企业级问题拆开然后一遍遍地去找上下文确认信息够了再动手生成答案。说白了就是让模型别急着回答先把上下文功课做扎实。老一套的 RAG为啥不够用了笔者先把问题摆出来。现在主流的那种一步到位的 RAG 系统压根就不是为今天这种跨多个数据源、要绕好几道弯的查询设计的。举个例子。假设有人问X 项目用的那台服务器具体参数是什么“系统大概能翻到一堆跟 X 项目相关的文档但这些文档里可能只写了个服务器编号。它不知道下一步该拿着这个编号再去另一个数据库里查一遍才能找到真正的参数。结果呢要么给个残缺的答案要么干脆甩一句没找到”。问题就出在这儿——信息散落在一个个彼此孤立的数据孤岛上得一层层往里挖才能把事实凑齐。而老一套的 RAG 没这个本事。于是就有了 agentic RAG。它会规划、会推理还会反复地跟各个数据源打交道专门对付这种复杂查询让回答更可靠、更准确。这次谷歌正式拿出来的是托管在 Gemini 企业级智能体平台上的**跨语料库检索Cross-Corpus Retrieval**功能背后跑的就是 agentic RAG。和市面上其他的多智能体 RAG 框架一样它也是靠一群分工明确的智能体协同作战来回答难题。但不一样的地方在于谷歌这套引入了一个叫充分上下文sufficient context的机制专门用来判断手头的信息到底够不够给出一个准确的答案。效果上跟标准 RAG 比这套框架在事实性数据集上的准确率最高能提升 34%。谷歌还拿自家内部的私有数据集做了测试结果是在多个特定领域的任务里模型的接地气程度grounding和推理准确率都更好了。多智能体架构是怎么干活的规划、改写、路由理解多智能体 RAG最好别把它当成一个搜索引擎而是当成一个组织有序的研究部门。老式的单体 RAG也有人叫它 “Vanilla RAG”也就是最朴素的那种干活很直白检索模块看一眼你的问题找出匹配的文档然后交给大模型生成回答完事。而在多智能体框架里这活儿被拆成了好几个专门的角色各司其职。最前面坐镇的是编排器Orchestrator它先掂量一下你的问题判断出这事儿一步搞不定然后把任务分派下去。接着是规划智能体Planner Agent负责画出信息的获取路线图——比如你同时问了某个项目的预算和时间线它就会盘算“得先查财务数据库再去翻项目管理日志。”然后轮到**查询改写器Query Rewriter登场它把你那句口语化的提问翻译成几条更精准的检索语句。比如X 项目最近咋样了“这种含糊的话会被改写成X 项目 Q3 状态报告和X 项目团队的主要阻碍”。改写完并行搜索智能体Search Fanout Agent**接手把这几条提炼过的查询分发到各个检索源去捞信息片段。最后大模型把所有上下文汇总到一起吐出最终答案。“注原文这里配有一段演示视频展示的是一套标准的 agentic RAG 系统。它虽然用了多个智能体但没有迭代检索的能力也不支持专门的跨语料库检索。谷歌这套和别家的到底差在哪关键就两个字坚持。跟其他 RAG 方案比谷歌这套的厉害之处在于——它知道自己什么时候信息不够然后会接着找一直找到上下文凑齐为止。这就避免了两种尴尬情况一种是第一次没搜到模型就开始瞎猜另一种是动不动就摆烂回一句我信息不够。当然有时候确实是真没有那这么回答没毛病。但很多时候信息明明就在那儿只是还没被翻出来而已。笔者拿一个医疗场景来说明。设想一位医生在问诊系统里这么问““John Doe 做完膝盖手术后的出院用药和饮食禁忌分别是什么他住院期间有没有出现过过敏反应注意只在住院或急诊期间临时用的药就别列了——但肝素静脉滴注和替奈普酶这两种除外。”这问题够刁钻吧。面对这种提问谷歌的框架会一口气派出好几个专门的智能体来处理。下面笔者先给个整体流程图再一步步拆开讲。“上图包含了一个充分上下文智能体并且能在回答问题之前反复迭代、检索更多信息。第一阶段编排根智能体Root Agent先把医生这段话拆解开分派给下面的子智能体。规划智能体一看发现要查的其实是三块互不相干的领域药房用药、营养科饮食、临床记录过敏史。查询改写器则把这一长串问题切成一个个简单、好搜的小问题这样检索器才能更精准地找到对应内容。第二阶段检索这是标准动作RAG 智能体把改写后的那一批查询同时丢进患者档案里搜。它顺利找到了用药信息和饮食信息但在那些最显眼的文件里怎么都翻不到过敏的记录。要是换成普通的朴素 RAG 系统故事到这儿可能就结束了——交一个不完整的答案上去交差。第三阶段充分上下文智能体这才是新研究的亮点可以把这个充分上下文智能体Sufficient Context Agent想象成流水线尽头那位质检员。在放行、允许生成回答之前它会盯着三样东西反复审查。第一样是检索到的原始片段。它会逐字逐句去看 RAG 智能体从数据库里捞出来的那些文本块。放在医生那个例子里可能就是出院小结和营养记录里的具体段落。它读这些内容就是为了确认回答问题所需要的信息到底在不在这些句子里。第二样是一份中间草稿。系统会先攒出一份草稿版回答然后充分上下文智能体把原始提问、这份草稿、外加检索到的片段三者放一块儿对照评估模型手里的料够不够写出一个全面又站得住脚的答案。如果问题问了三件事用药、饮食、过敏可片段里只覆盖了两件它当场就会判定上下文不充分。第三样也是最关键的一步——缺口分析。这个智能体不光说一句信息不够就完事它会精确地指出到底缺了什么生成一份带原因Reason和反馈Feedback的日志。比如它会这么记录已找到有了用药清单也有了低钠饮食的医嘱。缺口源文档里缺少关于过敏反应或住院期间不良事件的信息。它会拿手头找到的东西去对照最初的问题然后追问一句过敏这个问题咱们回答了吗如果没有它就发出上下文不充分的信号并给出明确的指引用药和饮食都找到了但过敏漏了。回去专门搜一下’皮疹’或者’不良事件’。要是碰上多数据源的情况它还能主动要求补充更多信息或者判断某个数据源跟问题压根不相关直接跳过。第四阶段迭代收到充分上下文智能体的反馈后查询改写器立马新建一条针对皮疹的检索。RAG 智能体这回钻进了头一次被它忽略掉的那些文件里把缺的信息给挖了出来。第五阶段综合生成最终答案充分上下文智能体再做最后一次检查。这下用药、饮食、过敏三样齐了它判定可以收工、不用再搜了。最后由综合智能体Synthesis Agent出马给医生写出一份干净、准确的总结。实验和结果谷歌在 FramesQA 上测了这套 agentic RAG这个数据集源自 FRAMES 那篇论文。里头有个典型的多跳问题长这样““在收视率最高的前两部电视剧季终集里截至 2024 年 6 月哪一部时长最长长出多少”要答对这题RAG 系统得分好几步走。首先得搞清楚收视最高的这两部季终集分别来自《陆军野战医院》M*A*S*H和《干杯酒吧》Cheers然后得查到它们各自的播放时长最后还得算出时间差。换成很多 RAG 的设定下不管是朴素 RAG还是没带充分上下文的 agentic RAG模型很可能就这么回了““翻了好几遍没找到 M*A*S*H 或 Cheers 的明确时长。文档里有收视数据但没写具体多少分钟或者多少小时。”这等于没回答。而谷歌的 agentic RAG 能搞定它先搜出这两部剧再靠查询改写器和充分上下文智能体发起一次专门针对时长的精确检索。料齐了之后Gemini 轻松就能判断出谁更长、长多少““M*A*S*H 的季终集时长 150 分钟是这前两名里最长的比 Cheers 的季终集长了 52 分钟——后者大约 98 分钟。”为了在更大规模上验证这个能力谷歌跑了一组实验。FramesQA 总共有 824 个查询外加一个含 2676 份 PDF 文档的语料库。在朴素 RAG 这一组里用的是谷歌自家的 RAG Engine它本身就配了一套先进的检索引擎、大模型解析器和重排器。然后拿它跟 agentic RAG 在两种设定下对比一种是单语料库设定只从 FramesQA 的文档里检索另一种是跨语料库设定额外掺进了三个用来捣乱的干扰数据集逼着规划智能体自己判断该去哪儿检索。这个跨语料库的场景其实就是在模拟企业里那种数据库由不同团队各管一摊的真实情况。准确率的算法是用大模型当裁判LLM-as-a-judge把系统给出的回答和数据集里的标准答案做比对。结果挺亮眼在跨语料库设定下系统的准确率几乎追平了单语料库。哪怕规划智能体得从 4 个候选语料库里挑出对的那个它依然能把查询正确路由过去答对了其中 90.1% 的问题。而且单语料库和跨语料库两个版本的延迟基本没差别平均也就差 3% 以内。这说明谷歌的 agentic RAG 系统确实能在多个互不相干的数据源上做推理也给更灵活的检索场景打开了想象空间。跨语料库 vs 单语料库 vs 朴素 RAG 的准确率对比“上图在 FramesQA 上对比跨语料库检索、单语料库检索和朴素 RAG 的表现可以看到谷歌这套 agentic 方案的准确率确实很高。写在最后把高级的查询规划、路由和充分上下文这几样捏到一起谷歌这套 agentic RAG 系统让 AI 生成的回答变得可审计、可追溯、有据可依。接下来就看机器学习社区会怎么用上这些新的智能体能力去搭出下一代靠谱的 AI 系统了。目前这个功能已经在 Gemini 企业级智能体平台上以公开预览public preview的形式开放。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
