注：本说明是为课程CS 329S：机器学习系统设计（斯坦福大学，2022年）编写的正在进行中的工作。对于充分开发的文本，请参阅《设计机器学习系统》（Chip Huyen，O’Reilly 2022）一书。幻灯片（短得多）😁). 谷歌文档的原始版本。
让我们从一位高管给我讲的一个故事开始，许多读者可能都能理解这个故事。大约两年前，他的公司聘请了一家咨询公司开发了一个ML模型，以帮助他们预测下周他们需要多少种杂货，这样他们就可以相应地重新进货。这家咨询公司花了六个月的时间开发这个模型。当咨询公司交出模型时，他的公司部署了它，并对其性能非常满意。他们终于可以向投资者吹嘘自己是一家人工智能驱动的公司。
然而，一年后，他们的人数下降了。一些商品的需求一直被高估，这导致额外的商品过期。与此同时，一些商品的需求一直被低估，导致销量下降。最初，他的库存团队手动更改模型的预测，以纠正他们注意到的模式，但最终，模型的预测变得如此糟糕，以至于他们无法再使用它。他们有三个选择：付给同一家咨询公司一大笔钱来更新模型，付给另一家咨询公司更多的钱，因为这家公司需要时间来跟上进度，或者雇佣一个内部团队来维护模型。
他的公司艰难地吸取了一个重要的教训，业内其他人也发现了这一点：部署模型并不是过程的终点。模型在生产中的性能会随着时间的推移而下降。一旦部署了一个模型，我们仍然必须持续监控其性能以检测问题，并部署更新以修复这些问题。
带有自然地面真值标签的任务是系统可以自动评估或部分评估模型预测的任务。谷歌地图上估计到达时间的模型就是一个例子。在旅行结束时，谷歌地图知道旅行实际花费了多长时间，因此可以评估预测到达时间的准确性。
自然标签是评估模型性能的理想选择。然而，即使你的任务本身没有自然的标签，也可以通过某种方式设置你的系统，让你可以收集一些关于模型的反馈。例如，如果你正在构建一个像Google Translate这样的翻译系统，你可以选择让社区为糟糕的翻译提交替代翻译。新闻源排名不是一项带有固有标签的任务，但通过在每个新闻源项目中添加like按钮和其他反应，Facebook能够收集关于其排名算法的反馈。
对于具有自然地面真值标签的任务，从提供预测到提供反馈所需的时间是反馈回路长度。
具有短反馈回路的任务通常在几分钟内就可以获得地面真相标签。这类任务的典型例子是推荐系统。推荐系统的目标是向用户推荐他们想要的项目。无论用户是否点击了推荐项目，都可以被视为对该推荐的反馈。被点击的推荐可以被认为是好的推荐（即标签是肯定的），而没有被点击的推荐可以被认为是坏的推荐（即标签是否定的）。许多任务可以被定义为推荐任务。例如，你可以将预测广告点击率的任务设定为根据用户的活动历史和个人资料向用户推荐最相关的广告。
然而，并不是所有的推荐系统都有短反馈回路。根据所推荐物品的性质，标签的延迟时间可以是几秒到几小时，在某些极端情况下，可以是几天或几周。如果推荐的项目是要在Reddit上订阅的SubReddit、要在Twitter上关注的人、要在Tiktok上观看的下一个视频等，那么从推荐项目到点击它（如果点击了它）之间的时间是秒。如果你处理较长的内容类型，如博客文章、文章或YouTube视频，可能需要几分钟甚至几小时。然而，如果你建立了一个系统，像one Stitch Fix那样为用户推荐衣服，那么在用户收到这些衣服并试穿之前，你不会得到反馈，这可能需要几周后。
除非每个推荐项目旁边都有一个提示：“你喜欢这个推荐吗？是/否”，否则推荐系统没有明确的负面标签。即使你添加了这个提示，也不能保证用户会响应。通常，如果缺乏正面反馈，建议被认为是不好的。在特定的时间窗口后，如果没有点击，则假定标签为负片。选择正确的窗口长度需要仔细考虑，因为它涉及速度和精度的权衡。短窗口长度意味着您可以更快地捕获标签，这允许您使用这些标签进行监控和持续学习。然而，短窗口长度也意味着您可能会过早地将某个项目标记为“在被单击之前不单击”。
无论你将窗口长度设置为多长，都可能会出现过早的负面标签。2021年初，推特广告团队的研究发现，即使广告点击次数最多发生在5分钟内，但点击广告后几小时就会出现一些点击。这意味着这类标签往往低估了实际点击率。如果你只记录了1000次点击，实际的点击次数可能会超过1000次。
对于反馈循环较长的任务，自然标签可能需要数周甚至数月才能到达。欺诈检测就是一个长反馈循环任务的例子。在交易结束后的一段时间内，用户可以质疑该交易是否欺诈。例如，当客户阅读信用卡对账单，发现一笔他们不认识的交易时，他们可能会与银行发生争议，向银行提供反馈，将该交易标记为欺诈。一个典型的争议窗口是一个月到三个月。争议窗口过后，如果用户没有争议，您可以假定该交易是合法的。
带有长反馈循环的标签有助于在季度或年度业务报告中报告模型的性能。然而，如果你想尽快发现模型的问题，它们并不是很有帮助。如果你的欺诈检测模型有问题，需要几个月才能发现，等到问题解决时，你的错误模型泄露的所有欺诈交易都可能导致一家小企业破产。
在确定ML系统故障的原因之前，让我们简要讨论一下什么是ML系统故障。当违反系统的一个或多个预期时，就会发生故障。在传统软件中，我们主要关心系统的操作预期：系统是否在预期的操作指标（如预期的延迟和吞吐量）内执行其逻辑。
对于ML系统，我们关心它的操作指标和ML性能指标。例如，考虑一个英法机器翻译系统。它的操作预期可能是，给定一个英语句子，系统会在第二个延迟内返回一个法语翻译。它的ML性能预期是，返回的译文在99%的时间内是对原始英语句子的准确翻译。
如果你在系统中输入了一个英语句子，但没有得到翻译，那么第一个期望值就被违反了，因此这是一个系统故障。
如果你得到了一个不正确的翻译，这不一定是系统故障，因为精度预期允许一定的误差范围。然而，如果你不断地在系统中输入不同的英语句子，并且不断地得到错误的翻译，那么第二个期望就被违背了，这就导致了系统故障。
操作预期违规更容易检测，因为它们通常伴随着操作中断，例如超时、网页上的404错误、内存不足错误、分段错误等。然而，ML性能预期违规更难检测，因为它需要在生产中测量和监控ML模型的性能。在上面的英法机器翻译系统的例子中，如果我们不知道正确的翻译应该是什么，那么在99%的时间里检测返回的翻译是否正确是很困难的。有无数的例子表明，谷歌翻译的错误翻译被用户使用，因为他们不知道这些翻译是错误的。出于这个原因，我们说ML系统通常会无声地失败。
为了有效地检测和修复生产中的ML系统故障，了解一个模型在开发过程中运行良好后，为什么会在生产中失败是很有用的。我们将研究两种类型的故障：软件系统故障和特定于ML的故障。软件系统故障是非ML系统可能发生的故障。下面是一些软件系统故障的例子。
依赖失败：系统依赖的软件包或代码库中断，导致系统中断。当依赖关系由第三方维护时，这种故障模式很常见，如果维护依赖关系的第三方不再存在，这种故障模式尤其常见1。
部署失败：由部署错误引起的失败，例如，当您意外地部署了模型的旧版本而不是当前版本的二进制文件时，或者当您的系统没有读取或写入某些文件的正确权限时。
硬件故障：当您用于部署模型的硬件（如CPU或GPU）表现不正常时。例如，您使用的CPU可能过热并出现故障。
停机或崩溃：如果系统的某个组件从某个服务器（如AWS或托管服务）运行，而该服务器已关闭，则系统也将关闭。
仅仅因为一些故障不是特定于ML的，并不意味着ML工程师理解这些故障并不重要。2020年，谷歌的两名ML工程师丹尼尔·帕帕西安（Daniel Papasian）和托德·安德伍德（Todd Underwood）研究了96起谷歌大型ML管道破裂的案例。他们回顾了过去15年的数据，以确定原因，并发现96次故障中有60次是由于与ML3无直接关系的原因造成的。大多数问题与分布式系统有关，例如工作流调度器或编排器出错，或与数据管道有关，例如来自多个源的数据连接错误或使用了错误的数据结构。
解决软件系统故障需要的不是ML技能，而是传统的软件工程技能，解决它们超出了本课程的范围。由于传统软件工程技能在部署ML系统中的重要性，大多数ML工程都是工程，而不是ML 4。对于有兴趣从软件工程的角度学习如何使ML系统可靠的读者，我强烈推荐O’Reilly与Todd Underwood合著的《可靠的机器学习》一书。
软件系统故障普遍存在的一个原因是，由于业界对ML的采用尚处于初级阶段，围绕ML生产的工具有限，最佳实践尚未得到充分开发或标准化。然而，随着ML生产工具和最佳实践的成熟，有理由相信软件系统故障的比例将减少，而特定于ML的故障的比例将增加。
特定于ML的故障是特定于ML系统的故障。例如，数据收集和处理问题、超参数差、训练管道中的变化未在推理管道中正确复制，反之亦然、导致模型性能随时间恶化的数据分布变化、边缘情况和退化的反馈回路。
在本课中，我们将重点讨论特定于ML的故障。尽管它们只占故障的一小部分，但它们可能比非ML故障更危险，因为它们很难检测和修复，并且可能会阻止ML系统被完全使用。在之前的课程中，我们已经讨论了数据问题、超参数调整，以及使用两条单独的管道进行训练和推理的危险。在本课中，我们将讨论部署模型后出现的三个新但非常常见的问题：改变数据分布、边缘情况和退化反馈循环。
当我们说ML模型从训练数据中学习时，这意味着该模型学习训练数据的基本分布，目的是利用学习到的分布为看不见的数据生成准确的预测，这些数据是它在训练期间没有看到的。我们将在下面的数据分布部分从数学上探讨这意味着什么。当模型能够为看不见的数据生成准确的预测时，我们说这个模型“推广到看不见的数据。5”我们在开发过程中用来评估模型的测试数据应该代表看不见的数据，模型在测试数据上的表现应该让我们了解模型推广的效果。
我在ML课程中学到的第一件事是，训练数据和看不见的数据必须来自同一个分布。假设看不见的数据来自与训练数据分布相同的平稳分布。如果看不见的数据来自不同的分布，该模型可能无法很好地推广。
这种假设在大多数情况下是不正确的，原因有二。首先，真实世界数据的潜在分布不太可能与训练数据的潜在分布相同。策划一个能够准确表示模型在生产中会遇到的数据的训练数据集是非常困难的。现实世界中的数据是多方面的，在许多情况下几乎是无限的，而训练数据是有限的，并且受数据集创建和处理期间可用的时间、计算和人力资源的限制。可能会出现许多不同的选择和采样偏差，使现实世界的数据与训练数据产生偏差。这种差异可能与使用不同类型表情编码的真实世界数据一样小。这种类型的分歧导致了一种常见的故障模式，称为“列车服务倾斜”：这种模式在开发中表现出色，但在部署时表现不佳。
第二，现实世界不是静止的。事情变了。数据分布发生了变化。2019，2019冠状病毒疾病2019冠状病毒疾病，但当人们搜索武汉时，他们可能想得到旅游信息，但是自从COVID-19，当人们搜索武汉时，他们可能想知道COVID-19起源的地方。另一种常见的故障模式是，模型在首次部署时表现出色，但随着数据分布的变化，其性能会随着时间的推移而下降。只要模型仍在生产中，就需要持续监控和检测这种故障模式。
当我使用2019冠状病毒疾病引起数据转移时，一些人会觉得数据转移只是因为不寻常的事件发生，这意味着它们不会经常发生。数据变化总是发生的，突然的、逐渐的或季节性的。它们可能会因为某个特定事件而突然发生，例如，当现有竞争对手改变其定价政策时，你必须更新价格预测以作出回应，或者当你在一个新的地区推出产品时，或者当一位名人提到你的产品从而导致新用户激增时，等等。它们可以逐渐发生，因为社会规范、文化、语言、趋势、行业等等都会随着时间而改变。这种情况也可能因季节变化而发生，比如人们可能更倾向于在寒冷下雪的冬季而不是春季要求乘坐野兔。
当谈到数据转移时，许多人认为这是由于外部变化造成的，比如自然灾害、假期或用户行为。但在现实中，由于ML系统的复杂性和部署过程中的不良做法，监控仪表盘上看起来像数据转移的大部分都是由内部错误8造成的，例如数据管道中的错误、错误填写的缺失值、，在训练和推理期间提取的特征、使用错误数据子集的统计数据标准化的特征、错误的模型版本或应用程序界面中迫使用户改变其行为的缺陷之间的不一致。
由于这是一种影响几乎所有ML模型的错误模式，我们将在“数据分布”一节中详细介绍这一点。
想象一下，有一辆自动驾驶汽车可以在99.99%的时间里安全驾驶你，但在另外0.01%的时间里，它可能会陷入一场灾难性事故，导致你永久受伤甚至死亡。你会用那辆车吗？
如果你想说不，你并不孤单。如果ML模型在大多数情况下表现良好，但在少数情况下失败，那么如果这些失败导致灾难性后果，它可能不可用。出于这个原因，主要的自动驾驶汽车公司正专注于使他们的系统在边缘情况下工作10 11 12。
边缘情况是指数据样本非常极端，导致模型出现灾难性错误。尽管边缘案例通常指的是从同一分布中提取的数据样本，但如果模型在其中表现不佳的数据样本数量突然增加，则可能表明基础数据分布发生了变化。
自动驾驶车辆通常用于说明边缘情况如何阻止部署ML系统。但这也适用于任何安全关键型应用，如医疗诊断、交通控制、eDiscovery 13等。非安全关键型应用也适用。想象一下，一个客户服务聊天机器人对大多数请求都给出了合理的响应，但有时它会吐出极端种族主义或性别歧视的内容。这个聊天机器人对任何想使用它的公司来说都是一个品牌风险，因此无法使用。
你可能想知道异常值和边缘情况之间的区别。边缘案例的定义因学科而异。在ML中，由于其最近在生产中的采用，边缘案例仍在被发现，这使得它们的定义有争议。
在这堂课中，离群值指的是数据：一个与其他例子截然不同的例子。边缘情况指的是性能：一个模型的性能明显低于其他示例的示例。异常值可能会导致模型表现异常糟糕，这使其成为边缘情况。然而，并非所有的异常值都是边缘情况。例如，在高速公路上行走的人是一个异常值，但如果你的自动驾驶汽车能够准确地检测到那个人并适当地决定运动响应，那就不是边缘情况。
在模型开发过程中，异常值可能会对模型的性能产生负面影响。在许多情况下，删除异常值可能是有益的，因为它有助于您的模型更好地了解决策边界，并更好地概括未知数据。然而，在推理过程中，你通常没有删除o的选项
......