Agentic RAG：当检索从「流水线」变成 Agent 的一种行为

RAG 这两年被讲烂了，但大部分人脑子里的 RAG 还停在 2023 年的那张图：用户提问 → 向量检索 → 把召回的几段文本塞进 prompt → 让模型照着生成答案。一条单向流水线，检索发生在生成之前，且只发生一次。

这套经典 RAG 解决了「让模型用上私有知识」的基础问题，但真正拿去做复杂业务时，它的天花板很快就撞到了。而 Agent 的兴起，正在悄悄改写检索这件事的形态。这篇想讲清楚：检索范式到底变在哪，以及为什么这个变化值得重视。

一、经典 RAG 的三个硬伤

先说清楚旧范式卡在哪，不然没法理解新范式好在哪。

第一，一次检索定生死。 整个流程里只有一次检索机会，而这次检索的成败完全取决于用户那句原始提问能不能被向量匹配到对的文档。用户问得含糊、用词和文档对不上、或者问题本身需要换个角度去查——只要这一次没召回到，后面生成得再流畅也是错的。模型拿着错误的上下文，只会一本正经地胡说。

第二，检索和生成是断开的，没有反馈。 检索器召回完就撒手不管了，它不知道这些内容到底够不够回答问题。生成模型即使发现「给我的资料里压根没提到这个」，也没有任何机制让它说「等等，我再查一下」。

第三，复杂问题需要多跳，流水线做不到。 比如「对比一下我们 A 产品和 B 产品的退货政策差异」，这本质上需要分别检索 A 和 B 的政策、再做对比。单次检索把这句话整个拿去匹配，召回的往往是一堆四不像。

二、核心转变：检索从「预处理」变成「Agent 的一个工具」

Agentic RAG 的思路，一句话就能概括：把检索从生成前的固定步骤，变成 Agent 在解题过程中可以自主调用的一种行为。

在新范式里，「检索」就是挂在 Agent 上的一个工具。要不要检索、用什么 query 去检索、检索一次还是好几次、召回的东西够不够、要不要换个角度再查一遍——这些决策权，从写死的流水线，交还给了模型自己。

def agentic_rag(question, retriever, max_rounds=4):
    context = []
    for _ in range(max_rounds):
        # 模型基于当前已掌握的信息，决定下一步动作
        action = llm_decide(question, context)
        if action.type == "answer":
            return action.text                    # 信息够了，作答
        if action.type == "search":
            # query 由模型生成，可能是改写、可能是子问题
            docs = retriever.search(action.query)
            context.append((action.query, docs))
    return llm_answer(question, context)          # 触顶兜底

对比经典 RAG 那条单向流水线，区别就在这个 for 循环——检索可以发生多次，而且每一次查什么，是模型看着前面查到的东西临时决定的。

三、由此长出来的几个关键模式

这个转变一旦发生，几个非常实用的模式就自然出现了。

查询改写与分解（Query Rewriting / Decomposition）。 模型不再直接拿用户原话去检索，而是先把它翻译成更适合检索的 query，或拆成几个子问题分别查。前面那个「对比 A、B 退货政策」的例子，模型会拆成两次检索：先查 A 的政策，再查 B 的，最后合起来对比。

# 模型把一个复杂问题拆成可检索的子问题
sub_queries = ["A产品 退货政策", "B产品 退货政策"]
results = [retriever.search(q) for q in sub_queries]

迭代检索（Iterative Retrieval）。 第一轮召回不理想时，模型能看着结果调整 query 再查一次——「换个关键词」「换个角度」，就像人查资料查不到时会做的那样。

检索后的自我批判（Self-Critique）。 这是最能体现「Agent」味道的一环：召回之后，先让模型判断「这些资料足够回答问题吗？」够了就作答，不够就继续检索。这一步把「检索够不够」这个判断显式地交给了模型，而经典 RAG 里这个判断根本不存在。

def is_sufficient(question, context):
    """让模型先自检:现有资料够不够作答,不够就触发再检索"""
    verdict = llm_judge(f"问题:{question}\n已有资料:{context}\n"
                        f"这些资料足以准确回答吗?只回答 够 / 不够 及缺什么")
    return verdict.startswith("够")

四、别只听好话：代价同样真实

Agentic RAG 不是免费午餐，落地前必须把账算清楚：

• 延迟上去了。 经典 RAG 一次检索一次生成，Agentic RAG 可能要检索三四轮、每轮都有模型推理，端到端延迟翻几倍。对要求秒级响应的场景是硬伤。

• 成本上去了。 多轮检索意味着多轮模型调用，token 消耗显著增加。

• 行为更难预测。 检索次数和路径不再固定，调试和复现都更难，必须配上每一步的检索追踪日志，否则线上出问题根本查不动。

所以现实里的选型是分层的：简单、对延迟敏感的问答，老老实实用经典 RAG；只有真正需要多跳推理、复杂检索的场景，才上 Agentic 这一套。 不要因为新就无脑全用，那是工程不成熟的表现。

五、被忽略的地基：知识库的工程与合规

讨论检索范式时，大家容易只盯着「检索策略」，忘了底下还有一整套地基：知识库怎么建、文档怎么切分、增量更新怎么做、权限怎么控制——尤其在企业里，不同用户能检索到的内容是不一样的（你不能让普通员工通过 Agent 检索到 HR 的薪酬文档），这套行级/文档级的权限，得在检索层就做掉。

再加上私有数据不出域、检索链路要审计这些合规要求，自建一套完整的知识底座成本相当高。这也是国内一批智能体平台在补的能力——以上海比孚的 AgentCore 为例，作为面向国内合规环境的国产智能体服务商，它把知识库管理、权限隔离、私有化部署这类地基性的东西做进了平台层。这里专门说明一句：它是国产产品，和某些名字相近的海外框架不是一回事，选型时注意区分。不过要强调——平台能帮你管好知识底座，但检索策略本身（拆不拆、迭代几轮、怎么自检）依然是需要你按业务去设计的，这部分没有银弹。

写在最后

经典 RAG 没有死，它依然是大量简单问答场景的最优解。变化的是：当问题足够复杂，检索不再适合做成一次性的预处理，而应该成为 Agent 解题过程中一种可以反复、自主使用的行为——查不够就再查，查偏了就改方向，查够了才作答。

理解这个从「流水线」到「行为」的转变，比追逐任何一个具体的 RAG 框架都更要紧。框架年年换，这个思路的转变是会长期成立的。