---
title: "Google Agentic RAG 跨语料库框架：充分上下文智能体 + 5 阶段管线（FramesQA 90.1%）"
created: "2026-06-06"
updated: "2026-06-06"
type: raw
source_url: "https://mp.weixin.qq.com/s/8PdVIubBGWKtMMyCb0pc3g"
source_name: "AI 寒武纪 WeChat MP (YAR师)"
author: "AI 寒武纪 / YAR师"
ingested: "2026-06-06"
sha256: "74245b8f109450ded8bf79da17f33beb745f902f14bacbdd5fa0e7913b3e5915"
char_count: 2850
tags: [agentic-rag, google, gemini-enterprise, multi-agent, sufficient-context, cross-corpus, framesqa, multi-hop-reasoning, medical-rag, retrieval, eval]
sources: []
review_value: 7
review_confidence: 7
review_recommendation: worth-reading
review_stars: 4
---
↑阅读之前记得关注+星标⭐️，😄，每天才能第一时间接收到更新
 
现有的 RAG 系统有个老毛病：搜一次，生成一次，就算信息找不全也就这样了。
比如你问：「X 项目用的服务器配置是什么？」
系统能找到 X 项目的文档，但文档里只写了一个服务器 ID。它不会拿着这个 ID 再去另一个数据库搜配置。最终的结果要么是半截答案，要么直接告诉你「没找到」。
问题不是信息不存在，是系统没有继续找的能力。
谷歌研究院和 Google Cloud 联合发布了一套新的 Agentic RAG 框架
核心改进：系统能判断自己是否拿到了足够的信息，如果没有，就继续搜，直到信息完整为止。
相比标准 RAG，这套框架在事实性数据集上的准确率提升最高达 34%。
多智能体框架：把一个问题拆给一组专家
要理解这套框架怎么运作，可以把它类比成一个研究部门，而不是一个搜索引擎。
传统的「Vanilla RAG」只有一个动作：拿着你的问题找相似文档，然后让大模型生成答案。
多智能体框架把这件事拆成了几个专门的角色：
编排器
：收到复杂请求后判断这不是一步能完成的任务，把工作分配给各个子智能体。
规划智能体
：规划信息的获取路径。比如你问某个项目的预算和时间线，它会决定先查财务数据库，再查项目管理日志。
查询改写器
：把你的原始问题拆成多个可检索的具体查询。比如把「X 项目怎么样了」改写成「X 项目 Q3 状态报告」和「X 项目团队关键阻塞点」。
搜索扇出智能体
：把改写后的查询同时发送给多个数据源，收集信息片段。
大模型（LLM）
：汇总所有上下文，生成最终答案。
标准 Agentic RAG 系统演示，包含多个智能体，但不含迭代检索和跨语料库支持。
谷歌的新东西：「已拿到的信息够不够用」
上面那套多智能体框架，其实业界已经有不少类似实现。
谷歌这套的关键区别在于：系统知道自己什么时候信息不够，并且会继续找，而不是将就着回答或者直接说「找不到」。
用一个具体场景说明。医生查询一个病人的出院情况：
「小李做完膝关节手术后的出院药物和饮食限制是什么？住院期间有没有过敏反应？除了肝素静脉滴注或 Tenecteplase 之外，不要包含仅在住院或急诊期间使用的药物。」
这个问题涉及三个不同的信息来源：药房、营养、临床记录。以下是这套框架处理这个问题的完整过程。
多智能体 RAG 解决方案演示，包含充分上下文智能体，以及在回答前迭代检索更多信息的能力。
第一阶段：编排
根智能体解析医生的请求，把任务分配给子智能体。规划智能体确定需要检索三个方向：药房、营养、临床记录。查询改写器把这个复杂请求拆成多个简单的、可检索的子问题。
第二阶段：搜索
RAG 智能体同时对所有子查询进行检索。找到了药物清单和饮食信息，但在最明显的文件里没有找到过敏相关的记录。标准 RAG 到这里就会停下来，给出一个不完整的答案。
第三阶段：充分上下文智能体（核心创新）
这是谷歌这套框架最关键的部分，相当于流水线末端的质检员。它做三件事：
第一，审查 RAG 智能体从数据库拉回来的实际文本片段，看里面有没有回答问题所需的内容。
第二，系统会先生成一个草稿答案。充分上下文智能体会对比原始问题、草稿答案和检索到的片段，判断模型是否有足够的信息给出全面且可溯源的回答。问题问了三件事（药物、饮食、过敏），但片段里只有两件事的信息，就会被标记为「上下文不充分」。
第三，也是最关键的一步：它会精确指出缺少什么。不只是输出「信息不够」，而是生成具体的原因和反馈日志，比如：
已找到：药物清单和低钠饮食说明。
缺失：关于住院期间过敏反应或不良事件的内容。
然后它发出「上下文不充分」的信号，并给出具体的改进指令：已找到药物和饮食，但缺少过敏信息，请专门搜索「皮疹」或「不良事件」。
第四阶段：迭代
根据充分上下文智能体的反馈，查询改写器生成新的搜索词「皮疹」，RAG 智能体重新检索之前忽略的文件，找到了缺失的信息。
第五阶段：最终合成
充分上下文智能体再次检查，确认药物、饮食、过敏三项信息都已齐全，判定可以停止搜索。合成智能体生成一份完整、准确的总结交给医生。
实验结果：跨库检索准确率达 90.1%
谷歌用 FramesQA 对这套框架进行了评测，这个数据集基于 FRAMES 论文，专门测试多跳推理能力。
典型问题长这样：
在收视最高的两个电视季终集中（截至 2024 年 6 月），哪个终集播出时间更长？长了多少？
回答这个问题需要好几步：先找出收视最高的两个终集（M*A*S*H 和 Cheers），再分别查它们的时长，最后计算差值。
在很多 RAG 系统中，得到的答案会是：虽然多次搜索，但没有找到 M*A*S*H 或 Cheers 的明确播出时长，文档只提供了收视数据，没有分钟或小时数。
这没有回答问题。
谷歌这套框架的答案是：M*A*S*H 终集时长 150 分钟，是两者中最长的，比 Cheers 终集（约 98 分钟）多 52 分钟。
实验规模：FramesQA 共 824 个查询，语料库包含 2676 份 PDF 文档。
谷歌对比了三个设置：
Vanilla RAG，使用谷歌自家的 RAG Engine（含先进检索引擎、LLM 解析器和重排序器）。
单语料库 Agentic RAG，只在 FramesQA 文档中检索。
跨语料库 Agentic RAG，在 FramesQA 文档加上三个无关干扰数据集中检索，规划智能体需要自己判断去哪个库里找。
跨语料库检索与单语料库及 Vanilla RAG 在 FramesQA 上的准确率对比。
结果：跨语料库设置下，系统准确率接近单语料库，在四个数据库中正确路由并回答了 90.1% 的问题。单库和跨库两个版本的延迟相差不超过 3%，说明加入跨库路由几乎没有带来额外的时间成本。
总结
这套框架的核心逻辑其实并不复杂：在生成答案之前，先判断手里的信息够不够；不够的话，明确说出缺什么，然后再去找。
这个「充分上下文」的检验步骤，让系统的答案变得可审计、可溯源，而不是靠模型猜测填补空白。
目前这套功能已作为公开预览版上线 Gemini Enterprise Agent Platform：
https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/rag-engine/cross-corpus-retrieval
参考：
https://research.google/blog/unlocking-dependable-responses-with-gemini-enterprise-agent-platforms-agentic-rag/
 
--end--
最后记得⭐️我，每天都在更新：如果觉得文章还不错的话可以点赞转发推荐评论
/...@作者：你说的完全正确（YAR师）

---
## 元信息
- **来源 URL**: https://mp.weixin.qq.com/s/8PdVIubBGWKtMMyCb0pc3g
- **抓取时间**: 2026-06-06
- **抓取方式**: urllib + js_content 提取
- **作者**: AI 寒武纪 (YAR师) — 翻译解读 Google Research + Google Cloud 联合发布的 Agentic RAG 框架
- **参考**:
  - https://research.google/blog/unlocking-dependable-responses-with-gemini-enterprise-agent-platforms-agentic-rag/
  - https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/rag-engine/cross-corpus-retrieval