RAG 多索引路由别让所有问题都冲向同一个向量库一、多索引不是为了显得架构复杂RAG 系统做大以后知识来源会越来越多。产品文档、工单、代码仓库、FAQ、指标说明都可能进入知识库。如果全部塞进一个向量索引召回会变得混乱。用户问代码错误结果召回产品宣传用户问合同条款结果拉出客服话术。多索引路由的价值是先判断问题去哪查再进入检索。它不是炫技而是减少噪音、降低成本、提升权限控制精度。知识库像仓库东西多了就得分区不然找螺丝能翻出一箱水果。我们团队的知识库从 300 篇文档涨到 4000 篇以后单一索引的 Top-5 召回相关性从 0.78 降到了 0.52。不是因为模型变差了而是语义空间中不同领域的文档互相干扰。把按来源分拆成 5 个独立索引后各自 Top-5 相关性回升到 0.72-0.82。多索引的代价是路由层多一次分类调用但这点成本远小于让用户收到错误答案的代价。二、先路由再检索再合并多索引链路可以先做问题分类选择一个或多个索引再分别检索和合并结果。flowchart TD A[用户问题] -- B[路由器] B -- C{问题类型} C --|产品文档| D[文档索引] C --|代码问题| E[代码索引] C --|工单经验| F[工单索引] D -- G[候选合并] E -- G F -- G G -- H[重排和生成]路由可以是规则、模型分类或混合策略。高风险场景建议规则先兜底模型负责补充。规则路由的好处是稳定、可解释、零延迟。比如用关键词匹配 代码编译报错 走代码索引工单历史解决过 走工单索引。规则不够智能但不会跑偏。模型分类对复杂问题更灵活但会有偶尔的分类错误。混合策略先跑规则规则不确定时再走模型是一个务实的折中。三、路由结果要带置信度如果路由器不确定就不要只查一个索引。可以查两个高置信候选或者追问用户。type RouteDecision struct { IndexName string Confidence float64 Reason string } func SelectIndexes(routes []RouteDecision) []string { var selected []string for _, r : range routes { if r.Confidence 0.65 { selected append(selected, r.IndexName) } } return selected }阈值要通过评测调整。路由错了后面检索再强也没用。阈值不应该是一个全局固定值不同索引的风险不同。FAQ 索引误查没有大问题但合同索引误查可能给出错误法律建议。可以给小众但风险高的索引设置更高阈值降低误路由概率。四、索引路由要和权限绑定不是所有用户都能查所有索引。路由器输出候选后还要按权限过滤。不能因为模型判断应该查合同索引就绕过合同权限。还要考虑跨索引重复。FAQ 和产品文档可能有同一段内容工单里也可能复制了文档。候选合并时要去重并保留来源类型避免证据看起来很多实际来自同一份说明。最后路由指标要可观测。记录问题类型、命中索引、召回数量和最终引用来源。RAG 质量差时先看路由有没有跑偏。路由器还要处理兜底索引。分类器低置信时可以走一个小范围通用索引而不是直接全库搜索。全库搜索看起来保险实际会把噪音放大。兜底索引应该只放高质量、低风险、覆盖广的内容。多索引还会带来版本问题。不同索引重建节奏不同产品文档已经更新工单索引还停在旧版本答案就可能前后矛盾。候选合并时要记录索引版本和更新时间让生成器知道哪份证据更新。路由评测要单独做。不要只看最终答案好不好。准备一批问题标注应该查询哪些索引评估路由命中率和误路由率。路由错了后面全链路都在错误方向上努力。索引路由还要支持人工覆盖。有些业务问题短期内无法靠分类器稳定识别可以用规则把关键词或入口页面绑定到指定索引。规则不是倒退它是生产兜底。等样本足够再把规则沉淀到模型或分类器里。还要注意跨索引重排。不同索引分数尺度不一定一致代码索引的 0.7 和文档索引的 0.7 未必能直接比较。合并候选前要做分数归一化或者按索引内排名和证据类型重新打分。路由还要考虑问题的时效性。用户问最新版本的功能变化路由应该优先查最新索引问历史版本的问题可以查归档索引。时效信息有时比语义相似度更重要。五、总结RAG 多索引路由要先判断问题应该去哪查再执行检索。路由结果要有置信度并和权限过滤绑定。多索引不是为了复杂而是为了让知识库分工清楚、召回更干净。系统查得少一点、准一点往往比全库乱翻更可靠。