DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

sayhaha 2020-08-10

本文转载自公众号“读芯术”(ID:AI_Discovery)。

近几年来,机器学习飞速发展,开展机器学习试验变成小事一桩。有了scikit-learn和Keras这样的资源库,只需几行代码,就能创建模型。

然而,把数据科学项目转变成有意义的应用程序(比如公告团队决策或融入产品的模型)却愈加困难。传统的机器学习项目涉及许多不同的技能组合,想同时掌握全部技能,即便不是绝无可能也绝非易事——那些罕见的既能开发优质软件,又能做工程师的数据科学家即为独角兽!

机器学习领域愈加成熟,许多工作都将融合软件、工程和数学知识,一些工作已然如此了。

引用传奇数据科学家、工程师、批判观察家Vicki Boykis博客《数据科学现已不同》中的话:“在热潮后期,数据科学渐渐与工程学靠拢。显而易见的是,数据科学家所需技能的可视性将减弱、数据依赖性将降低,且会愈加偏向传统计算机科学课程。”

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

为什么数据科学家需要了解DevOps

有那么多工程和软件技能,数据科学家应该学习什么呢?我选DevOps。

DevOps是开发和运营的合称,它于2009年在比利时的一场会议中诞生。该会议旨在缓解技术组织中开发、运营因长期的巨大分歧而产生的紧张态势。软件开发人员需要快速产出、频繁试验,而运营团队则优先考虑服务的稳定性及可用性(这群人让服务器全天候运转)。其目标对立,彼此之间更是竞争关系。

这不禁令人想到当下的数据科学。通过实验,数据科学家创造价值:用新方式建模、组合、转换数据。同时,聘用数据科学家的技术组织更看重稳定性。

这种分歧波及范围广泛:最新的Anaconda数据科学状况报告显示,认为自己能诠释数据科学对其组织影响的受访者不足一半(48%)。据估计,数据科学家创建的模型大多被束之高阁。我们目前没有十分可行的方式,能在建模团队及部署团队间传递模型。数据科学家、开发者及落实二者工作的工程师有着截然不同的工具、限制及技能。

DevOps的出现旨在解决开发者和运营者之间的软件僵局,并取得了极大成功:许多团队部署新代码的频率从数月一次变为一天数次。现在面对的是机器学习和运营的对抗,MLOps这一为数据科学服务的DevOps原则闪亮登场。

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

图源:unsplash

持续集成

DevOps既是理论,又是实践,它包括:

  • 自动化一切事物
  • 快速获得新想法的反馈
  • 减少工作流中的手动交接

在典型的数据科学项目中,存在如下应用:

  • 自动化一切事物。重复且可预测的部分数据处理、模型训练及模型测试皆可自动化。
  • 快速获得新想法的反馈。当数据、代码或软件环境发生变化时,在类生产环境下迅速对其进行测试(即,生产中有依赖项和限制的机器)。
  • 减少工作流中的手动交接。尽可能为数据科学家找寻模型测试的机会,切勿等到开发人员在生产环境下检测模型效果再行动。

为实现以上目标,DevOps采用的标准是持续集成(continuous integration, CI)。关键在于,改变项目源代码时(一般是通过git commits更改),软件被自动创建并测试,每个行为都会得到反馈。通常,CI与创建新功能Git分支的软件开发活动模型Git-flow配合使用。功能分支通过自动测试便可候选并入主分支。

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

CI在软件开发过程中的示意图

由此即可实现自动化——改变代码触发自动构建,测试紧随其后。由于迅速得到测试结果,便可以得到快速反馈,因此,开发者能对代码进行反复迭代。并且,由于一切皆为自动,无需等待他人反馈,实现零切换。

所以,我们为什么不使用已存在于机器学习中的CI呢?我将部分归因于文化,比如数据科学与软件工程群体的低交叉性。

另一部分就是技术原因。比如,了解模型性能,需查看准确率、特异度和敏感度等指标。要了解模型的性能,就需要查看准确率、特异度和灵感度等指标。数据可视化(如混淆矩阵或损失图)或许会对此有所帮助。所以,测试通过/失败并不会阻碍反馈。若要了解模型是否得到改进,我们需要了解当前问题领域的知识,所以测试结果需要以高效且可人为诠释的方式报道。

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

机器学习项目中的连续集成

持续集成系统如何运作?

现在,看看典型的CI系统如何运作。多亏了GitHub Actions和GitLab CI这类图像界面清晰且为新手提供详细操作文档的工具,学习CI系统的门槛降至最低。由于GitHub Actions对开源项目完全免费,我们就用它举例:

其运作方式如下:

(1) 建立一个GitHub仓库。创建名为.github/workflows的目录,在目录中放置一个特殊的.yaml文件,其中包含要运行的脚本,如:

$ python train.py 

(2) 更改项目库内文件,git commit更新,然后提交到GitHub库。

# Create a new git branch for experimenting$ git checkout -b "experiment" 
$ edit train.py# git add, commit, and push your changes 
$ git add . && commit -m "Normalized features" 
$ git push origin experiment 

(3) 检测到推送,GitHub立刻在其中一台计算机上运行.yaml文件的函数。

(4) GitHub弹出通知,是否成功运行函数。

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

在GitHub仓库的操作选项卡中找到以上内

就这么简单!只需更新代码,并把更新提交到数据库,工作流就自动执行。

回到第一步提到的特殊的.yaml文件——快速看一个。随意命名,文件后缀是.yaml即可,并将其储存在.github/workflows中。如:

# .github/workflows/ci.yamlname: train-my-model 
on: [push]jobs: 
   run: 
      runs-on: [ubuntu-latest] 
   steps: 
      - uses: actions/checkout@v2 
      - name: training 
      run: | 
         pip install -r requirements.txt 
         python train.py 

指令多如云,但大多数都是从一个Action到另一个Action——大可照搬这份GitHubActions指南,记得在“运行”段填写工作流就好。

若文件在项目库中,只要GitHub检测到代码更新(通过推送变更),GitHub Actions便会部署Ubuntu服务器,尝试执行安装需求的命令并运行Python脚本。请注意,项目仓库中必须有工作流程所需文件——在这里为requirements.txt和train.py!

得到更好的反馈

自动训练很酷,但对所有的结果来说,采用易于理解的格式也很重要。现在,GitHub Actions允许访问纯文本格式的服务器日志。

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

GitHub Actions日志的打印输出示例

但了解模型性能是个棘手的活儿。模型和数据都是高维且非线性的——若无图片,了解这二者太难了。

我可以展示一种将数据可视化放入CI循环的方法。近几个月,我在Iterative.ai的团队(做数据版本控制)一直在研究工具包,助力GitHub Actions和GitLab CI在机器学习项目中的使用,称为持续机器学习(Continuous Machine Learning ,简称CML)。这是开源且免费的。

团队的基本理念是:“用GitHub Actions训练机器学习模型”。我们已经建立了一些函数,可给出更详细的报告而非一个成功/失败的通知。CML有助于在报告中放置图片和表格,如这个SciKit-learn生成的混淆矩阵:

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

在GitHub中点Pull Request即显示此报告

为了制作报告,GitHub Actions执行Python模型训练脚本,用CML函数把模型准确率和混淆矩阵写入markdown文件。然后CML把markdown文件传到GitHub。

修改后的.yaml文件包含以下工作流(新添加的行以粗体突出显示)。

name: train-my-model 
on: [push] 
jobs:  
   run:    
      runs-on: [ubuntu-latest]    
      container: docker://dvcorg/cml-py3:latest     
      steps:      
      - uses: actions/checkout@v2       
      - name: training        
        env:           
           repo_token: ${{secrets.GITHUB_TOKEN }}    
        run: |      
  
           # train.py outputs metrics.txtand confusion_matrix.png  
           pip3 install -rrequirements.txt          
           python train.py                    
        
           # copy the contents ofmetrics.txt to our markdown report 
           cat metrics.txt >>report.md                     # addour confusion matrix to report.md 
           cml-publishconfusion_matrix.png --md >> report.md            # send the report to GitHub fordisplay  
           cml-send-comment report.md 

记住,.yaml现在包含更多详细配置信息,例如特殊的Docker容器和环境变量,以及一些要运行的新代码。每个CML项目中的容器及环境变量的详细信息都是固定的,用户无需操作,只关注代码就行。

将这些CML函数添加到工作流中,我们便在CI系统中创建了更完整的反馈循环:

  • 建立一个Git分支,在分支上更新代码。
  • 自动训练模型并生成度量(准确率)和可视化(混淆矩阵)。
  • 将这些结果嵌入到Pull Request中的可视报告。

当你和队友还在考虑更新是否有助于实现建模目标时,各种可参照的可视化表盘就已经新鲜出炉了。另外,该报告通过Git连接到确切项目版本(数据和代码)、训练所用服务器及服务器的日志。无比详细!工作空间不再总是漂浮着与代码无关的图表了。

这就是CI在数据科学项目中的基本概念。明确一下,这只是使用CI的最简单的实例。实际操作中很可能遇到各种更为复杂的情况。CML也有一些特性,可帮你使用储存在GitHub库之外的大数据集(使用DVC)并在云端进行训练,而非在默认的GitHub Actions服务器训练。这意味着能使用GPU和其它专业设置。

例如,我用GitHub Actions创建一个项目以部署EC2 GPU,然后训练神经风格转换模型。这是我的CML报告:

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

还可使用自己的Docker容器,进一步模拟

CI对机器学习的最后思考

总结一下,DevOps不是一种特定技术。它既是理论,又是一系列原则和实践,用于彻底重建开发软件过程,其高效性在于解决了团队工作及测试新代码的系统性瓶颈。

未来,数据科学愈加成熟,掌握在机器学习项目中运用DevOps原则的人就更加炙手可热——薪资可观,组织影响力大。持续集成是DevOps的基础,也是已知的建立具有可靠自动化、快速测试和团队自治文化的最有效方法之一。

GitHub Actions或GitLab CI之类的系统可实现CI。可使用这些服务构建自动模型训练系统。其益处颇多:

  • 代码、数据、模型和训练基础(硬软件环境)都是git版本。
  • 自动化工作、进行高频测试并得到迅速反馈(使用CML即可拿到可视化报告)。从长期看,这无疑会加速项目发展。
  • CI系统让每个团队成员都能看到工作进展。大家无需绞尽脑汁搜集最佳运行的代码、数据及模型。

DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南

图源:unsplash

相关推荐