6.3.3 什么是路由检索（Router Retrieval）？

先给结论：路由检索可以先理解成：系统在真正召回之前，先判断当前问题更适合去哪一路检索，然后把问题发到更合适的索引、检索器或检索策略里。

所以它的重点不是“多建几条路”，而是：

• 不让所有问题都走同一条路

为什么会需要路由检索

因为真实系统里的问题和数据往往并不统一。

例如同一个系统里，可能同时有：

• FAQ
• 产品政策
• API 文档
• 代码库

而用户的问题也会混在一起：

• 有的是术语型问题
• 有的是开放问答
• 有的是代码或接口问题

如果这些问题都走一模一样的检索策略，系统就很容易顾此失彼。

路由检索到底在路由什么

它路由的对象通常有几类：

1. 路由到不同数据源

• FAQ 库
• 文档库
• 代码库

2. 路由到不同检索方法

• BM25
• 向量检索
• 混合检索

3. 路由到不同粒度

• 文档级
• chunk 级
• 父子块

4. 路由到不同查询处理链

• 是否先 rewrite
• 是否先扩写
• 是否加 metadata filter

所以 Router Retrieval 的本质不是一个具体算法，而是一层：

• 检索前的分发决策

一个最小示意

if is_code_question(user_query):
    results = code_retriever.search(user_query)
elif is_policy_question(user_query):
    results = policy_retriever.search(user_query)
else:
    results = hybrid_retriever.search(user_query)

这段代码想说明的是：

• 同一个系统里，不同问题可以走不同检索器

真正重要的不是 if/else 本身，而是：

• 系统有没有先判断这类问题该去哪查

路由检索什么时候特别有价值

下面这些场景，通常尤其适合考虑路由：

1. 系统同时接入多种差异很大的数据源
2. 一部分问题明显偏 FAQ，一部分明显偏文档或代码
3. 不同问题适合的召回粒度差很多
4. 单一路径已经表现出明显的偏科

这类场景里，继续硬调单一路径往往越来越吃力。

Router Retrieval 和 Multi-Retrieval 的区别

这两个概念容易混。

可以先这样理解：

• Router Retrieval 更像先判断“该走哪一路”
• Multi-Retrieval 更像“几路一起召回，再合并”

一个偏分流，一个偏并行。

两者都可以存在，但解决的问题不完全一样。

一个常见误区

很多人会把路由检索理解成：

• 一定要有一个非常复杂的智能路由器

这不一定。

更稳的起步方式往往是：

• 先从简单、可解释的路由规则开始

比如：

• 代码问题走代码库
• 规则编号问题优先走 BM25
• FAQ 问题先走 FAQ 检索器

先把大类分开，往往就已经能明显提升稳定性。

一句话总结

路由检索就是在召回之前，先判断当前问题该去哪一路检索。它解决的不是单个检索器强不强，而是不同问题本来就该走不同路径。只要数据源、问题类型或检索策略差异足够大，路由就会很有价值。