查询漂移是什么
查询漂移指经过改写、摘要或多轮上下文注入后，检索目标偏离了用户本意：改写模型可能凭空补出用户没提过的型号或条件，多轮摘要过度压缩又把指代信息丢掉。发现手段是拿原查询和改写查询各自检索一次，比对结果的重叠度，重叠过低就进人工检查队列；预防手段是在改写提示词里明确禁止引入原文没有的实体与数字，并把原查询作为兜底召回路径保留下来，避免改写失败时整条链路无退路。
基本信息
| 主要成因 | 改写引入新实体、多轮摘要丢指代、术语替换错位 |
|---|---|
| 检测信号 | 原查询与改写查询的召回结果重叠度 |
| 预防手段 | 改写提示词禁止新增实体与数字 |
| 兜底策略 | 原查询与改写查询双路召回再融合 |
| 日志要求 | 同时保留原查询与改写结果 |
| 评测方式 | 改写前后各跑一次固定评测集 |
典型使用场景
- 多轮对话里「它」「这个」的指代被改写错，检索跑偏
- 术语归一化把产品专名替换成同义词，专名匹配不上
- 多轮摘要过度压缩后检索空转，返回一堆无关片段
- 新改写策略上线前做漂移检测，避免整体召回劣化
- 复盘线上「检索结果很奇怪」的投诉，定位是改写还是索引问题
漂移检测
漂移检测
orig_hits = retrieve(question) # 原查询检索
rewritten_hits = retrieve(rewritten) # 改写后检索
overlap = len(set(map(id, orig_hits)) & set(map(id, rewritten_hits)))
if overlap < 3: # 结果几乎不重叠
log_drift(question, rewritten) # 进人工检查队列
# 生产环境更稳的做法：两路结果做融合，而不是二选一漂移信号读法
| 信号 | 含义 | 处置 |
|---|---|---|
| 结果几乎不重叠 | 改写后意图已偏离 | 回退原查询，检查改写提示词 |
| 结果部分重叠 | 改写扩大了召回面 | 观察是否引入无关内容 |
| 改写后结果为空 | 改写引入了不存在的实体 | 禁止新增实体并加兜底路径 |
| 多轮后持续变差 | 历史摘要丢掉了指代信息 | 保留最近几轮原文，重写摘要 |
在改写提示词里写明不得引入原文没有的实体与数字，比事后检测更便宜：约束发生在生成时，成本几乎为零。
把原查询当作兜底召回路径，用融合（如倒数排名融合）合并两路结果，通常比只走改写后的一路更稳。