多知识库路由：一个入口先选库再检索

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