理解数据漂移与模型漂移：用 Python 进行漂移检测

文章主旨：模型上线后，数据分布与输入—目标关系会持续漂移，漂移监控的核心不是寻找单个超过阈值的统计量，而是持续判断“数据是否仍像训练时、模型是否仍可靠、问题发生在哪一层”，并据此决定校准、修复或重新训练。

关键要点：

• 漂移描述数据或数据关系发生变化，模型性能下降是其可能结果，二者并不等价；检测到漂移应视为风险信号和排障线索。
• 重点区分三类漂移：数据漂移／协变量偏移、目标漂移／先验概率偏移、概念漂移；概念漂移还可表现为突变、渐进、增量和概念再现。
• LLM 应用增加了意图漂移、Embedding 漂移、检索语料漂移和评估信号漂移等监控维度。
• 监控顺序通常为：数据质量 → 输入／预测分布 → 模型性能 → 漂移定位；有真实标签优先看性能指标，无标签则先看代理信号。
• 检测方法包括 K-S 检验、PSI、Wasserstein 距离、JS 散度、Page-Hinkley、域分类器等；但参考窗口选择、业务影响判断和是否重训，比单一算法更重要。

内容结构：

1. 01 先把“漂移”和“模型变差”分开：漂移是数据或数据关系变化，性能下降是其结果。检测到数据漂移不代表模型一定失效，反之也可能输入边际分布变化不明显但关系变化导致性能下降。生产监控不应采用“发现漂移 → 立即重训”的简单逻辑。

2. 02 三种最值得区分的漂移：用联合分布理解，生产变化可来自输入分布、目标分布或输入—目标关系变化。具体包括数据漂移（输入人群或采集管道变化）、目标漂移（正负样本基础比例变化）、概念漂移（规则本身变化）。数据管道变化应优先按数据质量故障处理。

3. 03 LLM 时代，漂移又多了一层：LLM 系统需关注输入和意图漂移、Embedding 漂移、检索语料漂移、评估信号漂移。RAG 中“模型变笨”可能实际来自检索层变化；自动评估下降也可能来自评估器版本变化，因此应同时记录被测模型与评估器版本。

4. 04 真正的漂移监控，应该看哪些信号：推荐监控顺序为数据质量 → 输入／预测分布 → 模型性能 → 漂移定位。有标签时优先看分类、回归、排序推荐或 LLM 任务指标；无标签时看缺失率、异常值、单变量／多变量漂移、预测分布、重要分群及 LLM 相关信号，避免告警疲劳。

5. 05 常见的漂移检测方法：K-S 检验用于比较连续分布；PSI 直观但阈值是经验性的；Wasserstein 距离衡量分布搬运成本；JS 散度适合概率分布；Page-Hinkley 适合连续在线监控。实践中应根据特征类型、样本规模和监控目的选择方法。

6. 06 单变量没有漂移，不代表整体没有变化：逐特征检查只能发现单变量漂移，特征间相关关系变化可能导致联合分布变化。域分类器是常见多变量检测思路，也适用于 Embedding 等高维数据。

7. 07 参考窗口怎么选，比算法本身更重要：需要区分为基准的 Reference Window 和最近监控的 Current Window。参考窗口不应简单等同于全部训练数据，应结合季节性、短期基线和长期基线选择，窗口过小或过大都有问题。

8. 08 用 Evidently 快速生成数据漂移报告：原文用 Adult 数据集构造差异数据，通过 DataDriftPreset 生成漂移报告，并说明可导出 HTML 和 JSON。报告显示 Drift = True 不应直接等价于自动重训，更稳妥流程是确认数据质量、定位关键特征／分群、检查性能或获取标签，再判断调阈值、校准、更新数据或重训。

9. 09 生产环境里，什么时候应该重新训练？重训至少应考虑性能是否真的下降、漂移是否影响模型真正依赖的区域、新数据是否足够代表新环境。更合理策略是：漂移作为预警，性能作为核心判断，业务影响决定优先级，重训只是修复手段之一。

10. 10 写在最后：模型训练完成时只学到过去某个时间窗口的世界，上线后数据、用户和业务持续变化。漂移监控要解决的是一套持续判断机制：现在数据还像训练时吗？模型还可靠吗？如果不可靠，问题发生在哪一层？

11. 参考资料：包括概念漂移综述、SciPy 文档、Evidently 文档与 GitHub、NannyML 文档等，用于补充漂移检测与模型性能监控方法。

文章总结：漂移监控应从“看几个指标是否报警”升级为生产级 MLOps 的持续判断机制，把漂移作为风险信号，结合模型性能、业务影响和问题定位，再决定修复、校准、更新数据或重新训练。