晨间论文
PDF将机器学习投入生产系统
机器学习的数据验证和软件工程
Adrian Colyer
这一次的晨间论文，我选择了两篇论文，分别探讨了将机器学习投入生产系统的不同方面。在“机器学习的数据验证”中，Breck等人分享了谷歌用于每天验证PB级生产数据的管道的细节。由于有如此多的活动部件，重要的是能够在数据分布影响模型性能之前检测和调查数据分布的变化。作为额外的福利，谷歌方法核心的数据验证库也已开源，以便您也可以尝试使用它 (https://github.com/tensforflow/data-validation)。
“机器学习的软件工程：案例研究”分享了微软在机器学习开始渗透到公司越来越多的系统时吸取的教训，从专门的机器学习产品到仅仅成为许多产品和服务不可或缺的一部分。这意味着这些项目上的软件工程流程和实践必须进行调整。本文再次证明了坚如磐石的数据管道的重要性，以及机器学习给开发项目带来的一些独特挑战。
机器学习的数据验证
Breck等人，《SysML'19》（系统和机器学习会议）
https://www.sysml.cc/doc/2019/167.pdf
(备用链接：https://mlsys.org/Conferences/2019/doc/2019/167.pdf)
此前在《晨间论文》中，我们研究了机器学习（ML）模型的持续集成测试，但可以说比模型更重要的是数据。垃圾进，垃圾出。
在本文中，我们重点关注验证输入到ML管道的数据的问题。这个问题的重要性怎么强调都不为过，特别是对于生产管道而言。无论使用何种ML算法，数据错误都可能对生成的模型质量产生不利影响。
Breck等人描述了谷歌在生产环境中部署的数据验证管道，“每天被数百个产品团队用于持续监控和验证数PB的生产数据”。这相当于每天数万亿的训练和服务示例，遍布700多个ML管道——足以积累关于哪些地方可能出错以及有哪些有用的保障措施的丰富经验！
可能出什么问题？
动机示例基于谷歌的实际生产中断，并演示了几个更棘手的问题：由在损坏的数据上训练引起的反馈循环；以及数据提供者和数据消费者之间的距离。
ML模型每天都在数据批次上进行训练，前一天的真实查询与标签结合，以创建第二天的训练数据。在某个上游，数据获取RPC（远程过程调用）开始在数据的子集上失败，并返回-1（错误代码）而不是期望的数据值。-1错误代码被传播到服务数据中，并且一切表面上看起来都很正常，因为-1是int特征的有效值。服务数据最终成为训练数据，模型很快学会预测特征值的-1。现在，模型对于受影响的数据切片将表现不佳。
此示例说明了一种常见的设置，其中数据的生成（和所有权！）与ML管道解耦... ML管道除了通过副作用（例如，-1在数据切片上变得更常见的事实）之外，对这种数据生成逻辑缺乏可见性，这使得检测此类特定于切片的问题变得更加困难。
由代码中的错误引起的错误很常见，并且往往与数据清理文献中通常考虑的错误类型不同。
在ML管道中集成数据验证
谷歌的数据验证是ML管道不可或缺的一部分，如下图所示。
管道通常以连续的方式工作，新批次数据的到来触发新的运行。管道摄取训练数据，验证它，将其发送到训练算法以生成模型，然后将训练好的模型推送到服务基础设施以进行推理。
数据验证阶段有三个主要组成部分：数据分析器计算新数据批次的统计信息；数据验证器根据模式检查数据的属性；模型单元测试器使用合成数据（模式引导的模糊测试）查找训练代码中的错误。
测试一批数据
给定一批传入数据，首先要回答的问题是它是否包含任何异常。如果是，将提醒值班人员启动调查。
我们期望数据特征在每个批次内保持稳定，因为后者对应于数据生成代码的单次运行。我们还期望某些特征在时间上接近的几个批次之间保持稳定，因为频繁大幅更改数据生成代码的情况并不常见。由于这些原因，我们认为批次内与预期数据特征的任何偏差（根据专家领域知识）都是异常。
预期的数据特征由模式捕获，如下图所示。
模式中指定的约束可用于确保某个特征存在（例如），或者包含一组预期的值等等。
模式的初始版本是自动合成的，之后由工程师进行版本控制和更新。在初始模式到位后，数据验证器会随着新数据的摄取和分析而推荐更新。例如，给定下图左侧的训练数据，可以导出右侧的模式。
如果某些数据到达时包含event的先前未见的值，则将提示用户考虑将新值添加到域中。
我们期望管道的所有者将模式视为与源代码同等重要的生产资产，并采用审查、版本控制和维护模式的最佳实践。
检测偏差
有些异常仅在比较不同批次的数据时才会显示出来——例如，训练数据和服务数据之间的偏差
• 特征偏差发生在特定特征在训练时和提供服务时采用不同的值时。例如，开发人员可能添加或删除了一个特征。或者更难检测的是，数据可能是通过调用时间敏感的API获得的，例如检索到目前为止的点击次数，并且经过的时间在训练和服务中可能不同。
• 分布偏差发生在训练数据批次中的特征值分布与服务时看到的分布不同时。例如，今天的采样数据用于训练第二天的模型，并且采样代码中存在错误。
• 评分/服务偏差发生在向用户呈现结果的方式可以反馈到训练数据中时。例如，对100个视频进行评分，但仅呈现前10个。其他90个将不会收到任何点击。
谷歌的ML服务基础设施记录服务数据的样本，并将其导入回训练管道，数据验证器在其中使用它来检测偏差。
为了检测特征偏差，验证器在训练数据和服务数据的相应批次之间进行键连接，然后进行逐特征比较。
为了检测分布偏差，使用了训练和服务分布之间的距离。期望存在一定的距离，但如果距离太高，则会生成警报。有一些经典的距离度量，例如KL（Kullback-Leibler）散度和余弦相似度，但产品团队很难理解它们的真正含义，因此也很难调整阈值。
最终，谷歌决定使用两个分布中任何单个值的概率最大变化作为距离度量。这很容易理解和配置（例如，“允许每个值最多更改1%”），并且每个警报都带有“罪魁祸首”值，可用于启动调查。回到我们的动机示例，频率的最大变化将与-1相关联。
模型单元测试
模型单元测试有点不同，因为它不是对传入数据的验证，而是对训练代码处理可能看到的多样化数据的验证。模型单元测试非常适合之前讨论的CI（持续集成）设置。
...[训练]代码对于平台的其余部分（包括数据验证系统）来说主要是黑匣子，并且可以对数据执行任意计算。正如我们在下面解释的那样，这些计算可能做出与数据不一致的假设，并导致严重的错误，这些错误会通过ML基础设施传播。
例如，训练代码可能会对数字特征应用对数，从而做出值始终为正的隐含假设。这些假设很可能不会出现在模式中（模式仅指定整数特征）。为了消除这些问题，模式用于以类似于模糊测试的方式生成合成输入，然后生成的数据用于驱动训练代码的几次迭代。
在实践中，我们发现，即使使用少量随机生成的示例（例如，数百个），模糊测试也可以触发训练代码中的常见错误。事实上，它的效果非常好，以至于我们将这种类型的测试打包为训练算法的单元测试，并将该测试包含在我们的ML平台的标准模板中。
谷歌生产环境中的经验
用户确实在初始生成后拥有了他们的模式，但所需的编辑次数通常很少，如下图所示。
...来自一些团队的轶事证据表明，心理转向以数据为中心的ML视图，其中模式不仅用于数据验证，还提供了一种记录管道中使用的新特征的方式，从而在团队成员之间传播信息。
下表显示了在30天内检测到的异常类型，以及团队是否因此采取了任何措施。产品团队修复了大多数检测到的异常。
此外，百分之六的所有模型单元测试运行都发现某种类型的错误，表明训练代码存在不正确的假设或模式规范不足。
相关工作
最后，我只想快速呼吁大家关注论文（§7）中的相关工作部分，其中包含数据验证、监控和清理领域工作的非常有用的摘要。
谷歌已将其数据验证库作为开源软件提供，网址为https://github.com/tensorflow/data-validation。
机器学习的软件工程：案例研究
Amershi等人，《ICSE'19》（国际软件工程会议）
此前在《晨间论文》中，我们研究了机器学习在Facebook和Google的传播，以及与流程和工具一起解决挑战的一些经验教训。今天轮到微软了。更具体地说，我们将研究一项针对500多名参与者的内部研究的结果，该研究旨在弄清楚随着人工智能和机器学习的兴起，微软的产品开发和软件工程正在发生怎样的变化。
...机器学习组件的集成正在公司各处发生，而不仅仅是在历史上以机器学习而闻名的团队中。
应用领域列表包括搜索、广告、机器翻译、预测客户购买、语音识别、图像识别、识别潜在客户、为演示文稿和文字处理文档提供设计建议、创建独特的绘图功能、医疗保健、改进游戏体验、销售预测、决策优化、事件报告、错误分析、欺诈检测和安全监控。
正如您可能想象的那样，这些都由各种不同的ML模型支撑。从事这项工作的团队在组成上也各不相同，有些团队包含具有多年经验的数据科学家，而另一些团队则刚刚起步。以我们在之前研究过的微软在线实验演化模型的方式，数据科学随着时间的推移从附加的专业技能转变为深度集成的能力。
一些软件团队聘请了博学家型的数据科学家，他们“包揽一切”，但随着数据科学需要扩展，他们的角色会细化为深入了解业务问题的领域专家、开发预测模型的建模者和创建基于云的基础设施的平台构建者。
为了帮助在公司内传播这些技能，使用了各种策略：一年两次的机器学习和数据科学内部会议，至少有一天专门介绍技术、算法和最佳实践的基础知识；全年举办关于项目背后工程细节和学术会议前沿进展的内部讲座；几个团队每周举办关于ML和深度学习的开放论坛；并且有数千名参与者的邮件列表和在线论坛。
一项由与微软内部14位经验丰富的ML领导者的对话提供信息的调查已发送给这些内部邮件列表的4,195名成员，共收到551份回复。受访者广泛分布在数据和应用科学（42%）、软件工程（32%）、项目管理（17%）、研究（7%）和其他（1%）领域。在551名受访者中，21%是经理，其余是个人贡献者。
一般流程
通用ML流程如下图所示。
(放大)
该图表非常不言自明，因此我不会详细说明所有单独的阶段。
为了简单起见，图1中的视图是线性的，但是，机器学习工作流程是高度非线性的，并且包含多个反馈循环。例如，如果工程师注意到训练数据和现实世界中的数据之间存在很大的分布偏移，他们可能希望返回并收集更具代表性的数据并重新运行工作流程... 如果系统是集成的，包含多个以复杂且意外的方式相互作用的ML组件，则此工作流程可能会变得更加复杂。
经验教训和新兴最佳实践
• 拥有涵盖（可能）此处概述的流程中所有不同阶段的无缝开发体验对于自动化至关重要。但要实现这一目标还远非易事。
重要的是开发“坚如磐石的数据管道，能够持续加载和处理数据，使工程师能够轻松尝试具有不同超参数的AI算法的许多排列组合”。
• 具有可视化工具的IDE在开始使用机器学习时很有用，但团队往往会随着经验的积累而不再使用它们。
• 以ML为中心的项目成功很大程度上取决于数据的可用性、质量和管理。
除了可用性之外，我们的受访者最关注支持以下数据属性：“可访问性、准确性、权威性、新鲜度、延迟、结构化、本体类型、连通性和语义可连接性”。
• 微软团队发现需要将传统数据管理工具与他们的ML框架和管道融合。数据源不断变化，并且需要严格的数据版本控制和共享技术。模型具有出处标签，说明它是根据哪些数据训练的以及使用了哪个版本的模型。数据集标有关于它们来自何处以及用于提取它的代码版本的信息。
• 以ML为中心的软件也经常看到由模型更改、参数调整和数据更新发起的修订，这些组合会对系统性能产生重大影响。为了解决这个问题，需要严格的推出流程。
...[团队]通过采用组合飞行技术（即，飞行更改和更新的组合），包括实验记分卡中的多个指标，以及对更敏感的数据类别执行人工驱动的评估，开发了系统流程。
• 模型构建应与软件开发流程的其余部分集成，包括通用代码存储库以及紧密耦合的冲刺和站会。
• 团队所需的支持根据他们使用ML的经验水平而变化，但无论经验水平如何，数据可用性、收集、清理和管理支持仍然是首要关注的问题。
(放大)
三大方面
我们确定了AI领域的三个方面，这些方面使其与以前的应用领域从根本上不同。它们的影响将需要在未来进行大量的研究努力才能解决。
1. 发现、管理和版本控制机器学习应用程序所需的数据比其他类型的软件工程要复杂和困难得多。“虽然有设计非常完善的技术来版本控制代码，但数据并非如此……”
2. 模型定制和模型重用需要与软件团队中通常发现的技能非常不同的技能（“您不能简单地使用文本编辑器更改参数”）。
3. AI组件比传统软件组件更难作为不同的模块处理——模型可能以复杂的方式“纠缠在一起”并体验非单调的错误行为。
虽然前两点是不言自明的，但第三点值得进一步解释。
在机器学习模型之间保持严格的模块边界很困难，原因有两个。首先，模型不易扩展。例如，（目前）还不能使用英语的NLP模型并添加一个单独的用于订购披萨的NLP模型，并期望它们能够一起正常工作...... 其次，模型以不明显的方式交互。在具有多个模型的大型系统中，每个模型的结果都会影响彼此的训练和调整过程。
在这些条件下，即使代码是分离的，一个模型的有效性也可能因另一个模型的更改而发生变化。这种现象有时被称为组件纠缠，并可能导致非单调的错误传播：系统中一部分的改进实际上可能会降低整体系统质量。
Adrian Colyer是Accel在伦敦的风险合伙人，他的工作是帮助在欧洲和以色列寻找和建立伟大的科技公司。（如果您正在从事有趣的科技相关业务，他很乐意通过[email protected]与您联系。）在加入Accel之前，他在技术岗位工作了20多年，包括担任Pivotal、VMware和SpringSource的CTO。
版权 © 2019 由所有者/作者持有。出版权已授权给。
经https://blog.acolyer.org许可转载。
最初发表于Queue第17卷，第4期—
在数字图书馆中评论本文
更多相关文章
Mark Russinovich, Ahmed Salem, Santiago Zanella-Béguelin, Yonatan Zunger - 智能的代价
LLM容易出现幻觉、提示注入和越狱漏洞，这对它们的广泛采用和负责任的使用构成了重大但可克服的挑战。我们认为这些问题是固有的，当然在当前这一代模型中是这样，并且可能在LLM本身中也是如此，因此我们的方法永远不能基于消除它们；相反，我们应该应用“深度防御”策略来减轻它们，并且在构建和使用这些系统时，要假设它们有时会在这些方向上失败。
Sonja Johnson-Yu, Sanket Shah - 你对人工智能一窍不通
长期以来，很难确定人工智能到底是什么。几年前，此类讨论会演变成长达数小时的会议，在会议上绘制维恩图并试图绘制出人工智能的不同子领域。快进到2024年，我们现在都知道人工智能到底是什么了。人工智能 = ChatGPT。或者不是。
Jim Waldo, Soline Boussard - GPT和幻觉
本实验的发现支持以下假设：基于LLM的GPT在更受欢迎且已达成普遍共识的提示下表现良好，但在有争议的主题或数据有限的主题上表现不佳。应用程序响应的可变性强调，模型依赖于其训练数据的数量和质量，这与依赖于多样化和可信贡献的众包系统类似。因此，虽然GPT可以作为许多日常任务的有用工具，但应谨慎对待它们对晦涩和两极分化主题的参与。
Erik Meijer - 虚拟阴谋：使用大型语言模型作为神经计算机
我们探索了大型语言模型（LLM）如何不仅可以充当数据库，还可以充当动态的、最终用户可编程的神经计算机。这种神经计算机的本机编程语言是一种受逻辑编程启发的声明性语言，它形式化并将思维链推理外部化，就像它可能发生在大型语言模型内部一样。
© 保留所有权利。