Appearance
6.2.1 什么是 Query Rewrite？什么时候要改写用户问题？
先给结论：Query Rewrite 可以先理解成：在不改变用户核心意图的前提下，把原始提问改写成更清晰、更完整、更适合检索的查询。
所以它的目标不是“把句子写漂亮”，而是：
- 让后续召回更容易抓住真正核心
Rewrite 到底在改什么
它通常改的不是答案，而是查询表达形式。
常见会做的事情包括：
- 补全省略对象
- 还原代词指代
- 把口语表达改成更明确的检索表述
- 去掉无关铺垫
- 把多轮对话里的短句恢复成独立可查的问题
也就是说，Rewrite 的本质是：
- 把“对话语言”变成“检索语言”
一个最小示意
python
raw_query = "那企业版这里是不是也一样？"
rewritten_query = "企业版退款规则是否与个人版一致"这段代码想说明的是：
- 原始问题对人类对话成立
- 改写后的问题对检索器更友好
什么情况下尤其需要 Query Rewrite
下面这些情况，通常更值得先做改写：
1. 多轮对话里的短句和代词句
例如：
- “那这个呢？”
- “这个规则也适用吗？”
- “如果不是企业版呢？”
这类输入如果不先补全，后面很难直接稳定召回。
2. 很长的口语化表达
例如用户把背景、情绪和多个铺垫都混在一起说。
这时 rewrite 的作用是：
- 抽出真正要查的核心对象和条件
3. 用户说法和知识库说法差异明显
例如用户问：
- “自动扣款怎么关”
而知识库更常用：
- “关闭自动续费”
这时 rewrite 可以把问题改成更贴近知识库表达的检索形式。
4. 一个问题里同时带着多个条件
例如：
- “如果是定制商品，而且已经发货了，还能不能退？”
有时系统需要先把条件表达整理清楚，再送入后续检索。
Rewrite 不等于随意改写
这点非常重要。
Query Rewrite 的前提是：
- 不改变用户核心意图
如果系统把问题改写得太过头，常见风险是：
- 把模糊问题改成了过度具体的问题
- 把一个开放查询缩窄成单一假设
- 把用户本来没说的边界硬加进去
这时看起来“更清晰”，实际却已经改偏了。
一个更稳的判断标准
你可以先用这个标准判断改写是否合理：
- 改写后，用户真正想查的对象更明确了
- 但问题的核心意图没有变
如果只是更顺、更短，但含义已经变了，那就不是好的 rewrite。
Rewrite 和检索器增强不是一回事
有些人会觉得：
- 检索器足够强，就不用 rewrite
这不总成立。
因为 Rewrite 解决的是：
- 输入表达本身的问题
而不是：
- 检索器模型能力不足的问题
一个强检索器当然有帮助，但如果输入本身就很残缺，系统还是会不稳。
一个常见误区
很多人会把 Query Rewrite 理解成：
- 给每个问题都重写一次
这也不一定是好做法。
因为有些问题本来就已经非常清晰，比如：
- “错误码 ERR_1042 表示什么？”
这种问题如果再重写，反而可能把精确信号稀释掉。
所以更稳的思路通常是：
- 在真正需要时才改写
一句话总结
Query Rewrite 是在不改变用户核心意图的前提下，把原始提问改成更适合检索的查询。它尤其适合处理多轮短句、口语化表达、指代和知识库表述差异，但不能为了“改得更漂亮”而改偏问题本身。