🔎大家好，我是Sonhhxg_柒，希望你看完之后，能对你有所帮助，不足请指正！共同学习交流🔎
📝个人主页－Sonhhxg_柒的博客_CSDN博客 📃
🎁欢迎各位→点赞👍 + 收藏⭐️ + 留言📝
📣系列专栏 - 机器学习【ML】 自然语言处理【NLP】 深度学习【DL】
🖍foreword
✔说明⇢本人讲解主要包括Python、机器学习（ML）、深度学习（DL）、自然语言处理（NLP）等内容。
如果你对这个系列感兴趣的话，可以关注订阅哟👋
文章目录
一次一个模型被部署后，它的性能应该像任何其他软件系统一样被监控。正如他们在“测试您的 ML 代码”中所做的那样，常规软件最佳实践适用。就像在“测试您的 ML 代码”中一样，在处理 ML 模型时还需要考虑其他事项。
在本章中，我们将描述监控 ML 模型时要牢记的关键方面。更具体地说，我们将回答三个问题：
-
为什么我们应该监控我们的模型？
-
我们如何监控我们的模型？
-
我们的监控应该采取什么行动？
让我们首先介绍监控模型如何帮助决定何时部署新版本或在生产中发现问题。
监测拯救生命
这监控的目标是跟踪系统的健康状况。对于模型，这意味着监控它们的性能和预测质量。
如果用户习惯的改变突然导致模型产生低于标准的结果，一个好的监控系统会让你注意到并尽快做出反应。让我们介绍一些监控可以帮助我们发现的关键问题。
监控以通知刷新率
我们在“新鲜度和分布转移”中看到，大多数模型需要定期更新以保持给定的性能水平。监控可用于检测模型何时不再新鲜且需要重新训练。
例如，假设我们使用从用户那里获得的隐式反馈（例如，他们是否点击推荐）来估计模型的准确性。如果我们持续监控模型的准确性，我们可以在准确性低于定义的阈值时立即训练新模型。图 11-1显示了此过程的时间线，当准确度低于阈值时会发生重新训练事件。
图 11-1。监控触发重新部署
在重新部署更新后的模型之前，我们需要验证新模型是否更好。我们将在本节“ML 的 CI/CD”中介绍如何执行此操作。首先，让我们处理其他需要监控的方面，例如潜在的滥用行为。
监视以检测滥用
在某些情况下，例如建立滥用预防措施或在欺诈检测系统中，一小部分用户正在积极努力打败模型。在这些情况下，监控成为检测攻击和估计攻击成功率的关键方法。
监控系统可以使用异常检测以检测攻击。例如，在跟踪每次登录银行在线门户的尝试时，如果登录尝试次数突然增加十倍，则监控系统会发出警报，这可能是攻击的迹象。
如图 11-2 所示，这种监控可以根据超过的阈值发出警报，或者包括更细微的指标，例如登录尝试的增长率。根据攻击的复杂性，建立一个模型来检测比简单阈值更细微的异常可能很有价值。
图 11-2。监控仪表板上的明显异常。您可以构建一个额外的 ML 模型来自动检测它。
除了监控新鲜度和检测异常，我们还应该监控哪些其他指标？
选择要监控的内容
软件应用通常监控指标，例如处理请求所需的平均时间、处理失败的请求比例以及可用资源量。这些对于跟踪任何生产服务很有用，并允许在太多用户受到影响之前进行主动修复。
接下来，我们将介绍更多要监控的指标，以检测模型的性能何时开始下降。
性能指标
一个如果数据分布开始发生变化，模型可能会变得陈旧。您可以在图 11-3中看到这一点。
图 11-3。特征分布的漂移示例
当涉及到分布变化时，数据的输入和输出分布都会发生变化。考虑一个模型的例子，它试图猜测用户接下来会看哪部电影。给定与输入相同的用户历史记录，模型的预测应根据可用电影目录中的新条目进行更改。
-
监控输入分布可以很简单作为监控汇总统计数据，例如关键特征的均值和方差，并在这些统计数据偏离训练数据中的值超过给定阈值时发出警报。
-
监测分布变化可能更具挑战性。第一种方法是监控模型输出的分布。与输入类似，输出分布的显着变化可能是模型性能下降的迹象。然而，用户希望看到的结果分布可能更难估计。
很难估计基本事实的原因之一是模型的行为通常会阻止我们观察它。要了解为什么会出现这种情况，请考虑以下示例信用卡欺诈检测模型如图 11-4 所示。模型将接收的数据分布在左侧。当模型对数据进行预测时，应用程序代码通过阻止任何预测为欺诈的交易来对这些预测进行操作。
一旦交易被阻止，我们就无法观察如果我们让它通过会发生什么。这意味着我们无法知道被阻止的交易是否真的是欺诈性的。我们只能观察和标记我们允许通过的交易。由于对模型的预测采取了行动，我们只能观察到非阻塞事务的偏斜分布，如右侧所示。
图 11-4。根据模型的预测采取行动可能会使观察到的数据分布产生偏差
只能访问真实分布的偏斜样本使得无法正确评估模型的性能。这个是反事实评估的重点，旨在评估如果我们没有对模型采取行动会发生什么。要在实践中执行此类评估，您可以不在一小部分示例上运行模型（请参阅 Lihong Li 等人的文章“搜索引擎点击指标的反事实估计和优化”）。不对示例的随机子集采取行动将使我们能够观察到欺诈交易的公正分布。通过将模型预测与随机数据的真实结果进行比较，我们可以开始估计模型的精度和召回率。
这种方法提供了一种评估模型的方法，但代价是让一部分欺诈交易得以通过。在许多情况下，这种权衡可能是有利的，因为它允许进行模型基准测试和比较。在某些情况下，例如在不能接受输出随机预测的医学领域，不应使用这种方法。
在“ML 的 CI/CD”中，我们将介绍其他策略来比较模型并决定部署哪些模型，但首先，让我们介绍要跟踪的其他关键指标类型。
业务指标
作为我们在本书中已经看到，最重要的指标是与产品和业务目标相关的指标。它们是我们判断模型性能的标准。如果所有其他指标都是绿色的，并且生产系统的其余部分表现良好，但用户不点击搜索结果或使用推荐，那么根据定义，产品是失败的。
为了因此，应密切监控产品指标。为了在搜索或推荐系统等系统中，这种监控可以跟踪点击率，即看过模型推荐的人点击它的比率。
某些应用程序可能会受益于对产品的修改以更轻松地跟踪产品成功，类似于我们在“征求反馈”中看到的反馈示例。我们讨论过添加分享按钮，但我们可以在更精细的级别跟踪反馈。如果我们可以让用户点击推荐以实施它们，我们就可以跟踪每个推荐是否被使用，并使用这些数据来训练新版本的模型。图 11-5显示了左侧聚合方法与右侧粒度方法之间的图示比较。
图 11-5。提出词级建议，让我们有更多机会收集用户反馈
由于我不希望 ML Editor 原型的使用频率足以使所描述的方法提供足够大的数据集，因此我们将放弃在此处构建它。如果我们正在构建我们打算维护的产品，收集此类数据将使我们能够获得有关用户认为最有用的建议的精确反馈。
机器学习的 CI/CD
CI/CD 支架用于持续集成 (CI) 和持续交付 (CD)。粗略地说，CI 是让多个开发人员定期将他们的代码合并回中央代码库的过程，而 CD 则侧重于提高新版本软件发布的速度。采用 CI/CD 实践允许个人和组织快速迭代和改进应用程序，无论他们是发布新功能还是修复现有错误。
因此，ML 的 CI/CD 旨在使部署新模型或更新现有模型变得更加容易。快速发布更新很容易；挑战在于保证其质量。
在 ML 方面，我们发现拥有一个测试套件不足以保证新模型比以前的模型有所改进。训练一个新模型并测试它在保留数据上的表现是好的第一步，但最终，正如我们之前看到的，没有什么可以替代现场表现来判断模型的质量。
前在向用户部署模型时，团队通常会以 Schelter 等人在他们的论文“机器学习模型管理中的挑战”中称为影子模式的方式部署它们。这是指与现有模型并行部署新模型的过程。运行推理时，会计算并存储两个模型的预测，但应用程序仅使用现有模型的预测。
通过记录新的预测值并将其与旧版本和可用的基本事实进行比较，工程师可以在不改变用户体验的情况下估计新模型在生产环境中的性能。这种方法还允许测试为可能比现有模型更复杂的新模型运行推理所需的基础设施。影子模式唯一没有提供的是观察用户对新模型的反应的能力。唯一的方法就是实际部署它。
一旦模型经过测试，它就是部署的候选对象。部署新模型伴随着使用户面临性能下降的风险。降低这种风险需要谨慎，这也是实验领域的重点。
图 11-6显示了我们在此介绍的三种方法中每一种的可视化，从最安全的评估测试集模式的方法到信息量最大但最危险的在生产环境中部署模型的方法。请注意，虽然影子模式确实需要工程努力才能为每个推理步骤运行两个模型，但它允许模型的评估几乎与使用测试集一样安全，并提供几乎与运行它一样多的信息在生产中。
图 11-6。评估模型的方法，从最安全和最不准确到风险最大和最准确
由于在生产中部署模型可能是一个有风险的过程，因此工程团队开发了增量部署更改的方法，首先仅向一部分用户显示新结果。接下来我们将介绍这个。
A/B 测试和实验
在 ML 中，目标实验的目的是最大化使用最佳模型的机会，同时最小化尝试次优模型的成本。有许多实验方法，最流行的是 A/B 测试。
A/B 测试背后的原理很简单：将用户样本暴露给新模型，然后将其余用户暴露给另一个模型。这通常是通过让更大的“控制”组为当前模型提供服务，为更小的“治疗”组提供我们想要测试的新版本来实现的。一旦我们进行了足够长的时间的实验，我们就会比较两组的结果并选择更好的模型。
在图 11-7中，您可以看到如何从总人口中随机抽样用户以将他们分配到测试集。在推理时，用于给定用户的模型由分配给他们的组决定。
A/B 测试背后的想法很简单，但实验设计所关注的问题，例如选择对照组和治疗组、决定多少时间是足够的以及评估哪种模型表现更好，都是具有挑战性的问题。
图 11-7。A/B 测试示例
此外，A/B 测试需要构建额外的基础设施，以支持为不同用户提供不同模型的能力。让我们更详细地介绍这些挑战中的每一个。
选择组和持续时间
决定应该为哪些用户提供哪种模型有一些要求。两组中的用户应尽可能相似，以便观察到的任何结果差异都可以归因于我们的模型，而不是同类群组的差异。如果 A 组中的所有用户都是超级用户，而 B 组仅包含偶尔使用的用户，则实验结果将不是决定性的。
此外，治疗组 B 应足够大以得出具有统计学意义的结论，但应尽可能小以限制接触可能更差的模型。测试的持续时间呈现出类似的权衡：太短，我们有没有足够信息的风险，太长，我们有失去用户的风险。
这两个约束已经足够具有挑战性了，但请考虑一下拥有数百名数据科学家的大公司的情况，他们并行运行数十个 A/B 测试。多个 A/B 测试可能同时测试管道的同一方面，这使得准确确定单个测试的效果变得更加困难。当公司达到这种规模时，这会导致他们构建实验平台来处理复杂性。请参阅 Jonathan Parks 的文章“Scaling Airbnb's Experimentation Platform”中所述的 Airbnb 的 ERF ；A. Deb 等人的帖子“Under the Hood of Uber's Experimentation Platform”中描述的 Uber XP ；或 Intuit 的开源Wasabi的 GitHub 存储库。
估计更好的变体
大多数 A/B 测试选择一个他们希望在组之间进行比较的指标，例如点击率。不幸的是，估计哪个版本表现更好比选择具有最高点击率的组更复杂。
由于我们预计任何指标结果都会存在自然波动，因此我们首先需要确定结果是否具有统计显着性。由于我们要估计两个总体之间的差异，因此最常用的检验是双样本假设检验。
为了使实验具有决定性，它需要在足够数量的数据上运行。确切的数量取决于我们正在测量的变量的值和我们旨在检测的变化的规模。有关实际示例，请参阅 Evan Miller 的样本量计算器。
在运行实验之前决定每个组的大小和实验的长度也很重要。如果您在 A/B 测试正在进行时继续测试重要性，并在看到重要结果后立即宣布测试成功，那么您将犯重复的重要性测试错误。这种错误包括通过投机取巧地寻找显着性而严重高估实验的显着性（再一次，Evan Miller 在这里有一个很好的解释）。
笔记
虽然大多数实验侧重于比较单个指标的价值，但考虑其他影响也很重要。如果平均点击率增加但停止使用该产品的用户数量翻倍，我们可能不应该认为模型更好。
同样，A/B 测试的结果应该考虑到不同用户群的结果。如果平均点击率增加但给定细分的点击率直线下降，则最好不要部署新模型。
实施实验需要能够将用户分配到一个组，跟踪每个用户的分配，并根据它呈现不同的结果。这需要构建额外的基础设施，我们将在接下来介绍。
建设基础设施
实验还伴随着基础设施要求。运行 A/B 测试的最简单方法是将每个用户的关联组与其余用户相关信息一起存储，例如在数据库中。
然后，应用程序可以依靠分支逻辑来决定根据给定字段的值运行哪个模型。这种简单的方法适用于用户已登录的系统，但如果注销用户可以访问模型，则该方法会变得更加困难。
这是因为实验通常假设每个组都是独立的并且只暴露于一个变体。当为注销用户提供模型时，很难保证给定用户在每个会话中始终提供相同的变体。如果大多数用户接触到多个变体，这可能会使实验结果无效。
其他用于识别用户的信息（例如浏览器 cookie 和 IP 地址）可用于识别用户。然而，这种方法再次需要构建新的基础架构，这对于资源受限的小型团队来说可能很难。
其他方法
A/B 测试是一种流行的实验方法，但还有其他方法试图解决 A/B 测试的一些局限性。
Multiarmed bandits 是一种更灵活的方法，可以连续测试变体和两个以上的备选方案。他们根据每个选项的执行情况动态更新要服务的模型。我已经在图 11-8中说明了多臂老虎机是如何工作的。Bandits 根据他们路由的每个请求的成功情况不断记录每个备选方案的执行情况。大多数请求只是简单地路由到当前最佳替代方案，如左图所示。一小部分请求被路由到一个随机的替代方案，如您在右侧所见。这允许 bandits 更新他们对哪个模型是最好的估计，并检测当前未服务的模型是否开始表现更好。
图 11-8。实践中的多臂强盗
Contextual multiarmed bandits 通过学习哪种模型对每个特定用户来说是更好的选择，将这个过程更进一步。
笔记
虽然本节涵盖了使用实验来验证模型，但公司越来越多地使用实验方法来验证他们对其应用程序所做的任何重大更改。这使他们能够持续评估用户认为哪些功能有用以及新功能的性能如何。
由于实验是一个艰难且容易出错的过程，多家初创公司已开始提供“优化服务”，允许客户将他们的应用程序与托管实验平台集成，以确定哪些变体表现最佳。对于没有专门实验团队的组织，此类解决方案可能是测试新模型版本的最简单方法。
结论
总的来说，部署和监控模型仍然是一种相对较新的做法。这是验证模型是否正在产生价值的关键方法，但通常需要在基础设施工作和仔细的产品设计方面做出重大努力。
随着该领域开始成熟，诸如Optimizely之类的实验平台应运而生，使其中的一些工作变得更加容易。理想情况下，这应该使 ML 应用程序的构建者能够为每个人不断改进它们。
回顾描述的所有系统，只有一小部分旨在训练模型。构建 ML 产品所涉及的大部分工作包括数据和工程工作。尽管如此，我指导过的大多数数据科学家发现更容易找到涵盖建模技术的资源，因此感觉没有准备好处理这个领域之外的工作。这本书是我试图帮助弥合这一差距的尝试。
835
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
