该触发重训练的信号只有两个：数据分布偏移（如新用户行为突变、特征逻辑变更）和线上指标持续下滑（如AUC连续3天跌超0.015或F1关键类掉点超5%）。
什么时候该触发重训练？看数据漂移和性能衰减信号
模型不是一劳永逸的，重训练不该靠日历或拍脑袋决定。真正该动的信号只有两个：数据分布偏移（比如新用户行为突变、上游特征生成逻辑改了）和线上指标持续下滑（如 AUC 连续 3 天跌超 0.015，或 F1 在关键类上掉点超过 5%）。别等模型完全失效才反应——等 precision 掉到 0.6 再重训，可能已经漏掉几百条高风险样本了。
常见错误是把「有新数据进来」直接当触发条件。但每天进 100 条标注数据 ≠ 要重训；而某天突然涌入 5000 条来自新渠道的订单数据，哪怕没标注，也得立刻启动漂移检测。建议用 KS 检验 或 PSI 对关键特征做周级快照比对，阈值设在 0.15 以上就标红预警。
如何避免重训练变成“定时炸弹”？控制训练边界和依赖链
重训练失败往往不是模型本身的问题，而是环境或数据链路悄悄变了。最常踩的坑是：训练脚本硬编码了 /data/v2/features.parquet，但上周数仓把路径切到了 /data/v3/features/，结果训出来的是空特征；或者用了 sklearn==1.2.2 训练，上线时服务用的是 sklearn==1.4.0，predict_proba 输出维度不一致直接报错。
实操上必须做到三点：
立即学习“Python免费学习笔记（深入）”；
- 所有数据路径、版本号、依赖包版本写进配置文件，**不写死在代码里**
- 每次重训练前跑轻量级校验：检查
train_df.shape[0]是否低于阈值、train_df['label'].nunique()是否等于预期类别数 - 用
conda env export > environment.yml固化环境，而不是只记requirements.txt
增量训练 vs 全量重训？别被名字骗，先看更新粒度和特征工程
所谓「增量训练」在 Python 生态里多数只是伪概念。像 SGDClassifier.partial_fit() 确实支持流式更新，但它要求所有特征必须和初训时**完全同构**——新加一个 is_weekend 特征？不行；把 user_age 分箱逻辑从 5 岁一组改成 10 岁一组？也不行。这时候硬上 partial_fit，训出来的模型实际是拿旧结构套新数据，偏差会越来越大。
真正适合增量的场景极少：特征集稳定、label 空间封闭、且业务能容忍几轮迭代的渐进式调整。其他情况老老实实全量重训更稳。重点不是快，是可复现。用 mlflow.log_param("train_mode", "full") 显式记录模式，别让下游猜。
怎么判断这次重训练“算成功”？别只盯 val_loss
val_loss 下降不代表线上有效。常见陷阱是验证集和线上数据分布不一致——比如验证集全是工作日数据，但线上周末流量占 60%，这时 val_loss 很低，online_recall@10 却掉了 12%。
上线前必须过三关：
- 用**近七天线上未见样本**做 holdout 测试，指标波动不能超过
±0.005（视业务敏感度调） - 对比新旧模型在相同 batch 上的
model.predict()差异率，如果np.mean(pred_new != pred_old) > 0.18，得查是不是 label 定义变了 - 检查
feature_importance主要排序是否突变（如原来 top3 是click_rate、session_len、age_group，现在变成ip_country、device_type、click_rate），突变大概率说明数据源污染或特征 pipeline 错位
重训练最难的不是跑通代码，是确认你训的到底是不是你想训的那个模型。每一步的输入、变换、输出，都得有可追溯的快照，不然下次出问题，连回滚点都找不到。
