机器学习平台设计：让实验能够交付

机器学习平台最值得解决的问题，是把一次有效的实验变成可以解释、重复和交付的结果。拥有更多训练机器，不等于已经拥有这套能力。

本文重写自 2017 年《深度学习平台设计指南》，保留“支持业务、支持研发、连接已有系统”的主张，去掉当年的公司流程、招聘信息和工具现状判断。

先找到最昂贵的断点

训练慢、实验结果找不到、数据版本不清楚、上线靠手工复制，都可能是平台需求，但优先级不同。应先观察模型从开发到使用的过程，找出最频繁、最昂贵或最容易出错的环节。

如果团队仍然无法确认一次实验用了哪份数据，先建设复杂的分布式调度，未必能提高交付质量。平台的目标应写成可观察的改善，例如减少重现实验的准备时间，或让一次发布可以追溯到明确评估结果。

实验结果不只是模型文件。至少要关联代码版本、数据标识、预处理方式、参数、环境、评价指标和产物位置。随机种子可以帮助控制一部分变化，但不保证跨硬件、并行算法和依赖版本完全复现。

可以给每次运行一个唯一标识，将它贯穿日志、指标和模型产物。失败运行也应保留足够信息，否则只看到成功结果，很难理解资源浪费和失败原因。

MLflow 的实验追踪提供了参数、指标和产物记录等具体机制，可作为实现参考；它并不能代替团队定义什么才是有效实验。MLflow Tracking

比较两个模型之前，先确认使用相同的数据划分、指标定义和评价过程。预处理如果提前接触测试数据，就可能使结果失真；重复试验时，也要注意逐渐把测试集变成调参集的问题。

除总体指标外，还应检查关键子群体与错误类型。一个平均值更好的模型，可能在重要场景中更差。业务决定哪些取舍可以接受，平台则负责把证据保留下来，而不是替所有业务设定同一个通过阈值。

上线接口应明确输入字段、类型、缺失值处理、输出含义和失败行为。训练时使用的预处理也必须与线上一致，否则发布的就不是评估过的同一个计算过程。

例如，一个分类模型除了权重，还需要对应的特征顺序、词表或类别映射。仅复制权重文件，却沿用另一版本的转换规则，会产生难以察觉的错误。

发布记录应把模型、预处理、配置和评估关联起来。出现问题时，回滚的是完整版本，而不是只换回一个文件。

训练任务需要声明资源需求、运行状态和产物位置。排队、取消、超时和失败重试应有清晰行为。一个失败任务不断重试，可能占满共享资源，让其他有效实验无法开始。

长任务可以按框架能力保存检查点，但检查点恢复需要验证代码、数据和状态兼容。资源利用率只是观察维度之一；为了让 GPU 一直满载而反复运行低价值实验，并不代表平台高效。

研发人员需要探索空间，平台则应在输入、产物和交付边界处建立约定。尽量让已有脚本通过小范围适配接入，而不是先要求所有人改用同一种交互界面。

上线后同时观察服务可靠性和模型效果。延迟、错误率、输入分布变化可以较早获得，真实标签可能延迟到达。没有及时标签时，可以监控代理信号，但不能把它直接当成准确率。

发现问题后，需要能够定位到数据、代码、模型和发布版本，并决定暂停、回滚、修复数据还是重新训练。这个过程是否可操作，比平台展示了多少功能更重要。

从一条实际业务流程开始，把实验记录、评估与发布连接起来，再按重复需求扩展。相关背景可继续阅读本站的算法与数据中台笔记。