部署机器学习模型的后期监视

概述

部署机器学习模型后下一步是什么?
部署后的监视是任何机器学习项目中的关键步骤
学习部署模型后的监视的各个方面

介绍

你已经建立了你的机器学习模型。你甚至已经准备将你的模型投入生产(或模型部署)。很好，你应该做好一切准备来打动你的终端用户或者客户。

但是等等，作为数据科学的领导者，你在项目中的角色还没有结束。现在需要仔细监视你和你的团队创建和部署的机器学习模型。有不同的方法可以执行部署模型后的监视，我们将在本文中讨论它们。

我们首先快速回顾一下本实用机器学习系列的前三篇文章。然后，我们会理解为什么机器学习中的"auto-healing(自愈)"问题，为什么每个专业人士都应该意识到这一点。我们将深入研究两种的后期监控的方法，并了解在哪里以及如何使用它们。

快速回顾这个系列文章

在本系列文章中，到目前为止，我们已经讨论了：

协调所有主要利益相关者的方法与涉及数据驱动产品的开发和部署
将定性业务需求转换为定量技术需求的基本框架，以及跟踪进展的一致方法
端到端系统设计，使机器学习组件与解决方案的其余部分协同交互，以提供最佳的用户体验

一旦部署了最优的端到端系统，我们是否宣告胜利并继续前进?不!至少现在还没有。

在本系列的第四篇(也是最后一篇)文章中，我们将讨论在部署机器学习(ML)的最终产品之后，数据科学领导者需要计划的各种部署后的监视和维护相关方面。俗话说"登顶难，待在那里更难"，最适用于这种情况。

"自愈"中的"自"与"愈"，以及去除"自"

关于机器学习模型有一个流行且危险的错误理解，即它们会自愈(auto-heal)。自愈的定义如下:

特别地，我们期望一个机器学习模型能够持续地、自动地识别出它在哪里犯了错误，找到纠正这些错误的最佳方法，并将这些变化整合到系统中，所有这些都几乎不需要人工干预。

现实情况是，这种"自愈"充其量只是一个遥不可及的梦想。

如今，只有少数机器学习技术能够在他们试图完成一项任务时从错误中学习。这些技术通常属于强化学习(RL)的范畴。即使在RL范例中，一些模型参数也由人工专家仔细地手动调整，并定期更新。

即使在真实场景情况下我们假设我们有大量的此类产品部署,现有组织的数据架构必须完全的从面向客户的计算环境的数据流无缝流入用于构建机器学习模型的计算环境。

所以，可以肯定地说，在今天的世界里，"自"在自愈中几乎是不存在的。

现在让我们看看为什么机器学习系统首先需要"愈"。数据生态系统中有几个方面会对系统的性能产生显著的负面影响。我在下面列出了其中的一些。

域内但看不见的数据

一个典型的机器学习模型是针对大约10%的可能的数据进行训练的。这要么是因为缺乏适当标记的数据，要么是因为对大量数据进行训练具有计算限制。

机器学习模型和训练策略的选择应该提供剩余90%数据的通用性。但是在这些数据中仍然会有模型输出不正确或不太理想的数据样本。

输入数据的变化性质

在所有真实的机器学习解决方案部署中，会有一个数据科学团队几乎无法控制的输入数据的子集。这些数据数据科学团队难以控制(这主要是由于数据世界的固有复杂性造成的)。

通过基本的完整性检查，可以相对容易地检测到输入数据中的简单变化，比如从"scalar"变化"list"。但是，有许多变化难以捕捉，对机器学习系统的输出产生了极大的不利影响，不幸的是，这种变化并不罕见。

例如，考虑一个部署来自动控制服务器室空调的系统。机器学习系统显然会将环境温度作为输入之一。

可以假定温度传感器是由一个不同的生态系统控制的，该生态系统可能决定将温度单位从摄氏温度更改为华氏温度，而不必通知机器学习系统的所有者。输入的这种变化将对系统的性能产生重大影响，并且绝对不会引发运行时异常。

随着系统变得复杂，几乎不可能预先预料到所有这些可能的更改，从而对详尽的异常处理进行编码。

数据解释的变化

几乎所有行业的格局都在迅速变化。像Dunzo、Doordash和Zelle都会解释为不存在的词，现在已经成为具有重要意义的关键词。

优步(Uber)过去只与交通相关，现在也可以被解读为与食品相关。几年前还与亚马逊毫无关系的Wholefoods，如今可以影响亚马逊的财务报告。

此外，现如今，送餐服务可能主要与单身汉的生活方式联系在一起。在不久的将来，送餐服务可能会与工作中的年轻父母的生活方式联系在一起。

这些例子表明，随着新的业务模型的出现，现有的业务会进入相邻的空间，进行合并或者收纳，并且对特定活动的人工解释可能会随着时间的推移而改变。数据的这种动态性质及其解释对我们的机器学习模型有严重的影响。

机器学习系统部署在意外的环境中

人类有一种能力比今天的机器强大得多，那就是将看似不相干的信息源编织在一起，形成一个完整的上下文来解释一个数据点。

以金融科技行业为例:

如果我们知道一个金融账户是英国居民的，那么对于机器和人类专家来说，将"BP"一词解释为"Bill Payment(账单支付)"就相对容易了。但是，如果在印度，其金融交易描述中有"BP"(英国石油公司)这个词，人类专家就可以很容易地从他们所能获得的所有上下文推断出，BP在这里可能代表"Bharat Petroleum)巴拉特石油公司)"。

机器几乎很难进行这种基于上下文的切换。然而，这并不是一个特例。随着机器学习系统变得越来越主流，人们期望它们能够模仿人类的情境感知行为。

当我们继续建立系统化的方法来将上下文编入机器学习系统时，我们需要建立(半)自动化技术来监控输入和输出数据的趋势。

主动监测模型

如果我们不能"自愈"，我们能做什么?下一个最好的方法是根据一组关键指标持续跟踪机器学习模型的健康状况，并生成特定的基于事件的警报。

明显的后续问题是这些关键指标是什么以及哪些事件触发警报。这些问题由主动模型监控框架解决。

监测框架的关键要素是确定哪些输入样本与训练数据中看到的模式严重偏离，然后由人工专家仔细检查这些样本。

不幸的是，没有通用的方法来确定哪些模式是最相关的。感兴趣的模式在很大程度上取决于数据域、业务问题的性质和所使用的机器学习模型。

例如，在自然语言处理(NLP)领域，一些简单的模式可能是:

识别所有的数据样本，其中至少有一个词在训练数据中没有出现
识别训练数据中大于或小于平均单词数为n个单词或小于等于M个单词的所有数据样本

一个稍微高级一些的模式可以基于所使用的机器学习技术。例如，在NLP域中，假设使用分布式表示将每个单词放在L维空间中。

我们可以使用诸如高斯混合模型(GMM)等建模技术来量化训练数据中的单词分布。现在，给定一个测试数据样本，求出给定GMM样本的概率。所有概率低于某一阈值的数据样本都可以标记为"非代表性"从而将其发送给领域专家进行进一步的调查。

甚至可以根据业务问题的知识、数据的细节或所使用的机器学习机制的细节设计更复杂的模式来识别感兴趣的测试样本。

例如，任何机器学习解决方案都可以看作是多个ML基本组件的组合。例如，在对话代理中用于意图挖掘的机器学习模型可能包含三个ML模块:

对原始语音输入进行音频分析以识别句子类型的模块。例如：陈述句，疑问句，感叹号或命令
用于对转录的语音输入进行文本分析以识别语义消息的模块
将以上两个模块的输出组合起来以识别意图的模块

在训练阶段，我们可以通过这三个模块来识别不同训练样本走过的路径的相对比例以及相应的预测输出。

在模型监控阶段，我们可以识别导致特定输出的样本，例如找到训练数据中从没有出现过的某些情况。

注意，要实现这种级别的基于模式的模型监视，端到端解决方案需要有一个健壮的日志记录机制。

被动式监测模型

在成功部署了一个机器学习驱动的解决方案之后，数据科学团队几乎总是觉得他们终于能吹嘘了，比如"我们的系统拥有最高99%的精确度!"

但是本能地(也是正确地)，面对客户的团队会问的第一件事是"解决1%的计划是什么?"

这需要执行根源原因分析(root-cause-analysis RCA)的被动式模型监控，并提供对何时修复bug的估计。

被动式模型监视与主动式模型监视非常相似。但是在最终目标方面有细微的差别。

主动式模型维护识别测试数据中的一般模式，这些模式与训练数据中的模式相比是异常值，而被动式模型维护的目标是识别特定测试样本中导致错误输出的原因以及如何纠正错误。

因此，数据科学团队在接受被动式模型维护过程所建议的纠正时需要谨慎，因为这些建议可能会对大范围的数据样本有害。

被动式模型维护的其他一些具有挑战性的方面是，一些bug可以通过一个配置文件中的简单更改来解决，而有些则可能需要对ML模型进行详细的重新训练。另外，一些bug可能在典型用户的容忍范围内，而另一些bug我称之为"渴望公开"的bug。

一个"渴望公开"的错误是机器学习系统的完全出乎人类专家的意料的错误行为。

例如，在一个基于ml的对话代理中，当用户询问"我累了"时，如果代理回答"你好，累先生，你好吗?"，那肯定会得到很多推特的转发或者类似的宣传!这些渴望曝光的bug需要立即解决。

因此，服务水平协议(Service Level agreement, sla)将需要仔细制定，一方面要考虑到问题的严重性，另一方面要考虑到需要进行的系统更改。

解决根本原因，而不是表面症状

鉴于各种各样的资源的变化可能会导致ML系统的性能随着时间的流逝而下降，并且需要在给定的SLA中解决该问题的巨大压力，可能会有一个“薄薄的规则层”来绕过ML层来解决客户需要的模型升级，这很诱人。

这种薄层或热修复方法实际上是一种"惰性修复"，从长远来看有可能变成灾难性的。因此，只有在极端情况下才能选择添加一层薄薄的规则，而且不允许超过一定的"厚度"。

当达到预先定义的"厚度"时，我们的机器学习模型必须重新训练，以解决在薄层中编码的问题。

借用医学领域的一个类比:处理症状可能不需要专家，但是如果直接代替所有专家的诊断，则情况可能会非常严重。

正如准确的医疗诊断来自于对患者历史的分析一样，主动式模型的维护必须足够广泛，以快速地帮助识别客户需要升级的根本原因。

对已经部署在实际生产环境中的机器学习模型进行再训练，说起来容易做起来难。首先，有多种方法可以解决特定的数据驱动问题，尤其当我们看到更多的数据时，我们对模型的选择甚至可能会改变。

其次，构建原始模型的数据科学团队和维护模型的团队可能无法就重新训练模型的最佳方式达成一致。此外，构建原始模型的团队在确定一种训练策略/建模技术之前，可能已经尝试过各种各样的训练策略/建模技术。

这些信息通常没有文档记录，因此模型再训练很可能导致精度的下降。

更糟糕的是，很多时候，终端客户可能更喜欢接收一致的输出，而不是现在正确但以前不正确的输出。例如:

假设你最初的语音识别系统80%的时候会把"Tim"和"Jim"混淆。最终客户估计了这种错误的频率，并在他们的下游处理中包含了相应的机制来尝试"Tim"和"Jim"，比例为80:20。

突然之间，当重新训练的语音识别系统将Tim/Jim的混淆降低到10%时，最终客户可能不愿意对他们的终端进行必要的(可能不重要的)更改。在这种情况下，业务团队和面向客户的团队可能会做出这样的决定:某些客户将继续使用旧的语音识别系统，而其他客户将迁移到新的系统。

这意味着数据科学团队现在必须维护两个模型!这开启了一个全新的讨论领域，叫做"机器学习模型欠下的技术债"。一致性胜过了准确性。

结果是"保持一致!"这句话对于ML模型和人类来说都是很好的激励语!这是一个我想要更多讨论的领域，但不在本系列中讨论。

名字有什么关系!

最后，人们普遍认为"模型维护"和"模型监控"听起来"不酷"，而"模型构建"听起来很"酷"。

相比之下，我所看到的是，"模型维护"所需要的数据科学成熟度、大数据工程深度和业务理解的程度，比"模型构建"所需要的要高一个数量级。

我总是倾向于将"模型维护"重新定义为"模型训练"，特别是考虑到维护和监控在确保客户满意方面所起的关键作用。

结尾

如果你身处科技行业，你肯定会注意到人工智能、机器学习、数据科学以及相关的技术词语。我真诚地相信，所有这些对数据驱动技术的关注将有助于提高现有流程的效率，并帮助征服长期以来难以捉摸的新技术前沿。

然而，对这些技术的普遍期望是危险的、不切实际的，这主要是由科幻文学的流行想象造成的。我们在一些低风险的消费者人工智能应用程序中看到的东西，也在一定程度上证实了这一点。

当执行决策者为他们的数据科学团队设置这样的期望时，他们无意中忽略了两个重要的因素:

数据科学不能孤立地产生影响，整个组织必须被训练成一种"数据文化"，当然这说起来容易做起来难
多年来，数据专家们一直在努力开发消费者人工智能应用程序，这些应用程序近来在媒体中越来越受欢迎。这种期望与实际情况之间的不匹配，让我们离所谓的"人工智能冬天"更近了一步。

我确信，数据驱动技术是解决当今科技界面临的大多数问题的最佳解决方案。但是，与此同时，为了让这些技术取得成功，我们需要一个有正确预期的整体方法。

通过这四篇系列文章，我希望分享我在"数据驱动解决方案的原型"和"部署在具有严格sla的现实世界中的实际数据驱动解决方案"之间的差距方面的经验。我希望当你进行你的数据驱动之旅时，你会发现这些知识是有价值的。