# 谷歌推出基于 Gemini Enterprise Agent Platform 的 Agentic RAG 框架

- 来源：Google Research：Blog（网页）
- 发布时间：2026-06-05 00:00
- AIHOT 分数：64
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.news/items/cmq1dossi0ev7sltrrihfn7pb
- 原文链接：https://research.google/blog/unlocking-dependable-responses-with-gemini-enterprise-agent-platforms-agentic-rag

## 精选理由

企业级 RAG 的新标杆，多 agent 架构加上‘足够上下文’检查，准确度提升 34%。做知识库问答的产品经理和架构师都应该认真看。

## AI 摘要

Google Research 与 Google Cloud 合作推出跨语料库检索（Cross-Corpus Retrieval）框架，作为 Gemini Enterprise Agent Platform 的 Agentic RAG。该多智能体工作流将复杂企业查询分解为子任务，通过规划、重写和路由，迭代搜索多个数据源直至获得充分上下文，再生成可靠回答。与标准 RAG 相比，在事实性数据集上准确率最高提升 34%；在多个领域特定内部数据集上也实现了更好的接地与推理准确性。

## 正文

我们推出全新的智能体 RAG 框架。基于 Google Research 与 Google Cloud 的合作，我们的多智能体工作流超越了标准 RAG，通过拆解复杂的企业查询，并迭代搜索足够的上下文，从而生成可靠的回答。

快速链接

RAG Engine 跨语料库检索

复制链接 ×

当前的单步检索增强生成（RAG）系统并非为现代业务工作流中的多来源、多跳查询而设计。例如，如果查询是“Project X 中使用的服务器规格是什么？”，系统可能会找到关于 Project X 的文档，但这些文档可能只提到一个服务器 ID。它不会知道要拿这个 ID 去另一个数据库中进行第二次搜索以找到规格。结果是得到部分答案或“未找到”的响应，因为信息分散在不同的数据“孤岛”中，需要更深入的探索才能找到事实。

于是有了“智能体 RAG”，它能够规划、推理，并与数据源迭代交互，从而处理复杂查询，提升可靠性与准确性。

今天，我们很高兴推出由 Google 的 Gemini Enterprise Agent Platform 托管的 由 Agentic RAG 驱动的跨语料库检索版本。与 其他多智能体 RAG 框架一样，我们的框架采用多个智能体协同工作，以可靠地回答复杂查询。与其他多智能体框架不同的是，我们的框架引入了 充分上下文来确认是否有足够的信息给出准确答案。与标准 RAG 相比，我们的框架在事实性数据集上的准确率提升最高达 34%。我们还使用专有的内部数据集对系统进行了评估，发现在多个特定领域任务上，我们实现了更好的 grounding 和更高的推理准确率。

多智能体架构如何运作：规划、重写与路由

不妨把多智能体 RAG 想象成一个有条不紊的研究部门，而不是单一的搜索引擎。在“单体式”或“Vanilla”RAG 系统中，检索组件只是查看你的问题，尝试找到匹配的文档，然后由 LLM 生成回答。

在多智能体框架中，系统将任务拆解为专门的角色：

编排器会评估你的复杂请求并判断：“这不是一步就能完成的任务”，然后将工作委派给各个智能体。

规划器智能体（Planner Agent）负责规划信息路径。例如，如果你询问某个项目的预算和时间线，规划器智能体会决定：“首先，我们需要查询财务数据库，然后我们需要查询项目管理日志。”

查询改写器（Query Rewriter）将你的请求转化为多个搜索查询。它把“Project X 怎么样了？”转化为“Project X Q3 状态报告”和“Project X 团队的关键阻塞项。”

搜索扇出智能体（Search Fanout Agent）接收这些精炼后的查询，并将它们发送到各种检索来源，以收集信息片段。

最后，由一个大语言模型聚合所有上下文，给出最终回复。

展示一个标准的智能体 RAG 系统。虽然它包含多个智能体，但不包含迭代式检索或专门的跨语料库支持。

我们的智能体 RAG 与其他方案有何不同

我们新的智能体 RAG 框架的关键区别在于持久性。与其他 RAG 方案相比，我们的框架之所以有效，是因为它知道何时缺少信息，并会持续搜索，直到上下文完整为止。这可以防止 AI 在第一次搜索无果时“猜测”，或者干脆说“我没有足够的信息”。虽然在某些情况下这是恰当的回应，但有时信息就在那里，我们只是需要找到它。

例如，设想一位医生询问患者的用药、饮食和过敏情况：

“John Doe 在膝关节手术后出院时的用药和饮食限制是什么，他在住院期间是否有过任何过敏反应？不要包括仅在医院住院或急诊就诊期间使用的药物，但肝素静脉滴注或 Tenecteplase 除外。”

作为回应，我们的框架会启动许多专门的智能体。我们在下图中概述了我们的解决方案，随后再对其进行更详细的描述。

展示我们的多智能体 RAG 解决方案，其中包括一个充分上下文智能体，以及在回答查询之前迭代检索更多信息的能力。

阶段 1：编排

根智能体（Root Agent）解析医生的请求，并将任务委派给子智能体。规划智能体（Planner Agent）识别出需要检查三个不同的领域：药房、营养和临床笔记。查询重写器（Query Rewriter）将冗长的请求拆解为简单、可搜索的问题，以便检索器能够更准确地找到相关内容。

阶段 2：搜索（标准步骤）

RAG 智能体一次性针对所有查询扇出（query fanouts）搜索患者的记录。它找到了药物和饮食信息，但在最明显的文件中找不到任何关于过敏的提及。在标准或“Vanilla”RAG 系统中，流程可能到此结束，给出一个不完整的答案。

阶段 3：充分上下文智能体（新的研究创新）

把充分上下文智能体想象成站在流水线末端的质量控制检查员。在允许生成回答之前，它会审查三项具体的发现：

1. 检索到的片段

充分上下文智能体会评估 RAG 智能体从数据库中提取的实际文本块。在医生的示例中，这些可能是“出院小结”和“营养笔记”中找到的具体段落。它阅读这些内容，以查看回答查询所需的信息是否存在于这些句子中。

2. 中间草稿

该系统还会生成一份“粗略草稿”回复。随后，Sufficient Context Agent 会审查提示词、草稿和检索到的片段，以评估模型是否拥有提供全面且有依据的回答所需的一切信息。如果提示词要求三件事（药物、饮食、过敏），但片段中只包含其中两件事的信息，Sufficient Context Agent 就会将其标记为“上下文不足”。

3. 缺失部分分析

这是最关键的部分。Sufficient Context Agent 会准确识别出缺失了什么。它不只是输出“这不够充分”；它会生成具体的“原因”和“反馈”日志。例如：

发现：“我们有药物清单和低钠饮食说明。”

缺口：“我们缺少源文档中关于住院期间过敏反应或不良事件的信息。”

Sufficient Context Agent 会将已找到的内容与原始请求进行对比，并询问：“我们回答了过敏这个问题吗？”如果没有，它就会发出“上下文不足”信号，并提供具体反馈：“你找到了药物和饮食，但漏掉了过敏。回去专门搜索‘皮疹’或‘不良事件’。”在多来源场景中，它还可以请求更多信息，或判定该来源与查询无关。

第 4 阶段：迭代

由于 Sufficient Context Agent 的反馈，Query Rewriter 创建了一个针对“rashes”的新搜索。随后，RAG Agent 更深入地查看它第一次忽略的文件，并找到了缺失的信息。

阶段 5：综合（最终答案）

Sufficient Context Agent 最后一次检查数据。现在它已经掌握了药物、饮食和过敏信息，于是判断我们可以停止搜索。最后，Synthesis Agent 为医生撰写一份清晰、准确的摘要。

实验与结果

我们在 FramesQA 上评估了智能体式 RAG，该基准基于 FRAMES 论文。一个多跳问题示例如下：

“在收视率最高的两大电视剧季终集（截至 2024 年 6 月）中，哪一集的时长最长，长多少？”

RAG 系统需要执行多个步骤才能得出正确答案。首先，它必须识别出收视率最高的两大季终集分别来自剧集 MAS*H 和 Cheers。然后，它必须找到它们的时长，并计算时长差。在许多 RAG 设置中（Vanilla RAG 或没有充分上下文的智能体式 RAG），我们最终可能会遇到模型说出类似这样的话：

“尽管进行了多次扫描，我没有找到 MAS*H 或 Cheers 的明确时长。这些文档提供了收视数据，但没有以分钟或小时为单位的时长。”

这并没有回答问题。

幸运的是，我们的智能体 RAG 可以解决这个问题：首先搜索这些电视剧，然后使用 Query Rewriter 和 Sufficient Context Agent 针对 MAS*H 或 Cheers 的时长进行定向搜索。随后，Gemini 可以轻松判断哪一部的完结集时长最长，以及长多少：

“MAS*H 的完结集时长为 150 分钟，是两者中最长的。它比 Cheers 的完结集长了 52 分钟，后者时长约为 98 分钟。”

我们进行了一项实验，以大规模测试这一能力（FramesQA 包含 824 条查询，以及一个包含 2,676 份 PDF 文档的语料库）。在“Vanilla”RAG 设置中，我们使用 Google 的 RAG Engine（它拥有先进的检索引擎、LLM 解析器和重排序器）。我们将此与我们的智能体 RAG 在两种设置下进行了比较。在单语料库设置中，我们从 FramesQA 文档中进行检索。在跨语料库设置中，我们还加入了另外三个干扰数据集，此时 Planner Agent 必须判断从哪里进行检索。这种跨语料库设置模拟了企业拥有由不同团队管理的数据库的使用场景。我们通过使用 LLM-as-a-judge 将系统响应与数据集中的标准答案进行比较来计算准确率。

在跨语料库设置下，我们的系统几乎达到了与单语料库相同的准确率。即使 Planner Agent 必须从 4 种可能性中选出正确的语料库，我们仍能成功路由搜索查询，并正确回答 90.1% 的问题。此外，单语料库和跨语料库两个版本的延迟大致相同（平均差异在 3% 以内）。这表明我们的 Agentic RAG 系统能够对多个互不相关的数据源进行推理，从而为更灵活的检索场景开辟了可能性。

在 FramesQA 上，跨语料库检索 与单语料库及 Vanilla RAG 的对比，表明我们的智能体方案实现了高准确率。

结论

通过结合先进的查询规划、路由和充足的上下文，我们的 Agentic RAG 系统确保 AI 生成的回答可审计、可追溯且有据可依。我们期待看到机器学习社区如何利用这些新的智能体能力来构建下一代可靠的 AI 系统。这项新功能现已在 Gemini Enterprise Agent Platform 中以公开预览版形式提供。

致谢

本项目是与 Bo Li、Zhongjie Mao、Tiger Jin、Yuhong Kan、Mohd Abdullah（Obito）、Chun-Sung Ferng、Pooneh Mortazavi、Roger (Peng) Yu、Eran Lewis 和 Ivan Kuznetsov 的共同工作。我们感谢 Kimberly Schwede 设计图形，感谢 Mark Simborg 提供写作协助。我们也感谢关键企业合作伙伴提供的重要用户反馈、数据和洞见。