Agentic RAG的迭代成本与分流策略

Agentic RAG 的落地价值已经被讨论得很多，但真正让企业在选型时犹豫的，往往不是“能不能答对”，而是“这套系统到底要多贵”。这里的成本不只是算力账单，还包括链路复杂度、延迟、维护负担，以及最容易被忽视的——无效迭代造成的资源空转。把迭代成本看清楚，才知道该在哪些地方引入 Agent 能力，哪些地方继续用短路径。

传统 RAG 的检索是一次性的，路径短、延迟可控，对制度摘录、名词解释这类意图清晰的问题足够。它的真实短板在于，一旦第一轮召回偏离目标，后续生成只能在残缺上下文里“圆场”，而且没有任何机制发现这个错误。Agentic RAG 的改进本质上是把“检索一次就定稿”改成“检索—评估—再检索”的闭环，智能体可以在证据不足时改写查询、拆解子问题、并行查多源，生成后还能对照材料做一致性检查。这个闭环解决了复杂查询的准确率问题，但代价是每一次多轮调用都在叠加延迟和算力开销。

关键在于分流，而不是一刀切升级。一个可行的判断框架是：问题是否需要跨文档比对、是否包含多条件叠套、是否存在来源冲突需要核对。如果三个条件都不满足，走传统短路径效率最高；只有命中这些特征的问题，才值得进入带规划与验证的长路径。很多企业踩的坑是把所有流量都切到 Agent 链路，结果简单问答的响应时间从几百毫秒变成几秒，成本翻了几倍，准确率却没有实质提升。

迭代成本里还有一个容易被低估的部分：无效空转。智能体在证据不足时继续检索是对的，但如果缺乏停止条件，它可能反复改写查询、反复召回同一批低相关片段，最后生成一个看似完整实则没收敛的答案。所以在设计链路时，要给迭代设置明确边界——比如最大检索轮次、相关性阈值、以及“证据仍然不足时主动声明不确定”的兜底策略。这比无限堆检索次数更接近企业级可用性。

评估体系也要跟着调整。只盯“能不能答”不够，更值得记录的是关键依据覆盖率、冲突信息有没有被点明、答非所问的比例，以及平均检索轮次和端到端耗时。这些指标能直接反映迭代是在收敛还是在空转，也能为后续的成本优化提供依据。

对企业知识库来说，从传统 RAG 走向 Agentic RAG，不是把整套系统推倒重来，而是先识别出“一次检索经常失手”的问题类型，在这些链路上引入查询改写、子问题拆解和回答前校验。其他场景继续用短路径。把迭代成本算清楚，分流策略自然就出来了——准确率和成本从来不是二选一，而是按问题复杂度合理分配资源的问题。