如果你的RAG系统上线之后用户问一句你好向量检索也能认认真真去知识库里找有没有你好的答案那说明你正处在大多数RAG项目从Demo走向生产的第一道坎上。我之前给某公司的客服知识库做过一套问答系统初期就是标准的召回-重排-生成三段式管道日志里每天都是一堆无意义检索用户明明在闲聊系统却拿闲聊问句去库里捞了六七条都不相关的文档最后大模型只好在几段不相干的文本里硬编一个答案。后来我把它推倒重来按Agentic RAG的思路去重构核心就落在两件事上查询路由和Web兜底。简单说系统在真正动手回答问题之前先判断这个问题需不需要检索、应该检索哪里、本地知识库能不能兜住本地兜不住的时候再考虑外部实时信息。这篇文章是系列的上篇重点把查询路由怎么设计、Web兜底怎么接进来讲清楚还会附上我在实际运行中踩过的三个坑。适合那些已经跑通普通RAG、正准备让它变得更聪明的开发者。如果你还在纠结为什么我加了知识库回答还会乱飘这类问题这篇应该能给你一个比较明确的思路方向。1. 让RAG长脑子之前为什么不能所有问题都走检索1.1 三个典型的失败案例先说我实际遇到过的三类问题它们几乎把你的RAG系统架在火上烤。第一类是寒暄和情绪类问题。用户上来一句你好在吗或者你们这个功能太难用了我要投诉。这类query送进向量检索知识库里根本没有对应文档召回结果全靠字面相似度硬凑。模型生成的回答看似礼貌实际上既没有信息量又让用户觉得机械。第二类是知识库版本滞后。客服知识库往往三个月才更新一次用户问最新版本是不是修复了某个问题本地库里的资料还是旧版。系统召回的是旧文档模型一本正经地告诉你没有修复实际上厂商早就改了。这不是模型笨是知识库本身没有答案。第三类是长尾新词和实时事件。比如某个新产品刚发布了一款配件用户问这个配件能不能用在老型号上知识库里没有收录这个配件的任何资料。传统RAG的处理方式是没有答案也硬答或者召回一些语义相近但实际无关的内容把问题带偏。这三类问题的共同点是问题本身超出了知识库的覆盖范围。RAG的本质是用有限的知识库回答有限范围的问题一旦问题超出边界检索这一步不是帮你补充信息而是在引入噪声。1.2 传统RAG管道的问题出在哪传统RAG管道是一个线性流程query进embedding模型做相似度检索取top-k文档拼进prompt交给大模型生成。这个流程有一个隐藏假设——所有问题都能在知识库里找到答案。但现实不是这样。你可以在系统里做一个简单统计拿一周的真实用户日志人工标记每条query是否能在知识库中找到标准答案。我做过一次结果大概只有六成问题真正依赖知识库其余四成要么是闲聊、要么是需要实时信息、要么是知识库根本没有覆盖的开放问题。这说明什么如果不对问题进行分流RAG至少有三成以上的检索调用是浪费的而且浪费的不只是算力还有回答正确率。这也是Agentic RAG和普通RAG最大的区别普通RAG把检索当作固定管道Agentic RAG把检索决策权交给系统自己。所谓Agentic在这里不是花哨的什么自主智能而是指系统在回答前先做一个判断——这个判断本身也是推理的一部分。1.3 从流程到决策循环的转变传统RAG和Agentic RAG的核心差异可以总结成下面这个表格维度传统RAG管道Agentic RAG问题定位默认所有问题都能在KB中找到先判别问题类型再决定路径检索策略固定走向量检索路由到KB、Web、聊天或工具失败处理检索不到就硬答触发Web兜底或明确告知无法回答响应延迟每条都做完整检索简单问题走快路径复杂问题走慢路径适用场景封闭知识库问答混合型问答、实时性要求较高的场景从工程角度看这个转变不是推翻重来而是给现有RAG管道加一个大脑。哪怕你暂时只做一个简单的二分路由——需要检索和不需要检索——回答质量都会有明显提升。下面开始说路由具体怎么做。2. 查询路由的第一道筛子先做类型识别而不是直接调模型2.1 四类问题与对应处理路径我先给问题分了四类实际起手可以改成三分类但设计时建议按四类预留。chat闲聊寒暄、情绪表达、与业务无关的开放话题。不检索直接让模型用自身能力回答或者走一个固定的礼貌话术。kb知识库内部问题产品规格、内部流程、售后政策、常见FAQ。走本地向量检索。web实时或外部信息时效性强、知识库没有覆盖、用户明确要求查最新信息。走搜索加抓取。tool需要计算或外部工具查时间、算数学、换算单位这类问题。先不做也行但路由里要留一个未识别通道避免强制塞进kb。很多团队上来就想让大模型做全部路由我的建议是不要。直接调LLM做路由看起来省事但每条query都多一次模型调用延迟和成本都会上升而且模型对规则的执行远不如规则本身可靠。更合理的做法是分级先用规则层挡住明显的简单类型规则层处理不了的才交给模型判断。2.2 Fast Track规则怎么定才不容易误伤规则层不需要搞得特别复杂我用了三个手段精确词表、正则匹配、极简意图分类。伪代码如下可以直接参考import re CHAT_KEYWORDS {你好, 在吗, 谢谢, 再见, 你是谁, 你能做什么} TOOL_PATTERNS [ r天气, r几点了, r算一下, r换算, r日期, ] def fast_route(query: str): q query.strip().lower() # 1. 精确词表命中率极高直接走chat if q in CHAT_KEYWORDS: return chat # 2. 正则命中说明是工具型请求 for pattern in TOOL_PATTERNS: if re.search(pattern, q): return tool # 3. 如果query明显很短且以疑问结尾交给上层决策 return None # 需要进一步判断这样设计有几个直接的收益便宜、快、稳定不需要经过大模型就能拦下一部分流量。实测中规则层能接住大概60%到70%的query剩下的30%左右才真正需要模型路由介入。在客服场景里这部分被规则层拦住的query基本就是高频寒暄词和固定句式模型的压力瞬间小了很多。2.3 规则层为什么不能当最终答案规则层虽然好用但短板很明显它不懂语义变形。用户说你们到底几点上班正则可以被几点命中归到tool类但用户说你们工作时间是什么规则层就蒙了语法上看起来是知识库问题。这就是为什么规则层的输出只能作为建议路由传给模型而模型需要结合完整上下文做最终判断。我在这套系统里的做法是规则层先给出一个候选类别如果候选类别可信度极高比如精确词表命中就直接短路返回否则把候选类别作为一个附加提示塞进路由prompt里让模型知道系统倾向于把它归为某类但你可以修正。这样一来规则层省了成本模型层补了语义理解两者互补而不是互相替代。3. 模型路由决策构造一个最小但完整的路由Prompt3.1 路由决策需要拿到的三样信息模型路由不能只让模型输出一个标签。只给标签系统根本不知道这个判断靠不靠谱出了问题也没法复盘。我在路由输出里固定了三样信息路由类型、置信度、判断理由。置信度尤其重要。模型说我觉得这是kb问题置信度0.9和置信度0.4的处理方式完全不同。前者可以直接信任后者就要准备回退策略。判断理由是为了做日志复盘比如线上出问题的时候你能看到模型因为用户提到了某个产品名而选择了web然后针对性修正。3.2 可落地的一段路由Prompt模板下面是我实际在用的路由Prompt做了一点脱敏简化。注意几个细节路径定义必须具体判断规则必须明确知识库优先输出格式必须是结构化JSON。这是减少误路由的关键。你是问答系统的路由判断器。用户问题可能属于以下路径 - kb知识库有稳定答案的内部问题产品、流程、政策、FAQ - web知识库覆盖不了需要实时信息或外部资讯的问题 - chat寒暄、闲聊、与业务无关的开放话题 - tool需要计算、时间、天气等外部工具的问题 判断规则 1. 知识库优先只要问题看起来是内部知识类就选kb。 2. 只有知识库明显无法覆盖且实时性或外部信息很重要时才选web。 3. 不确定时confidence必须低于0.6。 用户问题{query} 只输出JSON不要输出其他文本 {route: kb, confidence: 0.0, reason: 一句话判断理由}一个小经验最关键的其实不是那些花哨的路径描述而是那句知识库优先。如果不写这句话模型面对稍微模糊一点的问题时会倾向于选web因为它普遍觉得web更全面。加了这句之后误路由率肉眼可见地降下来。3.3 输出解析与低置信度回退路由模型的输出不一定会严格合法所以解析这层必须有容错。先用json.loads解析失败就正则提取route和confidence字段再失败就默认走kb路径——宁可本地查不到再兜底也不能随便跳到外部搜索去浪费成本。置信度回退策略我建议这样定confidence低于0.6时强制走kb路径。这个设计的逻辑是本地检索即便答不上来你还能后续接Web兜底但如果路由错了直接跳到Web延迟和成本都会失控。一条query最多做一次Web兜底如果搜完抓完还是没有高质量答案就要明确告诉用户我暂时没查到而不是反复重试。3.4 路由评测不靠感觉靠标注集路由这类模块很容易你觉得它还行因为大部分问题确实能被正确分类但你注意不到那些偶尔分错的。我的做法是攒一批人工标注测试集50到100条真实问题覆盖四类路径然后跑路由统计关键指标指标含义初版建议参考路径一致率路由结果与人工标注一致的比例≥85%kb误截率该走web却走了kb的比例≤5%web过度率不该走web却走了web的比例≤10%解析失败率模型输出无法被解析的比例≤1%这套pprompt我前前后后改了七八版改一次跑一遍标注集很快就知道哪里过度、哪里不足。路径一致率从最初的78%提到92%靠的就是这个标注集。4. 本地检索没把握时的Web兜底不是接API而是接可信信号源4.1 什么时候才真正走Web路由判为web只是第一步真正进入Web兜底流程还应该有触发条件。我在系统里做了三个知识库召回结果全部低于预设的相关性阈值或者top-k结果里最高分都不够格。query中包含明显的时间敏感词比如最新目前今年刚刚。用户明确表达了网上查一下这类需求。这里要强调的是Web兜底是兜底不是常态。如果系统里大量问题都在走Web说明知识库更新频率或内容覆盖有问题这时候该修的是知识库而不是扩大Web流量。4.2 搜索、抓取、过滤、引用四步走Web兜底流程我拆成四步查询改写、搜索结果获取、正文抓取与清洗、引用标注。很多人只做到了前两步直接把搜索API返回的摘要扔给模型效果很差。搜索API的摘要通常只有一两句而且经常截断模型只能凭那半句话硬编幻觉率非常高。查询改写也很重要。用户口语怎么办理社保卡直接搜效果一般改写成办理社保卡 流程 官方会好很多。改写时可以利用模型也可以提前配置规则具体取决于你的流量规模。4.3 正文抓取与语料组装实践抓取正文之后不能直接把整页HTML喂给模型。要把导航、广告、评论区全部清洗掉提取正文纯文本同时保留发布时间和页面URL。我会把清洗后的网页按如下格式拼进上下文给模型提供可引用的清晰来源[来源1] 标题某产品官方文档配件兼容性说明 发布时间2025-03-12 正文片段该配件支持2024年以后发布的所有型号老型号需要额外购买转接头。 [来源2] 标题某社区测评配件实测体验 发布时间2025-03-14 正文片段作者测试了老型号机器未发现兼容问题但转接头需要单独安装。如果你用的模型上下文窗口不大正文片段要按相关性截断。我一般只保留与query最相关的两到三个来源每个来源给两三个关键片段避免上下文过长稀释注意力。4.4 回答纪律模型在Web结果上的约束Web语料拼接进prompt之后还要在prompt里加回答纪律。最核心的是下面几条缺一条效果都会打折只能依据提供的来源列表作答禁止使用模型自带的百科知识补充。句子结束后标注来源编号比如根据官方文档[来源1]。所有来源都没有覆盖的信息直接说我目前没有查到不要编。优先采用发布时间最近的来源尤其是用户问的角度涉及时效性时。我把这些约束直接写死在系统prompt里而不是靠模型自觉。实际跑下来Web兜底回答的引用准确率从大概七成提升到了九成以上。4.5 Web兜底的验收标准接Web兜底之前最好先建立验收标准不然你根本不知道它到底是变好了还是变坏了。我的经验是选10条知识库没有、但外部应该有稳定答案的query例如某公司最新产品发布会的日期、某配件支持列表这类问题。要求是至少8条能给出正确答案且每条正确答案都标注了可验证的来源。达不到就继续调整查询改写和抓取清洗的逻辑直到达标为止。5. 上线后的实测三个容易忽略的坑与决策留痕5.1 坑一路由对了答案还是错问题出在正文没做二次筛选上线第一周我遇到一个很诡异的现象路由判断全部正确——该走web的走web该走kb的走kb——但用户反馈答案质量还是很差。查日志发现Web兜底把搜索结果里的前两三条标题和摘要当成了权威结果抓回来的正文跟用户问题关系并不大。搜索排序解决的是哪个页面更受欢迎不是哪个页面内容正好回答这个问题。后来我加了一个轻量re-rank步骤把抓回来的每段正文和用户query分别做embedding算相似度低于阈值的片段直接丢弃只保留最相关的片段进prompt。这一步成本很低却把Web兜底的回答质量拉高了一个档次。记住搜索API的排序不可直接信任你的系统要有二次筛选的能力。5.2 坑二Web兜底也会答非所问因为没有做时间戳校验另一个坑是时间。用户问某产品目前支持哪些设备系统搜到了一篇半年前的介绍文章内容详实、相关度高、embedding相似度也高于是模型把半年前的信息当成目前的情况答出去了。用户发现给的是过时信息比直接说查不到还糟糕。解决办法有两个层面一是语料清洗时保留发布时间二是在生成prompt里明确用户询问时效性信息时优先采用发布时间最近且来源可验证的结果。我当时把发布时间作为排序因子之一时间太旧的来源权重直接降一档问题才基本解决。5.3 坑三没有成本护栏路由一度全部走Web现在说一个我最肉疼的教训。上线首周的一个下午我瞄了一眼监控发现Web兜底占比冲到了50%以上平均延迟从1.5秒飙到5秒以上。查原因发现路由prompt里写了一大堆路径定义却漏了知识库优先那条规则模型面对稍微模糊一点的问题就倾向选web。这个比喻你可能觉得夸张但真的就是少了一句话的事。修复之后Web占比降到了20%-30%延迟基本回到正常。放一张我实测记录的参考分布不是标准答案但可以作为判断你的系统是否健康的参照路径流量占比平均延迟参考kb本地知识库60%-70%1-2秒web搜索兜底20%-30%3-6秒chat闲聊/对话5%-10%0.5-1秒tool计算/工具少量1-2秒如果Web占比长期超过40%不是知识库太弱就是路由prompt出了问题得回头查。5.4 让路由变得可观测每次决策都要留痕最后这部分看起来不性感但非常关键。路由模块上线后我要求每一条query都必须打结构化日志字段包括query原文、路由结果、置信度、判断理由、是否命中规则层、是否走了Web兜底、最终引用的来源列表、总耗时。没有这批日志后面任何调优都是在猜。有一次线上问答突然变差就是因为某个新词触发了路由规则层的误判把kb问题划成了web。没有日志的话你可能要费半天劲才能定位有了判断理由字段一眼就看到问题出在正则匹配上。我个人在实际操作中最大的体会是Agentic RAG不是让模型自动做所有事而是把要不要检索、检索哪里、结果够不够用这些原本由开发者拍板的决策变成系统内部的显式环节。上面的路由和兜底架子搭完之后下一步我准备把知识库没答案时的追问动作也交给模型自己决策那是下一篇要展开的内容。先把这个路由和兜底的根基打牢再谈更复杂的自主行为否则任何高级功能都是建在沙子上。