Agentic RAG 的下一跳:Google 把「够不够用」写进检索循环1×0:006:020:08开场:今天的动态1:01事件:Google 发布了什么2:28深挖:为什么这是 Loop Engineering3:53工程意义:团队该怎么落地5:23收尾:今天带走什么0:08主播今天聊一个很适合放进「Loop Engineering」视角里的动态:Google Research 和 Google Cloud 在 Gemini Enterprise Agent Platform 里推出了 Agentic RAG 相关能力,官方文档里叫 Cross Corpus Retrieval。它不再把 RAG 当成一次向量检索加一次回答,而是把检索做成一个循环:规划、改写查询、跨语料检索、检查上下文够不够,再决定要不要继续找。0:35主播这件事的技术味道很重,但它回应的是一个朴素问题:企业知识往往不在一个库里。项目状态在文档,预算在财务系统,客户记录又在另一套库。用户问一个多跳问题,传统 RAG 很容易第一把只捞到一半信息,然后模型开始补脑。Google 这次强调的点,是让系统自己发现「我还缺哪块证据」。1:01主播按 Google Research 的介绍,这个框架由多个角色协作。Orchestrator 先判断问题是不是一步能解决;Planner Agent 规划要查哪些信息路径;Query Rewriter 把长问题拆成多条可检索的查询;Search Fanout Agent 去不同数据源拉片段;最后再由模型综合回答。听起来像一套小型研究团队,但核心不在角色多,而在它多了一个质检环节。1:31主播这个质检环节叫 Sufficient Context Agent。它会读检索到的片段,也会看中间草稿,再对照用户原问题判断:现在这些证据够不够回答?如果不够,它不会只说「资料不足」,而是给出缺口反馈。比如医疗例子里,系统找到出院用药和饮食限制,却没找到过敏反应,它会要求下一轮专门搜索皮疹或不良事件。1:59主播实验数据也给了一个工程参照。Google 说,相比标准 RAG,这套 agentic RAG 在 factuality 数据集上最高把准确率提高三十四个百分点。在 FramesQA 实验里,数据集有八百二十四个问题和两千六百七十六份 PDF。跨语料设置加入了三个干扰数据集,也就是从四类语料里路由,系统仍然答对了百分之九十点一的问题,延迟平均只差不到百分之三。2:28主播如果把这个设计抽象一下,它不是「RAG 更聪明了」这么简单。它把 RAG 拆成了一个可观测循环:目标是什么,先查哪里,查到了什么,证据缺哪块,下一轮查询怎么改。以前很多 RAG 失败,是因为每一步都藏在一个黑盒 prompt 里。现在缺口被显式写出来,工程师才能把它接到日志、评估和告警里。2:55主播O'Reilly 最近把 agent 的原子单元概括成 think、act、observe 的循环。用这个框架看,Agentic RAG 正是在 observe 后面加了一道判断:观察结果能不能支撑行动?不能,就让下一次 act 更具体。这个小判断很实用,因为企业场景里最怕的不是回答慢一点,而是系统拿着半截材料给出一个听起来很完整的答案。3:23主播Google Cloud 文档里还有一个容易被忽略的实施细节:语料库创建时的 description 很重要,而且创建后不可编辑。原因很直接,规划代理要靠这些描述判断应该查哪个 corpus。换句话说,Agentic RAG 的效果不只取决于模型,也取决于你怎么给知识库写元数据。语料命名、边界说明、权限分层,都会进入检索循环。3:53主播对做 Agent 工程的团队,我会把它翻译成三条落地建议。第一,别只评估最终答案,也要评估中间缺口判断。系统有没有发现没查到的字段,可能比它第一轮查到什么更重要。第二,跨语料检索要先治理 corpus 描述,别等上线后才发现所有库都叫「公司资料」。第三,把「上下文不足」当成正常状态处理,而不是异常兜底文案。4:24主播这也解释了为什么 LangChain 最近会强调给 agent 一个可运行的 sandbox。无论是代码 agent 还是检索 agent,生产能力都来自同一种反馈回路:行动,观察结果,修正,再行动。代码 agent 是跑测试、看报错、改代码;RAG agent 是检索、看证据缺口、改查询。Loop Engineering 真正要设计的,不是某个 prompt,而是每次失败后系统怎样把失败转成下一步。4:56主播当然,这套能力不是所有场景都需要。如果只是查一个订单状态,简单工具调用就够了。真正适合它的,是多源、多跳、要求可追溯的知识工作:合规问答、医疗摘要、企业文档分析、复杂客户支持。只要问题的答案分散在几处,而且漏一处就会误导用户,就应该考虑把检索做成循环,而不是一次性召回。5:23主播今天的结论可以很具体:Agentic RAG 的进展,不是把检索包装成多 agent,而是把「证据是否足够」变成了流程里的一个节点。这个节点让系统知道什么时候继续查,工程师也能看到它为什么继续查。下一次你评估一个 RAG 系统,不妨少问一句「用了几个 agent」,多问一句:它发现自己还不知道什么吗?这里,才是 Loop Engineering 的分水岭。
围绕这条内容继续补充观点或上下文。