为什么要先改写再检索
用户提问往往口语化、带指代、夹着礼貌用语，直接拿去检索命中率低。查询改写（Rewrite-Retrieve-Read，Ma et al., EMNLP 2023）先在一步里把问题改写成 1-3 条独立可检索的查询语句：补全指代、展开缩写、去掉寒暄，然后执行检索。三步可以分别评估，哪一环拖后腿都能看出来。
基本信息
| 流程 | 改写 → 检索 → 基于结果作答 |
|---|---|
| 适用 | 多轮对话检索、口语化提问、缩写密集的领域 |
| 输出 | 仅输出查询语句列表，每行一条 |
| 兜底 | 改写偏离时保留原始问题作为备用查询 |
典型使用场景
- 多轮对话：把「那它怎么配」补全为含具体对象的完整查询
- 客服知识库：把口语问题改写成产品术语，提高检索命中
- 内部文档检索：展开缩写与内部代号后再检索
- 跨语言检索：先译成目标语言再用该语言的检索词
- 检索效果对比：对比原始查询与改写查询的召回差异，量化收益
改写提示示例
改写提示示例
把用户问题改写为 1-3 条独立、可检索的查询语句：
- 补全指代（它、这个 → 具体对象）
- 展开缩写，去掉礼貌用语
- 仅输出查询列表，每行一条
对话上下文：<history>
用户问题：<question>
# 保留原问题作为备用查询，改写失败时仍可检索
# 口语里的时间词（刚才、上次）结合会话时间换算成具体日期
# 每次改写结果记录下来，便于评估改写对召回的影响常见改写问题与处理
| 问题 | 表现 | 处理 |
|---|---|---|
| 指代未补全 | 查询里仍有「它」「那个」 | 提示要求替换为具体名称 |
| 过度改写 | 关键术语被替换成近义词 | 要求保留原文术语，只做补全与去噪 |
| 问题拆得过细 | 一条问题拆成五六条查询 | 限制条数为 1-3 条 |
| 时间词未换算 | 查询含「刚才」「上次」 | 结合会话时间换算为具体日期 |
改写过度（换掉关键术语）会降低召回，上线前用若干组离线样本对比改写前后的命中情况再决定。
口语问题里的时间词（「刚才」「上次」）要结合会话时间换算成具体日期，否则检索范围无法界定。