端到端 CD4ML 流程
通过逐步解决每个技术挑战，并使用各种工具和技术，我们设法创建了如下图所示的机器学习端到端流程的持续交付，该流程管理所有三个轴上的制品：代码、模型和数据。
在此基础上，我们需要一种简单的方法来管理、发现、访问和版本化我们的数据。 然后，我们将模型构建和训练过程自动化，使其具有可重复性。 这使我们能够实验和训练多个模型，这就需要测量和跟踪这些实验。 一旦找到合适的模型，我们就可以决定如何生产和提供服务。 由于模型在不断发展，我们必须确保它不会违反与消费者的任何契约，因此我们需要在部署到生产之前对其进行测试。 一旦投入生产，我们就可以使用监控和可观察性基础设施来收集新数据，这些数据可以进行分析并用于创建新的训练数据集，从而结束持续改进的反馈循环。
持续交付编排工具协调端到端 CD4ML 流程，按需提供所需的基础设施，并管理模型和应用程序如何部署到生产环境。
我们应该去向何方？
我们在本文中使用的示例应用程序和代码可在我们的 Github 存储库中获得，并用作我们在各种会议和客户中展示的半天研讨会的基础。我们将继续发展关于如何实施 CD4ML 的想法。在本节中，我们将重点介绍研讨会材料中未反映的一些改进领域，以及一些需要进一步探索的开放领域。
数据版本控制
在持续交付中，我们将每个代码提交视为发布候选，这会触发部署流水线的新执行。假设提交通过所有流水线阶段，它可以部署到生产中。在谈论 CD4ML 时，我们经常遇到的问题之一是“如何在数据更改时触发流水线？”
在我们的示例中，下图的机器学习流水线从 download_data.py 文件开始，该文件负责从共享位置下载训练数据集。如果我们在共享位置更改数据集的内容，它不会立即触发流水线，因为代码没有更改，DVC 将无法检测到它。要对数据进行版本化，我们必须创建一个新文件或更改文件名，这反过来又需要我们使用新路径更新 download_data.py 脚本，从而创建一个新的代码提交。
这种方法的改进是允许 DVC 为我们跟踪文件的内容，方法是将我们的手写下载脚本替换为：
dvc add data/raw/store47-2016.csv ➊ 复制代码
这将稍微改变我们机器学习流水线的第一步，如下图展示了更新第一步以允许 DVC 跟踪数据版本并简化 ML 流水线。
这将创建一个元数据文件，该文件跟踪我们可以提交给 Git 的文件内容的校验和。现在，当文件内容更改时，校验和将更改，DVC 将更新该元数据文件，这将是我们触发流水线执行所需的提交。
虽然这允许我们在数据更改时重新训练我们的模型，但它并不能说明数据版本控制的全部内容。一方面是数据历史记录：理想情况下，您希望保留所有数据更改的完整历史记录，但这并不总是可行的，具体取决于数据更改的频率。另一个方面是数据来源：了解哪些处理步骤导致数据发生变化，以及它如何在不同的数据集之间传播。还有一个问题是随着时间的推移跟踪和发展数据模式，以及这些变化是否向后和向前兼容。
如果您身处流媒体世界，那么数据版本控制的这些方面会变得更加难以理解，因此，我们期望在这个领域发展更多的实践、工具和技术。
数据流水线
到目前为止我们尚未涉及的另一个方面是如何对数据管道本身进行版本控制、测试、部署和监控。在现实世界中，一些工具选项比其他工具选项更好地启用 CD4ML。例如，许多要求您通过 GUI 定义转换和处理步骤的 ETL 工具通常不容易进行版本控制、测试或部署到混合环境。其中一些可以生成代码，您可以将其作为一个制品进行处理并将它们视为一个部署流水线。
我们倾向于更喜欢允许我们在代码中定义数据流水线的开源工具，这更容易进行版本控制、测试和部署。例如，如果您使用 Spark，您可能使用 Scala 编写数据流水线，您可以使用 ScalaTest 或 spark-testing-base 对其进行测试，您可以将作业打包为 JAR 制品，可以在 GoCD 中的部署流水线上对其进行版本控制和部署。
由于数据流水线通常作为批处理作业或作为长时间运行的流应用程序运行，我们没有将它们包含在端到端 CD4ML 流程图中，但它们也是集成问题的另一个潜在来源。如果他们改变了您的模型或您的应用程序期望的输出。因此，将集成和数据契约测试（Contract Tests）作为我们部署流水线的一部分来捕捉这些错误是我们努力的目标。
另一种与数据流水线相关的测试是数据质量检查，但这可能会成为另一个广泛讨论的话题，最好在单独的文章中讨论。
平台思维
您可能已经注意到，我们使用各种工具和技术来实现 CD4ML。如果您有多个团队尝试这样做，他们最终可能会重新发明事物或重复工作。这就是平台思维可以发挥作用的地方。不是通过将所有工作集中在一个成为瓶颈的团队中，而是通过将平台工程工作集中在构建与领域无关的工具上，这些工具隐藏了底层的复杂性并加快了团队尝试采用它的速度。我们的同事 Zhamak Dehghani 在她的 Data Mesh 文章中对此进行了更详细的介绍。
将平台思维应用于CD4ML是我们看到机器学习平台和其他产品越来越受关注的原因，这些产品正试图提供一个单一的解决方案来管理端到端的机器学习生命周期。许多主要的技术巨头已经开发了自己的内部工具，但我们认为这是一个活跃的研发领域，并期待新的工具和供应商出现，提供可以更广泛采用的解决方案。
逐步发展无偏见(Bias)的智能系统
一旦您的第一个机器学习系统部署到生产中，它将开始进行预测并用于处理看不见的数据。它甚至可能取代您以前拥有的基于规则的系统。重要的是要意识到您执行的训练数据和模型验证是基于历史数据，其中，可能包括基于先前系统行为方式的固有偏差。此外，您的 ML 系统可能对您的用户未来产生的任何影响，也会影响您未来的训练数据。
让我们考虑两个例子来理解影响。首先，让我们考虑一下我们在本文中探讨的需求预测解决方案。让我们假设有一个应用程序根据预测的需求来决定要订购和提供给客户的产品的确切数量。如果预测需求低于实际需求，您将没有足够的商品出售，因此该商品的交易量会减少。如果您只使用这些新交易作为训练数据来改进您的模型，那么随着时间的推移，您的需求预测将会下降。
对于第二个示例，假设您正在构建一个异常检测模型来确定客户的信用卡交易是否具有欺诈性。如果您的应用程序采用模型决定阻止它们，那么随着时间的推移，您将只有模型允许的交易的“真实标签”和较少的欺诈性交易来训练。模型的性能也会下降，因为训练数据会偏向“好”交易。
这个问题没有简单的解决方案。在我们的第一个示例中，零售商还考虑缺货情况并订购比预期更多的商品以弥补潜在的短缺。对于欺诈检测场景，我们有时可以忽略或覆盖模型的分类，使用一些概率分布。同样重要的是要认识到许多数据集是时间的，即它们的分布随时间而变化。许多执行数据随机拆分的验证方法假设它们是 i.i.d。 （独立同分布），但是一旦考虑到时间的影响，情况就不是这样了。
因此，重要的是不仅要捕获模型的输入/输出，还要捕获消费应用程序使用或覆盖模型输出的最终决定。这使您可以对数据进行注释，以避免在未来的训练轮次中出现这种偏差。当您面临这些问题时，管理训练数据并拥有允许人类管理它们的系统是另一个关键组件。
随着时间的推移发展智能系统以选择和改进 ML 模型也可以被视为元学习问题。该领域的许多最新研究都集中在这些类型的问题上。例如，强化学习技术的使用，如多臂老虎机问题，或生产中的在线学习。我们希望我们在如何最好地构建、部署和监控这些类型的 ML 系统方面的经验和知识将继续发展。
总结
随着机器学习技术不断发展并执行更复杂的任务，我们在如何管理此类应用程序并将其交付生产方面的了解也在不断发展。
通过引入和扩展持续交付的原则和实践，我们可以以安全可靠的方式更好地管理机器学习应用程序发布更改带来的风险。
通过销售预测应用程序示例，我们在本文中展示了 CD4ML 的技术组件，并讨论了我们如何实现它们的一些方法。我们相信这项技术将继续发展，新工具会出现又消失，但持续交付的核心原则仍然是相关的，您应该为自己的机器学习应用程序考虑这些原则。
