A Data Quality-Driven View of MLOps

作者：微软研究中心
发表时间：2021.02.15
摘要：开发机器学习模型可以看作是一个类似于为传统软件开发而建立的过程。两者之间的关键区别在于机器学习模型的质量与用于训练或执行评估的数据质量之间的强依赖性。

在这项论文中，我们演示了数据质量的不同方面如何在机器学习开发的各个阶段传播。通过对已知数据质量维度和下游机器学习过程的影响进行联合分析，我们表明可以有效设计典型MLOps管道的不同组件，提供了技术和理论视角。

介绍：
机器学习（ML）模型是根据数据“编译”的软件工件。与传统软件相比，这种观点激发了对相似性和差异性的研究。与传统的软件工件类似，在生产中部署的ML模型不可避免地要经历DevOps过程，该过程的目的是“缩短系统开发生命周期并提供高质量的连续交付”。

当此DevOps过程专门应用于ML时，使用术语“MLOps”。与传统的软件工件不同，ML模型的质量（如准确性、公平性和鲁棒性）通常反映了基础数据的质量，如噪声、不平衡和额外的对抗性干扰。

因此，提高ML模型的准确性、公平性和鲁棒性的最有希望的方法之一通常是通过数据清洗、集成和标签获取等手段改进数据集。由于MLOps旨在理解、测量和改进ML模型的质量，因此数据质量在MLOps中扮演着重要的核心角色也就不足为奇了。事实上，许多研究人员通过研究数据质量的不同方面，围绕MLOps开展了引人入胜的开创性工作。在监督不力的数据采集、ML工程管道、数据清洗、数据质量验证、交互、或细粒度监测和改进等领域。

同时，几十年来，数据质量一直是数据管理界领导的一个活跃而令人兴奋的研究领域，考虑到大多数研究都与下游ML模型无关（最近有一些突出的例外。研究人员研究了数据质量独立于下游ML模型的不同方面，可以分为以下四个维度：
（1）准确性–数据对于手头的任务来说是正确、可靠和合格的程度；
（2）完整性–给定数据集合包含描述相应真实世界对象集的数据的程度；
（3）一致性–违反一组数据定义的语义规则的程度；
（4）及时性（也称为现时性或波动性）–任务数据的最新程度。

经验和看法
在本文中，我们对我们以前的一些工作进行了俯瞰，这些工作与实现MLOps的不同功能有关。这些作品的灵感来自我们与学术和工业用户携手构建ML应用程序的经验，以及我们构建ease.ml的努力，一个定义端到端MLOps过程的原型系统。

我们的主要观察结果是，MLOps挑战往往必然伴随着数据管理挑战-鉴于前面提到的ML模型质量和数据质量之间的强烈依赖性，理解、测量和改进ML模型质量的永无止境的追求往往取决于理解、测量并改进底层数据质量问题。从技术角度来看，这带来了独特的挑战和机遇。正如我们将看到的，我们发现有必要重新审视几十年来对下游ML模型不可知的数据质量研究，并尝试与下游ML过程一起理解不同的数据质量维度——准确性、完整性、一致性和及时性。

在本文中，我们描述了四个这样的例子，它们来自我们之前的研究。表1总结了这些示例，每个示例都解决了MLOps中的一个特定问题，并提出了联合分析数据质量和下游ML过程的技术挑战。

在第2节中，我们提供了研究该主题的设置，强调了考虑潜在概率分布的重要性。在第3-6节中，我们重新讨论了ease.ml不同阶段的组件。系统完全从数据质量的角度出发。由于本文的性质，我们避免讨论这些组件之间的交互细节或它们的技术细节。最后，在第7节中，我们描述了所有组件共享的一个共同限制，并激发了该领域有趣的未来工作。

概念飘移：到目前为止所描述的ML的总体思想假设概率分布P（X，Y）随时间保持固定，这在实践中有时并非如此。随着时间的推移，分布的任何变化都被称为概念漂移。此外，通常假设特征空间X和标签空间Y在分布变化期间保持相同，这在实践中也可能是错误的。X或p（X）（在Y上的边缘分布）的变化通常被称为数据漂移，这可能导致训练或评估模型时丢失值。我们将在第3节中讨论这一特定方面。当p（X）的变化改变了p（Y|X）时，这称为真实漂移或模型漂移，而当p（Y | X）保持不变时，则是虚拟漂移。幸运的是，虚拟漂移对训练的ML模型几乎没有影响，假设一个模型成功地近似了整个特征空间X上的后验概率分布。

MLOps任务1：有效的ML质量优化

MLOps中的一个关键操作是寻求提高模型质量（例如精度）的方法。除了尝试新的架构和模型外，改善训练数据的质量和数量至少也同样重要。在许多其他方法中，数据清洗，即固定或移除噪声和脏样本的实践，一直是提高数据质量的著名策略。

MLOps挑战当涉及到MLOps时，一个挑战是并非所有噪声或脏样本对最终ML模型的质量都同等重要。换句话说，当通过ML训练过程“传播”时，不同输入样本的噪声和不确定性可能产生截然不同的影响。因此，简单地随机或与ML训练过程无关地清除输入样本可能会导致下游ML模型的次优改进。由于清洗任务本身通常由人工标注员在自动工具的指导下“半自动”执行，因此从MLOps的角度来看，成功的清洗策略的目标应该是最小化人工的工作量。这通常会导致部分清理数据集，清理额外的训练样本不会影响训练模型的结果（即，保持验证集上的预测和准确性）

数据质量视图 上述挑战的原则解决方案，需要联合分析训练集中不完整和有噪声的数据对在此类集合上训练的ML模型质量的影响。受这些启发，我们引入了一个称为CPClean的原则性框架，该框架对此类噪声传播过程进行建模和分析，以及基于顺序信息最大化的原则性清理算法。

我们的方法 用CPClean清理。**CPClean直接建模噪声传播-噪声和不完全性引入了多个可能的数据集，在关系数据库理论中称为可能世界，这些噪声对最终ML训练的影响只是训练多个ML模型的熵，每个可能世界有一个。直观地说，熵越小，输入噪声对下游ML训练过程的影响就越小。在这之后，我们首先启动所有可能的世界（即清洗后的训练数据的可能版本），通过对缺失的特征值独立应用多个完善的清理规则和算法。然后，CPClean进行多次迭代。在每一轮中，该框架建议训练数据进行清洗，以最小化部分清洗数据集上可能世界的条件熵。一旦一个训练数据样本被清洗，它将在所有可能的世界中被其清洗版本所取代。

其核心是使用序列信息最大化算法，在理论保证的情况下找到近似解（该NP难问题）。计算这样的熵通常很困难，而在CPClean中，我们提供了有效的算法，可以在多项式时间内计算特定分类器家族的这一项，即k-最近邻分类器（KNN）。

使用某些预测对不完整数据进行学习的这一概念受到了不完整数据上某些答案研究的启发。简言之，后者通过列举所有可能世界的结果来解释给定输入（由查询和不完整数据集组成）答案的确定性或一致性。将这种数据不完整性的观点扩展到非关系运算符（如ML模型）是一项自然但不平凡的工作，图1说明了这种联系。

局限性 将下游ML模型纳入人类清洁工作优先级并不新鲜。ActiveClean建议使用关于固定模型梯度的信息来解决此任务。或者，我们的框架依赖于一致的预测，因此，它适用于未标记的验证集和不可微的ML模型。我们使用kNN作为任意分类器的代理，考虑到它的高效实现，尽管可能存在成倍多的世界。然而，如何将这个原则框架扩展到其他类型的分类器还有待观察。此外，将这两种方法结合起来并为通用ML模型支持一种省力的清洁方法仍然是一个开放的研究问题。

MLOps任务2:防止不切实际的期望

在DevOps实践中，新项目通常通过可行性研究启动，以评估和理解成功的概率。这样一项研究的目标是防止有不切实际期望的用户花费大量金钱和时间开发注定失败的解决方案。然而，当涉及到MLOps实践时，这种可行性研究步骤在很大程度上是缺失的-我们经常看到用户期望很高，但数据集非常嘈杂，开始了一个昂贵的培训过程，几乎肯定会失败。

MLOps挑战 建模ML可行性研究问题的一种原则方法是询问：给定一个由训练集和验证集定义的ML任务，如何在不运行昂贵的ML训练的情况下估计最佳可能的ML模型可以实现的误差？这个问题的答案与传统的最大似然问题有关，即估计贝叶斯错误率（也称为不可约错误）(Bayes Error Rate) BER。这是一个与底层数据分布相关的量，使用有限的数据量估计它是一个众所周知的难题。尽管进行了几十年的研究，但提供实用的BER估计器仍然是一个开放的研究问题，并且没有已知的实用系统能够在真实世界的大规模数据集上工作。使可行性研究成为实际的MLOps步骤的一个关键挑战是了解如何利用数十年来关于BER估计的理论研究，以及如何进行折衷和优化

非零Bayes误差和数据质量问题 乍一看，，即使理解为什么每个任务的BER都不是零，也可能是相当神秘的-如果我们有足够的数据量和强大的ML模型，什么会阻止我们达到完美的精度？对此的答案与数据质量密切相关。
有两个经典的数据质量维度构成了误码率非零的原因：（1）数据的完整性，因特征空间或标签空间的定义不足而受到破坏；（2）数据的准确性，反映在噪声标签的数量上。在纯数学层面上，误码率不为零的原因在于，给定可实现的输入特征，不同类别的后验概率重叠。更直观地，对于给定的样本，标签可能不是唯一的。在图2中，我们展示了来自ImageNet验证集的一些真实示例。例如，图2a被标记为高尔夫球场，而车辆属于另一类别的概率为非零，例如拖拉机-附加功能可以通过提供更多信息来解决此类问题，从而产生单个可能的标签。

或者，对于给定的图像，实际上可能有多个“真”标签。图2b显示了这样一个示例，其中rooster类的后验值等于Piockok类的后验值，尽管在数据集中仅标记为rooster–将任务更改为多标签问题将解决此问题。最后，在验证集中有噪声标签产生了非零误码率的另一个充分条件。图2c显示了这样一个示例，其中馅饼被错误地标记为比萨饼。

数据质量观 在为ML模型构建实用BER估计器以表征数据质量对下游ML模型的影响方面存在两个主要挑战：（1）计算要求，（2）超参数的选择。必须在当今的高维特征空间中估计BER需要大量数据，以便在精度方面给出合理的估计，这导致了较高的计算成本。此外，任何实际估计器都应该对不同的超参数不敏感，因为在进行可行性研究之前，不知道有关数据或其潜在分布的信息。

我们的方法：ease.ml/snoopy 我们设计了一种新的BER估计方法，该方法（1）基于非参数的最近邻估计，无需调整超参数；以及（2）使用来自公共来源（如PyTorch Hub或Tensorflow Hub）的预训练嵌入，以显著降低特征空间的维数。上述使用ease进行可行性研究的功能。ml/snoopy如上图所示。有关更多详细信息，我们请感兴趣的读者参阅完整论文和该组件的演示论文。这种新方法的有用性和实用性通过一种新的评估方法在经过充分研究的标准ML基准上进行评估，该方法注入了不同数量的标签噪声，并遵循BER的演变。它依赖于我们的理论工作，在理论工作中，我们进一步深入解释了kNN在（可能是预训练的）特征变换上的行为，展示了BER增加和变换可以产生的收敛速度提升之间的明确权衡。

限制性 BER的标准定义假设训练和验证数据均来自同一分布，但这一假设在实践中并不总是成立。将我们的工作扩展到考虑训练和验证数据的两种不同分布的设置，例如，作为应用数据编程或弱监督技术的直接结果，提供了一条有趣的未来研究路线，同时为i.i.d.情况开发了更实用的BER估计器。

MLOps任务3：针对过度拟合的严格模型测试

在软件开发过程中运行快速而稳健的周期的主要进步之一是连续集成（CI）。其核心思想是以测试的形式仔细定义和运行一组条件，软件每次在投入生产之前都需要成功通过这些条件。这确保了系统的健壮性，并防止了生产代码的意外故障，即使在更新时也是如此。
然而，当涉及到MLOP时，重复使用相同测试用例的传统方法可能会引入严重的过度拟合风险，从而损害测试结果。

MLOps挑战 为了推广到未知的潜在概率分布，在训练ML模型时，必须小心不要过度拟合（有限）训练数据集。然而，很少有人关注测试集的统计泛化特性。按照最佳ML实践，新ML模型的最终测试阶段应该在每个测试集只执行一次，或者必须由开发人员完全混淆。以这种或那种方式处理测试集可以确保测试集的信息不会泄露给开发人员，从而防止潜在的过度拟合。不幸的是，在ML开发环境中，实现这两种方法中的任何一种都是不切实际的。
数据质量视图 采用在产品中连续测试和集成ML模型的思想的有两个主要的警告：（1）由于ML任务和模型的性质，测试结果本质上是随机的，（2）向开发人员透露测试结果可能会误导他们，使其过度拟合测试集。第一个方面可以通过使用从统计学理论中已知的既定浓度边界来解决；为了处理第二个方面，我们称之为测试数据的及时性，有一种由梯形图以及自适应分析的一般领域开创的方法，该方法允许对同一测试集进行多次重用，并向开发人员提供反馈。这项工作的关键洞察是，固定数据集的统计能力随着重复使用次数的增加而减少。换言之，要求有限数据集的泛化特性具有最小的统计可靠置信度限制了它在实践中的重用次数。

我们的方法 用ease.ml/ci 持续集成ML模型。在ml管道中，我们设计了一个CI引擎来解决上述两个挑战。系统的工作流程如图3所示。我们系统的关键要素在于（a）测试条件的语法和语义以及如何准确评估它们，（b）一个优化的样本量估计器，在需要刷新之前产生测试集重用预算。有关工作流以及部署在我们引擎中的高级系统优化的完整描述，请读者参阅我们的初始论文[和后续工作，其中进一步讨论了与现有软件开发生态系统的集成。接下来，我们概述了在确保有限数据的泛化特性的一般范围内的关键技术细节，这些数据用于重复测试训练的ML模型的准确性。

1.测试条件规范 经典CI测试条件和测试ML模型之间的关键区别在于，ML引擎的任何CI的测试结果本质上是概率的。因此，在评估我们称之为分数的测试条件的结果时，必须将期望的置信水平和公差定义为（ε，δ）要求。在这里ε（例如1%）表示置信区间的大小且估计得分至少以1− δ（例如99%）的概率存在的。我们的系统还支持变量d，该变量捕获新模型和旧模型之间不同预测的分数。为了测试测试条件是否通过或失败，需要区分两种情况。一方面，如果分数超出置信区间（例如，n-o>0.03或n-o<0.01），则测试立即通过或失败。另一方面，如果得分在置信区间内，则结果定义不明确。根据任务的不同，用户可以选择允许假阳性或假阴性结果（在统计假设检验中也称为“I型”和“II型”错误），之后，置信区间内的所有分数将自动被拒绝或接受。

2.测试集重复使用 在非自适应场景中，在运行测试后没有信息透露给开发人员，使用相同数据集执行H评估所需的最小样本量与使用δ/H错误概率运行单个评估相同，因为H模型是独立的。
因此，向开发人员透露任何类型的信息将导致大小为H的数据集乘以一次评估所需的样本数，并产生δ/H误差。然而这种琐碎的策略成本非常高，通常不切实际。我们系统的总体设计提供了一种不同的方法，显著减少了多次使用同一测试集所需的测试样本量。更准确地说，在每次提交后，系统只向开发人员显示一个二进制“通过/失败”信号。因此，可能存在2个不同的通过/失败响应序列，这意味着H次迭代所需的样本数与以δ/(2^H)错误概率运行单个迭代的样本数相同——远小于之前的δ/H。我们注意到，可以通过利用某些测试条件中存在的结构或低方差特性来部署进一步的优化，为此，我们请感兴趣的读者参阅全文。

局限性 主要局限性包括最坏情况分析，当开发人员充当敌手时会发生这种情况，目的是过度适应隐藏的测试集。采用其他不太实用的方法来建模开发人员的行为，可以实现进一步的优化，以减少这种情况下所需的测试样本数量。第二个限制在于缺乏处理概念转变的能力。监控概念转变可以被认为是一个类似的CI过程——不需要固定测试集和测试多个模型，可以固定单个模型并测试其在多个测试集上的泛化。从这个角度来看，我们希望我们在工作中得出的一些优化也可以潜在地应用于监测概念转变。然而，这需要进一步研究，并为未来形成一条有趣的研究路径。

MLOps任务4：高效的连续质量测试

DevOps原则的主要动机之一首先是能够执行快速循环，并通过快速适应变化来持续确保系统的鲁棒性。同时，这两种需求都是传统软件开发中众所周知的需求，自然会扩展到MLOps领域。许多MLOps实践者面临的一个挑战是，在生产模型时，必须处理数据分布的变化。当新的生产数据来自不同的（未知）分布时，在先前看到的数据分布上训练的模型可能不再表现良好。

MLOps挑战 虽然有各种关于自动域自适应的研究，但当呈现一组模型时，我们发现了一个不同的挑战，每个模型都可能是“陈旧模型”或给定某些域自适应方法的自动自适应模型。这种情况在许多公司都很常见-他们通常独立地在不同的数据切片上训练不同的模型（例如，每个季度一个模型），并使用不同的方法自动调整这些模型中的每一个以获得新数据。

因此，他们通常可以访问大量可以部署的模型，希望知道在新的生产数据集合（例如当前时间段，如当前日期）下使用哪一个模型。面临的挑战是，给定未标记的生产数据流，选择性能最佳的模型。从MLOps的角度来看，目标是最大限度地减少为了进行这种区分而需要获取的标签数量。

数据质量视图 根据定义，概念的转变与数据的及时性属性有关。可用的预训练模型旨在捕获训练数据随时间的变化。自然，如果可以访问有关当前时间戳和预训练模型的某些元信息（例如，当前工作日以及每个模型所代表的日期），则可以应用简单的规则来选择当前模型。
当没有这样的元数据可用时，这个问题变得特别困难。在这种情况下，访问完全标记的干净数据集将导致轻松选择达到最高精度的预训练模型。然而，与简单地收集一组未标记的样本相比，为足够大的测试集收集标签在实践中是非常昂贵的。原因是准确标记样本需要人工（如果不是专家级的话）注释员。因此，人们希望以最少的标记工作量，稳健地解决为当前时间跨度选择最佳模型的问题，从而依赖于关于其标记的不完整测试数据。
我们的方法 ease.ml/ModelPicker。 Model Picker是一种在线模型选择方法，用于选择性地对实例进行采样，这些实例可为预先训练的模型排名提供信息。具体而言，给定一组预先训练的模型和从数据源顺序到达的未标记数据样本流，模型选取器算法会回答何时查询实例的标签，以便在有限的标签预算下选取最佳模型。我们进行了严格的理论分析，以表明模型选取器对敌对流（例如非i.i.d.数据）没有遗憾，并且在敌对流和随机流的在线预测任务中都是有效的。此外，我们的理论界与访问所有标签的现有在线算法的界匹配（直到常数）

限制 模型选取器的一个直接扩展是用户可以立即访问未标记数据样本池的设置。在这种基于池的采样情况下，可以对整个数据样本集合进行排序，以选择信息量最大的示例，而不是顺序扫描数据以决定是否查询标签。尽管Model Picker适用于这样一种场景，即可以通过从样本池中采样i.i.d.来形成流，但可以利用整个数据收集的可用性，进一步降低基于池的场景的注释成本。

展望未来

我们用一个统一的主题简要描述了我们之前的四项工作-我们认为，所有这些工作都提供了有助于促进更好的MLOps流程的功能，从另一方面来说，这引入了新的基本技术问题，需要我们共同分析数据质量问题对下游ML流程的影响。在研究这些技术问题时，我们通常需要超越ML不可知的数据质量观，而是需要开发同时结合ML和数据质量两个方面的新方法。尽管我们迄今为止取得了进展，但这项努力仍处于初级阶段。在下文中，我们提出了两个未来方向，我们认为这两个方向对于促进MLOps作为一项重要功能和ML感知数据质量作为一个基础研究领域都是必要的。

ML感知数据质量 从技术角度来看，联合理解数据质量和下游ML过程既有趣又具有挑战性。我们在本文中讨论的所有结果都可以说是有限的——从问题的原则公式开始后，在这些原则框架内实现基本的计算挑战是不可避免的。我们通过（1）选择更简单的代理模型，我们可以得到更强大的结果和/或更高效的算法（例如，在ease.ml/snoopy和CPClean中使用的kNN），或者（2）针对实践中常用的特定情况进行优化（例如，我们优化的ease.ml/ci中的模式）。为了进一步促进一般的MLOps，我们迫切需要一种ML感知的数据质量，这种数据质量不仅具有原则性，而且对于更大的场景和ML模型集合也是实用的。这些都是技术上的挑战-简单地扩展我们开发的方法不太可能成功。我们希望我们目前的努力\可以在某种程度上成为“失败的例子”，其他研究人员可以从中汲取灵感.

超出精度之外，我们工作的另一个常见限制是，他们都专注于提高ML模型工件的精度。虽然这是模型质量最重要的方面之一，但最近研究人员还发现了模型质量的多个有趣维度，如稳健性、公平性和可解释性。尽管我们预计这些质量维度将成为未来MLOps流程的核心，但如何将我们为提高这些质量维度的准确性而开发的功能扩展到这些质量维度仍然是一个开放的问题。联合分析所有数据质量维度相对于量化ML模型的单个度量的影响是一个巨大且有前途的研究领域，我们相信这将进一步理解和改进MLOps过程。