简介

在本文中，我将讨论 MLOps 的总体目标、功能性 MLOps 框架的主要功能及其原理，以及在整个 ML 开发生命周期中利用这些功能的建议。

MLOps 的宗旨

MLOps 的主要作用是像管理真正的软件一样管理 ML 解决方案。这些解决方案必须能够承受巨大的流量和严格的服务水平协议。数据科学家和工程师必须预测并计划对解决方案的改进版本进行迭代和重新部署的需求。

模型训练

虽然 MLOps 主要关注的是 ML 解决方案的部署和迭代，但在模型培训过程中也应采用一些做法。遵循这些做法可以大大减少 ML 解决方案的初始部署和最终迭代的麻烦。

首先要考虑的是适当的身份和访问管理（IAM）。通常，用于训练 ML 模型的数据存储在内部系统或各种云数据存储中，必须以编程方式检索这些数据，以便进行训练、调整和最终评分。在初始开发过程中，数据科学家通常使用个人凭据与数据交互，但在生产工作流中使用此类凭据会产生安全问题。因此，当工作流从开发账户晋升到生产账户时，最好定义与个人无关的角色或组，以安全地获取并用于建立所需的连接。

训练过程中的另一个相关做法是为特征工程、预处理和模型训练任务选择和整合适当的工具。使用大量数据的企业可能会利用一个平台来并行化模型开发的上游任务，同时使用另一个平台来进行模型训练和调整。在这种情况下，大多数云平台都支持在临时开发和生产部署环境中与此类并行平台集成。在对现有 ML 解决方案进行迭代时，针对手头的任务正确利用和集成平台可大大加快开发时间。

最后一种做法，也可以说是最关键的一种做法，就是适当地创建和使用环境。除其他事项外，模型训练最终会形成一个评分脚本，该脚本将利用 ML 解决方案的工件（如训练好的模型文件）对生产数据进行预测。与其他脚本一样，该脚本也会使用执行代码所需的特定模块或库。创建或扩展一个包含这些依赖项的 docker 镜像，以便用来构建容器，在生产中运行 ML 解决方案的工作流，这样可以节省部署时间，确保可重复性，并提高环境的可重用性，以适应未来的迭代或类似的 ML 项目。

工件注册表

工件注册表充当存储部署 ML 解决方案所需对象的集中位置。这可能包括经过训练的模型文件、编码字典或评分前预处理所需的插补或标准化统计数据。

工件注册表的最基本功能是集中和组织部署 ML 解决方案所需的所有工件，但许多云平台还提供其他极具吸引力的功能，例如迭代之间的自动版本控制、训练数据的沿袭，以及通过管道或端点提供模型时直接从注册中心获取工件的能力。

模型部署模式

用于部署 ML 解决方案的模式主要取决于客户打算如何使用预测结果。如果要对观测数据组进行评分，并以中高延迟向用户提供服务，则适合批量部署。如果单个观察结果的评分延迟较低，或者你的 ML 解决方案将与其他应用程序集成，则适合采用端点部署。在某些情况下，结合使用这些模式也是明智之举。例如，当模型评分的上游和下游任务繁多、复杂且计算成本高时。

批量部署通常采用流水线的形式，有三个通用步骤，但也可以更少或更多步骤：(1) 预处理步骤，获取数据并为预测做好准备；(2) 评分步骤，使用前一步骤的数据，获取必要的工件，并对数据进行评分；(3) 后处理步骤，使用前一步骤的评分数据，对其进行操作和补充，供用户使用，然后将其写入所需的位置。每个步骤都可以定义为使用特定的环境和计算实例。此外，还可将管道配置为根据事件或设定的日程触发。

将 ML 解决方案部署到端点通常需要参考评分工件（如工件注册表）、评分脚本以及脚本将在其中执行的环境。端点通常可以支持多个部署，包括独特 ML 解决方案的各种迭代。将多个解决方案部署到单个端点的能力具有巨大的优势，可以为数据科学家提供一种方法，在生产中与真实客户一起测试其解决方案的最新迭代！部署之间的流量可以手动或自动分配；同样的功能还可以实现大规模 A/B 测试。值得注意的是，与使用管道相比，端点部署始终处于 "开启 "状态，这意味着它们是一种更昂贵的模式。

对于需要隔离关注点的部署，可以使用结合使用管道和端点的部署模式。这种管道看起来与批量部署没有什么不同，主要区别在于评分步骤会调用 ML 解决方案部署到的端点，而不是直接将工件（如训练好的模型文件）读取到管道执行的内存中使用。

模型监控

一旦开发并部署了 ML 解决方案，人们普遍认为该解决方案的功效会随着时间的推移而降低。当生产数据的特征相对于用于训练 ML 解决方案的历史数据发生变化时，或者当原始 ML 解决方案学习到的底层关系不再能令人满意地描述特征与响应之间的关系时，就会出现这种情况。这两种现象中的任何一种都被称为 "模型漂移"。

模型漂移可以根据训练数据和生产特征数据之间的分布差异来衡量，即所谓的 "数据漂移"。或者，也可以根据自己的评估标准（如 F1），将模型在生产过程中的功效与训练过程中的功效进行比较来衡量，这就是所谓的 "概念漂移"。

大多数云平台至少提供数据漂移检测服务。这些服务使用两个基本组件：基线和目标。基线由用于构建 ML 解决方案的训练特征数据组成。目标数据由你的 ML 解决方案评分的连续生产数据组成。基线和目标之间的分布差异会在设定的时间间隔内进行计算和报告。当计算出的差异超过设定的容差时，就会向数据科学家表明，他们的 ML 解决方案可能需要根据最新数据进行刷新，以保持客户所期望的性能标准。

在部署任何 ML 解决方案后，建立模型监控能力应该是 MLOps 框架的一项明确要求。但根据我的经验，这种期望在很大程度上是例外，而不是常规，导致人们普遍缺乏对已部署 ML 解决方案的稳定性和可用性的认识。

模型再训练管道

根据数据漂移检测等服务，当人工智能解决方案的性能漂移超出了可接受的范围时，就表明应该根据最新数据对模型进行重新训练。这可以通过模型再训练管道轻松实现，该管道与批量部署模式中使用的管道服务性质相同。请注意，自动重新训练并不涉及额外的特征工程、模型选择或超调。它只是在最新的数据样本上，利用之前设定的函数形式和学习到的超参数，对现有的 ML 解决方案进行重新训练。

模型再训练管道通常包括两个通用步骤： (1) 获取数据并为训练做准备的预处理步骤；(2) 通过后续步骤数据、重新训练 ML 解决方案并将生成的工件存入工件注册表的训练步骤。重新训练步骤还可以记录模型的性能，以供审查。

由于生成的 ML 解决方案的最新迭代的性质没有发生根本变化，因此可以使用原始解决方案的部署模式（包括环境、评分脚本或管道定义）将其无缝部署到生产中。到目前为止，我还不建议自动部署重新训练的模型。这一决定应由数据科学家自行决定。

此外，一些云平台还允许用户配置其再培训管道，以便在发生事件（如超过数据漂移检测服务中设定的容差）时自动触发。

拼接在一起

了解了功能性 MLOps 框架的要素后，让我们来讨论一下它们之间的关系。请注意，本示例仅说明端点部署模式的使用，其他模式也同样适用。

上图描述了我们的租户如何在从解决方案开始到迭代的 ML 开发生命周期中相互配合：

1. 最初的 ML 解决方案需要经过培训，注意使用适当的用户角色和组来获取外部数据，并为每项任务利用正确的平台。培训的最终成果是部署所需的工件、在生产中进行预测的评分脚本以及评分脚本的运行环境。
2. 部署所需的所有工件都将存入模型注册表，并充分利用其他可用功能（如版本控制、数据沿袭等）。
3. 初始的训练有素的 ML 解决方案（M1）将使用最合适的模式（在本例中为端点）进行部署，并参考适当的注册工件、评分脚本和环境。
4. 初始部署后，会创建一个模型监控服务（即数据漂移检测），以监控 ML 解决方案在生产中的性能。基线组件通过训练分区实例化，目标组件通过测试分区实例化。
5. 生产中的所有评分数据都会同时被转移并附加到模型监控服务的目标中，以计算模型漂移并发出警报。
6. 当原始 ML 解决方案的偏离程度超出可接受范围时，无论是手动还是使用自动触发器，都会执行自动模型再训练管道。
7. 自动模型再训练管道的最终结果是将所有更新的工件注册到工件注册表中，这是部署此次迭代的 ML 解决方案（M2）所必需的。
8. 最后，为最新迭代的 ML 解决方案手动部署已注册的工件集，并重复使用现有的基础设施。在此示例中，最新迭代与之前的迭代同时部署，因此客户流量可以慢慢分配到新版本，作为生产中的验证手段。

结论

在本文中，我强调了 MLOps 对于继续加快 ML 应用步伐的日益重要性，回顾了 MLOps 框架包括哪些功能，并讨论了这些功能在整个 ML 开发生命周期中的相互关系。

虽然许多组织才刚刚开始 MLOps 之旅，但我鼓励大家一次一种能力，使自己的方法更加成熟！