MLOps简介

一、什么是 MLOps？

机器学习操作 (MLOps) 基于可提高工作流效率的 DevOps 原理和做法。 例如持续集成、持续交付和持续部署。 MLOps 将这些原理应用到机器学习过程，其目标是：

• 更快地试验和开发模型
• 更快地将模型部署到生产环境
• 质量保证

顾名思义，MLOps就是机器学习时代的DevOps。它的主要作用就是连接模型构建团队和业务，运维团队，建立起一个标准化的模型开发，部署与运维流程，使得企业组织能更好的利用机器学习的能力来促进业务增长。

举个简单的例子，几年前我们对于机器学习的印象主要是拿到一堆excel/csv数据，通过notebook等尝试做一些模型实验，最终产出一个预测结果。但对于这个预测结果如何使用，对业务产生了什么影响，大家可能都不是很有概念。这就很容易导致机器学习项目一直停留在实验室阶段，一个接一个做POC，但都没法成功“落地”。

最近几年，大家对于机器学习项目落地愈发重视起来，对业务的理解，模型应用流程等都做的越来越好，也有越来越多的模型被部署到真实的业务场景中。但是当业务真实开始使用的时候，就会对模型有各种各样的需求反馈，算法工程师们就开始需要不断迭代开发，频繁部署上线。随着业务的发展，模型应用的场景也越来越多，管理和维护这么多模型系统就成了一个切实的挑战。

回顾这个发展，是不是感觉似曾相识？20年前软件行业在数字化演进道路上也遇到过类似的挑战。我们从部署一个Web服务到要部署几十甚至上百个不同的应用，在各种规模化交付方面的挑战之下，诞生了DevOps技术。像虚拟化，云计算，持续集成/发布，自动化测试等软件工程领域的各类最佳实践基本都跟这个方向有关。在不远的将来，或许智能模型也会与今天的软件系统一样普遍。一个企业需要使用非常多的业务系统来实现数字化流程，同样也需要非常多的模型来实现数据驱动的智能决策，衍生出更多与模型相关的开发运维，权限，隐私，安全性，审计等企业级需求。

因此最近几年，MLOps也逐渐成为了一个热门话题。有了好的MLOps实践，算法工程师一方面能更专注于擅长的模型构建过程，减少对模型部署运维等方面的“感知”，另一方面也让模型开发迭代的方向更加清晰明确，切实为业务产生价值。就像今日的软件工程师很少需要关注运行环境，测试集成，发布流程等细节，但却做到了一天数次发布的敏捷高效，未来算法工程师应该也能更专注于数据insights获取方面，让模型发布成为几乎无感又快速的自动化流程。

二、MLOps的各个步骤

从大的方面看，MLOps分3个步骤：

• 1. 项目设计，包括需求收集，场景设计，数据可用性检查等。
• 1. 模型开发，包括数据工程，模型工程，以及评估验证等。
• 1. 模型运维，包括模型部署，CI/CD/CT工作流，监控与调度触发等。

DevOps通过缩短开发部署的时间来更快地迭代软件产品，使得公司业务不断进化。MLOps的逻辑也是通过相似的自动化和迭代形式，加快企业从数据到insights的价值获取速度。

MLOps的核心要解决的问题之一是缩短模型开发部署的迭代周期，即各类efficiency问题。从Algorithmia的2020年的这份报告中可以看到，很大一部分公司需要31-90天上线一个模型，其中有18%的公司需要90天以上来上线一个模型。且在中小型公司中，算法工程师花在模型部署方面的时间比例也明显偏多。MLOps希望通过更标准化自动化的流程与基础设施支持，来提升模型交付的整体效率。

另外一方面，MLOps还希望能提供一个企业内各个角色无缝协作的平台，让业务，数据，算法，运维等角色能更高效率的进行协作，提升业务价值产出，即transparency的需求。后面我们的详细讨论中也会反复印证这两个核心诉求。

三、MLOps的原则

Automation

在整个workflow中所有可以自动化的环节，我们都应该进行自动化，从数据的接入到最后的部署上线。Google那篇经典的MLOps指导中就提出了3个层级的自动化，非常值得借鉴，后面我们会详细介绍。

Continuous

一说起DevOps，大家就很容易联想到CI/CD，也从侧面印证这条原则的重要性。MLOps在持续集成，持续部署，持续监控的基础上，还增加了持续训练的概念，即模型在线上运行过程中可以持续得到自动化的训练与更新。我们在设计开发机器学习系统时，要持续思考各个组件对“持续”性的支持，包括流程中用到的各种artifacts，他们的版本管理和编排串联等。

Versioning

版本化管理也是DevOps的重要最佳实践之一，在MLOps领域，除了pipeline代码的版本管理，数据，模型的版本管理属于新涌现的需求点，也对底层infra提出了新的挑战。

Experiment Tracking

实验管理可以理解为version control中commit message的增强。对于涉及模型构建相关的代码改动，我们都应该能记录当时对应的数据，代码版本，以及对应的模型artifacts存档，作为后续分析模型，选择具体上线的版本的重要依据。

Testing

机器学习系统中主要涉及到3种不同的pipeline，分别是数据pipeline，模型pipeline和应用pipeline（类似于模型与应用系统的集成）。针对这3个pipeline，需要构建对应的数据特征测试，模型测试以及应用infra测试，确保整体系统的输出与预期的业务目标相符，达到将数据insights转化为业务价值的目的。这方面Google的ML test score是一个很好的参考。

Monitoring

监控也是一项软件工程的传统最佳实践。上面提到的ML test score中也有一部分是与监控相关。除了传统的系统监控，例如日志，系统资源等方面外，机器学习系统还需要对输入数据，模型预测进行监控，确保预测的质量，并在出现异常情况时自动触发一些应对机制，例如数据或模型的降级，模型的重新训练与部署等。

Reproducibility

与传统软件系统的确定性行为不同，机器学习中带有不少“随机化”的成分，这对各种问题的排查，版本回滚，输出效果的确定性都提出了一定的挑战。因此我们在开发过程中也需要时刻将可复现原则放在心上，设计相应的最佳实践（如设定随机数种子，运行环境等各类依赖的版本化等）。

四、MLOps流程细节

我们来看下具体的机器学习项目流程，并对每一个模块中MLOps需要提供的支持进行详细的展开。

项目设计

项目设计所需要受到的重视程度毋庸置疑，之前在Fullstack Deep Learning的课程介绍中我们也有很大的篇幅来进行介绍。在MLOps领域，我们应该为这部分的工作也设计一系列的标准与文档。业界可以参考的材料也有很多，例如 Machine Learning Canvas ，Data Landscape 等。

数据接入

数据接入方面，我们会利用成熟的数据平台，例如各类数据仓库，数据湖或实时数据源等。对于接入到平台后的数据存储，可以优先考虑带有数据版本支持的组件，例如Delta Lake等。当然也可以采用DVC或自行元数据维护等方案来进行ML相关数据资产的管理。

数据分析

在数据接入后，一般会需要进行各类EDA分析。传统的做法一般是使用notebook来进行交互式分析，但对于分析结果的保存管理，共享协作，数据更新后的自动刷新，高级交互分析能力方面，原生notebook本身还是有不少缺陷，难以很好满足。有一些研究与产品在这个方向上做了一些改进，例如Polynote，Facets，Wrattler等。

数据检查

对于接入的原始数据，通常会出现各类质量问题或数据类型，含义，分布等方面的变化。而机器学习pipeline即使在数据有变化的情况下基本也能顺利运行成功，造成意向不到的各种“静默失败”问题，其排查处理会相当艰难，耗费算法工程师大量的时间精力。因此设置各类自动化的数据检查就显得尤为重要，例如Tensorflow Data Validation就是这方面比较知名的一个library。

O'Reilly在20年做了个关于数据质量方面的调研，发现企业中存在的主要数据问题如下所示：

除上述问题外涉及到模型应用，各类drift的探测也相当重要，比如输入数据的分布变化(data drift)，或者输入数据与预测目标之间关系的变化(concept drift)。为了应对这些数据质量问题，我们需要根据不同的业务领域设计相应的数据质量检查模板，并结合具体情况进行各类属性，统计，甚至基于模型的数据问题检查。

数据工程

这部分的工作包括数据清洗，数据转换，特征工程。根据业务形态的不同，这部分所占的比重可能会各不相同，但总体上来说这部分在整个模型开发过程中占的比重和遇到的挑战是比较大的。包括：

• 对于大量数据处理逻辑的管理，调度执行和运维处理。
• 对于数据版本的管理和使用。
• 对于数据复杂依赖关系的管理，例如数据血缘。
• 对于不同形式数据源的兼容和逻辑一致性，例如lambda架构对batch，realtime两种数据源类型的处理。
• 对于离线和在线数据服务需求的满足，例如离线模型预测和在线模型服务。

以数据血缘为例，一个经常遇到的场景是当我们发现下游数据有问题时，可以通过数据血缘图快速定位上游依赖项，分别进行排查。而在问题修复后，又可以通过血缘关系重新运行所有影响的下游节点，执行相关测试验证。

在建模应用领域，有不少数据处理特征工程方面的操作和应用会更加复杂，例如：

需要使用模型来生成特征，例如各种表达学习中学到的embedding信息。
需要考虑特征计算生成的实践开销与其所带来的模型效果提升的权衡。
跨组织的特征共享与使用。

在这些挑战下，feature store的概念逐渐兴起。

关于这方面又是一个比较大的话题，我们先不做细节展开。从上图可以看出的一个基础特性是我们会根据在线离线的不同访问pattern，选用不同的存储系统来存放特征数据。另外在下游消费时也要考虑特征的版本信息，确保整个流程的稳定可复现。

模型构建

模型构建方面总体来说是受到关注与讨论比较多的部分，有非常多成熟的机器学习框架来帮助用户训练模型，评估模型效果。这块MLOps需要提供的支持包括：

• 模型开发过程中的结果评估与分析，包括指标误差分析，模型解释工具，可视化等。
• 模型本身的各类元数据管理，实验信息，结果记录(指标，详细数据，图表)，文档(model card)等。
• 模型训练的版本化管理，包括各种依赖库，训练代码，数据，以及最终生成的模型等。
• 模型在线更新和离线再训练，增量训练的支持。
• 一些模型策略的集成，例如embedding的提取与保存，stratified/ensemble模型支持，transfer learning之类的增量训练支持等。
• AutoML类的自动模型搜索，模型选择的支持。

在模型实验管理方面，可以借鉴的产品有MLflow，neptune.ai，Weights and Biases等。

从以模型为中心的角度来看，与feature store一样，我们需要进一步引入model repository，支持链接到实验结果的记录，以及模型部署状态，线上监控反馈等信息的打通。各类与模型运维相关的操作都可以在这个组件中进行支持。开源方面的实现可以关注 ModelDB 。

集成测试

完成数据和模型两大块pipeline的构建后，我们需要执行一系列的测试验证来评估是否能将新模型部署到线上。包括：

• 模型预测方面的测试，如精度，预测稳定性，特定case回归等。
• Pipeline执行效率的测试，如整体执行时间，计算资源开销量等。
• 与业务逻辑集成的测试，如模型输出的格式是否符合下游消费者的要求等。

参考Google经典的ML Test Score，具体有以下各类测试：

• 数据验证测试，除了对原始数据输入方面的数据质量检查外，在机器学习的pipeline中做的各类数据特征处理，也需要用一系列的测试来验证其符合预期。
• 特征重要度测试，对于各类构建的特征，我们需要确保其在模型中的贡献度，以免造成计算资源和特征存储上的浪费。对于无用的特征也需要及时清理，控制pipeline的整体复杂度。
• 隐私审计等相关要求测试。
• 模型训练测试，模型应该能够利用数据进行有效训练，如loss会在训练中呈下降趋势。并且预测目标相对于业务目标是有提升作用。
• 模型时效性测试，与旧版本模型的效果进行比对，测试模型指标的下降速度，并设计模型的重训练周期。
• 模型开销测试，确保复杂模型的训练时间投入产出比，相比简单的规则和基线模型有显著的效果提升。
• 模型指标测试，确保模型的测试集验证或特定回归问题验证能够通过。
• 模型公平性测试，对敏感信息，例如性别，年龄等，模型应该在不同特征分组的情况下表现出公平的预测概率。
• 模型扰动测试，对模型的输入数据进行微小的扰动，其输出值的变动范围应该符合预期。
• 模型版本比对测试，对于没有进行重大更新的模型，例如例行触发的retrain，两个模型版本的输出之间不应该有过大的差别。
• 模型训练框架测试，例如重复执行2次相同的训练，应该给出稳定可复现的结果。
• 模型API测试，对于模型服务的输入输出做验证测试。
• 集成测试，对整个pipeline进行运行和验证，确保各个环节的衔接正确。
• 线上测试，在模型部署但对外服务前，需要进行与离线环境相同的一系列验证测试，确保运行结果无误。

模型部署

通过测试后，我们就可以把模型部署上线啦。这里又根据业务形态的不同分成很多不同的类型，需要考虑不同的发布方式，例如：

• Batch预测pipeline
• 实时模型服务
• Edge device部署，如手机app，浏览器等

模型部署的assets除了模型本身外，也需要包含end-to-end测试用例, 测试数据和相应的结果评估等。可以在模型部署完成后再执行一遍相关测试用例，确保开发和部署环境中得到的结果一致。

对于输出较为critical的模型，还需要考虑一系列model governance的需求满足。例如在模型部署前需要进行各类人工审核，并设计相应的sign-off机制。顺带一提responsible AI近年来也是越来越受到重视，在MLOps中的各个环节也需要关注相应功能的支持。

本文转自网络，版权归原作者所有，原文链接：https://segmentfault.com/a/1190000039957405
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！