5.3.3 为什么关键词匹配在很多场景下仍然很重要？

先给结论：因为很多业务问题要求的不是“语义差不多”，而是“关键字必须对上”。只要系统里还大量存在术语、编号、产品名、接口名、法规条款这些对象，关键词匹配就仍然很重要。

这也是为什么在真实 RAG 系统里，很多团队最后都会重新重视：

• BM25
• 关键词检索
• 精确命中能力

为什么“语义接近”有时还不够

语义检索很擅长找：

• 说法不同但主题接近的内容

但真实业务里，很多时候你需要的是：

• 不要把接口名搞错
• 不要把产品型号搞错
• 不要把规则编号搞错
• 不要把术语边界搞错

在这些场景里，“差不多相关”是不够的。

因为用户要的往往不是泛泛主题，而是那个精确对象本身。

哪些类型的词特别需要关键词命中

尤其是下面这些词，往往更适合靠关键词匹配稳住：

• 产品型号
• 规则编号
• 法条编号
• 接口名
• 函数名
• 字段名
• 缩写词
• 品牌名
• 内部专有名词

这些词有一个共同特点：

• 它们的区分度很强
• 一旦搞错，结果通常就不是“有点偏”，而是直接答错对象

为什么这些场景里 BM25 往往更稳

因为 BM25 天然就重视：

• 词有没有出现
• 词是否稀有
• 词项命中是否具有区分度

而很多术语、编号、专名恰恰符合这个特点：

• 一出现，就很能区分内容身份

例如：

• createOrder
• XG-500
• “4.2.3 条”

这些内容的价值，往往首先来自“命中了它本身”，而不是“和它语义差不多”。

为什么中文场景下这点经常更容易被忽视

因为很多中文问题看起来像自然语言问答，但里面经常夹着：

• 型号
• 缩写
• 中英混合术语
• 内部专名

如果只盯着“语义理解”，很容易忽略这些真正决定准确率的关键词。

这也是为什么很多中文业务知识库里，单路向量检索经常会出现一种现象：

• 大方向没错
• 但关键对象经常差一点

而这“一点”，往往恰好就是关键词层的问题。

一个更实际的例子

假设用户问：

• “createOrder 接口的 idempotencyKey 是必填吗？”

这里最重要的信息并不是一个模糊主题，而是几个明确对象：

• createOrder
• idempotencyKey
• 必填

如果系统只做语义召回，它也许能找到很多：

• 下单接口
• 幂等控制
• 请求字段说明

但未必能稳稳命中这一个接口和这一个字段。

这就是关键词匹配仍然重要的原因。

为什么关键词匹配也不是“老办法凑合用”

它不是一个为了兼容旧系统而保留的古老能力，而是：

• 在某些问题类型上，本来就更适合的检索信号

也就是说，关键词匹配重要，不是因为它历史悠久，而是因为：

• 真实问题里本来就有很多场景更依赖字面精确命中

一个常见误区

很多人会觉得：

• 只要 embedding 模型足够强，术语问题迟早也能解决

这通常过于乐观。

因为有些问题的关键不是语义抽象能力，而是：

• 能不能精确抓住那一个词
• 能不能把它和别的近似对象区分开

这类问题里，关键词信号往往仍然是第一层保障。

一句话总结

关键词匹配在很多场景下仍然重要，因为很多业务问题要的不是“主题接近”，而是“关键对象必须命中”。只要系统里还大量存在术语、编号、接口名、型号和专有名词，关键词检索就很难被完全替代。