Query 改写是什么？为什么用户原句直接拿去检索效果差？

先这样答

Query 改写是在检索前，根据用户意图、对话历史和知识库的表达方式，把原始问题转换成一个或多个更适合搜索的问题。用户原句常有口语、省略和指代，比如上一轮问完某个模型，这一轮只说「它呢」，直接计算向量时，查询中缺少实体和上下文，很难匹配知识库里完整、书面化的内容。

常见做法是先做指代消解和信息补全，把「它呢」还原成包含对象与问题类型的完整查询。还可以做同义扩展或生成多个查询变体，分别检索后合并结果，以覆盖不同措辞。HyDE 则先让模型生成一段假设答案，再用这段更接近文档表述的文本进行检索，但假设内容如果偏了，也可能把召回方向带偏。改写还会增加一次模型调用和延迟，因此关键词明确、命名实体清晰的问题通常可以直接检索。

面试时可以收束为：Query 改写解决的是用户表达与知识库表达不一致的问题，但是否改写要看查询是否完整，并权衡召回收益、延迟和改写错误的风险。

面试官会怎么追问

• 「多查询改写之后，结果怎么合并？」 可以对每个变体分别检索，再按文档标识去重，并用倒数排名融合或重排模型统一排序。关键是限制查询数量，并观察变体是否真的覆盖了不同表达，否则只会增加相似结果和计算成本。
• 「HyDE 为什么可能比直接查原问题更有效？」 用户问题通常很短，而假设答案包含更多主题词、实体关系和书面表达，向量表示可能更接近知识库文档。它生成的答案不要求事实完全正确，因为主要用途是构造检索表示，但内容偏离意图时仍会污染召回。
• 「怎么判断该不该做改写？」 可以先检查查询是否有未解析的指代、省略或过短表达，再结合离线召回评估和线上失败案例判断。若查询已经包含明确关键词、产品名或错误码，保留原句往往更稳，也可以把原句与改写结果同时检索作为保护。

回答的坑

• 把 Query 改写说成单纯润色语句是不够的，正确方向是说明它在补全检索意图并缩小用户表达与文档表达之间的差异。
• 只讲改写能改善召回而不提延迟和改错风险会显得脱离工程实践，应说明明确查询可以跳过改写，并为原始查询保留检索通道。