规划机器学习错误

这篇文章涵盖了我们生产中的机器学习课程的“需求和风险”讲座中的一些内容。其他章节见 表中的内容 .

Drivers, whether human or autonomous systems, may make mistakes. Anticipating this, we can design the environment to be safer, for example, installing bollards to protect pedestrians and buildings from driver mistakes (see also 世界系船柱协会 ).

软件系统中机器学习模型的预测可能是错误的。根据系统设计，错误的预测可能导致系统显示误导性信息或采取有问题的行动，这两者都可能导致各种问题和危害，从混淆用户到歧视、经济损失、伤害和死亡。更好的模型可能会犯更少的错误，但错误通常是不可避免的。机器学习模型的错误通常也是不可理解或不可预测的——最好将它们简单地视为不可靠的组件。因此，重要的是要考虑如何设计一个即使存在不可避免的错误也能提供价值并降低风险的整体系统。

虽然很难预测具体的错误（而且通常甚至可能不清楚“正确”的预测是什么，我们将在本章详细讨论模型质量 )，为错误的存在做计划是可能的，也是可取的。在本章中，我们将讨论识别系统中可能出现的错误及其后果的技术，以及将模型的风险和危害降至最低的设计选项。

The Docklands Light Railway system in London has operated trains without a driver since 1987. Many modern public transportation systems use increasingly sophisticated automation, including the Paris Métro Line 14 and the Copenhagen Metro (Picture CC BY 2.0 by 马特布朗 ).

在本章中，我们使用了两个具有不同风险程度的运行示例：一个是自动轻轨系统，另一个是电子邮件客户端的扩展，建议回复电子邮件。

Suggestions for email responses in GMail augment the user interface rather than automating responses or prompting users.

会发生错误

将机器学习模型视为一种有用的抽象 不可靠的组件 在一个可能在未知时间因未知原因而出错的系统中。系统设计人员应该始终预测模型的预测最终会出错，无论是检测火车路径中的障碍物还是建议电子邮件的答案。有了这个假设，挑战只是设计一个系统，使得机器学习组件的错误不会引发整个系统的问题。

即使我们不能期望训练出“完全正确”的模型，了解常见问题也将帮助我们更好地理解错误发生的原因，并帮助我们改进模型以减少出错的频率。

为什么 ML 模型会失败

模型可能会学习错误的概念或有盲点而没有意识到它们的原因有很多。我们讨论了一些常见的问题，但并不全面。

相关性与因果性。 机器学习在很大程度上依赖于数据中的相关性，但通常无法识别哪些相关性是由因果关系引起的，哪些可能只是源于数据中的噪声或数据收集过程中的决策。例如，有很多关于物体检测模型使用背景来识别前景中的报告，例如将雪中的狗识别为狼，或者当它们在海滩上时不识别奶牛——该模型依赖于训练数据中各种动物图像的典型背景，而不是学习人类用来识别动物视觉外观的抽象概念。我们将在章节中的快捷学习和对抗性攻击的背景下进一步探讨这一点模型质量和安全。

Example of an entirely spurious correlation between Maine’s divorce rate and the consumption of margarine based on data from the National Vital Statistics Reports and the U.S. Department of Agriculture (Figure CC BY 4.0, 泰勒·维根 ).

人类通常知道哪些因果关系是合理的或预期的，而大多数机器学习算法仅使用训练数据中的相关性，无法判断哪些相关性实际上是可靠的以做出预测。

混杂变量。 机器学习（以及人类研究人员）可能会将影响归因于相关但没有因果关系的变量，而忽略与混杂变量的联系。例如，在 2020 年分析患者数据的研究发现，男性秃顶与症状性 COVID 感染之间存在相关性，但这种影响可能只是简单地解释为年龄是一个混杂因素，即两者原因秃顶和更高的 COVID 风险。如果数据中包含混杂变量，机器学习算法可能有机会识别真实关系并补偿混杂变量，但通常此类数据可能不存在。

Spurious correlation in the data may be explained by a causal relationship with a third confounding variable.

逆因果。 机器学习在找到相关性时可能会将因果关系归因于错误的方向。例如，据报道，早期用宗师游戏训练的国际象棋程序已经知道牺牲皇后是获胜的一步，因为它经常发生在获胜的游戏中；机器学习算法可能会在需求量大时观察到酒店价格很高，因此建议设定高价格来创造需求——在这两种情况下都误解了相关性背后的因果关系，并以高置信度做出错误的预测。

缺少反事实。 训练数据通常不能表明在不同情况下会发生什么或如果采取了不同的行动，这使得归因因果关系变得困难。例如，我们可以观察过去的股票价格以试图预测未来的价格，但我们实际上并不知道在不同的市场条件或与竞争对手合并或不合并的不同决定下会发生什么。机器学习可能会尝试从许多类似观察结果之间的差异中观察因果关系，但收集令人信服的“假设”数据通常具有挑战性。

超出分布数据。 当要求对与训练期间看到的数据相似的数据进行预测时，机器学习模型通常更有信心。我们倾向于谈论 分布外 当输入与训练期间使用的数据分布不匹配时输入。模型可能会将学习到的规则外推到新数据，而没有意识到此类数据需要额外的规则。例如，自动驾驶列车中的模型可以准确地检测到摄像机图像中轨道上的成年行人和工人，但不会检测到从未包含在训练数据中的儿童或轮椅使用者。除了在某些训练数据中发现的相关性之外，人类通常更擅长通过常识推理处理分布外数据。各种模型的置信度得分和特定的分布外检测技术通常可以帮助识别此类情况——我们可以预期预测可能质量低下，并且可能较少依赖它们（“已知未知数”）。

其他原因。 其他很多问题都是由于训练数据不足、训练数据质量低、训练数据特征不足、训练数据有偏差、模型过拟合和欠拟合等诸多问题引起的。我们将在章节中讨论其中的几个模型质量和数据质量 .同样，我们通常可以发现问题并改进模型，但我们不能期望模型是完美的，并且应该始终预测可能会发生错误。

错误通常不是随机的

在推理物理过程中的故障时，我们通常假设一个潜在的随机过程，我们可以对其进行概率推理。例如，统计模型可以预测火车的钢轴在不同条件和腐蚀程度下随着时间的推移断裂的可能性，并且两个车轴将有相同的独立断裂机会，使我们能够随机推断更复杂组合的可靠性具有冗余的结构。软件错误通常不具有这种性质：软件不会因输入而随机失败，而是针对触发错误的特定输入。对于相同的输入，软件的多个副本将失败；即使是同一算法的多个独立实现也经常被观察到包含类似的错误，并且对于许多相同的输入都失败了。

虽然很容易随机推断机器学习模型的错误，但考虑到我们如何以百分比报告准确性，这是一条危险的道路。模型的错误不一定是随机分布的。错误可能以不明显的方式与输入的特定特征相关联，或者对某些亚群的影响比其他亚群更大（另见章节模型质量：切片和公平）。例如，火车的障碍物检测系统可能在几乎所有情况下都能正常工作，但它通常很难识别轮椅使用者；它可能具有 99.99% 的平均准确率，但在测试数据中不经常出现的特定类型的情况下仍然始终失败。与离线评估相比，我们可以监控生产中的错误，从而更可靠地了解错误频率（参见章节生产质量保证 )，但就频率或严重程度而言，今天的错误可能无法代表明天的错误。

虽然许多用于训练模型的机器学习算法是不确定的，但它们大多会生成在推理过程中具有确定性的模型，并且对于相同的输入总是会犯同样的错误。同样，在相同数据上训练的多个模型也可能会犯类似的错误，例如，如果数据包含虚假的相关性。

此外，攻击者可以尝试故意制造或操纵输入以引发错误（参见安全一章）。这样，即使是离线评估中准确率为 99.99% 的模型也可以生成大多受到攻击时的错误预测。例如，攻击者可能会用站台上的贴纸欺骗自动驾驶列车的障碍物检测模型，该贴纸被错误识别为障碍物并阻止列车运行（a 先前证明的对抗性攻击在交通标志的背景下）。

此外，许多模型的预测产生的置信度得分也需要谨慎解释。即使是高度自信的预测也可能是错误的。这甚至适用于校准模型，这些模型的置信度分数（平均而言）与预测的实际正确性相对应。

因此，我们只是建议系统设计人员将错误视为不可避免的错误，而无法准确预测未来部署中的分布甚至错误频率。虽然我们可以尝试学习错误更少的更好模型，但对于系统设计人员来说，这是一个很好的心理模型，可以为每一个可能错误的预测做好准备。

为失败而设计

机器学习模型是软件系统中的组件，模型是可能出错的不可靠组件这一事实并不意味着整个系统必然有故障、不安全或不可靠。 ML 组件在系统中的使用方式以及它与其他组件的交互方式决定了系统行为。也就是说，即使障碍物检测系统有时可能会误报障碍物或错过障碍物，列车中如何使用障碍物检测系统来避免碰撞又避免不必要的中断。这就是为什么理解整个系统的需求对于设计满足用户需求的系统如此重要，即使某些 ML 组件可能会出错。

人机交互设计（人在循环中）

系统通常使用机器学习以某种方式影响世界，要么通过自主行动，要么通过向可以采取行动的用户提供信息。减少人类参与通常是在软件系统中使用机器学习组件的关键目标，以降低成本、提高响应时间或吞吐量、减少偏见或消除繁琐的活动，从而让人类专注于更有趣的任务。尽管如此，在处理机器学习模型的错误时，让人类参与并注意到和覆盖错误是一种非常常见且通常很自然的方法。然而，在系统中设计人机交互具有挑战性，并且存在巨大的可能选项设计空间。用户可以通过不同方式与机器学习组件的预测进行交互。主要设计考虑因素包括：

如何使用模型的预测来实现目标（参见章节设定和衡量目标 )?
如何向用户呈现预测？建议还是自动采取行动？如何有效地影响用户对系统目标的行为？
如何最小化错误预测的后果？
如何收集数据以继续向用户和错误学习？

正如 Geoff Hulten 所概述的，通常人类 AI 设计需要平衡至少三个目标：(1) 实现系统目标，(2) 防止错误，以及 (3) 收集遥测数据以持续改进。不同的设计会做出不同的权衡，并对目标进行不同的优先排序。

正如章节中已经提到的从模型到系统，我们可以区分不同的常见交互模式，这为讨论可能的设计提供了一个很好的起点：

自动化： 系统基于模型的预测代表用户采取行动，而不需要用户参与决策。例如，自动系统控制无人驾驶火车的加速和门，垃圾邮件过滤器删除电子邮件，智能恒温器调节家庭温度，自动交易系统买卖股票。自动化将人类从循环中解放出来，提高了效率和反应时间，但不允许用户检查预测或动作，只有一些动作是可逆的。当我们对正确的预测有很高的信心或错误的潜在成本很低或可以通过其他方式减轻时，它最有用。
迅速的： 系统提示用户采取行动，用户可以遵循或拒绝。例如，物体检测系统可能会在离开车站前提醒操作员并要求确认，税务软件的模型可能会建议在继续之前检查输入费用中常见的某些扣除额，导航系统可能会建议是时候休息并询问是否添加附近的路边景点作为停靠点，或者欺诈检测系统可能会询问最近的信用卡交易是否具有欺诈性。提示让人们在循环中检查决策并采取行动，但提示可能具有破坏性，需要用户立即将认知努力投入到决策中，过于频繁的提示可能会令人讨厌并导致 通知疲劳 用户变得自满并开始忽略或盲目点击提示。当模型的置信度低或错误造成的成本高，并且提示出现的频率不高时，提示很有用。
组织、注释或扩充： 系统使用模型来决定向用户显示哪些信息以及以何种顺序显示。信息可能会在用户界面中突出显示或以更微妙的方式显示。在所有情况下，都会显示信息，但由用户决定是否以及如何做出反应。例如，电子邮件的可能答案会在电子邮件下方的 GMail 界面中以非侵入方式显示，用户可以单击或直接忽略它；一个安全系统，在火车操作员的摄像头中突出显示门附近的人；音乐流媒体服务可以提供个性化的播放列表；语法检查器可能会强调检测到的问题。或者，当用户请求时提供精选信息，例如提供搜索结果的模型或癌症预后模型突出显示图像中的区域以供放射科医生更仔细地探索。在所有这些情况下，系统只提供几个选项，但将决定和行动留给用户。这些方法侵入性较小，不需要立即采取行动。由于人类正在做出最终决定，因此当错误很常见或一开始就没有一个正确的预测时，这种方法可能会很有效。

请注意，这些设计在交互的力度方面有何显着差异，从完全自动化到仅提供信息，以及它们如何在不同程度上让人类参与其中。当然混合模式是可能的；例如，火车中的自主系统可以自动执行大多数操作，但当检测到火车前方的障碍物在 20 秒内没有移开时，它会提示（可能是远程的）人工操作员。决定设计的因素有很多，但要了解预期的交互频率和成本、正确预测的价值和错误预测的成本，以及用户在多大程度上有能力和知识来做出决策提供的信息将有助于指导设计过程。

通常，对于危害可能性有限或可以通过其他方式减轻危害的无聊和重复性任务，更自动化的设计很常见，而需要问责的高风险任务或用户喜欢执行的任务往往会让人类参与其中.此外，正如我们将在章节中讨论的那样可解释性和可解释性，提供带有预测的解释可以强烈影响人类如何与系统交互，以及他们在多大程度上建立信任或被操纵过度信任系统。

在本书中，我们不会深入探讨人机交互设计这个活跃且发展中的领域。有许多有趣的问题，例如（1）用户是否真的对系统或模型如何工作以及如何传达合适的模型有一个良好的心理模型，（2）如何对可以预期的内容和什么设定合理的期望系统可以做和不能做，以及为什么错误可能是不可避免的，以及（3）如何沟通用户如何改进或定制系统，以防出现错误时提供额外的反馈。

可撤消的操作

如果系统或其用户基于错误预测采取的行动是可逆的，则危害可能较小或暂时。例如，如果智能恒温器自动设置室温，用户可以简单地忽略该操作并很快恢复到舒适的温度；如果智能幻灯片设计器更改了幻灯片布局，用户只需撤消该步骤即可恢复以前的设计。也可以将系统设计为基于（不可靠的）模型预测采取的行动是明确可逆的，例如保留文档的历史记录或为每半个月策划和发送的系统提供免费退货运输带有个性化服装的包装。明确地使行动不可撤销并不适用于由于错误预测而采取的所有行动，因为许多行动都会产生永久性后果；例如，消除火车碰撞造成的结构损坏可能会增加维修成本，但在碰撞中失去的生命是无法挽回的。

在许多情况下，作为与系统正常交互的一部分，用户可以自行撤消操作，例如重置恒温器的温度或撤消幻灯片设计更改。在其他情况下，系统设计人员可能会提供明确的途径来上诉和推翻自动化决策，通常是通过涉及人工或额外步骤。例如，欺诈检测系统可能会阻止卖家作为在线平台上的机器人，但该系统可能会提供一种机制来吸引人类监督或使用身份验证机制，用户可以在其中上传政府身份证的图片。

护栏

在许多系统中，机器学习模型可用于通知可能的动作，但预测不会直接使用或传递，而是在附加步骤中进行处理。

当建议对电子邮件进行自动回复时，可以使用护栏来避免不适当或令人反感的建议，例如，通过使用禁用词列表简单地过滤回复。在当代自动驾驶列车系统中，护栏无处不在：这些系统通常在自己的分隔和围栏轨道上运行，这大大减少了障碍物的机会，通常甚至以高昂的成本增加站台屏蔽门以防止乘客跌倒在轨道上。此外，检测自动列车车门内人员的视觉模型还不够，但车门设计有额外的压力传感器来检测是否被阻塞。

Metro station Cour Saint-Émilion in Paris with automated platform screen doors that only open when a train is in the station (CC BY-SA 4.0 by 查贝01 ).

护栏通常依赖于非 ML 机制，例如将预测限制在可接受值的硬编码范围内，为常见错误或已知输入提供覆盖，应用硬编码启发式规则（例如过滤选择词），或使用平台屏蔽门等硬件组件和热熔断器（来自章节中的智能烤面包机示例从模型到系统）。护栏也可以非常复杂，例如在自动驾驶汽车中使用街道地图和基于视觉的系统，或者使用当前速度动态调整障碍物检测错误的容限。也可以使用其他机器学习模型，例如，使用情绪分析模型或毒性检测模型来识别和过滤有问题的建议电子邮件响应。当原始模型和用作保护措施的模型都出错时，仍然会出现问题，但是如果这些模型在很大程度上是独立的，那么两个模型出错的风险远低于原始模型失败的风险。

错误检测和恢复

系统设计人员经常考虑多个裁员至探测当事情出错时。例如，监控系统会观察服务器是否仍处于活动状态并做出响应，并且自主列车中的多个独立传感器会感知速度和周围环境。有大量的安全设计策略依赖于检测问题以减轻危害或恢复的能力。

Doer-Checker 模式。 Doer-Checker 模式是一种经典的安全模式，其中执行操作的组件（执行者）由第二个组件（检查者）监控。如果检查者可以在一定程度上确定执行者工作的正确性，它可以在检测到错误时采取纠正措施进行干预，即使执行者不受信任并且可能存在错误或不可靠。纠正措施可以包括提供新的替代输出，提供不太理想但安全的后备响应，或关闭整个系统。这种模式在很大程度上依赖于检测错误的能力。由于直接检测错误预测通常很困难（否则我们可能一开始就不需要预测），检测通常依赖于间接信号，例如用户反应或对结果的独立观察。例如，在自动驾驶列车中，当速度由机器学习模型控制时，充当检查员的安全控制器可能会观察到列车在弯道中危险地倾斜很远，并通过纠正制动命令进行干预——这里检查员不直接检查加速度命令输出或速度，但对列车的影响由独立的陀螺传感器评估。

优雅降级（故障安全）。 当检测到组件故障时，优雅降级是一种在系统级别降低功能和性能以保持安全运行的方法。也就是说，系统不是继续使用已知的故障组件运行或完全关闭系统，而是依靠备份策略来实现其目标，即使它以较低的质量和较低的速度这样做。例如，当电子邮件响应推荐服务出现故障时，电子邮件系统会在没有该功能的情况下继续运行。举一个更实际的例子，如果自动驾驶列车中的激光雷达传感器发生故障，列车可能会继续使用基于视觉的系统运行，但只能以较低的速度运行，同时与潜在障碍物保持较大的距离；如果没有完整的备用系统，最小的紧急组件可能能够安全地停止火车并提醒（远程）操作员或维护团队。

冗余

在系统中实施冗余是防御随机错误的常用策略。例如，在自动驾驶列车上安装两个摄像头来监控车门可确保即使其中一个摄像头的硬件发生故障，系统也能继续运行，系统在检测到故障后只需切换到另一个摄像头（称为热备）。除了通过比较多个冗余组件的输出来做出决策（例如通过投票）来更换完全失败的组件之外，还可以使用冗余。例如，我们可以使用三个独立的组件来检测自动列车中的障碍物，并使用中值或最坏情况值。

不幸的是，如果冗余部分在相同条件下失败，冗余将无济于事：运行相同非 ML 算法的多个实例或相同 ML 模型的多个实例通常会产生相同的输出。在实践中，即使是在相同数据上独立训练的独立实现的算法和模型也经常表现出类似的问题，这使得冗余对软件的有效性不如对硬件的有效。许多机器学习方法已经使用某种形式的冗余和内部投票来改进预测，称为 集成学习 ，例如，在随机森林分类器中。一般来说，如果不同的冗余计算有很大的不同，例如结合来自不同传感器的数据，冗余会更有效——例如，自动驾驶列车可能使用远程雷达、短程雷达、激光雷达和视觉、热像仪，结合信息来自地图、GPS、加速度计和指南针。

请注意，冗余可能很昂贵。自动驾驶汽车中的附加传感器系统可能会增加大量硬件成本，并且现有的车载硬件通常已经被现有计算推到了极限。系统设计人员需要在减少错误与增加硬件成本和计算工作量之间进行权衡（另见章节像软件架构师一样思考和机器学习组件的质量属性）。

遏制和隔离

设计具有不可靠组件的系统的经典策略是包含组件的错误并确保它们不会传播到系统的其他部分。一个传统的例子是将控制飞机的电传操纵系统与乘客的娱乐系统分开，这样后者（通常以低得多的质量标准建造）可以在不影响飞机安全的情况下崩溃和重新启动——将自动列车的控制系统与车站公告和车载广告的组件分开也是如此。在过去的灾难中有很多系统执行不佳的示例，例如美国海军舰艇在数据库应用程序中的某些数据输入导致零除错误传播并导致船舶的中央组件崩溃或崩溃后，必须重新启动整个控制系统 3 小时汽车可以通过娱乐系统远程入侵和停止。作为一般原则，不可靠和低关键组件不应影响高关键组件。

借助机器学习，我们通常不用担心输入会导致推理服务崩溃或利用漏洞导致推理服务操纵其他组件中的数据，因此沙盒、防火墙和零信任架构等传统隔离技术似乎与包含模型不太相关 -推理组件。当模型做出导致其他组件出现问题的错误预测时，通常会通过数据流产生涟漪效应。因此，谨慎考虑系统的哪些部分取决于特定模型的预测，当模型不可用时会发生什么，以及错误的预测如何导致下游影响。此外，当模型推理服务响应延迟或过载时，我们经常应该担心与时间相关的后果。对于所有这些，我们接下来讨论的危害分析和风险分析工具可能会有所帮助。

危害分析和风险分析

传统的安全工程方法可以帮助预测错误及其后果。它们有助于了解组件中的个别错误如何导致系统级别的故障和不良结果。许多这些安全工程方法，包括我们将在这里讨论的所有方法，都有很长的历史，并且是航空电子设备、医疗设备和核电站等传统安全关键领域安全工程的标准工具。随着机器学习作为不可靠组件的引入，即使在传统上对安全性不至关重要的系统中，预测和减少错误也变得更加紧迫：通过机器学习，我们倾向于尝试使用我们不完全理解的模型来解决雄心勃勃的问题，因此，即使看似有害的 Web 应用程序或移动应用程序也往往有潜在的危害，可能是造成压力、经济损失、歧视、污染或身体伤害（另请参阅负责任的人工智能工程章节）。尽早投入一些精力来预测这些问题可以改善用户体验，避免负面新闻，并避免实际伤害。

请注意，我们讨论的任何方法都不会提供正式的保证或可以确保避免或至少预期所有故障。这些方法旨在以尽力而为的方法提供结构和深思熟虑的过程，以改进以非结构化头脑风暴等临时方式思考错误的常见做法，如果有的话。这些方法都鼓励有意识地参与思考可能的失败及其后果，并思考如何在它们造成伤害之前避免它们。他们可以通过协作过程指导一群人，包括工程师、领域专家、安全专家和其他利益相关者。生成的文档可以广泛理解，以后可以更新和引用。

故障树分析

故障树分析是一种记录哪些条件可能导致系统故障的方法。故障树通常表示为自上而下的图表，显示系统故障（根源）与其潜在原因之间的关系，其中原因可能是组件故障或意外的环境条件等。在存在现有安全机制的情况下，通常存在多个事件链，这些事件必须一起发生才能导致系统故障。此外，通常有多个独立的条件可以触发相同的系统故障。故障树可以探索和记录这些复杂的关系。

故障树通常用于通过识别导致故障的条件和可能阻止故障的替代条件来分析过去的故障。然后可以用它来讨论如何预防这种和类似的系统故障，通常是通过对系统设计进行更改。

创建故障树。 为了创建故障树，我们从描述故障的事件开始 系统错误 .请注意，模型的错误预测是可能导致系统故障的组件错误，但它们本身并不是系统故障——系统故障应该根据实际行为描述整个系统的需求违规。通常，系统故障与轻微或严重的伤害有关，从压力和污染到身体伤害。例如，自动列车可能会与障碍物相撞或将乘客困在门内，电子邮件响应系统可能会提供甚至发送不适当的消息。然后从这个系统故障事件开始，我们将事件分解为触发故障所需的更具体的事件，其中可能包括错误的预测。在图形符号中和和或者门描述是否需要多个子事件来触发父事件或单个事件是否足够。只要对分析有用，将事件分解为较小的贡献事件就会递归地继续进行（决定何时停止需要一些判断）。未进一步分解的事件被称为 基本事件 在故障树分析的术语中。

在自动列车的背景下考虑以下示例。我们担心将乘客困在门内的系统故障（违反安全要求）。仅当基于视觉的模型未检测到车门内的乘客以及车门内的压力传感器在关闭时检测到障碍物均发生故障时，才会发生此故障。或者，如果人类操作员通过手动操作停用安全系统，也会发生这种情况。我们可以进一步分解这些子事件中的每一个。例如，基于视觉的系统可能由于模型的错误预测或由于相机故障或由于门附近的不良照明条件而失败。如果传感器发生故障或处理传感器信号的软件崩溃，则门中的压力传感器可能会失效。这些事件中的每一个都可以进一步分解，例如，考虑照明条件不佳的可能原因或不适当的手动操作的可能原因。

Partial example of a fault tree diagram for the system failure of trapping a person in the door of an autonomous train.

通常，如前所述，我们应该将机器学习模型视为不可靠的，因此它们往往会作为故障树中的事件突出显示。虽然我们可以推测一些失败的原因，但这些通常既不是必要条件也不是充分条件。因此，我们建议通常将机器学习模型的失败视为基本事件，无需进一步分解。

将需求分解为系统需求 (REQ)、环境假设 (ASM) 和软件规范 (SPEC)，如本章所述收集要求，对于从不同角度考虑可能的故障非常有用。顶级事件对应于系统的需求违规（在现实世界中），但促成此顶级事件的事件通常可以在错误的假设或未满足的规范中找到。虽然列出规范违规（软件错误、错误的模型预测）通常很直观，但质疑环境假设并将其违规视为故障树中的事件也很重要。例如，我们可能已经假设环境中的照明条件对摄像头来说足够好，或者操作员在覆盖门安全系统时非常小心——违反这些假设可能会导致系统故障。

分析故障树并设计缓解措施。 故障树显示了导致系统故障的各种情况，并且擅长突出缓解机制或缺乏缓解机制。通过列出触发故障所必需的一组基本事件，可以直接推导出系统故障发生的条件——这样的一组事件称为割集在我们的示例中，“门内人员”+“相机故障”+“压力传感器故障”是众多切割集之一。基本事件数最少的割集称为 最小割集 .现在，系统设计人员可以检查这些条件并确定可以进行额外缓解的情况，方法是防止基本事件或向最小割集添加额外事件，例如，通过引入安全措施、恢复机制、冗余或让人类参与其中。

在我们的示例中，软件模块崩溃可能导致门关闭似乎是有问题的。因此，通过系统重新设计，我们应该更改默认操作，并在读取门传感器的软件没有响应时防止门关闭，从而消除此基本事件，从而消除故障条件。在同一个例子中，我们还可以通过安装两个压力传感器来强化系统，防止单个压力传感器出现故障；现在需要同时发生两个压力传感器故障才能导致系统故障，增加最小割集的大小并降低故障的可能性。对于机器学习模型出错的可能性，我们通常无能为力，但我们可以确保需要额外的事件来触发系统故障，例如同时具有基于视觉和基于压力传感器的安全性控制门，就像我们在示例设计中所做的那样。

典型的故障树分析过程经历了多次迭代：(1) 分析需求，包括环境假设和规范，(2) 为每个关注的需求违规构建或更新故障树，(3) 分析树以识别割集，以及 ( 4) 考虑改变设计以消除基本事件或通过附加事件增加割集的大小。

请注意，故障树永远不会真正完整。即使进行了仔细的需求分析，我们也可能会错过导致失败的事件（“未知的未知数”或“ 黑天鹅事件 ”）。领域专业知识对于创建故障树和判断分解事件的程度至关重要。当从与领域专家的讨论或分析过去的系统故障中了解更多信息时，从业者可能会修改故障树。此外，我们的缓解措施很少是完美的，特别是如果我们仍然必须处理机器学习组件的不可靠性质以及从软件内部对现实世界和人类行为进行推理的复杂性。然而，即使故障树不完整，它们也是一个有价值的工具，可以用来思考故障场景并考虑将缓解措施作为系统要求和设计过程的一部分，以减少实践中发生故障的机会。

失效模式和影响分析 (FMEA)

如果故障树从系统故障倒推到导致或促成故障的事件，则该方法 失效模式和影响分析 (FMEA) 从组件故障到系统故障和相应危险的原因。故障树分析中的向后搜索对于分析事故和预期故障以改进系统特别有用，而使用 FMEA 的前向搜索对于识别以前未预料到的问题很有用。

FMEA 不是从需求开始，而是从识别系统的组件开始，然后列举每个组件的潜在故障模式，最后确定每个组件故障可能对系统的其余部分产生什么后果，以及如何检测或减轻这种影响.了解组件故障的后果通常需要很好地了解系统中不同组件如何交互以及组件如何影响整个系统行为。 FMEA 非常适合具有机器学习组件的系统：由于我们总是可以假设模型可能会出错，因此 FMEA 会引导我们思考每个模型的这些错误的后果。

在自动列车的门示例中，基于视觉的系统可能会因未检测到门内的人或检测到门内没有人而失败。细想这些错误的后果，我们可以发现，前者可能导致关门时伤人，而后者则可能导致列车无法发车，造成延误。从这里，我们可以直接考虑缓解措施，例如在门口添加压力传感器或增加人工（远程）操作员覆盖系统的能力，或者我们可以使用故障树分析来了解已识别的故障及其条件和更详细的缓解措施。在我们建议的电子邮件回复的其他场景中，可能值得更详细地考虑故障模式，而不仅仅是“提供错误的预测”并分析预测可能错误的方式：它可能偏离主题、难以理解、拼写错误、不礼貌、冒犯、性别偏见、计算缓慢或其他方面的错误——因为导致的失败和伤害可能不同。对于许多机器学习任务，已经存在可以指导分析的常见错误分类，例如物体检测中的常见错误 , 行人检测中的常见错误，和自然语言推理中的常见错误 .

FMEA 通常以表格形式记录，每个组件的每个故障模式都有一行。该行描述了组件、组件的故障模式、对系统的最终影响、潜在原因、检测组件故障的潜在策略（如果有）以及建议的操作（或缓解措施）。通常还会以数字方式判断问题的严重性，以确定问题和缓解措施的优先级。

Excerpt of an FMEA table for analyzing components in an autonomous vehicle, from David Robert Beachum. 评估自动驾驶汽车安全性的方法 . University of Texas Theses and Dissertations (2019).

作为故障树分析，FMEA 不提供任何保证，而是提供有关如何系统地思考问题的结构化指导，明确考虑每个组件可能出现故障的多种方式。虽然这可能无法预测所有可能的系统故障，但它有助于预测很多。

危害和可操作性研究 (HAZOP)

危害和可操作性研究 (HAZOP) 是另一种经典方法，与 FMEA 类似，它执行从组件错误到系统故障的前向分析。 HAZOP 相当简单，可以被认为是一种引导创造性的技术，用于识别组件或中间结果中可能的故障模式：它引导分析考虑具有特定特性的组件 引导性词汇 想出故障模式。

虽然引导词可以以特定领域的方式进行定制，但常见的引导词包括：

NO OR NOT：完全否定设计意图
更多：数量增加
LESS：数量减少
以及：定性修改/增加
部分：定性修改/减少
REVERSE：设计意图的逻辑相反
OTHER THAN / INSTEAD：完全替代
EARLY：相对于时钟时间
LATE：相对于时钟时间
之前：与顺序或顺序有关
之后：与顺序或顺序有关

一些研究人员建议使用机器学习特定的引导词，例如 WRONG、INVALID、INCOMPLETE、PERTURBED 和 INCAPABLE。

使用 HAZOP 进行的分析现在将每个组件或组件输出与每个引导词结合起来考虑。例如，如果自动列车中的障碍物检测组件确实如此，这可能意味着什么不是检测到障碍物，确实检测到 更多的 障碍物或部分障碍物，或确实检测到障碍物晚的，或者确实越来越 更多的 随着数据分布的漂移，错误会随着时间的推移而发生。并非每个指导词对每个组件都有意义（撤销检测障碍物？），某些组合可能需要一些创造性的解释（后？ )，但它们可能导致以前没有考虑过的有意义的故障模式。引导词也可以应用于系统的其他部分，包括训练数据、运行时数据、训练管道和监控系统，例如引导思考错误标签的后果、训练数据不足、相机输入延迟、扰动的摄像机输入、漂移分布和缺少监控。从那里可以像 FMEA 一样识别相应的系统故障。

概括

机器学习模型总是会出错，没有办法绕过它。我们可能对一些错误有一些直觉，但另一些则完全令人惊讶、奇怪或源于蓄意攻击。改进模型是改进系统的好方法，但它不会消除所有错误。了解一些错误的来源可以帮助我们改进模型，但不足以保证它们的正确性。因此，重要的是要考虑系统设计和缓解策略，以确保机器学习模型中的错误不会导致系统出现严重故障，从而可能在现实世界中造成更小或更严重的伤害。负责任的工程师将明确考虑系统中模型错误的后果，以预测问题和设计缓解措施。

故障树分析、FMEA 和 HAZOP 等经典安全工程技术有助于分析（潜在）系统故障的原因和组件故障的后果。虽然不提供保证，但这些技术有助于预测许多问题并有助于设计系统以避免问题或降低问题发生的可能性。

一旦预见到问题，通常会有许多设计策略来解决如何通过安全措施、恢复机制、冗余或隔离来补偿系统其余部分中的模型错误，或者如何设计系统与具有不同程度的人之间的交互有力。例如，通过合适的用户交互设计，我们可以确保人类保留代理权并且可以覆盖模型中出现的错误，例如，通过提供建议而不是完全自动化的操作或允许人类撤消自动化操作。

amboke

规划机器学习错误

规划机器学习错误

会发生错误

为什么 ML 模型会失败

错误通常不是随机的

为失败而设计

人机交互设计（人在循环中）

可撤消的操作

护栏

错误检测和恢复

冗余

遏制和隔离

危害分析和风险分析

故障树分析

失效模式和影响分析 (FMEA)

危害和可操作性研究 (HAZOP)

概括

延伸阅读

公告