6.3.4 为什么不同问题类型应该走不同检索策略？

先给结论：因为不同问题真正依赖的检索信号并不一样。有人要找术语，有人要找语义，有人要找整篇文档，有人只要一个局部条件。如果所有问题都走同一套检索策略，系统很容易在某一类问题上长期偏科。

所以检索策略分流不是为了让系统更花哨，而是为了让不同问题走对更适合自己的路径。

不同问题到底差在哪

至少常见会差在这几层：

• 查询表达方式不同
• 所需精度不同
• 依赖的上下文范围不同
• 数据域不同

例如：

• “错误码 ERR_1042 表示什么？”
• “会员自动扣费怎么关？”
• “这份退款政策主要讲了什么？”
• “createOrder 的 timeout 默认值是多少？”

这四类问题显然不适合完全同一种检索方式。

为什么硬走同一路径会出问题

如果所有问题都用同一路策略，常见后果是：

• 术语问题精度不稳
• 长文档问题上下文不完整
• FAQ 问题召回太散
• 代码和接口类问题经常偏题

这些问题未必会平均出现在所有查询上，但它们会在某些问题类型上反复出现。

这就是“系统平均看着还行，但某些类问题总翻车”的根源。

一个更实际的分流思路

你可以先把问题粗略分成几类：

1. 精确对象型问题

例如：

• 编号
• 型号
• 接口名
• 字段名

这类更适合优先强调：

• BM25
• 精确匹配

2. 语义问答型问题

例如：

• “什么情况下不能退款？”
• “怎么关闭自动续费？”

这类更适合优先强调：

• 向量检索
• 混合检索

3. 文档理解型问题

例如：

• “这篇文档主要讲了什么？”
• “这个政策整体范围是什么？”

这类往往更适合：

• 文档级检索
• 文档聚合后的再处理

4. 复杂约束型问题

例如：

• 带版本
• 带租户
• 带权限
• 带产品边界

这类往往更依赖：

• metadata filter
• 先路由再检索

为什么这件事本质上是“问题分类”

不同检索策略之所以要分流，本质上是因为系统先要判断：

• 当前问题属于哪一种检索形态

这也是为什么查询理解、rewrite、filtering、routing 这几章内容其实是连在一起的。

你只有先看清问题类型，后面的检索策略才不容易走错。

一个常见误区

很多人会把这个问题理解成：

• 我要选一个最强检索器，把所有问题都交给它

这通常是错误方向。

更稳的方向通常是：

• 承认不同问题本来就依赖不同信号
• 再让系统做适当分流

因为真实系统里，真正缺的常常不是“最强单点”，而是“对不同问题做不同处理”。

一句话总结

不同问题类型应该走不同检索策略，因为它们依赖的信号、精度、上下文范围和数据域都不同。把所有问题都塞进同一条检索路径，系统往往会长期偏科；做适当分流，反而更稳。