机器学习下的持续交付( 五 ) 文/DaniloSato、ArifWider、Christop

在研究阶段这些实验方法与传统软件的开发流程是截然不同的，因为我们知道很多实验的代码最终将被丢弃，最后只留下小部分被认为是值得投入生产环境中的。因为这个原因，我们需要一个明确的方法去追踪它们。
在我们的例子中，我们决定采取DVC建议的方法，在代码管理中使用不同的Git分支去追踪不同的实验。即使这违背了我们的在一个主干上实践持续集成的理论。 DVC能够获取和展示从不同分支或标签运行的实验的指标数据，有了这些数据的导航可以让人们更容易作出选择。
在传统的特征分支的软件开发中，如果这些分支长期存在的话容易引起合并时痛苦。这将降低团队重构代码的积极性，因为这些改变能影响到更大范围的代码库。并且它也阻止了持续集成的实践，因为它迫使你在多个分支间来回作业导致正确的集成被拖延，直到代码被合并回到主线。
对于ML的实验，我们希望大多数分支永远不会被集成，这些在实验间改变的代码通常不显著。从CI的自动化角度来看，我们确实想为每个实验训练多个模型，再收集那些会提醒我们哪个模型能够进行到下一阶段的部署到pipeline的指标。
除了DVC之外还有另一个我们使用的工具叫做MLflow Tracking来帮助我们追踪实验。它能够以主机服务的方式被部署，然后提供一个API或者是一个web接口来可视化多个实验的运行，并一起展示出来它们的参数和性能指标。就像下面的图6 。
文章插图
（图6:MLflow Tracking 的web UI 来展示实验的运行，参数以及指标。）
为了支持这个实验的流程，突出强调这个拥有弹性基础的好处也很重要，因为你或许需要能够使用多个实验的环境————有时候也会在特殊的硬件设备上————去训练。基于云服务的架构天生非常适合这种情况，同时许多的公共云服务提供商正在构建服务和解决方案来支持这个多方面的流程。
可持续交付业务流程设置所有的主要部件都已到位，然后我们需要将所有的事都紧系在一起，这就是我们的持续交付的业务流程设置工具起作用的地方。这个地方有许多可以选择的工具，其中大多数提供了设置方法和执行部署pipline去构建和发行软件到生产环境。在CD4ML中，我们有额外的编排要求：提供基础设施和执行机器学习训练的pipeline ，同时从多个模型实验中收集指标；构建，测试和我们的数据pipline的部署流程；以及集成测试和部署我们的模型到生产环境中。
我们使用GoCD作为我们的持续集成工具，因为它是由pipline作为首要关心部分的概念来构建的。不止这些，它也允许我们组合不同的pipeline来设置复杂的工作流和依赖。触发它们，之后在pipline之间确定手动或者自动升级的步骤。
在我们简单的模型中，我们并没有构建任何负载的数据pipeline或者基础设施配置，但是我们演示来怎样组合两个GoCD的piplines 。

机器学习pipeline：在GoCD代理下执行模型训练和评测，同样执行基础的threshold test来决定这个模型是否能够被推送至下一阶段。如果这个模型很好，我们进行dvc push的命令来把它作为一个组件公布。
应用程序部署的pipeline：构建和测试应用程序的代码，使用dvc pull获取从上游pipeline推送的模型，打包成一个新的包含来模型和应用程序的混合组件来作为Docker镜像，最后部署它们到Kubernetes 集群的生产环境上。

随着时间的推移，这个ML的pipeline能够扩展去同时执行多个实验（一种由GoCD的扇出/扇入对模型支持的特征），检查权重、公平性、正确率以及其他类型的大门来确定你的模型治理流程以便人们来决定哪个模型被推送和部署到生产环境中。
最后，另一方面你的持续交付的流程设置上需要确定回滚的方案，以防万一部署在生产环境下的模型在事实的证明下表现的不好或者不正确。这样为以上的流程增添了另一张安全网。
模型的检测以及可观测性既然模型存在，我们就需要去理解它是怎样在生产环境中表现的，同时使数据的反馈形成一个闭环。这里我们可以复用所有的，可能在你的应用程序和服务中，进行监控和可见的基础设施。
为日志集合和指标收集的工具通常用于从一个实时系统捕获数据，比如商业的KPIs ，软件可靠性和性能指标，解决问题的调试的信息，以及其他的能够在一些组件运行不正常时触发警告的的指标。我们也可以利用这些相同的工具来捕获数据，以此来理解我们的模型是怎样运作的，比如说：