机器学习工程（MLOps）实践：机器学习持续交付

2023-06-13 文而科技匡吉

机器学习在工业界的使用越发流行，但是和传统软件工作流程（例如：一个网站应用或者一个移动应用）相比，它的开发、部署和持续性更行迭代更加复杂。机器学习应用主要在三个维度变化：代码本身、模型算法、数据集。这些变化一般比较复杂并且难以预测，同时，它们也很难进行测试、解释和迭代更新。机器学习持续交付（CD4ML）是给机器学习应用带来持续**付和实际实践的重要法则。

1.介绍和定义

2015年，Sculley等人发布的著名**《Hidden Technical Debt in Machine Learning Systems》中，强调实际生活中，机器学习（ML）**，仅仅在工业业务开发代码中占据很小的一部分，存在大量的基础设施和流程来支持机器学习**的发展。**讨论了可集成在机器学习**的很多技术栈资源，其中许多是和数据依赖、模型复杂度、可重用性、测试、监控和在外部世界中的挑战相关的。

许多相似的问题同样存在于传统软件**中，而持续交付已经成为提供自动化、高质量和规范化的一种方法，来创造一个可靠和可重用的流程，将软件应用发布在实际生产中。

除了代码，对于ML模型的变化和用于训练的数据集管理，同样是软件交付过程中的重要挑战。

基于这样的思考，我们可以将持续**付的定义扩展，这些存在于真实世界机器学习**中的元素和挑战，也就是一种方法“对于机器学习的持续**付（CD4ML）”。

对于机器学习的持续**付（CD4ML），是一种软件工程方法，基于代码、数据和模型，以一种小型增量式模式，实现跨功能团队的机器学习应用。这样的应用，具有在任何时候可重现和可靠发布的特征。

2.一个用于销售预测的机器学习应用

自从2016年开始，我们就着手将持续**付模式应用于机器学习**中，以及我们发布一个学习案例，来自于我们使用AutoScout建立的客户端项目，来预测AutoScout平台发布的汽车**。

但是，我们决定构建一个样例ML应用，基于一个公共问题数据集，来展示CD4ML实现，因为我们无法使用实际业务中的代码（基于商业涉密考虑）。这个应用解决了一个众多零售商都会碰到的普通预测问题：基于历史数据，尝试去预测产品将来销售的**。考虑这样的目的，我们采用Kaggle上的公开数据集，目标并不是找出最优预测（这是数据科学家所适合处理的问题），而是证明怎么实现CD4ML。

使用一个监督学习算法和著名的scikit-learn Python库，我们使用标注过的输入数据来训练一个预测模型，并将这个模型集成到一个简单的Web应用中，然后部署在云服务器的生产环境中，如图2所说。

一旦部署成功，我们的Web应用允许用户选择一个产品和未来的一个日期，然后模型将会输出它对于在当天销售**的预测。

2.1常见的挑战和问题

尽管上述的实现有助于我们后续进一步的实现，但是实现这样端到端的过程仍然有着两个挑战。第一个挑战是组织结构：不同的团队可能在整个流程中位于不同的部分，因此如何跨越这些障碍是一个关键。数据工程师可以通过构建流程来获得数据，但是数据科学家可能担心ML模型的构建和优化。机器学习工程师或者开发者将会担心如何集成模型和发布对应的产品。

上面的问题会导致项目延迟和矛盾分化，一个普遍的现象是，工业场景下使用一个仅在实验室环境下可行的模型，并且不进行实用场景证明。或者，如果他们以手动临时方式将其投入生产，这样的产品就很难进行更新迭代。

第二个挑战是技术问题：如何实现过程的可重用和可审查。因为这些团队实用不同的工具，并且遵从不同的工作流程，这样对实现自动端到端开发造成困难。然而，除了代码意外还有很多需要管理的内容，以及对不同的组建进行版本化。其中一些内容工作量巨大，需要非常复杂的工具来实现高效的存储和货物。

解决组织挑战超出本文的范围，但是我们DevOps和敏捷开发中学习，构建跨功能和结果导向的团队，这样的团队包含不同端到端ML**部分的专家。如果你所属的组织无法实现这样的团队，至少尝试打破困难，然后合作解决系列问题。

本文的其余部分将探讨我们为技术挑战找到的解决方案。我们将深入研究每个技术组件，并慢慢改进和扩展端到端流程，使其更加健壮。

3.CD4ML的技术组建

正如我们考虑如何使用机器学习解决预测问题，第一步是要理解数据集。这样情况下，也就是一组CSV文件的**，包含以下的信息：

产品信息，例如：它们的类别、是否是易于腐烂的物品；
存储信息，例如：存储位置、如何进行聚类；
特殊事件信息，例如：公共假期、季节事件；
销售记录信息，例如：特定产品单位销售数量、日期和地址。

在这个阶段，数据分析师和数据科学家通常会执行某种探索性数据分析 (EDA) 以了解数据的形状，并识别广泛的模式和异常值。例如，我们发现销售单位数为负数的产品，我们将其解释为退货。由于我们只想探索销售，而不是退货，因此我们将它们从我们的训练数据集中删除。

在许多组织中，训练有用的 ML 模型所需的数据可能不会完全按照数据科学家可能需要的方式进行结构化，因此它强调了第一个技术组件：可发现和可访问的数据。

3.1可获得的数据

显而易见，最通常的数据资源会成为你的**核心。但是，从组织外部引入其他数据源也很有价值。我们发现了一些用于收集和提供数据的常见模式，例如使用数据湖架构、更传统的数据仓库、实时数据流**，或者最近，我们正在试验分散的数据网格架构。

数据流水线：

流水线是一个重载的术语，尤其是在 ML 应用程序中。我们希望将“数据管道”定义为通过一系列转换阶段获取输入数据，生成数据作为输出的过程。输入和输出数据都可以被提取并存储在不同的位置，例如数据库、流、文件等。转换阶段通常在代码中定义，尽管一些 ETL 工具允许您以图形形式表示它们 . 它们可以作为批处理作业执行，也可以作为长时间运行的流应用程序执行。出于 CD4ML 的目的，我们将数据管道视为工件，可以对其进行版本控制、测试和部署到目标执行环境。

无论您拥有哪种架构风格，重要的是数据易于发现和访问。数据科学家越难找到他们需要的数据，他们构建有用模型所需的时间就越长。我们还应该考虑到他们希望在输入数据之上设计新功能，这可能有助于提高他们模型的性能。

在我们的示例中，在进行初始探索性数据分析后，我们决定将多个文件反规范化为一个 CSV 文件，并清除不相关或可能将不需要的噪声引入模型的数据点（如负销售额） . 然后，我们将输出存储在云存储**中，例如 Amazon S3、Google Cloud Storage 或 Azure Storage Account。

使用此文件来表示输入训练数据的快照，我们能够设计一种简单的方法来根据文件夹结构和文件命名约定对数据集进行版本控制。数据版本控制是一个广泛的主题，因为它可以在两个不同的轴上发生变化：其架构的结构变化，以及随着时间的推移对数据的实际采样。我们的数据科学家 Emily Gorcenski 在这篇博文中更详细地介绍了这个主题，但在本文的后面，我们将讨论随着时间的推移对数据集进行版本控制的其他方法。

值得注意的是，在现实世界中，您可能会有更复杂的数据管道来将数据从多个来源移动到数据科学家可以访问和使用的地方。

3.2可重现性模型训练

机器学习流水线：

“机器学习管道”，也称为“模型训练管道”，是以数据和代码为输入，生成经过训练的ML模型作为输出的过程。这个过程通常涉及数据清洗和预处理、特征工程、模型和算法选择、模型优化和评估。虽然开发此过程包含数据科学家工作流 [1] 的主要部分，但出于 CD4ML 的目的，我们将 ML 管道视为所选模型训练过程的最终自动化实施。

一旦数据可用，我们就会进入模型构建的迭代数据科学工作流程。这通常涉及将数据拆分为训练集和验证集，尝试不同的算法组合，并调整它们的参数和超参数。这会生成一个模型，该模型可以根据验证集进行评估，以评估其预测的质量。这个模型训练过程的一步一步变成了机器学习管道。

在图 5 中，我们展示了如何为我们的销售预测问题构建 ML 管道，突出显示不同的源代码、数据和模型组件。输入数据、中间训练和验证数据集以及输出模型可能是大文件，我们不想将它们存储在源代码控制存储库中。此外，管道的阶段通常在不断变化，这使得很难在数据科学家的本地环境之外重现它们。

为了在代码中形式化模型训练过程，我们使用了一个名为 DVC（数据科学版本控制）的开源工具。它提供了与 Git 相似的语义，但也解决了一些 ML 特定的问题:

它有多个后端插件，用于在源控制存储库之外的外部存储上获取和存储大文件；
它可以**这些文件的版本，允许我们在数据发生变化时重新训练我们的模型；
它**用于执行 ML 管道的依赖关系图和命令，允许在其他环境中重现该过程；
它可以与 Git 分支集成，允许多个实验共存。

例如，我们可以使用三个 dvc 运行命令（-d 指定依赖项，-o 指定输出，-f 是记录该步骤的文件名，-M 是结果指标）配置图 5 中的初始 ML 管道：

每次运行都会创建一个相应的文件，该文件可用于版本控制，并允许其他人通过执行 dvc repro 命令来重现整个 ML 管道。

一旦找到合适的模型，我们会将其视为需要版本化并部署到生产环境的工件。使用 DVC，我们可以使用 dvc push 和 dvc pull 命令从外部存储发布和获取它。

您可以使用其他开源工具来解决这些问题：Pachyderm 使用容器来执行管道的不同步骤，并通过**数据提交和基于此优化管道执行来解决数据版本控制和数据来源问题。 MLflow Projects 定义了一种文件格式来指定管道的环境和步骤，并提供 API 和 CLI 工具来本地或远程运行项目。我们选择 DVC 是因为它是一个简单的 CLI 工具，很好地解决了这部分问题。

3.3模型服务

一旦找到合适的模型，我们需要决定如何在生产中提供和使用它。我们已经看到了一些模式来实现这一目标:

嵌入式模型：这是一种更简单的方法，您可以将模型工件视为在消费应用程序中构建和打包的依赖项。从现在开始，您可以将应用程序工件和版本视为应用程序代码和所选模型的组合。
模型作为单独的服务部署：在这种方法中，模型被包装在一个可以**于消费应用程序部署的服务中。这允许**发布模型更新，但它也可能在推理时引入延迟，因为每次预测都需要某种远程调用。
模型作为数据发布：在这种方法中，模型也被**处理和发布，但消费应用程序将在运行时将其作为数据摄取。我们已经在流/实时场景中看到了这一点，其中应用程序可以订阅在新模型版本发布时发布的事件，并将它们摄取到内存中，同时继续使用以前的版本进行预测。软件发布模式（例如 Blue Green Deployment 或 Canary Releases）也可以应用于此场景。

在我们的示例中，我们决定使用更简单的嵌入模型的方法，因为我们的消费应用程序也是用 Python 编写的。我们的模型作为序列化对象（pickle 文件）导出并由 DVC 推送到存储。在构建我们的应用程序时，我们将其拉取并将其嵌入到同一个 Docker 容器中。从那时起，Docker 镜像成为我们的应用程序+模型工件，它被版本化并部署到生产环境中。

除了使用pickle序列化模型对象之外，还有其他工具选项可以实现嵌入式模型模式。 MLeap 提供了用于导出/导入 Spark、scikit-learn 和 Tensorflow 模型的通用序列化格式。还有与语言无关的交换格式来共享模型，例如 PMML、PFA 和 ONNX。其中一些序列化选项也适用于实现“模型即数据”模式。

另一种方法是使用 H2O 之类的工具将模型导出为 JAR Java 库中的 POJO，然后您可以将其作为依赖项添加到您的应用程序中。这种方法的好处是您可以使用数据科学家熟悉的语言（例如 Python 或 R）训练模型，并将模型导出为在不同目标环境 (JVM) 中运行的编译二进制文件，这样可以更快地推理时间。

为了实现“模型即服务”模式，许多云提供商都有工具和 SDK 来包装您的模型以部署到他们的 MLaaS（机器学习即服务）平台，例如 Azure 机器学习、AWS Sagemaker 或 Google AI 平台 . 另一种选择是使用像 Kubeflow 这样的工具，这是一个旨在在 Kubernetes 上部署 ML 工作流的项目，尽管它试图解决的不仅仅是模型服务部分的问题。

MLflow Models 正试图提供一种标准方法来打包不同风格的模型，以供不同的下游工具使用，一些在“模型即服务”中，一些在“嵌入式模型”模式中。可以说，这是一个当前的开发领域，各种工具和供应商正在努力简化这项任务。但这意味着还没有明确的标准（**的或专有的）可以被视为明显的赢家，因此您需要评估适合您需求的正确选项。

值得注意的是，无论您决定使用哪种模式，模型与其使用者之间始终存在隐式契约。该模型通常会期望输入数据具有某种形状，如果数据科学家更改该合同以需要新输入或添加新功能，您可能会导致集成问题并**使用它的应用程序。这将我们引向测试的主题。

3.4机器学习中的测试和质量检测

可以在 ML 工作流程中引入不同类型的测试。虽然某些方面本质上是不确定的且难以自动化，但有许多类型的自动化测试可以增加价值并提高 ML **的整体质量:

验证数据：我们可以添加测试以根据预期模式验证输入数据，或验证我们对其有效值的假设——例如它们在预期范围内，或者不为空。对于工程特性，我们可以编写单元测试来检查它们的计算是否正确——例如数字特征被缩放或归一化，one-hot 编码的向量包含全零和单个 1，或者适当地替换缺失值。
验证组件集成：我们可以使用类似的方法来测试不同服务之间的集成，使用 Contract Tests 来验证预期的模型接口是否与消费应用程序兼容。当您的模型以不同格式生产时，另一种相关的测试是确保导出的模型仍然产生相同的结果。这可以通过针对相同的验证数据集运行原始模型和生产模型并比较结果相同来实现。
验证模型质量：虽然 ML 模型性能是不确定的，但数据科学家通常会收集和监控许多指标来评估模型的性能，例如错误率、准确性、AUC、ROC、混淆矩阵、精度、召回率等。它们在参数和超参数优化期间也很有用。作为一个简单的质量门，我们可以使用这些指标在我们的管道中引入阈值测试或棘轮，以确保新模型不会根据已知的性能基线降低。
验证模型偏差和公平性：虽然我们可能会在整体测试和验证数据集上获得良好的性能，但检查模型如何针对特定数据切片的基线执行情况也很重要。例如，您可能在训练数据中存在固有偏差，与现实世界中的实际分布相比，特征的给定值（例如种族、性别或地区）有更多的数据点，因此检查数据很重要不同数据切片的性能。像 Facets 这样的工具可以帮助您可视化这些切片以及数据集**征的值分布.

在我们的示例应用程序中，Favorita 定义的评估指标是归一化错误率。我们编写了一个简单的 PyUnit 阈值测试，该测试在错误率超过 80% 时中断，并且该测试可以在发布新模型版本之前执行，以演示我们如何防止错误模型得到提升。

虽然这些是更容易自动化的测试示例，但更全面地评估模型的质量更难。随着时间的推移，如果我们总是针对同一个数据集计算指标，我们就会开始过度拟合。当您有其他模型已经上线时，您需要确保新模型版本不会因看不见的数据而降级。因此，管理和策划测试数据变得更加重要 [2]。

当模型被分发或导出以供不同的应用程序使用时，您还可以发现在训练和服务时间之间工程特征计算方式不同的问题。帮助捕获这些类型问题的一种方法是将保留数据集与模型工件一起分发，并允许消费应用程序团队在集成后根据保留数据集重新评估模型的性能。这相当于传统软件开发中的广泛集成测试。

也可以考虑其他类型的测试，但我们认为在部署管道中添加一些手动阶段也很重要，以显示有关模型的信息并允许人们决定是否应该提升它们。这使您可以对机器学习治理过程进行建模，并引入对模型偏差、模型公平性的检查，或为人类收集可解释性信息以了解模型的行为方式。

随着更多类型的测试，它会让您重新思考测试金字塔的形状：您可以为每种类型的工件（代码、模型和数据）考虑单独的金字塔，以及如何组合它们，如图 6 所示。总的来说，ML **的测试和质量更加复杂，应该成为另一篇深入的**文章的主题。

3.5实验追踪

为了支持此治理过程，重要的是要捕获和显示信息，以便人们决定是否以及应将哪个模型提升到生产环境。由于数据科学过程非常以研究为中心，因此您通常会并行尝试多个实验，其中许多实验可能永远无法投入生产。

研究阶段的这种实验方法与更传统的软件开发过程不同，因为我们预计其中许多实验的代码将被丢弃，只有少数被认为值得投入生产。出于这个原因，我们需要定义一种方法来**它们。

在我们的例子中，我们决定遵循 DVC 建议的方法，使用不同的 Git 分支来**源代码控制中的不同实验。尽管这违背了我们在单个主干上实践持续集成的偏好。 DVC 可以从在不同分支或标签中运行的实验中获取和显示指标，从而可以轻松地在它们之间导航。

在传统软件开发的功能分支中进行开发的一些缺点是，如果分支是长期存在的，它会导致合并痛苦，它会阻止团队更积极地重构，因为更改会影响代码库的更广泛区域，并且会阻碍持续集成 (CI) 的实践，因为它迫使您为每个分支设置多个作业，并且适当的集成会延迟，直到代码合并回主线。

对于 ML 实验，我们期望大多数分支永远不会被集成，并且实验之间代码的变化通常不显着。从 CI 自动化的角度来看，我们实际上确实希望为每个实验训练多个模型，并收集指标以告知我们哪个模型可以移动到部署管道的下一阶段。

除了 DVC，我们用来帮助进行实验**的另一个工具是 MLflow Tracking。它可以部署为托管服务，并提供 API 和 Web 界面来可视化多个实验运行及其参数和性能指标，如图 7 所示。

为了支持这个实验过程，强调拥有弹性基础设施的好处也很重要，因为您可能需要多个环境可用 - 有时还需要专门的硬件 - 用于培训。基于云的基础设施非常适合这一点，许多公共云提供商正在构建服务和解决方案来支持这个过程的各个方面。

3.6模型部署

在我们的简单示例中，我们只是尝试构建一个模型，该模型与应用程序一起嵌入和部署。在现实世界中，部署可能会带来更复杂的场景:

多个模型：有时您可能有多个模型执行相同的任务。例如，我们可以训练一个模型来预测每种产品的需求。在这种情况下，将模型部署为单独的服务可能更适合使用应用程序以通过单个 API 调用获得预测。并且您可以稍后改进该发布接口背后需要多少模型。
影子模型：在考虑替换生产中的模型时，此模式很有用。您可以将新模型与当前模型并排部署，作为影子模型，并发送相同的生产流量以在推广之前收集有关影子模型如何执行的数据。
竞争模型：一个稍微复杂一点的场景是当你在生产中尝试模型的多个版本时——比如 A/B 测试——以找出哪个更好。这里增加的复杂性来自确保流量被重定向到正确模型所需的基础设施和路由规则，并且您需要收集足够的数据来做出具有统计意义的决策，这可能需要一些时间。另一种评估多个竞争模型的流行方法是 Multi-Armed Bandits，它也要求您定义一种方法来计算和监控与使用每个模型相关的奖励。将此应用于 ML 是一个活跃的研究领域，我们开始看到一些工具和服务出现，例如 Seldon 核心和 Azure Personalizer。
在线学习模型：与我们目前讨论的离线训练并在线用于预测的模型不同，在线学习模型使用的算法和技术可以随着新数据的到来不断提高其性能。他们在生产中不断学习。这带来了额外的复杂性，因为如果没有提供相同的数据，将模型版本化为静态工件将不会产生相同的结果。您不仅需要对训练数据进行版本控制，还需要对会影响模型性能的生产数据进行版本控制。

再一次，为了支持更复杂的部署场景，您将受益于使用弹性基础设施。除了可以在生产中运行这些多个模型之外，它还允许您通过在需要时启动更多基础设施来提高**的可靠性和可扩展性。

3.7持续**付编排

有了所有主要构建块，就需要将所有内容联系在一起，这就是我们的持续交付编排工具应运而生的地方。在这个领域有很多工具可供选择，其中大多数提供了配置和执行部署管道的方法，以构建和发布软件到生产环境。在 CD4ML 中，我们有额外的要求来编排：基础设施的供应和机器学习管道的执行，以训练和捕获来自多个模型实验的指标；我们数据管道的构建、测试和部署过程；不同类型的测试和验证来决定推广哪些模型；提供基础设施并将我们的模型部署到生产中。

我们选择使用 GoCD 作为我们的持续交付工具，因为它是以管道的概念作为首要关注点构建的。不仅如此，它还允许我们通过组合不同的管道、它们的触发器以及定义管道阶段之间的手动或自动升级步骤来配置复杂的工作流和依赖项。

在我们的简化示例中，我们还没有构建任何复杂的数据管道或基础设施配置，但我们演示了如何组合两个 GoCD 管道，如图 8 所示：

机器学习管道：在 GoCD 代理内执行模型训练和评估，以及执行基本阈值测试以决定模型是否可以提升。如果模型良好，我们执行 dvc push 命令将其发布为工件。
应用程序部署管道：构建和测试应用程序代码，使用 dvc pull 从上游管道获取提升的模型，将包含模型和应用程序的新组合工件打包为 Docker 映像，并将它们部署到 Kubernetes 生产集群。

随着时间的推移，ML 管道可以扩展为并行执行多个实验（GoCD 的扇出/扇入模型支持的功能），并定义您的模型治理流程以检查偏差、公平性、正确性和其他类型门以做出有关将哪个模型推广并部署到生产的明智决策。

最后，持续交付编排的另一个方面是定义回滚过程，以防已部署的模型在生产中表现不佳或不正确。这为整个过程增加了另一个安全网。

3.8可观测性的模型监控

现在模型已经上线，我们需要了解它在生产中的表现并关闭数据反馈循环。在这里，我们可以重用可能已经为您的应用程序和服务准备好的所有监控和可观察性基础设施。

日志聚合和指标收集工具通常用于从实时**中捕获数据，例如业务 KPI、软件可靠性和性能指标、用于故障排除的调试信息以及在出现异常情况时可能触发警报的其他指标。我们还可以利用这些相同的工具来捕获数据以了解我们的模型的行为方式，例如:

模型输入：将哪些数据馈送到模型，从而可以了解任何训练服务偏差。模型输出：模型根据这些输入做出哪些预测和建议，以了解模型在真实数据上的表现。
模型可解释性输出：模型系数、ELI5 或 LIME 输出等指标，允许进一步调查以了解模型如何进行预测，以识别训练期间未发现的潜在过度拟合或偏差。
模型输出和决策：我们的模型根据生产输入数据做出哪些预测，以及根据这些预测做出哪些决策。有时应用程序可能会选择忽略模型并根据预定义的规则做出决定（或避免未来的偏见）。
用户行为和奖励：基于进一步的用户行为，我们可以捕获奖励指标以了解模型是否具有预期效果。例如，如果我们显示产品推荐，我们可以**用户何时决定购买推荐产品作为奖励。
模型公平性：针对可能存在偏见的已知特征（例如种族、性别、年龄、收入群体等）分析输入数据和输出预测。

在我们的示例中，我们使用 EFK 堆栈进行监控和可观察性，由三个主要工具组成:

Elasticsearch：一个开源搜索引擎。
FluentD：统一日志层的开源数据收集器。
Kibana：一个开源 Web UI，可以轻松探索和可视化 Elasticsearch 索引的数据。

我们可以检测我们的应用程序代码，将模型输入和预测记录为 FluentD 中的事件:

这个事件然后在 ElasticSearch 中被转发和索引，我们可以使用 Kibana 通过 Web 界面对其进行查询和分析，如图 9 所示。

还有其他流行的监控和可观察性工具，例如 ELK 堆栈（一种使用 Logstash 而不是 FluentD 进行日志摄取和转发的变体）、Splunk 等。

当您在生产中部署多个模型时，收集监控和可观察性数据变得更加重要。例如，您可能有一个影子模型要评估，您可能正在执行拆分测试，或者使用多个模型运行多臂***实验。

如果您在边缘训练或运行联合模型，这也很重要——例如在用户的移动设备上——或者如果您正在部署在线学习模型，这些模型会随着时间的推移从生产中的新数据中学习而发生变化。

通过捕获这些数据，您可以关闭数据反馈循环。这是通过收集更多真实数据（例如在定价引擎或推荐**中）或通过在循环中添加人员来分析从生产中捕获的新数据并对其进行管理以创建用于新模型和改进模型的新训练数据集来实现的 . 关闭这个反馈循环是 CD4ML 的主要优势之一，因为它允许我们根据从实际生产数据中获取的知识来调整我们的模型，从而创建一个持续改进的过程。

4.端到端的CD4ML流程

通过逐步解决每个技术挑战，并使用各种工具和技术，我们设法创建了图 10 所示的端到端流程，该流程管理跨所有三个轴的工件的提升：代码、模型和数据。

在基础上，我们需要一种简单的方法来管理、发现、访问和版本化我们的数据。然后，我们将模型构建和训练过程自动化以使其可重现。这使我们能够试验和训练多个模型，这就需要测量和**这些试验。一旦我们找到合适的模型，我们就可以决定如何生产和提供它。由于模型在不断发展，我们必须确保它不会**与消费者的任何合同，因此我们需要在部署到生产之前对其进行测试。一旦投入生产，我们就可以使用监控和可观察性基础设施来收集新数据，这些数据可以进行分析并用于创建新的训练数据集，从而关闭持续改进的反馈循环。

持续交付编排工具协调端到端的 CD4ML 流程，按需提供所需的基础设施，并管理模型和应用程序如何部署到生产中。

5.MLOps未来展望

我们在本文中使用的示例应用程序和代码可在我们的 Github 存储库中找到，并被用作我们在各种会议和客户中介绍的为期半天的研讨会的基础。我们将继续发展关于如何实施 CD4ML 的想法。在本节中，我们将重点介绍研讨会材料中未反映的一些改进领域，以及一些需要进一步探索的**领域。

数据版本化

数据流程

平台思考

无偏差智能**进化

6.总结

随着机器学习技术不断发展并执行更复杂的任务，我们对如何管理此类应用程序并将其交付到生产环境的知识也在不断发展。通过引入和扩展持续交付的原则和实践，我们可以以安全可靠的方式更好地管理发布对机器学习应用程序的更改的风险。使用示例销售预测应用程序，我们在本文中展示了 CD4ML 的技术组件，并讨论了我们如何实现它们的一些方法。我们相信这种技术会继续发展，新工具会出现和消失，但持续交付的核心原则仍然相关，您应该为自己的机器学习应用程序考虑。

股票资讯