结论先摆：当你有好几个知识库（产品库、售后库、政策库……），千万别把用户问题一股脑甩给所有库一起检索。正确做法是在前面加一道"路由"——先判断这个问题该去哪个库，选定了再进那个库检索。我这么改完之后，召回准了，速度也快了。
为什么要先选库
我维护过一个客服 Agent，挂了三个知识库：产品功能、退换货政策、账户安全。一开始我偷懒，所有库合并成一个大库检索。结果用户问"怎么退货"，向量召回里混进来一堆"产品功能介绍"的内容，因为这些文档里也常出现"退"这个语境相近的词。答案就被污染了。
合在一起检索还有个问题：库一大，噪声就多，topK 里塞满了不相关库的内容，真正该出现的政策条款被挤下去。
分库 + 路由就解决了这个。问"退货"先路由到政策库，只在政策库里检索，干净。
路由怎么配
我用的是一个能拖拽配流程节点的低代码平台，路由这步我试过两种做法：
做法一：让模型来分类。在检索之前加一个判断节点，给模型一段提示，让它根据用户问题输出该走哪个库。提示我是这么写的：
用户问题：{question} 请判断该问题属于以下哪个知识库，只输出库名： - product：产品功能、使用方法、参数配置 - policy：退换货、退款、售后政策 - account：登录、密码、账户安全 若都不匹配，输出 none。模型输出库名后，流程根据这个名字路由到对应的检索节点。这种方式灵活，能处理口语化、模糊的提问，是我目前主力用的。
做法二：关键词规则路由。命中某些词就强制走某个库，比如出现"退款/退货"直接进政策库，不走模型判断。这种快、稳、零成本，但只能覆盖词面明确的情况。
我现在是两者叠着用：能用规则秒判的先走规则，规则兜不住的再交给模型分类。纯规则覆盖不全，纯模型又慢一点还要花 token，叠起来性价比最高。
几个坑
一是none这个兜底分支一定要留。用户问的问题三个库都不沾边时，模型如果被逼着必须选一个，会硬塞进最像的那个库，然后检索出一堆不相关内容硬答。留了 none，我就让它走"暂无相关资料"的话术，比瞎答强。
二是路由节点本身会引入一点延迟和 token 开销，因为多了一次模型调用。我这边多了几十到一百毫秒，问题不大，但如果你的库就一两个，其实没必要上路由，直接检索更省事。路由是库多了之后才划算。
三是库的边界要设计清楚。如果两个库内容本身就重叠（比如"账户安全"和"政策"都讲到了封号），路由会反复纠结，分类不稳。这种情况要么合库，要么把边界重新切干净。
整体下来，多库路由最大的收益是召回干净——每个库专注自己的领域，检索结果的信噪比高了一大截。代价就是多一道判断、流程复杂一点，调试时要多看一个节点的输出对不对。
模型那层我接的讯飞星辰 MaaS，路由判断和最终回答都调它的现成接口，没自己部署算力。
