Google Research 在 6 月 8 日向 Gemini Enterprise Agent Platform 添加了一个 Sufficient Context Agent,将其作为名为 Cross-Corpus Retrieval 的 public-preview 功能 ship。该框架是多代理 RAG,其独特贡献是 pipeline 中一个特定的 agent,其唯一工作是决定到目前为止 retrieved 的 evidence 是否真正足以回答问题。标准 RAG retrieve 一次并回答。该框架运行五个阶段:一个 Root Agent 解析请求并委派,一个 RAG Agent 跨多个 data sources fan-out 并行 queries,Sufficient Context Agent 根据原始 prompt 检查 retrieved snippets,如果发现 gaps,一个 Query Rewriter 生成新的定向搜索,一个最终的合成步骤在模型被允许生成之前确认完整性。Google 发布的数字:在 FramesQA(2,676 个 PDF 文档上的 824 个 queries)上,系统在从四个来源选择正确数据库时达到 90.1% accuracy,比 vanilla RAG baseline 提供高达 34% 的 factuality 改进(该 baseline 本身使用 advanced retrieval engine 加 LLM parser 加 re-ranker),并将延迟保持在 single-corpus 和 cross-corpus 模式之间的 3% 以内。

值得检查的机制是 Sufficient Context Agent 做了什么使它区别于标准的 relevance 或 confidence 检查。典型的 RAG quality gate 产生一个二进制或一个 score:relevant 或不,confident 或不,当它失败时它要么仍然回答,要么返回"insufficient context"并停止。Sufficient Context Agent 做一些更具体的事:当 evidence 不完整时,它写一个 Reason and Feedback log,命名 gap。不是"insufficient"而是"在 corpus A 中找到了 server ID 但没有 hardware specs,它们应该在第二个数据库中"。那个命名的 gap 是 Query Rewriter 消费以生成下一次搜索的东西。因此 loop 不是用相同 query retrieve-score-retry,而是 retrieve、诊断具体缺失的部分、rewrite query 以针对那个部分、再次 retrieve。它针对的三个 failure modes 是具体的,对任何 ship 过 RAG 的人都熟悉:partial answers(你在一个来源中找到了一半答案并停止),premature not-found(第一次搜索返回空所以系统放弃),和 hallucination(context 不完整所以模型 guess 来填补空洞)。命名 gap 是将一个死胡同"我不知道"转换为一个定向的下一次搜索的东西。

生态系统解读是这是我们一直跟踪的相同 state-externalization 模式,现在应用于 knowing-what-you-don't-know 问题,并 ship 进一个 enterprise runtime 而不是作为 paper 发布。Harness-1 将 retrieval bookkeeping 外部化到环境。Memory OS 将 agent 内存外部化到六个类型化的层。Sufficient Context Agent 将 sufficiency 判断外部化到一个带有书面 log 的专用 agent,而不是将其留作生成器 confidence 的隐式属性。战略背景是这落在 Gemini Enterprise Agent Platform 内,与 Antigravity 2.0 的 Managed Agents 居住的相同 enterprise tier,这意味着 Google 正在一次一个外部化 capability 地组装 enterprise agent 堆栈:orchestration、retrieval、sufficiency-checking、query-rewriting,每一个都是你租用的 runtime 中的一个命名 component,而不是你编写的 prompt。那是 agentic-RAG 研究方向的 productization,34% 的 factuality 数字是他们向在第一波中被 RAG-自信地幻觉烧伤的 enterprise buyers 提出的论证。

周一早上,如果你在生产中运行 RAG,你的 failure mode 是在 multi-hop queries 上自信的错误答案:Sufficient Context 模式是要研究的架构,关键的设计 move 是让 sufficiency check 命名具体的 gap 而不是发出一个二进制,因为命名的 gap 是使 re-search 定向而不是重复的东西。你可以自己构建这个模式而不需要 Gemini 平台,components 是一个 orchestrator、一个并行 retriever、一个被 prompt 来写 gap log 的 sufficiency-checker、一个 query rewriter 和一个 synthesizer。如果你是 Gemini Enterprise Agent Platform 上的 enterprise:Cross-Corpus Retrieval 现在处于 public preview,FramesQA 数字值得根据你自己的文档 corpus 验证,特别是 cross-corpus database-selection accuracy,因为那是标准 RAG 处理最差的 multi-source 情况。如果你为 agentic RAG 评估 buy-versus-build:这个 release 是 buy 选项具体地变得更好,问题是 3% 的延迟开销和平台 lock-in 是否值得不必自己构建和维护五个 agent 的 loop。如果你跟踪 agent-runtime 整合线索,注意它 ship 在哪里:不是作为 open framework 或 research artifact,而是作为 enterprise runtime 内的租用 capability,那正是主要 vendors 竞相拥有的层。