机器学习工作流解析：从离线模型到持续演化的 ML System

核心结论：ML Workflow 不是围绕模型训练展开的一条流水线，而是 Data、Algorithm 与 Machine 在真实约束下持续协同、验证和反馈的工程闭环。

问题背景：模型有效，不等于系统可用

在很多机器学习课程和入门项目中，一个项目通常被压缩为三步：

准备数据 → 训练模型 → 在测试集上评估

只要测试集上的 Accuracy 足够高，任务似乎就完成了。这个抽象适合解释算法，却不足以描述生产中的 ML System。

一个离线模型即使达到 95% 的准确率，仍可能因为以下原因无法使用：

• 模型占用 4 GB 内存，但目标设备只有 512 MB 可用内存；
• 训练时和推理时使用了不同的特征处理逻辑，形成 Training-Serving Skew；
• 测试集来自受控环境，而线上输入由不同设备、地区和人群产生；
• 平均延迟满足要求，但 P99 Latency 超出业务 SLO；
• 上线后输入分布发生变化，模型在代码没有改动的情况下悄然退化；
• 系统能够输出预测，却无法解释低置信度结果，也没有回滚和人工兜底路径。

这些失败都不是单纯的算法失败，而是工作流没有把数据、模型、基础设施和生产环境连接起来。

《Machine Learning Systems》使用 D·A·M Taxonomy 描述 ML System 的三个基本部分：

• Data：数据的质量、规模、分布、表示方式和流动路径；
• Algorithm：模型结构、训练方法、计算图和预测逻辑；
• Machine：CPU、GPU、加速器、内存、存储、网络及运行时系统。

三者并不独立。Data 决定 Algorithm 能学到什么，也决定训练阶段需要搬运多少数据；Algorithm 决定计算量与内存占用；Machine 的算力、带宽、功耗和部署位置，又会反过来限制可用模型与数据处理方式。

因此，ML Workflow 的对象并不是一个模型，而是一个随生产环境变化而持续演化的 ML System。

一、ML Lifecycle 与 ML Workflow 不是同一个概念

ML Lifecycle 描述系统会经历哪些阶段；ML Workflow 描述如何协调这些阶段，使约束、产物和反馈能够在阶段之间正确传递。前者是生命周期的地图，后者是让这张地图真正运转起来的工程方法。

《Machine Learning Systems》将生命周期概括为六个阶段：

1. Problem Definition；
2. Data Collection and Preparation；
3. Model Development and Training；
4. Evaluation and Validation；
5. Deployment and Integration；
6. Monitoring and Maintenance。

它们在阅读顺序上是线性的，在实际工程中却构成闭环：

还可以从两条并行管线理解这个过程：

• Data Pipeline：Collection → Ingestion → Analysis → Labeling → Validation → Preparation；
• Model Development Pipeline：Training → Evaluation → Validation → Deployment。

生产反馈将两条管线连成一个系统。缺少反馈时，它们只是两条会在集成阶段碰撞的局部流水线。

为什么 ML Workflow 不能照搬传统软件流程

传统软件通常在代码不变时保持行为稳定。ML System 的代码、配置和服务都可能没有变化，但现实世界一旦改变，模型与输入分布之间的统计关系就会改变。

“Data is Source Code”不是一句比喻，而是工程事实。数据版本变化能够改变系统行为，其影响不亚于一次代码提交。

二、问题定义：先约束系统，再讨论模型

问题定义不应该是“训练一个欺诈识别模型”，而应形成可以验证的多层契约。以在线交易风险分类为例，至少需要同时定义三类目标。

三个目标不能互相替代。模型的 Recall 提升，不代表业务损失一定下降；平均 Latency 较低，也不代表峰值时段不会违反 P99 SLO；离线 AUC 更高，更不代表模型能在给定内存、功耗和成本预算内运行。

问题定义还需要同时覆盖三层约束：

• Statistical Constraints：整体指标、分群指标、置信度校准和可接受的错误类型；
• Physical Constraints：Cloud、Edge、Mobile 或 TinyML 部署范式，以及延迟、内存、带宽、功耗预算；
• Operational Constraints：隐私、监管、审计、人工复核、失败兜底和组织流程。

正确的问题定义更接近一份系统契约：

business_goal:
  minimize: fraud_loss
  guardrail: legitimate_transaction_decline_rate

model_requirements:
  fraud_recall_min: 0.90
  subgroup_recall_gap_max: 0.05
  calibration_required: true

system_requirements:
  deployment: cloud_online_serving
  p99_latency_ms_max: 30
  peak_qps: 20000
  rollback_required: true
  delayed_label_support: true

这份契约并非一次冻结。系统扩大到新地区、新交易类型或新监管环境时，原有目标可能需要增加分群阈值、新的硬件假设或更严格的审计要求。业务问题可能稳定，但将业务问题转化为工程目标的方式会随着生产事实演化。

三、数据工程：不是训练前的一次性准备

Problem Definition 指定模型需要解决什么问题，Data Engineering 决定系统实际上有能力学到什么。

数据阶段至少包含以下产物：

• 可追溯、可版本化的数据集；
• 明确的 Schema 与特征语义；
• 统一的训练和推理预处理逻辑；
• 标签来源、标注质量与延迟说明；
• 数据切分规则；
• 数据质量检查与分布基线；
• 隐私、保留期限与访问控制策略。

数据质量问题为何会贯穿整个系统

以欺诈识别为例，真实标签可能要等拒付或人工调查完成后才能获得。如果直接把“被规则系统拦截”当作欺诈标签，模型学到的可能不是欺诈规律，而是旧规则系统的决策偏好。这个问题无法通过增加网络层数解决。

常见的数据风险包括：

• Data Leakage：训练数据包含推理时不可获得的信息；
• Sampling Bias：训练样本无法代表未来线上流量；
• Label Bias：标签反映历史决策偏差，而不是目标事实；
• Data Quality Failure：缺失值、异常编码、错误时间戳或特征语义变化；
• Training-Serving Skew：训练和线上 Serving 使用不同计算逻辑或不同数据时间窗口。

因此，数据验证不能只检查文件是否存在或字段类型是否正确，还要验证分布、时间一致性、标签质量与业务语义。

更多数据不一定更有价值

数据规模增加会扩大存储、网络和训练成本，但模型收益可能已经进入边际递减区间。若性能瓶颈来自某个地区的样本覆盖不足，再采集大量已有地区的重复样本几乎没有意义。此时更合理的动作是进行 Data Selection、补齐失败切片或改善标签质量。

数据在系统中的代价可通过书中的 Iron Law of ML Systems 表达：

其中：

• D_{\text{vol}} 是系统实际需要读取和搬运的数据量；
• BW 是有效数据带宽；
• O 是模型和工作负载需要执行的操作量；
• R_{\text{peak}} 是硬件峰值计算能力；
• \eta_{\text{hw}} 是硬件利用效率；
• L_{\text{lat}} 是调度、序列化、网络、运行时与集成产生的固定开销。

数据阶段主要塑造 D 和 D_{\text{vol}}。盲目扩充数据集可能让第一项持续增加，却没有带来相应的模型质量收益。高质量数据选择、缓存、预取、格式优化和将计算移动到数据附近，都是 Data 与 Machine 协同设计的一部分。

四、模型开发：实验结果必须可比较、可复现

模型开发阶段决定 Algorithm 的主要结构，也直接设定操作量 O 的下限。一个大模型即使能够在训练集群上运行，也未必能满足 Serving 的成本、延迟和内存预算。

这一阶段的核心不是“找到最高分模型”，而是建立可信的实验比较：

• 固定或记录 Random Seed；
• 版本化训练数据与预处理代码；
• 保存代码提交、依赖环境和硬件配置；
• 记录超参数、训练日志、模型权重和评估结果；
• 使用 Ablation Study 隔离单个设计的真实贡献；
• 对小幅指标提升进行多次运行和统计显著性分析。

一个可部署模型的完整 Artifact 不只是权重文件，还应包含：

Model Artifact
├── model weights
├── inference graph / model definition
├── preprocessing and postprocessing
├── dependency and runtime specification
├── training configuration
├── dataset and feature version
└── evaluation report and lineage metadata

若实验记录只有“Run 48 比 Run 47 高 0.5%”，但无法确认两次运行是否使用相同数据、相同随机种子、相同依赖和相同硬件，那么这个提升可能只是噪声。不可复现会直接形成 Technical Debt，因为任何后续回归都难以定位究竟来自代码、数据、环境还是随机性。

Iteration Velocity 本身就是系统能力

更大、更准的模型不一定带来更好的最终系统。若一次训练需要一周，小模型一次迭代只需一小时，后者能够更快地验证数据切片、特征、模型结构和部署约束。大量快速且可信的迭代，可能超过少量高成本实验带来的初始精度优势。

这意味着 AI Infra 的价值不能只用单次训练吞吐量衡量。更重要的问题是：从修改数据或代码，到获得可比较的验证结果，需要多长时间？数据缓存、任务调度、Checkpoint、实验追踪和自动评估共同决定端到端 Iteration Time。

五、Evaluation 与 Validation 回答不同问题

Evaluation 主要回答“模型在选定指标上表现如何”；Validation 回答“整个系统是否满足真实生产条件下的业务、统计、资源和风险约束”。

单一总体指标很容易掩盖失败切片。总体 Accuracy 达标，并不能容忍某个地区、设备或用户群体的 Recall 跌破安全下限。模型评估至少应覆盖四组指标：

1. Model Quality：Accuracy、Precision、Recall、F1、AUC、Calibration；
2. Slice Quality：地区、设备、时间段、用户群体和长尾类别；
3. System Performance：P50/P95/P99 Latency、Throughput、Memory、Energy、Cost；
4. Business Outcome：欺诈损失、误拦截率、人工复核量和用户转化。

从离线到线上逐步扩大风险暴露

生产验证不是一次“大爆炸式上线”，而应逐步扩大真实流量暴露：

顺序很重要。Shadow Mode 在不影响用户决策的情况下复现真实输入；Canary 将风险限制在少量流量；A/B Testing 则比较新旧模型的因果效果。跳过前一阶段，不是消灭了相应风险，只是把发现风险的时间推迟到代价更高的阶段。

Validation Gate 还应检查监控、Rollback 和人工兜底是否已经就绪。若只能发布模型，却不能快速识别异常或限制影响范围，就不能视为具备部署条件。

六、部署与 Serving：把模型变成可运行的系统

Deployment and Integration 阶段主要处理 Iron Law 中的 L_{\text{lat}}，包括：

• 模型加载与 Runtime 初始化；
• 请求排队、Batching 与调度；
• 特征读取和远程调用；
• 数据序列化与设备间传输；
• CPU、GPU 或专用加速器执行；
• 后处理、业务规则与下游系统集成。

如果模型计算只占 5 ms，而特征读取、排队和序列化占 40 ms，那么更换更快的 GPU 并不能解决主要问题。此时应分析完整 Critical Path，而不是只观察模型 Kernel。

不同部署形态有不同的约束：

• Online Serving 关注 Tail Latency、峰值吞吐量和可用性；
• Batch Inference 关注总完成时间、资源利用率和调度成本；
• Edge/Mobile 关注内存、功耗、模型大小和离线能力；
• TinyML 受到极严格的存储、能耗和算子支持限制。

因此，部署范式必须在 Problem Definition 时确定。把它推迟到模型完成之后，往往会发现精度最高的模型在目标机器上根本不可行。

AI Infrastructure 在各阶段承担什么角色

AI Infra 不是 GPU 集群的同义词。它是承载数据流、计算流和控制流的系统层：数据流决定样本与特征如何移动；计算流决定训练和推理如何执行；控制流决定任务如何调度、版本如何晋升、异常如何触发回滚或重训。

七、监控与反馈：上线是闭环的起点

传统服务监控通常关注 CPU、内存、错误率和服务存活状态。对 ML System 来说，这些指标只能证明服务正在运行，不能证明模型仍然有效。

生产监控至少要覆盖四类指标：

1. Operational Metrics：Latency、Throughput、Queue Depth、Error Rate、资源利用率；
2. Data Stability Metrics：特征缺失率、取值范围、输入分布和预测分布；
3. Proxy Metrics：预测置信度、拒绝率、人工复核率等不依赖真实标签的早期信号；
4. Model and Business Metrics：有 Ground Truth 后计算的 Recall、Precision、分群表现与业务损失。

这四类指标对应不同的反馈速度。Operational Metrics 可以在秒级发现服务故障；Proxy Metrics 可在标签尚未到达时，于小时级暴露模型行为变化；真正的模型质量可能要等数天或数周后才能确认。

Data Drift、Concept Drift 与 Training-Serving Skew

• Data Drift：线上输入分布 P_t(X) 相对训练分布 P_0(X) 发生变化；
• Concept Drift：输入和标签之间的关系 P(Y\mid X) 发生变化；
• Training-Serving Skew：训练与推理的数据或处理逻辑不一致。

Drift 只是风险信号，不等价于准确率一定下降。某个无关特征发生显著变化，模型质量可能不受影响；反过来，较小但集中在关键切片上的变化也可能造成严重退化。因此，漂移检测应与模型敏感性、分群指标和真实标签反馈结合。

自动重训不等于自动安全上线

一个完整的反馈路径通常是：

监控触发 → 定位数据或模型问题 → 生成候选数据集
→ 重新训练 → 离线与生产条件验证 → 人工或策略审批
→ Shadow / Canary → 晋升或回滚

若把“检测到 Drift”直接连接到“全量发布新模型”，系统可能把数据污染、短期波动或错误标签快速放大。Continuous Training 的重点不是自动执行训练命令，而是把验证门槛、Artifact Lineage 和风险控制一起自动化。

Rollback 同样比传统软件复杂。回滚旧模型只能恢复旧 Artifact，不能恢复过去的数据分布。旧模型在当前流量上可能比新模型更差，因此回滚只是止损手段，不是真正的状态恢复。

八、约束传播：为什么越晚发现问题越贵

ML Workflow 的关键不是阶段数量，而是约束如何跨阶段传播。

假设在线欺诈模型在 Deployment 阶段才发现 P99 Latency 必须小于 30 ms。这个约束会沿着工作流反向传播：

1. Serving 无法仅靠增加实例满足成本预算，需要减小模型；
2. Model Development 必须调整结构、压缩模型或减少特征；
3. 特征变化使训练数据和预处理管线失效；
4. 模型需要重新训练、重新评估和重新验证；
5. 若精度下限无法满足，Problem Definition 还要重新讨论业务策略与人工兜底。

《Machine Learning Systems》用近似关系表达 Constraint Propagation Principle：

这个公式不是精确的项目估算模型，而是强调返工的复合效应：一个隐藏约束每跨过一个阶段，都会让更多数据、模型、配置、验证和部署产物建立在错误假设之上。

降低这种成本的有效办法是建立 Stage Interface Contract：

Stage Contract 的意义不是增加文档，而是在错误仍便宜时阻止它继续传播。

九、贯穿示例：一次线上退化如何驱动完整迭代

假设欺诈分类模型已经上线，某天监控发现某地区的人工复核率在两小时内上升 20%，但 Ground Truth 尚未返回。

第一步，Operational Metrics 显示 Latency、Error Rate 和资源使用正常，说明服务没有显式故障。Proxy Metrics 中的模型置信度明显下降，风险更可能来自数据或模型行为。

第二步，Data Stability Metrics 显示该地区近期切换了支付渠道，某组交易特征的取值范围和缺失模式发生变化。Lineage 系统进一步确认，训练数据中几乎没有该渠道样本。

第三步，团队不立即全量重训，而是补采该渠道样本，验证标签定义，并建立新的数据切片。候选模型训练后，不只比较总体 AUC，还检查该渠道的 Recall、正常交易误拦截率、Calibration 和 P99 Latency。

第四步，新模型进入 Shadow Mode。线上真实请求同时送给旧模型和新模型，但仍由旧模型做决策。确认特征处理一致、资源预算满足后，再用 Canary 承接少量流量。

第五步，若新模型改善该地区指标且没有破坏其他切片，才逐步晋升。若效果仍不满足要求，反馈可能继续返回 Data Collection，甚至回到 Problem Definition，重新设计该渠道的人工复核策略。

这个过程说明：监控不是最后一项运维工作，而是把生产事实重新输入 Data、Algorithm 和 Machine 决策的控制系统。

十、常见误区

误区一：ML Workflow 就是数据预处理加模型训练

这种理解只覆盖离线开发，没有覆盖部署约束、生产验证和反馈。真正的工作流管理完整系统的生命周期。

误区二：Accuracy 更高的模型一定更好

总体 Accuracy 可能掩盖关键切片失败，也没有反映 Latency、Memory、Cost、Calibration 和业务损失。模型选择是多目标约束优化，不是单指标排序。

误区三：部署完成意味着项目结束

部署只是模型首次接触真实分布。Data Drift 和 Concept Drift 会让模型在代码不变时退化，因此上线是反馈闭环的起点。

误区四：Data Engineering 只是清洗数据

Data Engineering 还包括采集、Schema、标注、版本、Lineage、特征一致性、质量验证、存储布局和数据交付性能。它决定模型能力边界，也经常决定系统吞吐量。

误区五：自动重训可以解决所有模型退化

重训无法自动修复错误目标、污染标签、缺失切片或不合理部署约束。没有 Validation Gate 的自动重训，可能更快地生产错误模型。

误区六：监控模型只需要看服务是否存活

服务存活只能排除部分显式故障。模型可能在 Error Rate 为零时持续给出质量下降的预测，必须结合数据、代理、模型和业务指标。

误区七：AI Infra 就是提供 GPU

GPU 只覆盖部分计算资源。AI Infra 还要让数据、实验、Artifact、Serving、监控与反馈形成可追溯、可复现、可回滚的闭环。

总结：从 Model-centric 转向 System-centric

Model-centric 写法：

1. 固定一份数据并训练模型；
2. 用单一离线指标选择最高分版本；
3. 模型完成后再考虑部署；
4. 上线后只监控服务可用性；
5. 结果是局部模型最优，但系统可能因数据错位、资源超限或持续 Drift 而失败。

System-centric 的 ML Workflow 写法：

1. 在 Problem Definition 阶段同时确定业务、统计、物理和运营约束；
2. 用 Stage Contract 管理数据、模型、验证和部署产物；
3. 让 Data、Algorithm 与 Machine 从第一天开始协同设计；
4. 通过离线评估、Shadow、Canary 和 A/B Testing 逐级验证；
5. 用多时间尺度监控把生产信号反馈到数据、模型、基础设施和目标定义。

ML Workflow 的本质：将 D·A·M 的空间耦合展开到时间维度，在持续反馈中管理一个会随现实世界变化而演化的 ML System。

参考资料

• Vijay Janapa Reddi, Introduction to Machine Learning Systems, Volume I: ML Workflow。
• Vijay Janapa Reddi, Introduction to Machine Learning Systems, Volume I。