RAG 这两年被讲烂了但大部分人脑子里的 RAG 还停在 2023 年的那张图用户提问 → 向量检索 → 把召回的几段文本塞进 prompt → 让模型照着生成答案。一条单向流水线检索发生在生成之前且只发生一次。这套经典 RAG 解决了「让模型用上私有知识」的基础问题但真正拿去做复杂业务时它的天花板很快就撞到了。而 Agent 的兴起正在悄悄改写检索这件事的形态。这篇想讲清楚检索范式到底变在哪以及为什么这个变化值得重视。一、经典 RAG 的三个硬伤先说清楚旧范式卡在哪不然没法理解新范式好在哪。第一一次检索定生死。整个流程里只有一次检索机会而这次检索的成败完全取决于用户那句原始提问能不能被向量匹配到对的文档。用户问得含糊、用词和文档对不上、或者问题本身需要换个角度去查——只要这一次没召回到后面生成得再流畅也是错的。模型拿着错误的上下文只会一本正经地胡说。第二检索和生成是断开的没有反馈。检索器召回完就撒手不管了它不知道这些内容到底够不够回答问题。生成模型即使发现「给我的资料里压根没提到这个」也没有任何机制让它说「等等我再查一下」。第三复杂问题需要多跳流水线做不到。比如「对比一下我们 A 产品和 B 产品的退货政策差异」这本质上需要分别检索 A 和 B 的政策、再做对比。单次检索把这句话整个拿去匹配召回的往往是一堆四不像。二、核心转变检索从「预处理」变成「Agent 的一个工具」Agentic RAG 的思路一句话就能概括把检索从生成前的固定步骤变成 Agent 在解题过程中可以自主调用的一种行为。在新范式里「检索」就是挂在 Agent 上的一个工具。要不要检索、用什么 query 去检索、检索一次还是好几次、召回的东西够不够、要不要换个角度再查一遍——这些决策权从写死的流水线交还给了模型自己。defagentic_rag(question,retriever,max_rounds4):context[]for_inrange(max_rounds):# 模型基于当前已掌握的信息决定下一步动作actionllm_decide(question,context)ifaction.typeanswer:returnaction.text# 信息够了作答ifaction.typesearch:# query 由模型生成可能是改写、可能是子问题docsretriever.search(action.query)context.append((action.query,docs))returnllm_answer(question,context)# 触顶兜底对比经典 RAG 那条单向流水线区别就在这个for循环——检索可以发生多次而且每一次查什么是模型看着前面查到的东西临时决定的。三、由此长出来的几个关键模式这个转变一旦发生几个非常实用的模式就自然出现了。查询改写与分解Query Rewriting / Decomposition。模型不再直接拿用户原话去检索而是先把它翻译成更适合检索的 query或拆成几个子问题分别查。前面那个「对比 A、B 退货政策」的例子模型会拆成两次检索先查 A 的政策再查 B 的最后合起来对比。# 模型把一个复杂问题拆成可检索的子问题sub_queries[A产品 退货政策,B产品 退货政策]results[retriever.search(q)forqinsub_queries]迭代检索Iterative Retrieval。第一轮召回不理想时模型能看着结果调整 query 再查一次——「换个关键词」「换个角度」就像人查资料查不到时会做的那样。检索后的自我批判Self-Critique。这是最能体现「Agent」味道的一环召回之后先让模型判断「这些资料足够回答问题吗」够了就作答不够就继续检索。这一步把「检索够不够」这个判断显式地交给了模型而经典 RAG 里这个判断根本不存在。defis_sufficient(question,context):让模型先自检:现有资料够不够作答,不够就触发再检索verdictllm_judge(f问题:{question}\n已有资料:{context}\nf这些资料足以准确回答吗?只回答 够 / 不够 及缺什么)returnverdict.startswith(够)四、别只听好话代价同样真实Agentic RAG 不是免费午餐落地前必须把账算清楚延迟上去了。经典 RAG 一次检索一次生成Agentic RAG 可能要检索三四轮、每轮都有模型推理端到端延迟翻几倍。对要求秒级响应的场景是硬伤。成本上去了。多轮检索意味着多轮模型调用token 消耗显著增加。行为更难预测。检索次数和路径不再固定调试和复现都更难必须配上每一步的检索追踪日志否则线上出问题根本查不动。所以现实里的选型是分层的简单、对延迟敏感的问答老老实实用经典 RAG只有真正需要多跳推理、复杂检索的场景才上 Agentic 这一套。不要因为新就无脑全用那是工程不成熟的表现。五、被忽略的地基知识库的工程与合规讨论检索范式时大家容易只盯着「检索策略」忘了底下还有一整套地基知识库怎么建、文档怎么切分、增量更新怎么做、权限怎么控制——尤其在企业里不同用户能检索到的内容是不一样的你不能让普通员工通过 Agent 检索到 HR 的薪酬文档这套行级/文档级的权限得在检索层就做掉。再加上私有数据不出域、检索链路要审计这些合规要求自建一套完整的知识底座成本相当高。这也是国内一批智能体平台在补的能力——以上海比孚的AgentCore为例作为面向国内合规环境的国产智能体服务商它把知识库管理、权限隔离、私有化部署这类地基性的东西做进了平台层。这里专门说明一句它是国产产品和某些名字相近的海外框架不是一回事选型时注意区分。不过要强调——平台能帮你管好知识底座但检索策略本身拆不拆、迭代几轮、怎么自检依然是需要你按业务去设计的这部分没有银弹。写在最后经典 RAG 没有死它依然是大量简单问答场景的最优解。变化的是当问题足够复杂检索不再适合做成一次性的预处理而应该成为 Agent 解题过程中一种可以反复、自主使用的行为——查不够就再查查偏了就改方向查够了才作答。理解这个从「流水线」到「行为」的转变比追逐任何一个具体的 RAG 框架都更要紧。框架年年换这个思路的转变是会长期成立的。