企业官网建设流程全解析

这篇文章要聊的，是谷歌新推出的一套 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%免费】