MLOps简介

1、什么是 MLOps？

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

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

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

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

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

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

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

2、MLOps的各个步骤

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

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

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

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

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

3、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

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

4、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中的各个环节也须要关注相应功能的支持。