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 多索引路由要先判断问题应该去哪查，再执行检索。路由结果要有置信度，并和权限过滤绑定。多索引不是为了复杂，而是为了让知识库分工清楚、召回更干净。系统查得少一点、准一点，往往比全库乱翻更可靠。