Appearance
L02-13 查询改写：用户的问题往往不适合直接检索
全局中心内容：改写是收益/成本比很高的一环，但每多一次模型调用都要算进延迟和账单。 全局讲解主线：三类坏 query → 四种改写策略 → 成本对比 → 编码 → 缓存 → 取舍建议。
P1 · 产出页
中心内容：一个可开关的查询改写器，支持多查询与 HyDE，带缓存。
- 讲解技巧
- 开场展示三条真实 query：「那个东西怎么弄」「上次的那个」「你能不能帮我看看」。
- 结论：真实用户的提问质量远低于我们的想象。
- 时长：20s
P2 · 三类坏 query
中心内容：指代不清 / 过短 / 口语化。
- 讲解技巧
- 每一类给一个真实例子，并说明检索时会发生什么（召回一堆不相关的高频文档）。
- 特别讲指代：「它支持吗」——没有上下文时向量检索几乎必然失败。
- 时长：4min
P3 · 四种改写策略
中心内容：上下文补全 / 多查询扩展 / HyDE / 关键词抽取。
页面内容：四种策略的原理、成本、适用场景对照表
讲解技巧
- 多查询扩展是性价比最高的：一次调用生成 3~5 个变体，召回率提升明显。
- HyDE 讲清原理：先让模型编一个「假答案」，拿假答案去检索——因为它比原问题更接近文档的措辞。
- 关键词抽取用于喂 BM25 通道，成本低。
时长：7min
P4 · 成本对比
中心内容：每次改写都要一次模型调用，链路延迟直接增加。
页面内容：各策略的额外调用次数与延迟增量
讲解技巧
- 给一个清醒的判断：多轮对话场景，上下文补全必须用；单轮问答场景，可以先不上改写。
- 建议用便宜的小模型做改写，不要拿主力模型干这活。
时长：4min
P5 · 编码：改写器
中心内容：改写结果要缓存，且用原 query + 上下文指纹做 key。
页面内容：QueryRewriter；多查询并发检索；结果去重
讲解技巧
- 重点讲去重：多查询会产生重复召回，要按 sourceId + chunkIndex 去重后再融合。
- 提醒缓存 key 要包含对话上下文摘要，否则同一句话在不同上下文下会取到错误缓存。
时长：6min
P6 · 什么时候不该改写
中心内容：精确查询改写反而会引入噪声。
- 讲解技巧
- 给判据：query 里包含编号、专有名词、明确实体时，不要改写，直接检索 + BM25 更准。
- 工程做法：用规则判断（包含数字编号/英文大写词）跳过改写。
- 时长：3min
P7 · 效果验证
中心内容：改写要分「有上下文」「无上下文」两组测。
- 讲解技巧
- 强调分组测试的必要性：整体指标会掩盖「改写只在多轮场景有效」这个事实。
- 时长：3min
P8 · 避坑与小结
中心内容：改写失败要能降级为原 query，不能让整个问答挂掉。
- 讲解技巧
- 引出下一节：文档更新了怎么办——02-14 增量更新。
- 时长：2min
讲师备忘
| 项 | 内容 |
|---|---|
| 课前必做 | 准备 3 条真实坏 query；准备改写前后的召回对照 |
| 最容易超时处 | P3 策略表，四种策略容易讲散——先给结论表再逐个展开 |
| 学员最常问 | 「HyDE 会不会加重幻觉？」答：只用于检索排序，不进 Prompt，风险可控 |
| 现场备用 | 无网络 → 用预生成的改写样例讲解 |