布吉岛 Agent

Appearance

5.3.4 什么类型的问题更适合用 BM25？ ​

先给结论：当一个问题的核心在于精确命中某些词，而不是覆盖近义表达时，它通常就更适合优先用 BM25。

也就是说，判断是否更适合 BM25，关键不是看问题写得像不像自然语言，而是看：

  • 这个问题最重要的检索信号到底是什么

第一类：带明确编号的问题 ​

如果问题里带有明确编号，BM25 往往更合适。

常见包括：

  • 规则编号
  • 条款编号
  • 型号编号
  • 订单号格式说明
  • 错误码

这类问题的共同点是：

  • 编号本身就是最强区分信号

这时系统首先要做的，不是猜主题，而是先把这个编号命中。

第二类：带专有术语的问题 ​

如果问题里包含明确术语、专名、接口名、字段名，BM25 通常也更占优势。

比如：

  • 某个 API 名称
  • 某个数据库字段
  • 某个内部系统名称
  • 某个药品、零件、设备型号

这些对象一旦写出来，它们本身就比“语义接近”更值得优先相信。

第三类：要求高精度、容错空间很小的问题 ​

有些问题不是不能接受“差不多”，而是：

  • 一旦命错对象，结果就基本不可用

例如：

  • 具体接口说明
  • 明确型号参数
  • 指定法条条文
  • 某个配置项含义

这类问题里，系统宁可先精确抓对象，也不该一开始就过度依赖语义扩散。

第四类：查询本来就很短，但关键词区分度很强 ​

有些查询虽然很短，但并不模糊。

例如：

  • XG-500
  • ERR_1042
  • createOrder
  • idempotencyKey

这类查询里，最强信号不是上下文语义，而是这个词本身。

这时 BM25 往往比向量检索更直接、更稳。

第五类：文档本身就是术语密集型资料 ​

如果数据源本身大量由这些内容组成，BM25 价值通常会更高：

  • 技术文档
  • API 文档
  • 参数表
  • 法规条文
  • 设备型号说明
  • 产品目录

这些资料里，词项命中的意义往往非常强。

也就是说，不只是“什么问题适合 BM25”，还包括“什么数据天然更适合 BM25 作为重要召回信号”。

一个更实用的判断框架 ​

如果你拿到一个问题，不确定更该信 BM25 还是向量检索，可以先问这 4 个问题：

  1. 这个问题里有没有明确术语、编号、专名
  2. 命错一个关键对象，代价是不是很高
  3. 用户真正想找的，是某个精确对象，还是一个主题范围
  4. 这份知识库里，这类对象是否本来就区分度很强

如果这 4 个问题里有两到三个答案都偏向“是”，那通常就说明：

  • BM25 至少应该是重要信号之一

一个最小对比例子 ​

更适合 BM25 的问题 ​

  • “错误码 ERR_1042 表示什么？”
  • “createOrder 的 timeout 默认值是多少？”
  • “XG-500 的保修期多久？”

更适合语义检索的问题 ​

  • “怎么避免重复下单？”
  • “会员自动扣费怎么关？”
  • “什么情况下不能退款？”

两类问题的差别就在于：

  • 前一类更依赖精确对象
  • 后一类更依赖语义表达

一个常见误区 ​

很多人会把 BM25 理解成只适合“搜索框里输入几个词”的旧式搜索。

这不准确。

更稳的理解是：

  • 只要一个问题的关键在于精确命中词项，它就可能适合 BM25

哪怕这个问题表面上看起来是一整句自然语言，也一样成立。

一句话总结 ​

更适合用 BM25 的问题，通常都具备一个共同点：关键检索信号是精确词项本身，而不是语义泛化。只要问题里包含明确编号、术语、专有名词，或者命错对象代价很高，BM25 往往就应该优先参与召回。