什么是 查询改写（Query Rewriting）？
查询改写（Query Rewriting）是一种检索前转换，它把用户请求和允许使用的上下文转换为一个或多个搜索查询，同时保留原始意图、实体、约束和授权范围。
快速了解
| 规范文档 | 官方规范 |
|---|
工作原理
按失败模式选择转换方式
代词和省略主语适合对话去上下文化，别名和版本适合术语归一，语料语言不一致时使用翻译，词汇鸿沟使用扩展，多跳问题则拆成可独立检索的 Facet。Multi-query Retrieval 会并行执行多种表达，随后去重或融合排序；[Query2doc](https://arxiv.org/abs/2303.07678)则用生成的伪文档文本扩展查询。HyDE、Routing 与 Reranking 解决相邻问题，不能全部笼统称为查询改写。
意图与策略契约
一条改写记录应包含原始请求、限定范围的对话轮次、Rewriter 与 Prompt 版本、输出查询、语言、用途和 Trace ID。必须保留关键实体、否定、单位、版本和时间范围；歧义无法可靠消除时应向用户澄清。保留原始查询作为检索基线，并拒绝虚构事实或扩大范围的候选。Tenant、ACL、Source 和 Retention 等授权过滤不能序列化为自由文本，应原样传给每个检索分支。
评测与发布门禁
[Rewrite-Retrieve-Read 论文](https://arxiv.org/abs/2305.14283)证明学习型 Rewriter 能改善其评测任务，但不能证明改写适用于所有语料。应对 Original-only、Rewrite-only 和 Original-plus-rewrite 做消融，按查询切片报告 Recall@k、MRR 或 nDCG、Context Precision、答案正确性与忠实度、不可回答处理、Drift、Latency 和 Cost。只有收益经过 Reranking 后仍存在，并且精确标识符和原本表现良好的查询没有回退时，才可发布。
主要特点
- 在检索前把用户表达转换为一个或多个检索假设
- 支持去上下文化、归一、翻译、扩展或分解
- 保留原始请求作为意图权威来源和比较基线
- 在生成查询文本之外携带不可变权限与来源过滤
- 可能提高召回，同时降低精确率或增加请求链延迟
- 必须做检索与答案级消融，因为文案流畅不等于改写有效
常见用途
- 根据限定的对话上下文解析追问
- 把产品别名和缩写映射为语料中的标准术语
- 为稀疏与稠密检索生成互补查询
- 把多跳请求拆成能返回证据的子查询
- 翻译检索文本，同时保留名称、数字、版本和过滤条件
示例
Loading code...常见问题
查询改写与提示词改写是一回事吗？
不是。查询改写在保留用户信息需求的前提下，改变送入搜索或检索系统的文本；提示词改写改变提供给生成模型的指令。RAG Pipeline 可以同时使用两者，但它们的输入、风险和评测指标不同。
RAG 系统什么时候不应改写查询？
精确标识符、带引号短语、已有良好结果的查询、严格低延迟链路，以及必须由用户澄清的歧义请求，都应跳过或谨慎使用改写。始终保留原查询进行对比；看似流畅的改写可能删掉稀疏检索需要的词法信号。
查询改写中的语义漂移是什么？
语义漂移是改写通过增加假设、删除约束、改变否定或解析错实体而改变了信息需求。可通过实体与约束检查、带标签的意图判断和端到端检索测试发现；不合格时应回退原查询或要求用户澄清。
是否应同时检索原查询和改写查询？
Multi-query Retrieval 通常应保留原查询，因为它保存用户原始措辞并提供安全基线。可用 Reciprocal Rank Fusion 或 Reranking 等有记录的方法合并结果，同时去重文档，并验证额外分支确实提高召回而没有让噪声淹没上下文。
应该如何评估查询改写？
在有 Query-Document 标注的代表性集合上，对比 Original-only、Rewrite-only 和组合检索。报告 Recall@k、MRR 或 nDCG、Context Precision、答案正确性与忠实度、不可回答行为、Drift Rate、Latency 和 Cost，并按追问、精确 ID、多语言和多跳查询分层。