（英国剑桥大学）部署机器学习中的挑战：案例研究综述（中）中文译文 Challenges in Deploying Machine Learnings: a Survey of Case Studies

论文原文：https://arxiv.org/pdf/2011.09926.pdf

翻译：闪闪·Style

 

前一篇文章：（英国剑桥大学）部署机器学习中的挑战：案例研究综述（上）中文译文

 

（5）模型验证

模型验证阶段的目标是多方面的，因为机器学习模型应该很好地推广应用于看不见的输入，证明对边缘情况的合理处理和整体的健壮性，并且满足所有的功能需求。在本节中，我们将讨论模型验证的三个步骤：需求编码、形式化验证和基于测试的验证。

（5.1）需求编码

定义机器学习模型的需求是测试活动的一个重要先决条件。通常情况下，模型性能的提高并不能转化为业务价值的增加，如Booking.com在将150个模型投入生产后所发现的那样[44]。因此，需要定义和衡量更具体的指标，例如：KPI与其他业务驱动的度量。在Booking.com的案例中这些指标包括客户转化率、客户服务订票或订票取消。甚至需要跨学科的努力来定义这样的度量，因为需要从建模、工程和业务角度进行理解。一旦定义好，这些度量就用于对生产环境的监控和对模型更新的质量控制。

此外，简单地测量机器学习模型的精度不足以了解其性能。从本质上讲，绩效指标应该反映受众的优先级。例如，Sato等人[45]建议验证模型的偏差和公平性，而在Wagstaff等人[31]描述的情况下，控制航天器资源的消耗至关重要。

（5.2）形式化验证

形式化验证步骤验证模型功能是否符合项目范围内定义的需求。这种验证可以包括正确性的数学证明或输出误差边界的数值估计，但正如Ashmore等人[14]指出的那样，这在实践中很少发生。更常见的是，质量标准是通过广泛的监管框架正式制定的。

机器学习解决方案必须遵守法规的一个例子是银行业[46]。这一要求是在全球金融危机之后制定的，因为业界意识到有必要加强对模型的审查。因此，对于定义模型如何构建、批准和维护的过程，现在应用了更高级别的监管控制。例如，英国审慎监管局（Prudential Regulation Authority）和欧洲央行（European Central Bank）[48]已经发布了官方指南。这些指导原则要求为所有业务决策解决方案准备好模型风险框架，这些框架的实现要求开发人员拥有广泛的测试套件，以理解他们开发的机器学习模型的行为。在这种情况下，形式化验证步骤意味着确保模型符合相应法规规定的所有标准。

监管框架与全国性政策有相似之处，我们将在第7.1节中详细讨论。

（5.3）基于测试的验证

基于测试的验证旨在确保模型能够很好地推广应用于以前看不到的数据。虽然收集验证数据集通常不是问题，因为它可以通过拆分训练数据集派生而来，但对于生产部署来说，这可能还不够。

在理想的场景中，测试是在真实的环境中进行的，在这种环境中可以观察到业务驱动的度量，正如我们在第5.1节中讨论的那样。由于各种安全、保证和规模原因，真实环境中的全尺度测试具有挑战性，并且常常被模拟测试所取代。自动车辆控制模型就是这样[26]。模拟的成本更低，运行速度更快，并且提供了创建现实生活中很少遇到的情况的灵活性。由于这些优点，模拟在这一领域变得越来越普遍。然而，重要的是要记住，基于模拟的测试依赖于模拟开发人员所做的假设，因此不能被视为真实世界测试的完全替代品。即使仿真与真实世界之间的微小变化也会对系统行为产生剧烈的影响，因此作者得出结论：对于自主车辆来说，仅对模型和仿真环境进行验证是不够的。强化学习领域的经验进一步强调了这一点[25]，其中使用模拟是训练代理的事实标准。

此外，数据集本身也需要不断验证，以确保数据错误不会蔓延到流水线中，也不会影响整体质量。Breck等人[49]认为，当数据中的问题不被注意时，最常见的场景之一是数据生成与机器学习流水线相互分离。出现这样的问题可能有多种原因，包括代码中的错误、反馈循环、数据依赖关系的更改。数据错误可以在流水线的不同阶段传播和表现出来，因此必须通过在机器学习流水线中包含数据验证例程来尽早捕捉到它们。

（6）模型部署

在生产中运行的机器学习系统是一个复杂的软件系统，必须随着时间的推移进行维护。这给开发人员带来了另一组挑战，其中一些挑战是与运行常规软件服务共有的，还有一些是机器学习特有的。

工程中有一个单独的学科叫做DevOps，它专注于成功维护和支持现有生产系统所需的技术和工具。因此，有必要将DevOps原理应用于机器学习系统。然而，尽管DevOps的一些原则直接适用，但在已投入生产的机器学习方面也存在一些独特的挑战。Dang等人[50]详细讨论了这一点，他们将术语AIOps用于机器学习系统的DevOps任务。还提到一些挑战，包括：缺乏高质量遥测数据以及缺失采集这些数据的标准方法、获取标签的难度（使得有监督学习的方法不适用）、缺少关于掌控机器学习模型的一致最佳实践等。在本节中，我们将讨论与模型部署中的三个步骤有关的问题：集成、监控和更新。

（6.1）集成

模型集成步骤由两个主要活动组成：构建运行模型的基础设施与用可以使用和支持的形式实现模型本身。前者是一个几乎完全属于系统工程的主题，因此不在本文的范围之内，后者是我们研究的兴趣所在，因为它揭示了机器学习和软件工程交叉的重要方面。事实上，软件工程中经常使用的许多概念现在正在机器学习上下文中被重新发明。

代码重用是软件工程中的一个常见主题，而机器学习可以从采用相同的思维方式中获益。数据和模型的重用可以直接转化为对时间、精力或基础设施的节省。一个说明性的例子是Pinterest所采用的面向学习图像嵌入的方法[51]。在Pinterest内部使用了三个模型，它们都有着相似的嵌入方法，为了使它们能够独立地进行迭代，它们一开始是彻底分开进行维护的。然而，这带来了工程上的挑战，因为处理这些嵌入方法的每一个努力都必须乘以三。因此，团队决定研究学习通用嵌入集的可能性。结果证明这是可能的，这种重用最终简化了它们的部署流水线，并提高了单个任务的性能。

Sculley等人[52]给出了机器学习从业者现在面临的被广泛选择的工程问题。它们大多被认为是工程上的反模式（anti-patterns），但目前广泛存在于机器学习软件中。其中一些问题，例如抽象边界侵蚀（abstraction boundaries erosion）和校正级联（correction cascades），是由于在软件必须明确依赖于外部数据的情况下使用机器学习造成的。其他的，如胶水代码（glue code）或流水线丛林（pipeline jungles），源于该领域开发通用软件包的普遍趋势。本文讨论的另一个问题来源是配置债务，这是由于除了常规软件系统可能需要的所有配置之外，机器学习系统还添加了大量必须设置与维护的机器学习特定配置内容。

研究人员和软件工程师经常发现他们在同一个项目上一起工作，目的是用机器学习的方法来达到商业目标。从表面上看，似乎有一个明确的职责划分：研究人员开发模型，工程师构建运行模型的基础设施。实际上，在考虑开发过程、模型输入和输出以及性能度量时，它们关注的领域通常是重叠的。这两种角色的贡献者通常使用相同的代码。因此，将研究人员循环（loop）到整个开发过程中是有益的，确保他们与工程师一起拥有产品代码库，使用相同的版本控制并参与代码评审。尽管存在明显的入职和启动缓慢的挑战，但这种方法被视为在产品交付的速度和质量方面带来了长期收益[12]。

（6.2）监控

监控是由Sculley等人[52]报告的与维护机器学习系统相关的问题之一。社区正处于了解要监视的数据和模型的关键指标以及如何基于它们进行报警的早期阶段。监测机器学习模型不断变化的输入数据、预测偏差和总体性能是一个开放的问题。本文强调的另一个特定于数据驱动决策的维护问题是反馈回路。生产中的机器学习模型可以通过定期的再训练来影响它们自己的行为。在确保模型保持最新状态的同时，还可以创建反馈循环，在这个循环中，对模型的输入进行调整以影响其行为。这可以是有意的，也可以是无意中发生的，这是运行实时机器学习系统时的一个独特挑战。

Klaise等人[53]指出了异常值检测的重要性，它是一个关键工具，用以标记不能在生产环境中使用的模型预测值。作者列举了两个导致这种预测发生的原因：模型无法在训练数据集之外进行泛化，以及由于校准不当而对正常分布外实例的预测过于自信。异常值检测器的部署本身就是一个挑战，因为标记的异常值数据很少，检测器的训练常常成为一个半监督甚至无监督的问题。

Ackermann等人[54]提供了有关监控机器学习系统的更多信息。本文描述了美国两个警察部门的早期干预系统（EIS）。从表面上看，他们的监控目标似乎完全是标准的：数据完整性检查、异常检测和性能指标。人们希望能够使用开箱即用的工具来完成这些任务。然而，作者解释说，为了保持良好的模型性能，他们必须从头开始构建所有这些检查。例如，数据完整性检查意味着验证某个输入表的更新以及历史记录的校验和，性能指标是根据前k项（top k）输出中的变化次数定义的，异常情况则是随着时间的推移通过秩序相关性（rank-order correlations）来跟踪的。所有这些监测工具都需要大量的调查和实施。这突出了当前可用的端到端机器学习平台的一个常见问题：最终的机器学习解决方案通常对问题的细节非常敏感，以至于现成的工具不能很好地满足他们的需求。

最后，我们要注意的是，在选择监控和验证的指标之间存在重叠。后者在第5.1节中讨论。

（6.3）更新

一旦模型的初始部署完成，通常需要能够在以后更新模型，以确保它始终反映数据和环境的最新趋势。有多种技术可以使模型适应新数据，包括有计划的定期再训练和持续学习[55]。然而，在生产环境中，模型更新也会受到实际考虑的影响。

直接影响模型更新过程质量和频率的一个特别重要的问题是概念漂移。机器学习中的概念漂移被理解为在联合分布p（X，y）中观察到的变化，其中X是模型输入，y是模型输出。如同在Jameel等人[56] 针对分类问题的研究中，或在Celik和Vanschoren[57]在自动机器学习（AutoML）上下文的研究中所看到的那样，这种现象可能会对模型性能产生重大的不利影响。概念漂移的产生有多种原因。例如，正如Masegosa等人[58]所解释的那样，随着2008年金融危机的发展，金融业面临着动荡的变化，如果能采用先进的检测技术，它可以为当前的危机提供更多的见解。如Langenkämper等人[59]所述，无法避免数据收集过程中的波动也会导致数据的变化，该论文研究了海洋图像采集设备和位置的细微变化对深度学习模型性能的影响。正如Zenisek等人[60]在他们关于工业机械磨损的预测性维护的研究中所显示的那样，即使是在微观尺度上，数据变化也会产生显著的后果。尽管概念漂移已经被认识了几十年[61]，但这些例子表明，它仍然是当今机器学习应用的一个关键问题。

除了何时重新训练模型以使其保持最新状态的问题之外，还有一个关于如何将模型工件交付到生产环境的基础架构问题。在软件工程中，这类任务通常通过连续交付（continuous delivery）来解决，这是一种通过构建自动流水线来构建、测试和部署软件变更用以加快开发周期的方法。用于机器学习解决方案的连续交付很复杂，因为与常规软件产品中只在代码中发生更改不同，机器学习解决方案经历了三个轴向的变化：代码、模型和数据。Sato等人[45]中可以看到，将机器学习的连续交付作为一个独立的学科来制定。这项工作描述了在构建完整流水线的每个步骤中所涉及的部分和可以使用的工具。一个完整的连续交付流水线可以给现实生活中的机器学习解决方案带来的好处可以在Wider and Deger[62]的研究中找到。

（7）横切特征（cross-cutting aspects）

在本节中，我们将描述机器学习项目必须考虑的另外三个方面：伦理、最终用户的信任与安全。部署流水线的各个阶段都会受到影响。

（7.1）伦理

伦理考虑应始终对数据收集活动产生影响。正如艾伦图灵研究所（Alan Turing Institute）发表的关于伦理人工智能的报告[63]所述，“在整个人工智能项目交付工作流程中建立一个持续的人的责任链是至关重要的”。如果研究人员和开发人员不遵循这一建议，可能会因为各种原因出现复杂情况：违反政府法规、不合理的结果、现有问题的恶化等等[63]。

许多国家都制定了保护个人数据权利的法规。从个人那里收集的信息越敏感，对其使用的规定就越严格。当然，处理一些最敏感信息的行业是医疗保健行业。根据Han等人[64]的研究，许多国家都有严格的法律来保护患者的数据，这使得在医疗保健中采用机器学习尤其困难。此类法规的例子包括欧盟的一般数据保护法规[65]和亚洲国家的伦理筛查法[66]。一方面，毫无疑问，这些规则是绝对必要的，以确保人们对使用他们的数据感到满意。另一方面，所需的大量审查、软件更新和数据收集/注释周期使得跟上机器学习的技术进步异常困难，正如Han等人[64]根据他们在日本医疗保健部门部署机器学习解决方案的经验所解释的那样。

公司不应该只关注解决方案的技术方面，正如DeepMind和皇家免费NHS基金会信托基金会（Royal Free NHS Foundation Trust）在研究Streams时发现的那样，Streams是一种在严重情况下自动审查测试结果的应用程序[67]。他们最初的合作在患者数据的使用和患者参与方面不够具体，这引发了对他们遵守数据保护法规的调查。修订后的合作协议更加全面，包括患者和公众参与策略，以确保数据的使用符合伦理要求。

由于机器学习模型使用以前看到的数据来做出决策，它们可能会使数据中已经存在的问题恶化。奥尼尔详细讨论了刑事司法领域的这种影响[68]。“计算犯罪风险的方法”通常是用“人的偏见”来计算的。然而，他们使用看似中立的人口统计信息，而这些信息往往最终成为一种代理（proxy）。结果，人们因种族或收入而处于不利地位。

同样，Soden等人[69]提到通过使用有偏见的训练数据集会加剧社会不平等，这是将机器学习应用于灾害风险管理（DRM）领域的主要关注点之一。此外，有人认为，机器学习通过组合先前不同的数据集，在脆弱性、冲突和暴力环境中引起隐私和安全问题。专家和公众的作用被降低也被数字版权管理专业人士视为一个伦理问题。其中一些问题属于机器学习的分支研究领域，在机器学习中被称为公平性[70]。我们将在第7.3节讨论相关的跨领域安全问题。

Anantrasirichai和Bull[71]讨论了在创造性艺术领域中使用机器学习的一个有趣的伦理特征。当一个经过训练的模型被用来创作一件视觉艺术作品时，它的作者身份并不完全清楚。因此，独创性问题需要特别注意。与这个问题密切相关的是，越来越多的人担心使用机器学习生成虚假内容，这些内容很容易被用于错误的目的[72]。

机器学习遇到的另一个伦理问题是基于数据的决策。随着机器学习工具在关键决策过程中的应用，伦理问题也随之增加。Muthiah等人做了说明性批注[73]。他们的预测内乱的系统被称为EMBERS，被设计用来作为一种预测和交流工具，然而作者指出，它也有可能被政府滥用，可能是由于对其在社会中的作用的误解，或者是故意而为之的。

（7.2）最终用户的信任

最终用户通常会谨慎对待机器学习[74]、[3]、[75]。就其自身的协议而言，模型提供的解释很少，这使得很难说服最终用户使其相信这些模型的实用性[64]。为了说服用户信任基于机器学习的解决方案，必须投入时间来建立这种信任。在本节中，我们将探讨如何在实践中做到这一点。

如果一个应用程序有一个定义明确的可访问的受众，那么让这些人尽早参与项目是培养他们对最终产品的信心的有效方法。这种方法在医学中非常常见，因为最终产品通常针对的是定义明确的医疗工作者群体。一个例子是名为“败血症观察”的项目[76]。在这个项目中，我们的目标是建立一个模型来估计病人患败血症的风险。这并不是第一次尝试实现预测的自动化，由于之前的尝试被认为是失败的，医务人员对败血症观察的最终成功表示怀疑。为了克服这种怀疑，团队将建立信任作为首要任务，方法是：

1. 建立强有力的沟通渠道；
2. 与利益攸关方分享在制定目标方面取得的进展，而不是展示技术进步；
3. 建立公共和外部问责机制；
4. 在项目的早期阶段让一线临床医生和企业级决策者参与进来。

这项工作的一个关键信息是，模型的可解释性作为一个建立信任的工具是有局限性的，并且应该考虑用其他方法来获得最终用户的高可信度。虽然这听起来可能有争议，但事实上它与“Project explAIn”项目的结论一致，后者发现人工智能决策解释的相对重要性因上下文而异[77]。

Soden等人[69]也提出了类似的观点，他们探讨了机器学习对灾害风险管理（DRM）的影响。由于部署的机器学习解决方案越来越复杂，公众越来越难以参与，也越来越难以信任基于机器学习的灾害风险管理服务，例如洪水面积估计或飓风造成的损失预测。作为一种缓解措施，作者建议可以将模型描绘的所在地区的居民意见视为一种“风险”，并尽可能依赖开放软件和数据，使这些解决方案的开发尽可能透明。

构建值得信赖的产品的一个合理方法是在具有定制用户体验的专业用户界面上投入时间。Firebird[22]是一个帮助确定美国亚特兰大市消防检查重点目标的系统，其开发人员发现，引入机器学习解决方案替代以前使用的纸笔法的最佳方法是开发一个用户界面，表明以最终用户（消防人员与消防部门的检查员）的方式展示建模结果是最有用和最清楚的。Ackermann等人[54]也报道了类似的经验。

在拉丁美洲，EMBERS[73]是一个预测人口水平事件（如抗议）的系统，其作者注意到他们的用户有两种使用该系统的模式：（a）高召回率：获取大多数事件，然后使用其他方法过滤它们；（b）高精度：关注特定区域或特定假设。为了改善用户体验，从而增加他们对产品的信心，用户界面进行了改进，以方便地支持这两种模式。这个案例研究强调了上下文感知个性化对机器学习系统接口的重要性，这是Project explAIn[77]提出的一个重要观察结果。

Budd等人[24]指出，接口设计直接影响为收集未标记数据而构建的应用程序的质量。他们讨论了一系列收集医学图像标签的项目，这些项目都得益于设计良好的用户界面。作者的结论是，最终用户界面在注释应用程序的总体成功中起着很大的作用。

最后，当目标受众对机器学习有经验和良好理解的时候，基于其决策可以被解释的模型解决方案是首选的。Bhatt等人[11]分析了可解释性作为机器学习模型在企业内部部署的一个特征，发现这是大多数利益相关者必须具备的要求，包括管理人员、机器制造工程师、监管者等。此外，他们的调查显示，与公平性和稳健性的衡量标准一样，可解释性得分是一个理想的模型指标。

（7.3）安全

机器学习在整个机器学习部署工作流程中开辟了新的威胁向量，如Kumar等人[78]所述。针对机器学习的专门对抗性攻击可以发生在模型本身，用于训练的数据以及由此产生的预测。对抗性机器学习领域正在研究这种攻击对机器学习模型的影响以及如何防范它们[79,80]。Kumar等人最近的研究发现，行业从业者没有能力保护、检测和响应对其机器学习系统的攻击[81]。在本节中，我们将描述实践中报告的会影响已部署的机器学习模型的三种最常见的攻击：数据中毒、模型窃取和模型反转。我们特别关注对抗性机器学习，同时认为在部署系统时其他相关的一般安全问题，如：访问控制和代码漏洞，超出我们的工作范围。

在数据中毒中，对抗性攻击的目标是在训练阶段故意破坏模型的完整性，以操纵产生的结果。中毒攻击在机器学习模型不断更新新的输入训练数据的情况下尤其相关。Jagielski等人报告说，在使用线性模型的医疗环境中，在训练集中引入中毒率为8%的特定恶意样本导致半数患者的剂量不正确[82]。

数据中毒也可能发生在利用我们在6.2节中讨论过的反馈循环的集体努力的结果，就像微软的Twitter机器人程序Tay[83]一样。Tay的目的是随着时间的推移提高对语言的理解，但很快被大量故意恶意的推文淹没。在发布后的16小时内，Tay令人不安的消息中有一部分是辱骂性的或攻击性的，因而这个机器人程序就被关闭了。

另一种类型的对抗性攻击是通过查询已部署模型的输入（例如通过公共预测API）并监视其输出，对其进行反向工程。为了训练一个替代模型，对抗性查询被精心设计来最大限度地提取关于模型的信息。这种类型的攻击被称为模型窃取。简而言之，这种攻击会导致知识产权的损失，这可能是防御者的一个关键商业优势。Tramèr等人[84]已经证明，可以通过一系列的机器学习算法（包括：logistic回归、决策树、支持向量机和神经网络）复制Google、Amazon和Microsoft提供的机器学习服务在生产中部署的模型。在他们的工作中，他们报告了从650次到4013次的查询数量，以提取一个等价的模型，时间范围从70秒到2088秒。

一种相关的攻击是模型反转攻击，其中对抗性攻击的目标是恢复私人训练集的一部分，从而破坏其机密性。Fredrikson等人已经证明，他们可以利用模型来恢复训练数据，这些模型报告了他们预测的置信值[85]。Veale等人[86]强调了防止模型反转攻击的重要性，把它作为遵守数据保护法（如GDPR）的关键一步。

（未完待续）

 

下一篇文章：（英国剑桥大学）部署机器学习中的挑战：案例研究综述（下）中文译文