研究人员和学者们倾向于关注机器学习模型的数学质量。在机器学习运维中,我们可以在一组不同的问题中找到价值,这些问题将帮助我们了解模型和系统可能出错的地方,当它们发生时如何修复问题,以及我们如何预防性地设计长期系统健康状况:
训练数据来自何处?
这个问题是指概念上的,即我们需要充分了解训练数据的来源以及它应该代表什么。如果我们在寻找垃圾邮件,我们是否能获得路由信息,以及它是否能被不良分子操纵?如果我们正在模拟用户与纱线产品的互动,那么它们是以什么顺序显示的,以及用户是如何在页面上移动的?我们不能访问哪些重要的信息,原因是什么?围绕着数据访问或存储,是否有任何我们需要考虑的政策因素,特别是围绕隐私、道德或者法律或监管限制?
数据存储在哪里以及如何验证?
这是前一个问题在字面意思上的扩展。数据是存储在一个大的平面文件中,还是在一个数据中心内共享?什么访问模式是最常见或最有效的?是否有任何聚合或抽样策略可以降低成本,但会丢失信息?隐私方面的考虑是如何实施的?一个给定的数据要存储多长时间,如果用户希望从系统中删除他们的数据会发生什么?我们如何知道存储的数据没有被破坏,馈送的数据没有不完整,以及我们可以应用哪些明智的检查和验证?
有哪些特征以及它们是如何计算的?
特征是我们从原始数据中提取的信息,以便于机器学习模型的消化,通常由模型开发者以“越多越好”的方式添加。从操作的角度来看,我们需要保持对每个单独的特征的完整理解,它是如何计算的,以及如何验证结果。这很重要,因为特征计算层面的错误可以说是系统层面问题的最常见来源。同时,这些往往是最难被传统的机器学习验证策略检测到的——一个保留验证集可能会被同一个特征计算的错误所影响。如前所述,最隐蔽的是当特征在训练时由一个代码路径计算(例如,为了优化内存效率)而在服务(实际部署)时由另一个代码路径计算(例如,为了优化延迟)时所发生的问题。在这种情况下,模型的预测可能出现问题,但我们可能没有真实的验证数据来检测。
该模型在哪种样本上表现得最差?
几乎所有的机器学习模型都是不完美的,至少在某些种类的样本上,它们的预测会出错。重要的是,要花时间查看我们的模型出错的数据,了解任何共性或趋势,这样就可以确定这些故障模式是否会以某种关键的方式影响下游用例。这往往涉及一些人工的努力,除了更高层次的总结之外,还要有实际的人去看实际的数据来充分了解它。
该模型怎样随着时间更新?
有些模型很少更新,比如自动翻译的模型,它是在大量的数据上训练出来的,隔几个月推送给设备上的应用一次。另一些模型则更新得非常频繁,例如垃圾电子邮件过滤器模型,由于垃圾邮件发送者不断发展并开发新的技巧以试图避免被发现,该模型必须不断保持更新。然而,我们有理由认为,所有模型最终都需要更新,我们将需要有适当的结构,以确保在任何新版本的模型上线之前都存在一整套的验证检查。我们还需要与组织中的模型开发人员就谁对模型性能做出判断,以及如何处理预测准确性方面的问题达成明确的协议。
我们的系统如何在更大的环境中发挥作用?
我们的机器学习系统很重要,但就像许多复杂的数据处理系统一样,它们通常只是一个更大的整体系统、服务或应用程序的一部分。我们必须对自己的机器学习系统如何融入大局有足够的理解,以防止问题的发生,并在问题发生时诊断出原因。我们需要知道为模型提供数据的全套上游依赖关系,包括在训练期间和服务期间,并知道它们如何变化或失败,以及如果发生这种情况,我们如何被提醒。同样,我们需要知道模型预测的所有下游消费者,以便在模型出现问题时可以适当地提醒他们。我们还需要知道模型的预测如何影响最终用例,模型是否属于任何反馈循环(直接或间接)的一部分,以及是否存在任何循环依赖关系,如一天中的时间、一周中的某一天或一年中的某一天的影响。最后,我们需要知道,在更大的系统范围内,像准确性、新鲜度和预测延迟这样的模型质量有多重要,这样就可以确保这些系统级的要求得到很好的确立,并且随着时间的推移继续被我们的机器学习系统满足。
可能发生的最坏情况是什么?
也许最重要的是,如果机器学习模型失败了,或者如果它针对一个给定输入给出了最坏的预测,我们需要知道整个系统会发生什么。这种知识可以帮助我们定义防护措施、回退策略或其他安全机制。例如,可以想象,一个股票价格预测模型可能会导致对冲基金在几毫秒内破产 [3] ,除非有特定的防护措施来限制某些类型的购买行为或金额。