生产型机器学习系统

生产机器学习系统远不只是模型代码，还包括采集、验证、特征、服务、监控和流程编排。

生产系统包含数据采集、清洗、特征变换、训练、验证、发布、推理、监控和回滚。模型文件只是其中一个环节。很多事故来自特征口径变化、数据源故障和线上线下处理不一致。

定义数据契约：每列是什么、单位是什么、允许缺失吗、何时更新、异常值如何处理。训练和线上服务都遵循同一契约，才有机会让离线指标在真实流量中成立。

图示可左右滑动查看

静态训练离线定期生成模型；动态训练持续用新数据更新。选择取决于变化速度、成本和风险。

静态训练按计划或条件用固定数据集重新训练并发布新版本，容易复现和审核。动态训练不断吸收新数据，适合分布快速变化的任务，但错误数据也会更快污染模型。

选择时比较业务变化速度、标签到达时间、训练成本和可回滚要求。很多团队先用静态训练建立可靠发布流程，再逐步提高频率。

批量推理提前计算结果；在线推理在请求到来时实时计算。

静态推理（批量推理）提前对大量对象计算结果，在线请求读取缓存；成本和延迟较低，但结果可能滞后。动态推理在请求到来时实时计算，可以使用最新特征，但要求稳定的低延迟服务。

有些系统采用混合方式：夜间批量计算基础分数，用户访问时再用实时行为做少量调整。必须标明结果的更新时间，避免用户误认为它始终是实时的。

重新训练应由数据变化、性能下降、业务规则或固定周期触发，而不是只因为时间过去。

特征变换可在数据准备阶段预先完成，也可在模型服务时实时完成。无论位置在哪里，训练与推理必须用同一套版本化逻辑，否则会出现训练—应用偏差。

重新训练可以由性能下降、输入分布变化、业务规则改变或固定周期触发。触发后先检查标签是否可靠，再决定是修数据、改特征还是训练新模型。

离线指标通过后仍要测试数据契约、延迟、容量、回退和真实流量中的业务影响。

上线前先保证训练可复现：保存训练数据的版本和时间范围、代码提交、特征处理版本、随机种子、超参数、评估报告及模型产物。另一位同事据此应能复跑出可解释的接近结果；如果训练数据已经被覆盖，只保存模型文件还不够。

把测试分层。单元测试检查“金额以元还是分存储”“缺失值如何填补”等特征规则；API 测试检查必填字段、类型、响应格式、超时与非法输入；集成测试让采集、特征、模型服务和结果消费端一起跑一笔请求。还要用目标硬件测试延迟、内存和并发。

发布门槛要有两道：相对当前线上模型不能明显退步，还要达到业务规定的绝对下限。例如某组召回率不能低于事先约定的阈值。这里的具体数值需由真实业务与风险决定；一个模型即使比旧版提高，也可能仍不够安全。

模型可先以“影子模式”接真实请求但不影响用户，比较新旧输出；再对小流量灰度发布，确认特征一致、线上延迟、错误率和业务指标。出现异常时，按预先演练的步骤恢复旧模型与旧特征版本。离线 AUC 改善不一定带来业务收益。

需要同时监控输入数据、特征变换、服务性能、预测分布和延迟到达的真实标签。

监控从输入开始。数据契约写清每列的类型、单位、合法范围、允许缺失率和更新时间；每批数据都做模式检查。例如交易金额约定单位是“分”、不得为负，若某天的 99 分位突然扩大 100 倍，应优先排查上游单位变化，而不是马上重训。

第二层检查特征处理：用固定样例分别跑离线训练流水线和线上推理流水线，比较输出是否一致；记录每个特征的缺失率、分位数和类别比例。训练—应用偏差表示两边处理不一致。标签泄漏则是训练时使用了预测时刻本不可能知道的信息，通常会造成离线成绩虚高。

第三层看模型和服务：总体与关键人群的召回率、误报率或误差，预测分数分布，接口错误率与 P95 延迟，模型版本和训练距今时间，以及输出中 NaN、无穷大或不合法值。总体平均数正常，不代表每个地区、设备或新老用户都正常。分群样本太少时还需展示样本量，避免把随机波动当故障。

真实标签可能在数天后才出现。当天可以先监控无标签信号，例如输入分布、分数分布和服务故障；等标签到达后再计算实际准确率、召回率或业务结果。输入分布改变只是预警，不自动等于模型质量下降；应结合延迟标签和人工抽样判断。

每项告警都要有阈值、负责人和处理手册。排查顺序可以是：核对采集与单位 → 对比训练和线上特征 → 检查模型版本及服务 → 按群体核对效果。若新版本造成严重退化，先回滚止损，再分析是数据修复、特征变更还是需要重训，并保留事故时间线。

图示可左右滑动查看

上线评审要覆盖目标、数据、指标、退化方式、所有者和人工兜底。

上线评审可逐项问：这个功能解决了什么问题？数据源能持续提供吗？预测是否会反过来影响未来训练数据？谁负责故障处理？没有模型时的基线是什么？

反馈循环尤其重要：推荐系统总推热门内容，就只会收集热门内容的点击；模型可能越来越确信冷门内容不受欢迎。要通过探索流量、随机抽样或因果评估减少自我强化。