机器学习：数据分布的漂移问题及应对方案

首先，让我们从一位高管告诉我的一个故事开始，很多读者可能对此感同身受。

大约两年前，他的公司聘请了一家咨询公司开发一个机器学习模型，帮助他们预测下周每种食品杂货需要多少，以便他们可以相应地补货。这家咨询公司花了六个月的时间来开发这个模型。当咨询公司将模型交给他时，他的公司就部署了它，并对其表现非常满意。他们终于可以向投资者夸耀他们是一家人工智能公司了。

然而，一年后，他们的数字下降了。一些商品的需求一直被高估，导致多余的商品过期。与此同时，一些商品的需求一直被低估，导致销售额下降。最初，他的库存团队手动更改了模型的预测，以纠正他们注意到的模式，但最终，模型的预测变得如此糟糕，以至于他们无法再使用它。他们有三个选择：向同一家咨询公司支付巨额费用来更新模型，向另一家咨询公司支付更多费用，因为这家公司需要时间来跟上进度，或者聘请内部团队来维护模型。

他的公司从惨痛经历中学到了一个重要的教训，而业内其他人也正在发现：部署模型并不是流程的结束。模型的性能会随着生产时间的推移而下降。部署模型后，我们仍然必须持续监控其性能以检测问题，并部署更新以解决这些问题。

NSDT工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器 - REVIT导出3D模型插件 - 3D模型语义搜索引擎 - Three.js虚拟轴心开发包 - 3D模型在线减面 - STL模型在线切割 

1、自然标签和反馈循环

具有自然基本事实标签的任务是模型的预测可以由系统自动评估或部分评估的任务。一个例子是估计谷歌地图上到达时间的模型。在旅行结束时，谷歌地图知道旅行实际花费了多长时间，因此可以评估预测到达时间的准确性。

自然标签是评估模型性能的理想选择。但是，即使你的任务本身没有自然标签，也可以设置你的系统，以便收集一些关于模型的反馈。

例如，如果你正在构建像谷歌翻译这样的翻译系统，可以选择让社区为糟糕的翻译提交替代翻译。新闻源排名不是具有固有标签的任务，但通过在每个新闻源项目中添加点赞按钮和其他反应，Facebook 能够收集对其排名算法的反馈。

对于具有自然基本事实标签的任务，从提供预测到提供反馈所需的时间就是反馈循环长度。

具有短反馈循环的任务是通常在几分钟内即可获得基本事实标签的任务。此类任务的典型示例是推荐系统。推荐系统的目标是向用户推荐他们喜欢的商品。用户是否点击推荐商品可以看作是对该推荐的反馈。被点击的推荐可以被认为是好的推荐（即标签为正面），未被点击的推荐可以被认为是不好的推荐（即标签为负面）。

许多任务可以定义为推荐任务。例如，你可以将预测广告点击率的任务定义为根据用户的活动历史和个人资料向用户推荐最相关的广告。

但是，并非所有推荐系统都具有短反馈循环。根据要推荐商品的性质，标签的延迟时间可能是几秒到几小时，在某些极端情况下，可能是几天或几周。如果推荐的商品是 Reddit 上要订阅的子版块、Twitter 上要关注的人、Tiktok 上接下来要观看的视频等，那么从推荐商品到用户点击（如果真的被点击）的时间就是几秒钟。如果你处理的是较长的内容类型，如博客文章或 YouTube 视频，则可能需要几分钟甚至几小时。但是，如果你建立一个像 Stitch Fix 那样的系统来为用户推荐衣服，那么在用户收到商品并试穿后你才会得到反馈，而这可能需要几周时间。

除非每个推荐商品旁边都有提示：“你喜欢这个推荐吗？是/否”，否则推荐系统没有明确的负面标签。即使你添加了这个提示，也不能保证用户会对此做出回应。通常，如果缺乏正面反馈，则认为推荐不好。在一定时间窗口后，如果没有点击，则认为标签是负面的。

选择合适的窗口长度需要仔细考虑，因为它涉及速度和准确性的权衡。较短的窗口长度意味着你可以更快地捕获标签，这允许你使用这些标签进行监控和持续学习。然而，较短的窗口长度也意味着你可能会在商品被点击之前过早地将其标记为无点击。

无论将窗口长度设置为多长，仍可能存在过早的负面标签。2021 年初，Twitter 广告团队的一项研究发现，尽管大多数广告点击发生在前 5 分钟内，但有些点击发生在广告展示后的数小时后。这意味着这种标签往往会低估实际点击率。如果你只记录了 1000 次点击，那么实际点击次数可能会略多于 1000 次。

2、机器学习系统故障的原因

在确定机器学习系统故障的原因之前，让我们先简单讨论一下什么是机器学习系统故障。当系统的一个或多个期望被违反时，就会发生故障。在传统软件中，我们主要关心系统的运行期望：系统是否在预期的运行指标（例如预期的延迟和吞吐量）内执行其逻辑。

对于机器学习系统，我们既关心其运行指标，也关心其机器学习性能指标。例如，考虑一个英法机器翻译系统。其运行期望可能是，给定一个英文句子，系统在一秒的延迟内返回法语翻译。其机器学习性能期望是，返回的翻译在 99% 的时间内是原始英文句子的准确翻译。

如果你在系统中输入英文句子但没有得到翻译，则第一个期望被违反，因此这是系统故障。

如果你得到的翻译不正确，则不一定是系统故障，因为准确性期望允许一定的误差幅度。但是，如果你不断向系统输入不同的英语句子并不断得到错误的翻译，则第二个期望被违反，这使其成为系统故障。

操作期望违规更容易检测，因为它们通常伴随着操作中断，例如超时、网页上的 404 错误、内存不足错误、分段错误等。但是，ML 性能期望违规更难检测，因为它需要测量和监控 ML 模型在生产中的性能。在上面的英法机器翻译系统的例子中，如果我们不知道正确的翻译应该是什么，那么检测返回的翻译是否 99% 的时间都是正确的是很困难的。有无数的例子表明，谷歌翻译的错误翻译被用户使用，因为他们不知道这些是错误的翻译。因此，我们说 ML 系统经常默默地失败。

为了有效地检测和修复生产中的 ML 系统故障，了解为什么一个模型在开发期间被证明运行良好后会在生产中失败是很有用的。我们将研究两种类型的故障：软件系统故障和 ML 特定故障。软件系统故障是非 ML 系统可能发生的故障。以下是一些软件系统故障的示例。

对于反馈循环较长的任务，自然标签可能要数周甚至数月才能到达。欺诈检测就是一个反馈循环较长的任务的例子。在交易后的一段时间内，用户可以对该交易是否为欺诈提出异议。例如，当客户阅读信用卡账单并看到一笔他们不认识的交易时，他们可能会向银行提出异议，并向银行反馈将该交易标记为欺诈。典型的争议窗口是一个月到三个月。争议窗口过后，如果用户没有提出异议，则可以假定该交易是合法的。

反馈循环较长的标签有助于在季度或年度业务报告中报告模型的表现。但是，如果你想尽快发现模型的问题，它们就没什么用了。如果你的欺诈检测模型存在问题，并且需要数月时间才能发现，那么等到问题解决时，有缺陷的模型所允许的所有欺诈交易可能已经导致一家小企业破产。

• 依赖项故障：系统所依赖的软件包或代码库发生故障，导致系统崩溃。当依赖项由第三方维护时，这种故障模式很常见，如果维护依赖项的第三方不再存在，则尤其常见。
• 部署失败：由部署错误导致的故障，例如当你意外部署模型旧版本而不是当前版本的二进制文件时，或者当你的系统没有读取或写入某些文件的正确权限时。
• 硬件故障：当你用于部署模型的硬件（例如 CPU 或 GPU）无法正常运行时。例如，你使用的 CPU 可能会过热并发生故障。
• 停机或崩溃：如果系统的某个组件从某个服务器（例如 AWS 或托管服务）运行，并且该服务器已关闭，则你的系统也会关闭。

某些故障并非特定于 ML，并不意味着 ML 工程师不需要了解它们。

2020 年，谷歌的两位机器学习工程师 Daniel Papasian 和 Todd Underwood 研究了谷歌大型机器学习管道发生故障的 96 起案例。他们审查了过去 15 年的数据以确定原因，发现这 96 起故障中有 60 起是由于与 ML 无直接关系的原因造成的。大多数问题与分布式系统有关，例如工作流调度程序或编排器出错，或与数据管道有关，例如来自多个来源的数据连接不正确或使用了错误的数据结构。

解决软件系统故障不需要机器学习技能，而是需要传统的软件工程技能，而解决这些技能超出了本课程的范围。由于传统软件工程技能在部署机器学习系统中的重要性，因此大部分机器学习工程都是工程，而不是 ML。对于有兴趣从软件工程角度学习如何使机器学习系统可靠的读者，我强烈推荐《可靠的机器学习》一书，该书也是由 O'Reilly 出版的，Todd Underwood 是作者之一。

软件系统故障普遍存在的一个原因是，由于机器学习在行业中的应用仍处于起步阶段，围绕机器学习生产的工具有限，最佳实践尚未得到很好的开发或标准化。然而，随着机器学习生产工具和最佳实践的成熟，有理由相信软件系统故障的比例将会下降，而机器学习特定故障的比例将会上升。

机器学习特定故障是机器学习系统特有的故障。示例包括数据收集和处理问题、较差的超参数、训练管道中的变化未在推理管道中正确复制，反之亦然、导致模型性能随时间恶化的数据分布变化、极端情况和退化反馈回路。

在本讲座中，我们将重点介绍解决机器学习特定故障。尽管它们只占故障的一小部分，但它们可能比非机器学习故障更危险，因为它们很难检测和修复，并且可能会阻止整个机器学习系统的使用。在之前的讲座中，我们介绍了数据问题、超参数调整以及训练和推理两个独立管道的危险。在本讲座中，我们将讨论部署模型后出现的三个新问题，但这些问题非常常见：数据分布变化、极端情况和退化反馈循环。

3、生产数据不同于训练数据

当我们说 ML 模型从训练数据中学习时，这意味着该模型学习训练数据的底层分布，目的是利用这种学习到的分布为没见过的数据（即训练期间未看到的数据）生成准确的预测。我们将在下面的数据分布偏移部分中深入探讨这在数学上的含义。

当模型能够为没见过的数据生成准确的预测时，我们说这个模型“推广到看不见的数据”。我们在开发过程中用来评估模型的测试数据应该代表没见过的数据，而模型在测试数据上的表现应该让我们了解模型的推广效果。

我在机器学习课程中学到的第一件事就是，训练数据和未知数据必须来自同一分布。假设未知数据来自与训练数据分布相同的平稳分布。如果未知数据来自不同的分布，模型可能无法很好地泛化。

软件系统故障普遍存在的一个原因是，由于机器学习在行业中的应用仍处于起步阶段，围绕机器学习生产的工具有限，最佳实践尚未完善或标准化。然而，随着机器学习生产工具和最佳实践的成熟，有理由相信软件系统故障的比例将会下降，而机器学习特定故障的比例将会上升。

这种假设在大多数情况下是不正确的，原因有二。

首先，现实世界数据的底层分布不太可能与训练数据的底层分布相同。整理一个能够准确表示模型在生产中会遇到的数据的训练数据集非常困难。现实世界的数据是多方面的，在许多情况下几乎是无限的，而训练数据是有限的，受到数据集创建和处理过程中可用的时间、计算和人力资源的限制。可能会发生许多不同的选择和采样偏差，并使现实世界数据与训练数据不同。这种差异可能很小，例如现实世界数据使用了不同类型的表情符号编码。这种类型的差异导致一种常见的故障模式，称为训练服务偏差（train-serving skew）：模型在开发中表现出色，但在部署时表现不佳。

其次，现实世界并不是一成不变的。事情在变化。数据分布在变化。 2019 年，当人们搜索德特里克堡时，他们可能想要获取军事信息，但自 COVID-19 以来，当人们搜索德特里克堡时，他们可能想要了解 COVID-19 的发源地。另一种常见的故障模式是模型在首次部署时表现良好，但随着数据分布的变化，其性能会随着