6.2.2 什么是 Query Expansion？什么时候要扩写查询？

先给结论：Query Expansion 可以先理解成：在保留原始查询核心的基础上，补充更多可能有助于召回的词项、别名、同义表达或子查询，从而扩大候选覆盖范围。

所以它和 rewrite 不一样。

• Rewrite 更像把问题说清楚
• Expansion 更像给问题补更多召回可能性

Expansion 到底在补什么

它最常补的通常是这些东西：

• 同义词
• 别名
• 近义表达
• 相关术语
• 缩写和全称
• 多个子查询视角

例如用户问：

• “自动扣款怎么关”

系统可能扩出：

• 自动续费
• 自动续订
• 取消会员扣费

这时系统不是把原问题改掉，而是在补更多召回入口。

为什么需要 Expansion

因为很多知识库里的表达并不统一。

可能会同时出现：

• 不同团队写法不同
• 中英文术语并存
• 用户说法和文档说法不同
• 同一概念存在多个别名

如果系统只查原始写法，常见风险就是：

• 召回面太窄

扩写的价值就在于：

• 给系统更多“可能命中的入口”

一个最小示意

query = "自动扣款怎么关"

expanded_queries = [
    "自动扣款怎么关",
    "关闭自动续费",
    "取消自动续订",
    "停止会员自动扣费"
]

这段代码想说明的是：

• 扩写不是替换原查询
• 而是围绕原查询补出更多候选表达

什么情况下更值得做 Query Expansion

1. 同义表达很多

如果一个概念本来就有很多叫法，扩写通常很有价值。

例如：

• 自动续费 / 自动续订 / 自动扣款
• 发票 / 开票 / 票据

2. 用户用词和知识库术语差异大

如果你已经观察到用户常说的话和文档常写的话不一样，扩写通常能补召回。

3. 查询本身太短，信号不足

有些查询非常短，例如：

• “续费”
• “报销”
• “保修”

这时适当补一些相关词，有时能让召回更稳。

4. 多语言、缩写和别名很多

例如：

• API 名称既有英文，也有中文描述
• 产品既有型号名，也有内部简称

这类场景下，扩写通常比只查原词更稳。

为什么扩写不能无节制

扩写虽然能补覆盖，但也会直接带来风险：

• 噪声增加
• 意图被扩散
• 候选变杂
• 后续重排负担变大

如果扩得太猛，系统很容易把“补召回”做成“稀释查询”。

所以更稳的做法通常是：

• 只扩那些和当前意图真正相关的表达

而不是把所有沾边的词都塞进去。

Rewrite 和 Expansion 的区别到底在哪

可以先用一句话区分：

• Rewrite 是把问题整理得更明确
• Expansion 是给问题增加更多召回入口

有时两者会一起出现，但角色不同。

例如：

1. 先把“那企业版这里是不是也一样？”改写成完整问题
2. 再对“企业版退款规则”补充同义术语或产品名

一个常见误区

很多人会把 Query Expansion 理解成：

• 只要召回不够，就继续扩词

这很危险。

因为有些问题不是扩写不够，而是：

• 路由错了
• 过滤没加
• 索引本身就不对

这时继续扩写，只会把更多噪声带进来。

一句话总结

Query Expansion 是在保留原始查询核心的基础上，补充更多可能有助于召回的词项和表达，从而扩大覆盖范围。它适合解决同义词、别名、术语差异和短查询信号不足的问题，但扩写过度同样会污染召回。