机器学习持续交付（CD4ML）：自动化机器学习应用的端到端生命周期

机器学习持续交付（Continuous Delivery for Machine Learning，简称 CD4ML）旨在将持续交付的原则和实践应用到机器学习应用中，帮助团队自动化机器学习应用从数据准备、模型训练、测试验证到部署监控的端到端生命周期。

机器学习应用正在行业中变得越来越普遍。但与传统软件，例如 Web 服务或移动应用相比，机器学习应用的开发、部署和持续改进要复杂得多。机器学习应用同时受到代码、模型和数据三类因素的影响，其行为通常更复杂、更难预测，也更难测试、解释和改进。

什么是机器学习持续交付（CD4ML）？

在 Sculley 等人于 2015 年发表的一篇著名论文《机器学习系统中的隐藏技术债务》中，作者指出，在真实世界的机器学习系统中，真正的机器学习代码只占很小一部分；而支撑系统持续演进的基础设施和流程，则要庞大得多。论文还讨论了这类系统中可能累积的多种技术债务来源，包括数据依赖、模型复杂性、可复现性、测试、监控，以及对外部环境变化的响应能力等。

传统软件系统同样会面临许多类似问题。持续交付正是通过自动化、质量保障和工程规范，建立一套可靠、可重复的软件发布流程，使软件能够安全地交付到生产环境。

在《持续交付》一书中，Jez Humble 和 Dave Farley 对持续交付作出了如下定义：

持续交付是一种能力：能够以可持续的方式，安全、快速地将各种类型的变更——包括新功能、配置变更、缺陷修复和实验——发布到生产环境，或交付给用户。

对于机器学习系统而言，除了代码之外，模型及其训练数据的变更同样是需要管理、并纳入软件交付流程的重要变更类型。

图 1：机器学习应用中的三个变化轴——数据、模型和代码——以及它们发生变化的一些原因

基于这一点，我们可以扩展持续交付的定义，将真实世界机器学习系统中的新要素和新挑战纳入其中。我们将这种方法称为“机器学习持续交付”，即 CD4ML。

机器学习持续交付是一种软件工程方法：跨职能团队以代码、数据和模型为基础，以小而安全的增量构建机器学习应用，使其能够随时复现、可靠发布，并具备较短的适应周期。

这个定义包含以下基本原则。

软件工程方法： 它帮助团队高效地构建高质量软件。

跨职能团队： 来自数据工程、数据科学、机器学习工程、软件开发、运维以及其他知识领域的专家，具备不同技能和工作方式。他们以协作方式共同工作，充分发挥每位成员的能力和优势。

基于代码、数据和机器学习模型生成软件： 机器学习软件生产过程中产生的所有制品都需要被管理和版本控制，并且往往需要不同的工具和工作流来支撑。

小而安全的增量： 软件制品的发布被拆分为较小的增量，使团队能够更清楚地观察和控制结果差异，从而提升整个过程的安全性。

可复现且可靠的软件发布： 尽管模型输出可能具有不确定性，也并不总是容易复现，但将机器学习软件发布到生产环境的过程本身应当可靠且可复现，并尽可能通过自动化实现。

随时可发布的软件： 机器学习软件必须始终处于可发布状态。即使企业并不打算频繁发布，也应随时具备发布能力。因此，何时发布软件应当是业务决策，而不是技术决策。

短适应周期： 短周期意味着开发和反馈周期以天甚至小时为单位，而不是以周、月甚至年为单位。实现这一目标的关键，在于流程自动化，并在流程中内建质量保障机制。这样可以形成反馈循环，使团队能够根据模型在生产环境中的表现持续调整模型。

本文将介绍我们在实施 CD4ML 过程中发现的关键技术组件，并通过一个示例机器学习应用解释相关概念，展示如何将不同工具组合起来，构建完整的端到端流程。在适当之处，我们也会介绍所选工具的替代方案。此外，随着这一实践在行业中不断成熟，本文还将探讨未来的发展方向和研究空间。

机器学习持续交付在销售预测中的应用

自 2016 年以来，我们一直在思考如何将持续交付应用到机器学习系统中，并曾发布和展示过一个案例研究。该案例来自我们与海外某汽车交易平台合作的客户项目，目标是预测其平台上发布车辆的价格。

不过，由于我们无法使用真实客户代码作为示例，因此决定基于一个公开问题和公开数据集，构建一个示例机器学习应用，用于演示 CD4ML 的实现方式。该应用解决的是许多零售商都会面临的常见预测问题：如何基于历史数据预测特定产品未来的销量。

我们基于海外某大型食品零售商在某数据竞赛平台上发布的问题，构建了一个简化解决方案。为了演示 CD4ML 的实现，我们对原始数据集进行了合并和简化，因为我们的目标并不是获得最佳预测结果——这项工作更适合由数据科学家完成。

我们使用监督学习算法和流行的 Python 库 scikit-learn，基于带标签的输入数据训练预测模型，并将该模型集成到一个简单的 Web 应用中，随后部署到云端生产环境。

图 2：训练机器学习模型、将其与 Web 应用程序集成并部署到生产环境的初始流程

部署完成后，Web 应用允许用户选择产品和未来日期，模型则会输出该产品在该日期的销量预测。

图 3：用于演示我们模型运行情况的 Web 用户界面

机器学习应用交付中的常见挑战

这个示例为后续讨论提供了良好的起点，但要完整实现这一流程，本身就存在两大挑战。

第一个挑战来自组织结构。不同团队可能负责流程中的不同部分，而在交接过程中，团队之间往往缺乏明确的跨职能协作规范，形成所谓的“隔墙移交”。例如，数据工程师可能负责构建数据管道，以提供数据访问能力；数据科学家则专注于构建和改进机器学习模型。随后，机器学习工程师或开发人员还需要考虑如何集成该模型，并将其发布到生产环境。

图 4：大型组织中常见的功能孤岛会造成障碍，阻碍机器学习应用程序部署到生产环境的端到端流程自动化。

这种协作方式会导致延迟和摩擦。一个常见现象是，某些模型只能在实验室环境中运行，并长期停留在概念验证阶段。即使它们最终以手工、临时的方式投入生产，也往往很快变得陈旧，并且难以更新。

第二个挑战是技术性的：如何使流程具备可复现性和可审计性。由于这些团队使用的工具和工作流不同，因此很难实现端到端自动化。除了代码之外，还有更多制品需要管理，而对这些制品进行版本控制并不容易。其中一些制品体积可能非常庞大，需要更复杂的工具才能高效存储和检索。

解决组织层面的挑战超出了本文的讨论范围。不过，我们可以借鉴敏捷和 DevOps 的经验，组建跨职能、以结果为导向的团队，汇集不同领域的专家，共同端到端交付机器学习系统。如果组织暂时无法做到这一点，至少也应鼓励团队打破边界，在整个流程中尽早且频繁地协作。

在实践中，如果团队希望先从协作层面降低沟通成本，也可以借助 Worktile 这类通用项目协作系统，将任务、项目、文档、即时沟通、目标、日历、甘特图、工时和审批等协作要素统一到一个工作空间中，使数据工程、数据科学、开发、测试和运维等不同角色围绕同一目标协同推进。

本文余下部分将重点讨论我们针对技术挑战找到的解决方案。我们将逐一分析各个技术组件，并逐步改进和扩展端到端流程，使其更加稳健。

CD4ML 的关键技术组成部分

当我们考虑如何用机器学习解决预测问题时，第一步是理解数据集。在本例中，数据集由一组 CSV 文件组成，包含以下信息：

• 产品信息，例如产品分类以及是否为易腐商品；
• 门店信息，例如门店位置以及门店分组方式；
• 特殊事件，例如公共假日、季节性活动，或某一年发生在当地的一次强震；
• 销售交易记录，包括特定产品在特定日期和地点的销售数量。

在这一阶段，数据分析师和数据科学家通常会进行探索性数据分析，也就是 EDA，以理解数据结构，并识别整体模式和异常值。例如，我们发现有些产品的销量为负数，并将其解释为退货。由于我们希望探索的是销量而不是退货，因此将这些记录从训练数据集中移除。

在许多组织中，训练有效机器学习模型所需的数据，其结构并不总是完全符合数据科学家的需求。这就凸显出第一个关键技术组成部分：可发现且可访问的数据。

可发现且可访问的数据

最常见的数据来源是组织的核心交易系统。不过，引入组织外部的数据源同样可能带来价值。我们观察到一些常见的数据收集和使用模式，例如数据湖架构、更传统的数据仓库、实时数据流集合，以及近年来持续被探索的去中心化数据网格架构。

无论采用哪种架构，确保数据易于发现和访问都至关重要。数据科学家越难找到所需数据，构建有效模型所需的时间就越长。与此同时还应考虑到，数据科学家可能希望基于输入数据构建新的特征，以提升模型性能。

在我们的示例中，完成初步探索性数据分析之后，我们决定将多个文件反规范化为一个 CSV 文件，并清理掉无关数据点，或那些可能为模型引入不必要噪声的数据点，例如负销售数据。随后，我们将结果存储在云存储系统中，例如主流云厂商提供的对象存储服务。

通过使用该文件表示输入训练数据的一个快照，我们可以基于文件夹结构和文件命名约定，设计一种简单的数据集版本控制方法。数据版本控制是一个广泛的话题，因为数据会从两个不同维度发生变化：其一是数据模式的结构变化，其二是数据样本本身随时间推移而发生的变化。相关从业者曾在专题文章中对这一问题进行过更深入的讨论；本文稍后也会介绍其他对数据集进行时间维度版本控制的方法。

值得注意的是，在真实场景中，你可能需要更复杂的数据管道，才能将来自多个来源的数据移动到数据科学家可以访问和使用的位置。

可复现的模型训练

数据可用之后，我们就进入迭代式数据科学工作流，也就是模型构建。这通常包括将数据拆分为训练集和验证集，尝试不同算法组合，并调整其参数和超参数。最终会生成一个模型，并基于验证集对其进行评估，以衡量预测质量。模型训练过程中的各个步骤共同构成机器学习流水线。

在我们的销售预测问题中，机器学习流水线包含不同的源代码、数据和模型组件。输入数据、中间训练集和验证集，以及输出模型都可能是大型文件，我们不希望将它们存储在源代码控制仓库中。此外，流水线的各个阶段通常也在不断变化，这使得这些流程很难在数据科学家的本地环境之外复现。

图 5：我们销售预测问题的机器学习流程，以及使用 DVC 实现自动化的 3 个步骤。

为了将模型训练过程规范化为代码，我们使用了一个名为 DVC，即 Data Version Control 的开源工具。它提供了与 Git 类似的语义，同时解决了一些机器学习场景中特有的问题：

• 它提供多个后端插件，可以在源代码控制仓库之外，从外部存储中获取和保存大型文件；
• 它可以跟踪这些文件的版本，使我们能够在数据变化时重新训练模型；
• 它可以跟踪依赖关系图，以及执行机器学习流水线所需的命令，从而允许在其他环境中复现该过程；
• 它可以与 Git 分支集成，使多个实验能够同时存在。

例如，我们可以使用三个命令配置初始机器学习流水线。其中，dvc run 命令用于定义流水线步骤，-d 指定依赖项，-o 指定输出，-f 指定记录该步骤的文件名，-M 指定结果指标：

dvc run -f input.dvc \
  -d src/download_data.py \
  -o data/raw/store47-2016.csv \
  python src/download_data.py

dvc run -f split.dvc \
  -d data/raw/store47-2016.csv \
  -d src/splitter.py \
  -o data/splitter/train.csv \
  -o data/splitter/validation.csv \
  python src/splitter.py

dvc run \
  -d data/splitter/train.csv \
  -d data/splitter/validation.csv \
  -d src/decision_tree.py \
  -o data/decision_tree/model.pkl \
  -M results/metrics.json \
  python src/decision_tree.py

每次运行都会创建一个相应的文件，该文件可以提交到版本控制系统中，并允许其他人通过执行 dvc repro 命令复现完整的机器学习流水线。

一旦找到合适的模型，我们会将其视为需要版本控制并部署到生产环境的制品。借助 DVC，我们可以使用 dvc push、dvc pull 和 dvc fetch 等命令，在外部存储中发布和获取模型。

还有一些开源工具也可用于解决类似问题。有些工具使用容器执行流水线的各个步骤，并通过跟踪数据提交来优化流水线执行，从而解决数据版本控制和数据溯源问题。也有工具定义了项目文件格式，用于指定流水线的环境和步骤，并提供 API 和 CLI 工具，以便在本地或远程运行项目。我们选择 DVC，是因为它是一个简单易用的 CLI 工具，并且能够很好地解决这一部分问题。

模型服务与模型部署方式

找到合适的模型后，我们需要决定如何在生产环境中部署和使用它。我们观察到几种常见模式。

嵌入式模型： 这是一种较简单的方法，即将模型制品视为依赖项，并在使用该模型的应用内部构建和打包。从此之后，应用制品和版本可以被视为应用代码与所选模型的组合。

将模型部署为独立服务： 在这种方式中，模型被封装在一个服务中，并可以独立于使用该模型的应用进行部署。这使得模型更新能够独立发布，但也可能带来推理延迟，因为每次预测都需要进行某种形式的远程调用。

将模型作为数据发布： 在这种方式中，模型也被独立处理和发布，但使用模型的应用会在运行时将其作为数据摄取。我们见过这种方法应用于流式或实时场景：应用可以订阅模型新版本发布事件，并在新版本发布时将其加载到内存中，同时继续使用旧版本进行预测。蓝绿部署、金丝雀发布等软件发布模式也可以应用于这一场景。

在我们的示例中，由于应用本身也是用 Python 编写的，因此我们选择了更简单的嵌入式模型方式。模型被导出为序列化对象，也就是 pickle 文件，并由 DVC 推送到存储中。构建应用时，我们拉取该模型，并将其嵌入同一个 Docker 容器。从那一刻起，这个 Docker 镜像就成为了“应用 + 模型”的组合制品，并被版本控制和部署到生产环境。

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

另一种方法是使用相关工具，将模型导出为 Java JAR 库中的 POJO 对象，再将其作为依赖项添加到应用中。这种方式的优势在于，你可以使用数据科学家熟悉的语言，例如 Python 或 R 来训练模型，再将模型导出为编译后的二进制文件，在不同目标环境，例如 JVM 中运行，从而在推理阶段获得更好的性能。

为了实现“模型即服务”模式，许多云服务提供商都提供了工具和 SDK，可以将模型封装并部署到其机器学习平台中。另一种选择是使用 Kubeflow。Kubeflow 是一个旨在将机器学习工作流部署到 Kubernetes 上的项目，尽管它试图解决的问题远不止模型服务这一部分。

MLflow Models 致力于提供一种标准化的模型打包方式，使模型能够以不同形式呈现，并被不同下游工具使用，包括“模型即服务”和“嵌入式模型”两种模式。不言而喻，这一领域仍处于发展阶段，各类工具和供应商都在努力简化这一过程。这也意味着，目前尚不存在一个被广泛公认的最佳标准，无论是开源方案还是专有方案。因此，你需要根据自身需求评估合适的解决方案。

值得注意的是，无论选择哪种模式，模型与其使用者之间始终存在一种隐式契约。模型通常期望输入数据符合特定格式。如果数据科学家更改该契约，例如要求新的输入或添加新的特征，就可能引发集成问题，并破坏使用该模型的应用。这就引出了测试的话题。

机器学习中的测试与质量保障

机器学习工作流中可以引入多种类型的测试。尽管某些方面本质上具有不确定性，且很难实现自动化，但许多自动化测试仍然可以带来价值，并提升机器学习系统的整体质量。

数据验证： 我们可以添加测试来验证输入数据是否符合预期模式，也可以验证我们对有效值的假设，例如它们是否位于预期范围内，或者是否不为空。对于人工设计的特征，我们可以编写单元测试来检查其计算是否正确，例如数值特征是否完成缩放或归一化，独热编码向量是否包含所有零和一个 1，或者缺失值是否被正确替换。

组件集成验证： 我们可以借鉴服务之间集成测试的方法，使用契约测试验证预期模型接口是否与使用该模型的应用兼容。另一种相关测试是：当模型以不同格式部署到生产环境时，确保导出的模型仍能产生相同结果。具体做法是使用同一验证数据集分别运行原始模型和生产模型，并比较结果是否一致。

模型质量验证： 尽管机器学习模型的性能具有不确定性，但数据科学家通常会收集并监控一系列指标来评估模型性能，例如错误率、准确率、AUC、ROC 曲线、混淆矩阵、精确率和召回率等。这些指标在参数和超参数优化过程中也非常有用。我们可以将这些指标作为简单的质量门禁，在流程中引入阈值测试或棘轮机制，确保新模型的性能不会低于已知基准模型。

模型偏差与公平性验证： 即使模型在整体测试集和验证集上表现良好，我们仍然需要检查它在特定数据切片上的表现是否优于基线模型。例如，训练数据中可能存在固有偏差：某个特征，如种族、性别或地区的某些取值，在训练集中出现得远多于其在现实世界中的实际分布。因此，检查模型在不同数据切片上的表现非常重要。Facets 等工具可以帮助可视化这些切片，以及数据集中各个特征值的分布情况。

在我们的示例应用中，原始问题定义的评估指标是归一化错误率。我们编写了一个简单的 PyUnit 阈值测试：当错误率超过 80% 时，测试失败。该测试可以在发布新模型版本前执行，用于演示如何阻止劣质模型被推广到后续阶段。

尽管上述测试更容易实现自动化，但要更全面地评估模型质量仍然更加困难。随着时间推移，如果我们始终使用同一个数据集计算指标，就可能出现过拟合。此外，当已经有其他模型在生产环境中运行时，还需要确保新模型版本不会在未见过的数据上表现下降。因此，管理和维护测试数据尤为重要。

当模型被分发或导出供其他应用使用时，可能会出现训练阶段与实际应用阶段特征计算方式不一致的问题。发现这类问题的一种方法是，将一个保留数据集与模型一起分发，让使用模型的应用团队在集成后使用该保留数据集重新评估模型性能。这相当于传统软件开发中的完整集成测试。

还可以考虑其他类型的测试。不过，我们认为，在部署流程中加入一些人工步骤也很重要，用于展示模型信息，并允许人工判断是否应推广该模型。这样可以构建机器学习治理流程，并引入模型偏差、模型公平性检查，或收集可解释性信息，帮助人们理解模型行为。

随着测试类型不断增多，你需要重新思考测试金字塔的结构：可以为每种制品类型——代码、模型和数据——分别构建测试金字塔，也可以考虑如何将它们组合在一起。总而言之，机器学习系统的测试与质量控制更加复杂，值得另写一篇文章进行深入讨论。

图 6：CD4ML 中如何组合数据、模型和代码的不同测试金字塔的示例

实验跟踪：如何管理多个机器学习实验

为了支持模型治理流程，收集并展示相关信息至关重要。只有这样，人们才能决定是否将某个模型推广到生产环境，以及应该推广哪一个模型。由于数据科学流程高度依赖研究探索，因此通常会同时开展多个实验，而其中许多实验最终都不会进入生产环境。

这种研究阶段的实验方式与传统软件开发流程不同，因为我们预期许多实验代码最终会被丢弃，只有少数实验被认为值得投入生产。因此，我们需要建立一套方法来跟踪这些实验。

在我们的案例中，我们决定采用 DVC 建议的方法，即使用不同 Git 分支在源代码控制系统中跟踪不同实验。尽管这与我们通常偏好的单主干持续集成方式相悖，但 DVC 可以获取并展示不同分支或标签下实验运行产生的指标，从而便于我们在实验之间进行切换和比较。

在传统软件开发中，使用特性分支开发存在一些缺点：如果分支存活时间过长，可能导致合并困难；由于变更可能影响代码库中更广泛的区域，团队可能不愿积极重构；此外，它也会阻碍持续集成实践，因为你不得不为每个分支设置多个任务，而真正的集成会被推迟到代码合并回主线之后。

但对于机器学习实验而言，我们预计大多数分支永远不会被合并，而且实验之间的代码差异通常并不大。从持续集成自动化的角度来看，我们真正希望的是：为每个实验训练多个模型，并收集指标，以判断哪些模型可以进入部署流程的下一阶段。

除了 DVC，我们还使用实验跟踪工具辅助实验管理。这类工具可以作为托管服务部署，并提供 API 和 Web 界面，用于可视化多个实验运行及其参数和性能指标。

图 7：MLflow 跟踪 Web 用户界面，用于显示实验运行、参数和指标

为了支持这一实验过程，强调弹性基础设施的优势非常重要，因为你可能需要多个可用环境，有时还需要专用硬件来进行训练。云基础设施天然适合这种需求，许多公有云提供商也正在构建相关服务和解决方案，以支持该过程中的不同环节。

模型部署的复杂场景

在我们的简单示例中，我们只尝试构建一个模型，并将其嵌入应用中进行部署。在真实应用中，模型部署场景可能复杂得多。

多模型： 有时，你可能需要多个模型执行同一任务。例如，我们可以训练一个模型来预测每种产品的需求。在这种情况下，将模型部署为独立服务可能更适合应用使用，因为应用可以通过单个 API 调用获取预测结果。之后，你可以根据需要调整已发布接口背后的模型数量。

影子模型： 当你考虑替换生产环境中的模型时，这种模式非常有用。你可以将新模型作为影子模型，与现有模型并行部署，并向它发送相同的生产流量，以便在正式发布之前收集其性能数据。

竞争模型： 更复杂的场景是，你在生产环境中尝试多个模型版本，例如进行 A/B 测试，以判断哪个版本表现更好。复杂性来自两个方面：一是需要基础设施和路由规则确保流量被正确重定向到相应模型；二是需要收集足够数据，以便做出具有统计意义的判断，而这通常需要一定时间。另一种评估多个竞争模型的常见方法是多臂老虎机算法。这同样要求你定义如何计算和监控使用每个模型带来的收益。将这种方法应用于机器学习仍是一个活跃研究领域，我们已经开始看到一些相关工具和服务出现。

在线学习模型： 与前文讨论的“离线训练、在线预测”的模型不同，在线学习模型使用特定算法和技术，能够随着新数据到来持续提升性能。它们会在生产环境中持续学习。这带来了额外复杂性：如果模型没有接收到完全相同的数据，那么将其版本化为静态组件也无法产生相同结果。因此，你不仅需要对训练数据进行版本控制，还需要对会影响模型性能的生产数据进行版本控制。

再次强调，为了支持更复杂的部署场景，弹性基础设施会带来很大帮助。它不仅能支持在生产环境中运行多个模型，还能在需要时快速启动更多基础设施，从而提升系统可靠性和可扩展性。

持续交付编排

当所有主要构建模块都已就位后，下一步就是将它们整合在一起，而这正是持续交付编排工具发挥作用的地方。该领域有许多工具可供选择，大多数工具都提供配置和执行部署流水线的能力，用于构建软件并将其发布到生产环境。

在 CD4ML 中，我们还有一些额外的编排需求：配置基础设施并执行机器学习流水线，以训练模型并捕获多个模型实验的指标；构建、测试和部署数据管道；执行各种类型的测试和验证，以决定推广哪些模型；以及配置基础设施并将模型部署到生产环境。

我们选择了一款以流水线为核心概念设计的持续交付工具。它允许我们组合不同流水线及其触发器，并在流水线阶段之间定义手动或自动晋级步骤，从而配置复杂流程和依赖关系。

在这个简化示例中，我们尚未构建复杂的数据管道或基础设施配置，但我们演示了如何组合两条流水线：

机器学习流水线： 在持续交付代理中执行模型训练和评估，并执行基本阈值测试，以决定模型是否可以晋级。如果模型表现良好，则执行 dvc push 命令，将其发布为制品。

应用部署流水线： 构建并测试应用代码，使用 dvc pull 从上游流水线获取已晋级模型，将模型与应用程序打包为新的组合制品，也就是 Docker 镜像，并将其部署到 Kubernetes 生产集群。

图 8：在 GoCD 中结合机器学习流水线和应用程序部署流水线

随着时间推移，机器学习流水线可以扩展为并行执行多个实验。持续交付工具中的扇出/扇入模型可以支持这一点。同时，还可以定义模型治理流程，用于检查偏差、公平性、正确性以及其他类型的门禁，从而对哪个模型应被推广和部署到生产环境做出更明智的决策。

在更完整的研发管理场景中，也可以借助 PingCode 这类智能化研发管理工具，把团队目标、客户反馈、需求清理、评审排期、开发、测试、发布和 Wiki 知识沉淀串联起来，并打通研发工具链，使 CD4ML 流程中的需求、代码、测试、发布和经验数据更加顺畅地流转。

最后，持续交付编排的另一个重要方面是定义回滚流程，以便在已部署模型在生产环境中表现不佳或出现错误时及时回退。这为整个流程增加了一层额外安全保障。

模型监控与可观测性

模型上线后，我们需要了解它在生产环境中的表现，并完善数据反馈机制。在这里，我们可以复用已经部署在应用和服务中的监控与可观测性基础设施。

日志聚合和指标收集工具通常用于从实时系统中捕获数据，例如业务关键绩效指标、软件可靠性和性能指标、故障排查所需的调试信息，以及其他可能在异常情况下触发告警的指标。我们也可以利用这些工具捕获数据，以了解模型运行情况，例如：

模型输入： 模型接收了哪些数据，以便了解训练数据与实际应用数据之间的偏差。

模型输出： 模型基于输入数据做出了哪些预测和建议，以便了解模型在真实数据上的表现。

模型可解释性输出： 例如模型系数、ELI5 或 LIME 输出等指标，可用于进一步分析模型如何做出预测，从而识别训练阶段未发现的潜在过拟合或偏差。

模型输出与决策： 模型基于生产输入数据做出了哪些预测，以及系统基于这些预测做出了哪些决策。有时，应用可能会选择忽略模型输出，并根据预定义规则做出决策，例如为了避免未来产生偏差。

用户行为与奖励： 基于用户后续行为，我们可以收集奖励指标，以了解模型是否达到了预期效果。例如，如果我们展示产品推荐，可以追踪用户是否购买了推荐产品，并将其作为奖励信号。

模型公平性： 分析输入数据和输出预测与已知可能存在偏见的特征之间的关系，例如种族、性别、年龄和收入群体等。

在我们的示例中，我们使用 EFK 技术栈进行监控和可观测性分析。该技术栈由三个主要工具组成：

• Elasticsearch： 一个开源搜索引擎；
• Fluentd： 一个用于统一日志层的开源数据收集器；
• Kibana： 一个开源 Web UI，可用于浏览和可视化 Elasticsearch 中索引的数据。

我们可以在应用代码中添加埋点，将模型输入和预测结果作为事件记录到 Fluentd：

# predict_with_logging.py

df = pd.DataFrame(data=data, index=['row1'])
df = decision_tree.encode_categorical_columns(df)
pred = model.predict(df)
logger = sender.FluentSender(TENANT, host=FLUENTD_HOST, port=int(FLUENTD_PORT))
log_payload = {'prediction': pred[0], **data}
logger.emit('prediction', log_payload)

随后，该事件会被转发并索引到 Elasticsearch 中，我们可以使用 Kibana 的 Web 界面查询和分析它。

图 9：在 Kibana 中分析我们模型的预测结果与真实输入数据的对比

此外，还有其他流行的监控和可观测性工具，例如使用不同日志摄取和转发组件的日志分析技术栈，以及商业日志分析平台等。

当生产环境中部署了多个模型时，收集监控和可观测性数据尤为重要。例如，你可能需要评估影子模型、执行 A/B 测试，或运行包含多个模型的多臂老虎机实验。

如果你在边缘侧训练或运行联邦模型，例如在用户移动设备上运行模型，或者部署的是会随时间推移而发散的在线学习模型，那么监控和可观测性同样重要，因为这些模型会持续从生产环境中的新数据中学习。

通过采集这些数据，你可以形成闭合的数据反馈循环。这可以通过两种方式实现：一是收集更多真实数据，例如在定价引擎或推荐系统中；二是引入人工参与，分析从生产环境中采集的新数据，并对其进行整理，从而为新的、改进后的模型创建新的训练数据集。闭合这一反馈循环是 CD4ML 的主要优势之一，因为它使我们能够根据真实生产数据中的经验持续调整模型，实现持续改进。

端到端 CD4ML 流程

通过逐步解决每个技术挑战，并使用多种工具和技术，我们成功创建了一套端到端流程。该流程管理了代码、模型和数据这三个维度上制品的晋级与发布。

图 10：机器学习端到端持续交付流程

首先，我们需要一种简便的方法来管理、发现、访问和版本控制数据。随后，我们自动化模型构建和训练过程，使其具备可复现性。这让我们能够实验并训练多个模型，同时也要求我们对这些实验进行测量和跟踪。一旦找到合适模型，就可以决定如何将其投入生产并提供服务。由于模型会不断演进，我们必须确保它不会违反与使用方之间的任何契约，因此需要在部署到生产环境之前进行测试。模型上线后，我们可以使用监控和可观测性基础设施收集新数据，对其进行分析，并用于创建新的训练数据集，从而形成持续改进的反馈循环。

持续交付编排工具负责协调端到端 CD4ML 流程，按需提供所需基础设施，并控制模型和应用如何部署到生产环境。

CD4ML 未来的发展方向

本文使用的示例应用和代码可以在代码托管平台的仓库中找到，它们也是我们在多个会议和客户现场举办半天研讨会的基础。我们仍在持续完善 CD4ML 的实现方式。在本节中，我们将重点介绍研讨会材料尚未覆盖的一些改进领域，以及一些仍需进一步探索的开放问题。

数据版本控制

在持续交付中，我们将每次代码提交都视为一个发布候选版本，它会触发部署流水线重新执行。假设该提交通过流水线所有阶段，就可以部署到生产环境。在讨论 CD4ML 时，我们经常被问到一个问题：“当数据发生变化时，如何触发流水线？”

在我们的示例中，机器学习流水线始于一个 download_data.py 文件，该文件负责从共享位置下载训练数据集。如果我们更改共享位置中的数据集内容，流水线不会立即触发，因为代码没有变化，DVC 无法检测到这种变化。要对数据进行版本控制，我们需要创建一个新文件或更改文件名，而这又要求我们更新 download_data.py 脚本中的新路径，从而创建一次新的代码提交。

改进这一方法的方式是让 DVC 直接跟踪文件内容。我们可以用以下命令替代手写下载脚本：

dvc add data/raw/store47-2016.csv

这会略微改变机器学习流水线的第一步。

图 11：更新第一步，使 DVC 能够跟踪数据版本并简化机器学习管道

该命令会创建一个元数据文件，用于跟踪文件内容的校验和。我们可以将这个元数据文件提交到 Git。现在，当文件内容发生变化时，校验和也会变化，DVC 会更新该元数据文件，而更新后的元数据文件就是触发流水线执行所需的提交。

尽管这种方式允许我们在数据发生变化时重新训练模型，但它并不能完整解决数据版本控制问题。一个方面是数据历史记录：理想情况下，我们希望保留所有数据变化的完整历史，但这并不总是可行，具体取决于数据变化频率。另一个方面是数据溯源：我们需要了解哪个处理步骤导致了数据变化，以及这种变化如何在不同数据集之间传播。此外，还需要考虑如何跟踪和演进数据模式，以及这些变更是否具备向前和向后兼容性。

如果你处在流式数据场景中，数据版本控制的这些方面会变得更加复杂。因此，我们预计这一领域还将出现更多实践、工具和技术。

数据管道

我们尚未讨论的另一个方面是如何对数据管道本身进行版本控制、测试、部署和监控。在实际应用中，有些工具比其他工具更适合实现 CD4ML。例如，许多需要通过图形界面定义转换和处理步骤的 ETL 工具，通常很难进行版本控制、测试，或部署到混合环境。而有些工具则可以生成代码，你可以将这些代码作为制品纳入部署流水线。

我们倾向于使用开源工具，因为它们允许我们用代码定义数据管道，而这更易于版本控制、测试和部署。例如，如果使用 Spark，数据管道可能用 Scala 编写，你可以使用 ScalaTest 或 spark-testing-base 进行测试，将作业打包为 JAR 文件，然后对其进行版本控制，并通过部署流水线发布。

由于数据管道通常以批处理作业或长期运行的流式应用形式运行，因此我们没有将其纳入前文的端到端 CD4ML 流程图中。不过，如果数据管道改变了模型或应用预期的输出，它们也可能成为集成问题的另一个来源。因此，我们努力在部署流水线中加入集成测试和数据契约测试，以尽早发现这些错误。

与数据管道相关的另一种测试是数据质量检查。不过，这同样是一个非常宽泛的话题，最好另写一篇文章专门讨论。

平台思维

正如你可能已经注意到的，我们使用了多种工具和技术来实现 CD4ML。如果多个团队同时尝试这样做，他们最终可能会重复造轮子，并投入大量重复劳动。这时，平台思维就能发挥作用。

平台思维并不是将所有工作集中到一个团队中，从而制造新的瓶颈；相反，它强调将平台工程能力聚焦于构建与领域无关的工具。这些工具能够隐藏底层复杂性，并加速不同团队的采用。相关学者在关于数据网格的文章中，对这一点作过更详细的阐述。

将平台思维应用于 CD4ML，正是我们看到机器学习平台以及其他试图提供端到端机器学习生命周期管理方案的产品日益受到关注的原因。许多大型科技公司都开发了自己的内部工具，但我们认为这仍是一个活跃的研发领域。我们期待新的工具和供应商不断涌现，提供更具通用性的解决方案。

无偏智能系统的演进

一旦第一个机器学习系统部署到生产环境，它就会开始进行预测，并用于处理未见过的数据。它甚至可能取代之前使用的基于规则的系统。我们必须意识到，之前进行的训练数据和模型验证都是基于历史数据，而这些历史数据本身可能包含由先前系统行为带来的固有偏差。此外，机器学习系统未来对用户产生的任何影响，也会反过来影响未来的训练数据。

为了更好理解其影响，我们来看两个例子。

第一个例子是本文探讨的需求预测方案。假设有一个应用使用预测需求来决定订购并提供给客户的产品数量。如果预测需求低于实际需求，就会出现库存不足，导致该产品交易量下降。如果未来只将这些新增交易量作为训练数据来改进模型，那么随着时间推移，需求预测的准确性可能会下降。

第二个例子是异常检测。假设你正在构建一个模型，用于判断客户信用卡交易是否为欺诈交易。如果应用采纳模型判断并阻止某些交易，那么随着时间推移，你将只拥有模型允许交易的“真实标签”，而用于训练的欺诈交易数据会减少。此外，由于训练数据逐渐偏向“正常”交易，模型性能也可能下降。

这个问题没有简单的解决方案。在第一个例子中，零售商可能需要考虑缺货情况，并订购比预测数量更多的商品，以弥补潜在短缺。在欺诈检测场景中，我们有时可以基于某种概率分布，忽略或覆盖模型分类结果。同样重要的是要意识到，许多数据集都是时间相关的，也就是说，它们的分布会随时间变化。许多随机划分数据的验证方法都假设数据是独立同分布的，但一旦考虑时间因素，这一假设就不再成立。

因此，我们不仅要记录模型输入和输出，还要记录最终应用是否使用或覆盖模型输出的决策过程。这样，我们就可以对数据进行标注，从而避免在未来训练轮次中引入偏差。管理训练数据并建立相应系统，使人工能够进行数据整理，是应对这些问题的另一个关键要素。

随着时间推移，构建一个能够选择并改进机器学习模型的智能系统，也可以被视为一个元学习问题。该领域许多前沿研究都聚焦于此类问题，例如强化学习技术，如多臂老虎机算法的应用，以及生产环境中的在线学习。我们预计，关于如何构建、部署和监控这类机器学习系统的经验和知识仍将不断发展。

常见问题

什么是 CD4ML？

CD4ML 指机器学习持续交付，即将持续交付的原则和实践应用到机器学习应用中，使团队能够可靠、可复现地发布由代码、数据和模型共同组成的软件系统。

CD4ML 和 MLOps 有什么关系？

CD4ML 可以被视为 MLOps 实践中的一个重要方向，重点关注机器学习系统从开发、训练、测试到部署和监控的持续交付能力。

为什么机器学习应用比传统软件更难持续交付？

传统软件主要管理代码变更，而机器学习应用还需要同时管理数据和模型变更。数据漂移、模型性能波动、可复现性、模型监控和偏差治理，都会让交付流程更加复杂。

机器学习持续交付的核心价值是什么？

它的核心价值在于降低机器学习应用发布风险，加快模型迭代速度，并通过自动化流水线、质量门禁和生产反馈循环，实现模型和应用的持续改进。

结论

随着机器学习技术不断发展，能力日益复杂，我们对如何管理并将这类应用部署到生产环境的理解也在持续提升。通过引入并扩展持续交付的原则和实践，我们可以更安全、更可靠地管理机器学习应用变更发布过程中的风险。

本文以一个销售预测应用为例，展示了 CD4ML 的关键技术组成部分，并探讨了实现这些组成部分的多种方法。我们相信，这一领域会继续演进，新的工具将不断出现，也会有工具逐渐退出舞台。但持续交付的核心原则仍然适用，并值得你在自己的机器学习应用中加以考虑。