data drift指输入数据分布随时间发生偏移，如用户年龄层或设备类型变化，导致模型在子群上性能（如precision）隐性下降；仅靠accuracy无法及时发现，需用evidently等工具基于统计检验监控特征级漂移。
什么是Data Drift，以及为什么不能只靠准确率判断是否要重训
模型上线后性能下降，往往不是因为accuracy突然暴跌（那通常已是严重故障），而是输入数据的分布悄悄偏移了——比如用户年龄段从20–35岁扩展到45–65岁，或图像采集设备从iPhone换成了安卓低端机。这种Data Drift可能几周内都看不出accuracy变化，但precision在特定子群上已持续下滑。监控必须基于统计差异，而不是业务指标延迟反馈。
用Evidently + Prometheus + Alertmanager搭轻量级Drift告警链路
别写轮子，也别硬塞进Airflow调度流里——Drift检测是低频、高IO、可离线的操作，和训练任务本身解耦更稳。
- 每天凌晨用
evidently.report.Report比对最新1万条线上预测样本 vs 原始训练集，生成DataDriftTable报告 - 提取报告中
drift_detected为True的特征数，通过prometheus_client暴露为data_drift_feature_count指标 - Alertmanager配置规则：
alert: HighDataDrift<br>expr: data_drift_feature_count > 3<br>for: 24h
——避免单日噪声触发误重训
关键点：Evidently默认用KS test（连续）和Chi-square（离散），但对高基数类别特征（如URL、user_id hash）会报ValueError: too many categories，需提前用column_mapping把这类列设为exclude。
Drift触发后，如何安全启动重训练而不中断服务
自动重训最危险的不是跑不起来，而是新模型上线后latency翻倍或NaN输出炸掉下游。必须加隔离层。
- 训练脚本末尾不直接
model.save()，而是写入带时间戳的路径：models/model_20240521_1422.pkl - 在线服务用
model_registry.py统一加载，每次HTTP请求前检查os.path.getmtime()，仅当发现新文件且通过pytest tests/test_model_sanity.py（含np.isfinite校验+100条样本前向推理耗时 - 旧模型不删，保留最近3个版本，便于快速回滚——
ls models/ | sort -r | tail -n +4 | xargs rm放在训练脚本最后
哪些Drift信号其实该被忽略？
不是所有统计显著的漂移都要响应。重点看三类：
-
target列本身漂移（如订单金额中位数上涨50%）——这属于业务变化，应人工评估是否需重标或加特征，而非立刻重训 - 特征
missing_rate突增（如某API字段开始大量返回null）——优先修数据管道，不是模型问题 -
feature_importance排名倒置（如原来top3的user_age跌出前10）——这才是强重训信号，说明模型逻辑基础已松动
真正难的是界定“多大漂移算严重”——别设固定阈值，用历史分位数：如果drift_p_value低于过去30天同特征的5th percentile，才视为异常。这个动态基线得存进drift_baseline.db，每次检测完更新。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
