推荐阅读：部署机器学习方案之困（上）
一、概述
近年来，机器学习无论是作为学术研究领域还是实际商业问题的解决方案，都受到了越来越多的关注。然而，就像其他领域一样，在学术环境中起作用的研究和实际系统的要求之间往往存在着显著差异，所以在生产系统中部署机器学习模型可能会带来许多问题。
本文介绍一篇剑桥大学2020年发表的研究综述【1】，其调研了在各种用例、行业和应用中部署机器学习解决方案的公开报告，提取了与机器学习部署工作流阶段对应的实际考虑因素。对于从业者而言，了解在机器学习部署的各个阶段所面临的挑战是非常重要的，本文将对这方面进行主要阐述，最后介绍潜在的解决方案，共分为上、下两篇，本篇为下篇，希望各位能从中受益并引发更多思考。
二、机器学习方案部署的常见问题和挑战
在工业环境中开发基于机器学习的解决方案包括四个阶段：数据管理、模型学习、模型验证和模型部署，而这些阶段没有严格的时间轴，在一定程度上存在并行和反馈循环。本节将讨论从业者在最后一个阶段中面临的常见问题和挑战，并讨论涉及到的其他问题。
2.1 模型部署
在生产中运行的机器学习系统是一个复杂的软件系统，必须随着时间的推移进行维护。在工程中有一个独立的学科DevOps，专注于维护和支持现有生产系统所需的技术和工具，尽管DevOps的一些原则可以直接应用，但是投入生产的机器学习仍然存在许多独特的挑战。在本节中，我们将讨论模型部署中的三个步骤：集成、监控和更新。
1、集成
首先，模型集成包括运行模型基础设施的构建和模型的实现，前者不在本文的讨论范围，后者揭示了机器学习和软件工程的交叉，软件工程中经常使用的很多概念在机器学习中被重用。代码重用是软件工程中常见的概念，机器学习也采用了相同的思维方式，数据和模型的重用节省了时间、精力和基础设施。
其次，还有一些广泛存在于机器学习软件中的问题，如抽象边界侵蚀和修正级联，是由于在软件必须明确依赖于外部数据的情况下使用机器学习造成的，再如胶水代码或流水线杂乱无章，源于该领域开发通用软件包的普遍趋势。另一个问题是配置债，这是由于除了常规软件系统可能需要的所有配置之外，机器学习系统还添加了大量必须设置与维护的机器学习特定的配置内容。
最后，表面上看研究人员和软件工程师各司其职，前者制作模型，后者构建运行模型的基础设施，但在实际开发过程中他们所关注的领域经常是重叠的，因为将研究人员循环到整个开发过程中是有益的，确保他们与工程师一起拥有产品代码库，使用相同的版本控制并参与代码评审，这为产品交付的速度和质量带来长期的好处。
2、监控
首先，除了监控不断变化的输入数据、预测偏差和总体性能之外，还有一个特定于数据驱动决策的维护问题是反馈循环。生产中的机器学习模型可以通过定期的再训练来影响它们自己的预测，在确保模型保持最新状态的同时，还可以创建反馈循环，对模型的输入进行调整以影响其行为。
其次，一般的监控包括数据完整性检查、异常检测和性能指标，除此之外人们也总是希望使用开箱即用的工具来完成任务。然而，为了保持良好的模型性能，必须从头开始构建所有这些检查，例如数据完整性检查意味着验证某个输入表的更新以及历史记录的校验和，性能指标是根据前k个输出的变化数量定义的，异常情况则是随着时间的推移通过秩序相关性来跟踪的。
最后，所有这些监控工具都需要大量的调研和实施，这突出了当前可用的端到端机器学习平台的一个常见问题，即最终的机器学习解决方案通常对问题的细节非常敏感，开箱即用的工具通常不能很好地满足需求。
3、更新
一旦完成了模型的初始部署，通常需要在以后能够更新模型以确保它总是反映数据和环境的最新趋势。有多种技术可以使模型适应新的数据，包括定期再训练和持续学习，然而在生产中，模型的更新也受到实际考虑的影响。
一个特别重要的直接影响模型更新过程质量和频率的问题是概念漂移，如果不及时发现，可能会对模型性能产生重大不利影响。概念漂移可能是由于数据收集过程中的波动造成的，即使在微观尺度上发生的数据变化也会产生显著的结果。
在何时重新训练模型以使模型保持最新之外，还需关注如何将模型交付到生产环境基础架构的问题。在软件工程中，通常用持续交付来解决，通过构建一个用于构建、测试和部署软件变更的自动化管道来加速开发周期。与常规软件产品只是代码的变更不同，机器学习解决方案通常在代码、模型和数据三个维度发生变化，因此其持续交付更为复杂。
2.2 其他问题
1、伦理
在整个人工智能项目交付工作流中建立一个持续的人的责任链是至关重要的。一方面，各国都制定了个人数据保护的法律法规，数据收集应始终考虑伦理因素，这虽然确保了数据安全，但是大量的审查、软件更新和数据收集周期使其难以跟上机器学习的技术进步。另一方面，由于机器学习模型使用之前看到的数据来做出决策，所以可能会加剧数据中已经存在的问题，也可能有加剧不平等或制造虚假信息的风险。
2、用户信任
模型本身提供的解释非常少，这使得最终用户很难相信模型的实用性。模型可解释性来建立信任是有局限性的，为了说服用户信任基于机器学习的解决方案，必须投入时间来建立这种信任，除了强有力的沟通渠道、尽可能开放数据和软件之外，界面设计也发挥着很大的作用，当然，当用户有相关经验时，可解释的模型解决方案是首选。
3、安全
针对机器学习的对抗性攻击可能发生在模型本身、训练数据和预测阶段。对抗性机器学习领域研究了这种攻击对机器学习模型的影响以及如何防范它们，我们特别关注对抗性机器学习，并在部署系统时考虑其他相关的一般安全问题，如访问控制和超出我们工作范围的代码漏洞。在实践中有三种最常见的攻击会影响已部署的机器学习模型。
首先是数据中毒，对抗性攻击的目标是在训练阶段故意破坏模型的完整性以操纵产生的结果，在机器学习模型不断更新训练数据的情况下，中毒攻击尤其相关。
其次是模型窃取，通过查询已部署模型的输入对其进行逆向工程并监控输出，精心设计对抗性查询，以最大限度地提取关于模型的信息并训练替代模型，这种攻击会导致知识产权的损失。
最后是模型反转，其对抗性攻击的目标是恢复训练集特别是涉及隐私的数据，从而破坏其机密性。
三、潜在解决方案
3.1 工具和服务
机器学习工具和服务市场正在快速增长，针对个别部署问题的工具不断发布，对于我们强调的一些问题，使用正确的特定工具是非常合理的。市场上的许多平台为用户提供端到端的体验，包括数据存储、再训练和部署等，例如AWS SageMaker、Microsoft AzureML、Uber Michelangelo、TensorFlow TFX等。一个典型的机器学习平台除了基础功能外，还包括数据存储设施、带有用于训练和推理操作的API模型托管、一组用于监控模型健康状况的通用指标以及一个接受用户自定义更改的接口。通过为常见任务提供托管基础设施和一系列开箱即用的实现，这些平台大大减少了在生产中与维护机器学习模型相关的操作负担。
数据完整性在质量控制中起着重要作用，是一个活跃的研究分支，模型本身也可以从测试套件的开发中受益，以验证它们的行为，这通常是通过反复试验来完成的，目前也正在开发更正式的方法。
获取标签通常是真实世界数据的一个问题，弱监督已经成为机器学习的一个单独领域，用以寻求解决这一问题的方法。因此，一些弱监督库目前正积极地在社区内被使用，并显示出良好的工业应用效果，一些最流行的工具包括Snokel、Snuba和Cleanlab。
使用特定的工具来解决个别问题是一种直接的方法，然而从业者需要意识到，使用特定的工具会在解决方案中引入额外的依赖项，虽然单个附加的依赖关系似乎是可控的，但是它们的数量会迅速增加并成为维护负担。此外，新的机器学习工具不断发布，从业者需要通过学习其优缺点来选择合适的工具。
3.2 整体性方法
尽管机器学习部署需要一定数量的软件开发，但机器学习项目与传统的软件工程项目有本质的不同，主要差异有数据发现、数据集准备、模型训练、部署成功度量等，其中有些定义不够精确而无法进行可靠的时间估计，有些具有巨大的潜在风险，而有些则难以衡量项目的整体附加值。因此，机器学习部署并不能很好地适应软件工程管理范式的通用方法，也不能很好地适应常见的软件体系架构模式。
面向数据的架构（DOA）是一个有想法的例子，它建议重新思考软件开发通常是如何完成的。DOA的思想是考虑用基于流的体系结构取代当前企业系统中普遍存在的微服务体系结构，从而使业务逻辑元素之间的数据流更加显式并可访问。微服务体系结构虽然在实现高扩展性和单一责任原则方面非常成功，但是也使数据流很难跟踪，并且每个服务的所有者都要确保输入和输出存储形式一致。DOA通过将数据移动到无状态执行节点之间的数据流中来解决这一问题，从而使数据在设计上可用和可跟踪，因而数据发现、收集和标记变得更加简单。从本质上讲，DOA建议认可现代系统通常是数据驱动的，因此需要在其体系结构原则中对数据予以优先考虑。
如上所述，机器学习项目通常不适合常用的项目管理流程，因此需要考虑专门为机器学习量身定制。整体性方法在创建机器学习应用程序时有可能为其部署提供极大的方便，但是所有这些方法都需要投入大量的时间，因此在采用任何一种方法之前，都应仔细评估风险与收益。
四、小结
出于在生产中部署机器学习方案的实际考虑，本文讨论了从业者在机器学习方案部署过程中的最后一个模型部署阶段需要应对的挑战，以及涉及的伦理、用户信任和安全问题，最后也讨论了两种可能的解决方案。可以看到学术界在部署方面的经验和论文并不多，希望能给从业者带来一些思考的同时，学术界也能够从更加实用的角度来推动机器学习方案的部署。
参考文献
[1] Paleyes A , Urma R G , Lawrence N D . Challenges in Deploying Machine Learning: a Survey of Case Studies[J]. 2020.