指标预测模型每天训练，如何评估其漂移并自动重训练
解读
性能测试工程师在国内互联网/金融/运营商场景下，不仅要压测，还要把压测结果（RT、TPS、错误率、CPU、内存、GC、DB 慢 SQL 等）沉淀为“容量预测模型”，用于提前回答“618 零点能不能扛住”“新上线推荐接口会不会把 Redis 打爆”。
模型一旦上线，每天凌晨用前一天全量监控数据重新训练。业务迭代快、大促节奏紧，如果模型“飘了”却没及时发现，就会出现“预测 2 万并发安全，结果 1.2 万就雪崩”的生产事故。
面试官问“如何评估漂移并自动重训练”，核心想看三件事：
- 懂不懂数据漂移（概念、类型、业务表现）；
- 会不会设计“轻量级、可工程落地”的监控-告警-重训练闭环；
- 有没有把性能测试资产（脚本、指标、场景）与 MLOps 打通的经验。
回答必须体现“性能测试视角”，而不是泛泛地讲机器学习。
知识点
- 数据漂移（Data Drift）与概念漂移（Concept Drift）
- 数据漂移：输入指标分布变了（例：大促前接口日均 QPS 从 5k 涨到 3w，RT 分布右移）。
- 概念漂移：输入-输出映射关系变了（例：代码加了本地缓存，同样 QPS 下 RT 下降 30%，原模型高估容量）。
- 性能测试常用指标分布
- 连续型：RT、CPU%、GC 暂停时间、DB 连接数。
- 离散型：错误码占比、状态码 200/5xx 比例。
- 漂移检测算法（适合批式每日触发）
- PSI（Population Stability Index）：分箱后对比训练集与预测集，>0.2 视为显著漂移。
- KS（Kolmogorov-Smirnov）：两条 CDF 最大垂直距离，>0.1 告警。
- 在线自适应：DDM/EDDM，适合实时，但国内多数团队每天跑一次批，PSI+KS 足够。
- 触发阈值设计
- 核心特征（QPS、RT、CPU）任一 PSI>0.2 即触发；辅助特征（内存、GC）可放宽到 0.25，减少抖动。
- 自动重训练 Pipeline（MLOps 轻量版）
- 数据源：夜维同步 Prometheus+ELK+APM 到 Hive/Doris；
- 特征工程：用性能测试基线脚本打标签（“安全”“临界”“失效”）；
- 训练：Airflow 调度 Spark ML/XGBoost，输出 pmml/onnx；
- 验证：回滚最近 7 天真实流量做 shadow 预测，误差>15% 则阻断上线；
- 发布：通过 Nexus 私服推模型文件，性能测试平台自动加载；
- 兜底：同时保留“上周模型”，一键回滚。
- 性能测试团队与算法/运维三方协同
- 测试侧负责“特征语义正确性”（RT 是否含重试、CPU 是否取宿主机）；
- 算法侧负责“模型可解释性”（SHAP 值看哪项指标对容量预测贡献最大）；
- 运维侧负责“资源隔离”（重训练任务打在离线集群，避免影响凌晨备份）。
答案
“我去年在 XX 支付负责容量预测系统，模型每天凌晨 2 点重训练。评估漂移分三步：
第一步，特征级监控。把训练集（过去 30 天）与预测集（当天）按 10 等分箱，计算 QPS、RT、CPU、GC 暂停时间四个核心特征的 PSI，任一 PSI>0.2 即判漂移；同时跑 KS 检验做交叉验证，防止分箱带来的假阴性。
第二步，模型级监控。用前一天真实流量做 shadow 预测，若平均绝对百分比误差 MAPE>15%，也视为漂移。
第三步，业务级兜底。大促封板期间，只要研发提交“性能相关”的 MR（含 SQL、线程池、缓存、JVM 参数），无论 PSI 是否触发，都强制重训练，避免概念漂移漏检。
一旦触发漂移，Airflow 自动拉起重训练 DAG：①拉取 Prometheus 原始指标；②用性能基线脚本自动打标签（安全/临界/失效）；③XGBoost 训练+5 折交叉验证；④shadow 验证通过后，pmml 推送到 Nexus；⑤性能测试平台热加载新模型，旧模型保留 7 天可回滚。整个流程 30 分钟内完成，上线半年未出现因模型漂移导致的容量误判。”
拓展思考
- 如果业务方要求“小时级”甚至“30 分钟级”预测，PSI 批式检测来不及，可引入“在线漂移检测”——用 Druid 实时 rollup 特征均值和方差，滑动窗口计算 KL 散度，阈值触发后走“增量训练”而非全量训练，节省 70% 时间。
- 多云/混合云场景下，同一套代码在阿里云、华为云、私有云表现不同，可把“云厂商+机型”作为分层变量，做多层 PSI（Stratified PSI），避免“整体 PSI 平稳、局部云已漂移”的陷阱。
- 性能测试团队可以反向输出“特征重要性排行榜”，告诉研发“GC 暂停时间对容量预测权重占 42%”，推动对方先把 GC 调优，再谈扩容，真正把“测试左移”落到实处。