一句话定义
Query Rewrite 是在检索前改写用户问题：补全上下文、扩展同义词/术语、生成多个查询版本，或用 HyDE 先写一个假设答案再检索。
为什么需要它
用户问题往往口语化、缺上下文，或者用词和文档不一致。直接拿原问题做向量检索，可能召回不到正确片段；改写能让查询更接近文档的表达。
常见做法
- 改写：补全省略的主语/上下文，把口语问题变成明确查询。
- 扩展：加入同义词、领域术语、缩写全称。
- 多查询：生成多个版本分别检索，再合并去重。
- HyDE：先让模型写一个假设答案，用答案的向量去检索；答案不一定对，但用词更接近文档。
HyDE
HyDE 不依赖假设答案正确，而是利用“答案式文本”的用词分布提升召回。它增加了生成成本，也可能把错误假设带进检索。
关键取舍
- 改写提升召回，但可能改变原意；要保留原问题并评估偏差。
- 多查询/扩展增加检索次数和延迟。
- HyDE 多一次生成，适合文档风格与问题差异大的场景。
- 改写策略要按失败率启用，不是所有查询都需要。
- 改写可以由规则、模型或混合方式完成。
- 多查询要合并去重，避免重复上下文。
- HyDE 适合文档风格正式、用户问题口语化的场景。评测看召回提升。
常见误区
- 改写一定更好：错误改写会把检索带偏。
- HyDE 需要答案正确：它只需要用词接近文档。
- 多查询越多越好：延迟和噪声都会上升。
- 改写能替代 Reranker：一个改查询，一个排结果。
用在哪里
- RAG 检索前置。
- 口语化客服、跨语言/跨术语检索。
- 文档用词和用户用词差异大的知识库。
相关概念
- RAG：Query Rewrite 服务的流程。
- Vector Database：改写后的查询在这里检索。
- Reranker：对召回结果精排。