企业级 Agentic RAG 落地：让系统自动决定检索几轮

一、上篇的终点就是本篇的起点上篇我们用 RAG 架构搭好了企业级知识库混合检索 重排 记忆沉淀都上了。数据一度很好看朴素 RAG 的召回率能做到 70%进阶 RAG 拉到 92%单轮检索的平均准确率到 85%。但一到生产真正把我们卡住的不是答不准而是同一套检索配置面对不同难度的问题表现忽高忽低。用户问企业 AI 系统一般多少钱一轮检索就够答案干净利落用户问老板让我评估上不上企业 AI 系统我要从哪几个维度给大家做汇报这一轮检索就明显不够——它需要跨成本选型落地风险好几个主题去找材料。固定单轮检索有个天然的矛盾要么召回不足难题漏材料要么噪声太大简单题喂一堆废话。而问题是不知道用户接下来会问哪一种的你又不可能对每个问题都跑十轮。我们团队在做 XEAOS企业 AI 操作系统的知识中枢时被这个瓶颈卡住过很久。最后落的方案不是把检索轮数调成一个魔法数字而是让系统自己判断这一题到底该检索几轮。这就是本文要讲的 Agentic RAG。二、自适应检索轮数把检索从一步变成一个可规划的循环先别想得太玄。Agentic RAG 的本质就一句话把原来固定的一次检索变成检索 → 评估 → 决定要不要再检索的循环。我们落地时没有一上来就上复杂框架而是先按直觉把流程排出来排成了三个按顺序走的动作第一档先直接检索。所有问题都先正常做一轮混合检索 重排拿到结果和一个置信分数。第二档置信不够 → 改写 Query 再检。如果第一轮的分数低于阈值大概率是这个问题用户没问清楚、或者我们的检索词表达和知识库原文对不上。这时不急着多检先改写一下提问换个说法、补上同义词再检一轮。第三档还不行 → 拆子问题分步检索。如果改写后还是低分说明这不是问法不对而是这个问题本身跨了多个主题。那就把它拆成几个子问题每个子问题单独检索一轮把结果拼起来。每一轮的末尾都有一个自评动作这一轮拿到的材料够不够支撑回答不够就再往下走一档够了就停把材料交个通用模型去组织答案。我们只定了一条简单的判定线作为门槛首轮 top-1 相似度的得分低于某个阈值才触发第二档。剩下的靠自评兜底。这条线不严谨、不是最优解但它够用而且让我们先把整条链路跑通——这是我们在工程上一直坚持的原则先跑通真实链路再谈抽象和优化。三、技术落地一小段能看懂核心逻辑的代码写代码不是这篇文章的重点太多人也绕不开所以我只放一小段、用中文注释讲清低置信 → 改写 → 再检 → 复核 → 出引用这条主循环。核心就一个函数先检、评、看够不够、不够就循环Pythondef agentic_rag(question, retriever, llm, threshold0.7):# 第一档先正常检一轮docs, score retriever.search(question)if score threshold:return llm.answer(question, docs) # 够直接答# 第二档改写提问再检一次q2 llm.rewrite(question) # 换个说法 / 补同义词docs2, _ retriever.search(q2)if len(docs2) 0:return llm.answer(question, docs2) # 有材料就用# 第三档拆子问题每个子问题单独检一轮合并subs llm.plan(question) # 拆成 2~4 个子问题all_docs []for s in subs:d, _ retriever.search(s)all_docs dreturn llm.answer(question, all_docs)def agentic_rag(question, retriever, llm, threshold0.7):# 第一档先正常检一轮docs, score retriever.search(question)if score threshold:return llm.answer(question, docs) # 够直接答# 第二档改写提问再检一次q2 llm.rewrite(question) # 换个说法 / 补同义词docs2, _ retriever.search(q2)if len(docs2) 0:return llm.answer(question, docs2) # 有材料就用# 第三档拆子问题每个子问题单独检一轮合并subs llm.plan(question) # 拆成 2~4 个子问题all_docs []for s in subs:d, _ retriever.search(s)all_docs dreturn llm.answer(question, all_docs)就这么一段。真实生产里你还要加去重、引用编号、超时保护但骨架就是这三档循环。杠杆全在那个 score threshold 上——它决定了这一题要不要再多花延迟去换更高的召回。四、工程代价我们踩的三个坑Agentic RAG 不是白捡的精度是有代价的。我们实测的数据准确率从进阶 RAG 的 85% 提到 91%但延迟翻了 3 倍。91% 的准确率增量是用延迟和成本换来的。第三个坑我们踩得尤其深坑一延迟失控。多轮检索天然更慢3 倍延迟在对话场景是能体感出来的。我们的解法是把 threshold 调高一点让大多数简单问题只走第一档就停——用一轮的代价换大多数时候的即时响应。坑二召回外溢。拆子问题拆过头会检回来一堆不相关的材料反而污染答案。后来我们给每个子问题也套了置信过滤低分的子问题直接丢弃。坑三幻觉兜底。多轮检索以后模型更容易把跨轮拼来的材料里没有的事实脑补进去。我们用两层兜底强制模型给每个事实标引用编号再对低置信的回答做拒答处理——资料不足就明说不硬编。这也是我们用来回答多检的轮到底值不值的方法不看感觉看命中率增量。如果多跑一轮只能把名义准确率提零点几个点但要付 3 倍延迟这个增量就是亏的只有当多检明显补回了跨主题的关键材料时这笔延迟才花得值。五、完整小节从工作台到运行时到这里多数 Agentic RAG 的文章就收尾了。但我们踩完坑回头复盘发现一个更深的问题如果把召回不够就改写、再不够就拆子问题这套逻辑写死在某个对话服务的 Prompt 里那它再聪明,也是一个会拆题的聊天工作台。 能力长在界面层一换业务场景就要重写难演进、难复用、难观测。这也是市面上很多企业 AI 系统的通病——它们把系统做成一个功能堆砌的工作台一个聊天框一堆工具按钮能力全是硬编码的。界面看着丰富核心其实很僵。我们做 XEAOS 时换了个思路一句话概括就是Workspace 是界面真正的系统是 Runtime。所谓 Runtime翻译成大白话就是把一件具体能力比如检索生成编排记忆从一个写死的页面里抽出来封装成一个有明确接口、能独立调度、只看输入输出的运行时模块。每个 Runtime 只干一件事对外暴露统一的接口可以被系统随时调用、组合、升级。回到 Agentic RAG 这里那个检索几轮、查哪个源、要不要再证的自适应逻辑我们没有把它做成某个聊天框里的 prompt而是做成了 Knowledge Runtime管检索与知识读写 Agent Runtime管意图与任务拆解 Workflow Runtime管流程编排 三个运行时之间的协作。Knowledge Runtime 只要回答给一个查询返回相关材料Agent Runtime 只负责判断这个问题要不要拆、拆成几个Workflow Runtime 把前面两个串起来决定循环怎么走、何时停。这三个模块互相不知道对方内部怎么写只通过接口通信。于是这套 Agentic RAG 不再属于任何一个页面而是系统层面可复用的能力。今天它服务于知识问答明天同样的编排就能服务于别的业务——能力长在了系统层而不是界面层。这就是我们理解的差别普通企业 AI 系统是堆出来的工作台能力强依赖页面密我们自己搭的系统是跑起来的运行时能力由模块编排而来可以一圈圈向外扩展。RAG → Agentic RAG → 企业 AI 运行时一路走下来的三级递进落点不是某个更聪明的算法而是架构立场的转变。