从AWS技术白皮书看MLOps解决方案

在谈过MLOps在广泛的定义，以及拆分成团队、技术、流程三个面向之後。想必大家也开始思考，一个好的专案和解决方案应该要长什麽样子，有没有哪些规范可以参考、有没有一些企业案例可以学习。

今天透过AWS的技术白皮书，带大家看看：什麽是技术白皮书、针对决策期、导入/执行期、验收期，各有哪些资源可以参考。一起学习，在云端的环境上，一个架构完善解决方案的完整样貌，以及针对MLOps的面向上，解决方案可以怎麽设计以及实践。

什麽是技术白皮书

近几年随着B2B与B2C的技术与商业采购复杂度不断增加，对於决策者来说，面临的局势变动得更快，须考虑的因素也更多了。因此研究报告、白皮书等内容，占据了决策早期的重要因素之一。根据2018与2021的内容偏好报告指出(1)71% 的受访者使用白皮书作为从可靠来源获取洞察力的一种方式。(2)企业在做决策的初期，白皮书是所有资料来源当中比重最重的，占了57%。[6]

＊图片来源:2021内容偏好报告

技术白皮书内容通常来自该领域的相关经验者所撰写，通常是由技术公司提供的教育训练和吸引潜在客户的其中一环，协助公司在目标受众建立可信度与分享知识。内容大部分陈述的该产业的现况、问题，进而讲述解决方案，有些也包含案例分享。 如同这篇分享的AWS技术白皮书，可在官网找到之外。若你是使用其他云服务，也能在该公司官方网站找到相对应的白皮书或者最佳实践建议。技术白皮书本身仅供参考、案例分享，但不会有程序码这样细节的内容。各公司在实作的时候，还是会需要依照业务逻辑修正、调整。

如何阅读白皮书

第一次阅读白皮书的读者，通常会被冗长的篇幅吓到。像是架构完善框架白皮书(AWS Well-Architected Framework)有79页PDF。而MLOps：持续交付的机器学习白皮书(MLOps: Continuous Delivery for Machine Learning on AWS)也有69页PDF的长度。

如果在开始阅读之前，脑中已经有几个问题想解答，会让整份文件的阅读轻快许多。如果要说是核心观念的话，就是把架构完善框架的五个支柱，应用到ML专案上。这五个支柱分别是：(1)卓越营运(2)安全性(3)可靠性(4)效能达成效率(5)成本优化。详细细节可以到架构完善框架白皮书阅读。

在这个框架下，退一步来思考，把整个专案分几个阶段来讨论：(1)决策期(2)导入期(3)验收期

(1)决策期：还未导入ML专案，正要了解全貌

这个阶段整个团队都属於正在做功课、了解现况的阶段，但是基於每个角色在专案的角色不同、背景不同、各自做功课的方向也都不大相同。

(a)决策者： ML正在从实验阶段扩展到标准业务流程，帮助企业增加收入并降低成本。 决策者在初期阶段会想了解资源的分配与使用，例如一个解决方案的月支出、年支出大约多少，带来效益为何，安全性以及合规性需注意哪些。推荐阅读：

• 架构完善框架白皮书的五个支柱(5 pillars)
• Machine Learning Lens - AWS Well-Architected Framework
• How Accenture Industrializes Machine Learning Workloads on AWS
• 加上Case Study，看看其他公司的成功案例。

(b)DevOps： 在已经具备有DevOps的经验下，搭配Iguazio CTO在CNCF的一场演讲。从DevOps的角度来学习，可以怎麽透过git 的CICD流程协助ML专案。并且在前期与ML团队沟通需要的开发环境，以便於能够设置让ML团队能够顺利开发的环境。确保在开始实作的时候，能有相关的技术支撑，有很好的开发与产品品质。建议阅读：

• MLOps automation with Git Based CI/CD for ML
• How Accenture Industrializes Machine Learning Workloads on AWS

(c)资料科学家与资料工程师： 在专案的初期需要专注在商业问题与ML问题的对应以及资料的来源与品质，这会让ML团队与专案负责人、决策者有大量的沟通。确保公司已收集足够品质、数量的资料。并且与公司的资料安全专家合作，确保资料如何流进ML团队以及相关授权。建议阅读：

• How Accenture Industrializes Machine Learning Workloads on AWS

(2)导入/执行期：正要开始实作

(a)决策者： 当决策者已评估，决定一个专案要开始实作，过程当中就不会干涉太多。最多会关注几个重要的指标，这些指标可从MLOps 带给商业与技术流程的5个好处与12个指标复习。

(b)DevOps： 在开始执行的时候，DevOps团队也扮演了非常重要的角色(个人觉得跟ML团队一样重要)。假若公司团队决定将ML专案的资源架在k8s上，DevOps团队需要负责维运一个或数个k8s集群，包含授权、安全性、软硬体资源规划等。若是把服务都放在云托管服务(managed service)，那麽DevOps团队肩膀上的负重就会少一些。DevOps在这阶段则需要学习，如何将既有的devops mindset带到这个ML专案上。建议阅读：

• Machine Learning Lens - AWS Well-Architected Framework
• MLOps: Continuous Delivery for Machine Learning on AWS

(c)资料科学家与资料工程师： 在这阶段会需要和DevOps大量的沟通，从实验的版本控制、交付程序码时候所应该启动的测试与验证、以及每次模型进到产品的开发管线(pipeline)的维护。资料科学家除了过去既有的ML知识之外，也需要补充许多跟产品交付相关的知识。建议阅读：

• Machine Learning Lens - AWS Well-Architected Framework
• MLOps: Continuous Delivery for Machine Learning on AWS

(3)验收期：已开始实作，产品上线後的维运。

这一阶段虽然说是验收期，但也可以说是展开下一次迭代的准备期。盘点目前做到的状况，与预期期待落差相距多少。规划下一次的执行期。

(a)决策者： 须从大方向看目前的专案进程，在MLOps的成熟度有多少。(之後再补充一篇"不同阶段成熟度的MLOps指标"好了。)除了在商业指标与技术指标之外，专案的社会影响力，像是公平、安全、偏见和可持续性问题等等的问题，也都是大家持续关注的内容。在ML发展的过程当中，当使用了更强大的模型之时，是否也提供一项能帮助到弱势群体、确保所有任机会均等的方式，来协助使用者们。

(b)DevOps： 除了ML专案的稳定交付之外，DevOps团队也能够和ML团队一起看MLOps Principles，回过头确认在测试、服务监控等方面是否都已经完善。并且参照MLOps: Operationalizing Machine Learning on AWS - AWS reference architecture - AWS reference architecture，在模型建立、模型产品化、测试与品质控管、部署、监测以及将整个使用者回馈能够整合成闭锁开发循环。

(c)资料科学家与资料工程师： ML团队则是在验收期需要盘点在模型开发、模型部署以及维运上是否有完整的开发周期、如何收集使用者的资讯与反馈，持续改进现有的系统。除了在架构的完整性需要与DevOps沟通与对齐之外，与决策者也需要相互对齐，商业相关的指标是否都有在这次交付被满足，有哪些关键的资料点会是我们想在下一次迭代的时候关注等等。推荐阅读：

• MLOps Principles
• MLOps: Operationalizing Machine Learning on AWS - AWS reference architecture

结论

今天整理了数个技术白皮术，希望大家在有空的时间可以思考一下，自己目前所在的专案状况，依照自己的需求列下几个问题，到白皮书里面找答案。如果愿意分享的话也可以在文章下方留言或联系我分享你的经验与问题。

Reference
[1]. The Ultimate Guide to Writing Technical White Papers
[2]. MLOps Architecture Guide - neptune.ai
[3]. AWS Well-Architected Framework - AWS Well-Architected Framework
[4]. MLOps: Operationalizing Machine Learning on AWS
[5]. AWS Whitepapers & Guides
[6]. 2021 Content Preferences Survey
[7]. The balancing act of AI in the enterprise