查询改写解决什么
查询改写要弥合「用户怎么说」与「文档怎么写」之间的鸿沟。口语化、含指代、省略主语的提问直接送去检索，往往什么都命中不到。改写环节把当前问题与最近几轮对话合并，补全指代、还原实体、把口语转成书面化表述，输出一条可以独立理解的检索查询，再交给向量与关键词两路召回。
基本信息
| 输入 | 用户原话 + 最近几轮对话 |
|---|---|
| 输出 | 独立、书面化、含关键实体的问题 |
| 适用 | 多轮对话、口语提问、简称与别名 |
| 风险 | 改写引入新信息可能改变原意 |
| 成本 | 一次小型 LLM 调用，通常可缓存同会话结果 |
改写提示词示例
改写提示词示例
把下面的问题改写成适合检索的独立查询：补全代词指代，
保留所有实体与限定条件，不要回答问题、不要添加原文没有的信息。
对话历史：{history}
当前问题：{question}
输出：改写后的问题（一行）典型使用场景
- 多轮对话里的追问：把「那它支持吗」补成「该接口是否支持批量写入」
- 口语化提问：把「怎么老是断」改写成「连接中断的常见原因与排查」
- 简称与内部叫法：把部门简称还原成制度文件里的正式名称
- 跨语言文档库：把中文问题改写成与文档同语种的查询
- 长问题包含多个意图：拆成两条查询分别召回后再合并
改写质量怎么判断
- 实体是否齐全：原问题里的型号、版本、单位一个都不能丢
- 是否越界：改写结果不该出现原问题与对话历史中都没有的信息
- 是否可独立理解：脱离上下文单看这一句，也能知道在问什么
- 是否保持提问形态：改写结果不应变成答案或结论
- 是否便于检索：书面化表述比口语碎片更容易命中文档用语
常见改写失败
| 失败表现 | 根因 | 处理方向 |
|---|---|---|
| 引入新实体 | 提示词没有禁止添加信息 | 明确要求只补全不新增 |
| 改写后答非所问 | 模型顺手回答了问题 | 在提示词里显式禁止作答 |
| 多轮指代仍残留 | 对话历史截断过早 | 给足最近几轮，或先做指代消解 |
| 同义扩展过度 | 重写成多个宽泛主题 | 限制为一条聚焦查询，多路交给专门策略 |
改写后与原问题建议都走一遍召回再合并，避免改写错误导致整条链路跑偏；改写失败时至少还有原始查询兜底。
改写结果要留档：把原始问题、改写结果与命中片段一起记录，排查召回问题时才能判断是改写错了还是检索本身有短板。