世界启动Ⅹ--了解机器学习工程中的挑战和机遇

前言

ML 工程师从事的 4 项主要任务。

图 1：ML 工程工作流程中的常规任务。

上述每个任务为机器学习工作流程增加了什么价值？
决定机器学习成功的 3V 因素是什么？
如何处理机器学习工程的实验性质？
如何将以产品为中心的指标与传统的 ML 指标相结合来选择正确的模型。
在将模型投入生产后，如何才能保持模型的最佳性能？

了解上述内容可以让我们更深入地了解推动 ML 工程成功的因素。一旦我们了解了这一点，我们就可以了解如何应对目前困扰各地 ML 工程师的以下挑战 -

开发-生产不匹配：开发和生产环境之间存在差异。这包括数据泄漏；Jupyter Notebook 使用理念不同；以及非标准化代码质量——所有这些都会导致生产中出现意想不到的错误。使用提供类似环境同时支持不同迭代速度的工具来弥合这一差距至关重要。我还强烈建议利用异步文档/样式指南检查 + 团队文化来标准化其中许多实践，以便您的工程师无意识地遵循您已建立的 SOP。正如一位智者（我）曾经说过的那样——潜意识的洗脑往往在教育失败的地方取得成功。关于这一点的更多内容将在未来的文章中介绍。
处理数据错误：机器学习工程师在处理一系列数据错误（例如模式违规、缺失值和数据漂移）方面面临挑战。困难在于确定每种错误类型的适当响应，并减轻误报导致的警报疲劳。这些问题可以通过开发/购买用于实时数据质量监控和自动调整警报标准的工具来解决。
驯服 ML 错误的长尾：由于错误不可预测且通常是定制的，因此调试 ML 管道带来了独特的挑战。虽然症状可能相似，但找出根本原因可能非常耗时，并导致“调试创伤”的感觉。对错误进行分类并开发能够深入了解性能下降及其根本原因的工具是潜在的解决方案。这就是我执着地强调更好的透明度和监控框架的原因——它们可以帮助您避免巨大的重复性错误。
冗长的多阶段部署：机器学习实验的迭代和不可预测性 + 多阶段部署流程可能导致验证和推出新模型或功能的时间表延长。这通常会导致由于优先级的转变或用户行为的演变而放弃一些想法。精简部署和预测端到端收益的工具可以最大限度地减少浪费的努力。然而，最好的办法是接受“少即是多”的格言。寻找尽快验证（不）想法的方法，因为这将为您节省大量时间和精力。记住，你赢得每一场你不打的仗。
观察到的反模式：多种反模式阻碍了 MLOps 的发展，包括行业需求与课堂教育不匹配、渴望让 GPU 不断运行实验而缺乏战略重点、在观察结果后修改解释的倾向以及对特定管道的了解没有记录。解决这些反模式需要改进教育资源、自动化文档工具，并在实验中转向优先考虑质量而不是数量。

最后，作者讨论了 MLOps 工具的总体情况。总体情况可分为四层：用于管理执行的运行层；用于指定依赖项和计算的管道层；用于单个计算单元的组件层；以及用于底层资源的基础设施层。

如果您是 MLOps 工具构建者，请了解这些层，并寻找显著提升其中 3V 的方法。本节的两个要点是：

工程师喜欢能够增强他们体验的工具。我们在姊妹刊物《Tech Made Simple》中深入讨论了这个问题。改善用户体验（尤其是对于比较成熟的工具/应用程序）的投资回报率往往高于改善工程设计（让火车跑得更快很昂贵，但在火车上安装 WiFi 让旅途变得轻松却很容易）。
随着我们深入研究，变化的频率会降低。运行层有很多变化，而基础层的变化往往很少。许多团队倾向于通过非常短期的视角来做出基础决策（“AWS 给了我们一个很好的折扣”或“我们雇佣的团队只知道 Azure”），但这可能会导致以后出现巨大的问题。在深入决策之前，花一些时间深入思考基础权衡是值得的。引用作者的话——“基础架构的变化频率远低于堆栈中的其他层，但每次更改都更加费力，并且容易产生广泛的后果”。俗话说，“花 10 个小时磨斧头，花 2 个小时砍树。”

机器学习团队如何遭遇“骗局”

你在 Tinder 上约会的大多数人最令人印象深刻的是不是他们的 Photoshop 技能？如果是这样，请考虑加入 ML 团队，并接受专业的欺骗。训练和生产环境之间的差异通常会导致性能指标过高，并且在系统投入生产时会陷入与失败的激烈斗争。让我们来谈谈发生这种情况的一些最常见的原因。

数据泄露

当您的模型在训练期间获取现实世界中无法获得的信息时，就会发生数据泄漏。

各位动漫迷们，你们对 Jojos 的评价有多高？

这可能以多种方式发生：

目标泄漏：意外地在训练数据中包含与目标变量直接相关的特征，本质上泄露了答案。
训练-测试污染：没有正确分离训练和测试数据，导致过度拟合和模型性能不准确。这个问题
时间泄漏：未来的信息会及时泄漏到训练数据中，给出不切实际的“提示”。当我们随机分割时间数据时，就会发生这种情况，从而为训练数据提供它不会给出的关于未来的提示
数据预处理不当：在拆分之前，对整个数据集进行标准化、缩放或归纳等步骤。与时间泄漏类似，这可让您的训练数据洞察所有值。例如，想象一下计算所有客户的平均收入，然后将其拆分以预测贷款违约。训练集“知道”总体平均值，这在实践中并不现实。
使用泄露的特征进行外部验证：当最终在真正保留的集合上进行测试时，模型仍然依赖于在进行实际预测时实际上无法获得的特征。

我们通过在数据处理上投入大量精力来解决数据泄漏问题（良好的人工智能安全主要是通过良好的数据验证 + 软件安全实践来解决的 - 这是我愿意为之付出努力的山丘）。以下是一些具体的技术-

彻底的数据清理和验证：仔细检查数据中是否存在不一致、缺失值和潜在泄漏点。实施数据质量检查和验证程序，以确保您的数据代表现实世界。
谨慎进行特征工程：注意您创建的特征及其泄漏的可能性。避免直接揭示目标变量或过度依赖训练数据分布的特征。
严格的代码审查：让多双眼睛审查您的代码，以识别潜在的数据泄漏途径，尤其是在复杂的预处理或特征工程步骤中。让局外人审核您的做法在这里会是一个很好的补充。
这些流程会降低您的速度。在 ML 工程中，速度和安全性之间存在着矛盾。我没有足够的经验来领导 AI 项目，无法告诉您如何解决这个问题，也无法教您如何确定您的团队应该处于哪个位置。但是，我们可爱的小巧克力牛奶教派中确实有很多高级领导者，我希望你们中的一些人可以在这里分享您的见解。现在，让我们继续讨论您的开发和生产环境之间可能存在不匹配的下一个原因。

Jupyter 笔记本

Jupyter Notebooks 是数据探索和实验的首选工具。它们的交互性和灵活性使其成为快速原型设计和尝试新想法的理想选择。然而，它们的自由格式结构也可能导致代码混乱、缺乏可重复性以及难以过渡到生产。

笔记本可以让你用简单 + 速度换取质量。根据你的优先级，这意味着你要么支持，要么反对在生产中使用笔记本。以下段落非常有见地地阐述了为什么有些人在生产中使用笔记本 -

“ Jupyter 笔记本在开发过程中被广泛使用以支持高速度，这并不令人惊讶。然而，让我们感到惊讶的是，尽管参与者普遍认为笔记本中的代码质量较差，但一些参与者更喜欢在生产中使用它们，以尽量减少开发和生产环境之间的差异。P6 提到，他们可以在本地下载、执行和操作生产笔记本运行中的数据时快速调试。P18评论了从单一脚本代码库迁移到笔记本的模块化优势：我们将管道的每个组件都放在一个笔记本中，这让我的生活变得轻松多了。现在 [调试时]，如果我想的话，我可以只运行一个特定的组件，而不是整个管道……我不需要关注所有其他组件，这也有助于迭代”

我不是这些人中的一员，但考虑到我们身处 Kali Yug，人们可以预料到这种退化。以下引自论文的内容更接近我在生产中使用 Notebooks 的经验 -

“P10 讲述了他们公司的一个轮班，将他们想要复制或部署的任何工作从笔记本中移出：这里有各种各样的手动问题。你知道，有人会用笔记本中的错误输入运行某些东西，我花了一天半的时间进行调试。然后我发现这都是垃圾。八个月前，我们意识到这行不通。我们需要投入工程努力来创建 [非笔记本] 管道”

为什么会出现这些差异？本文提出了一个绝妙的观点。本质上，安全性和速度之间的矛盾再次出现——

关于笔记本的轶事表明，相互竞争的优先事项之间存在冲突：1) 笔记本支持高速度，因此需要用于开发环境；(2) 相似的开发和生产环境可防止引入新的错误；(3) 在生产中使用笔记本很容易出错，例如，使用错误的输入运行；复制粘贴而不是重复使用代码。每个组织对这些优先级的排名都不同，最终表明他们是否在生产中使用笔记本。

本文还涉及非标准化质量要求如何导致开发和生产之间的不匹配。我们不会涉及这一点，原因有二。首先，我认为该出版物对这个主题没有任何深刻的见解。其次，要对这个主题（特别是在更一般的意义上）发表任何明智的言论需要经验，而我缺乏经验。现在，我会坚持通用的，“清晰明确的沟通很重要，公司不应该羞于投资文档、风格指南和知识共享机制。

✨✨数据错误的惊人范围✨✨

硬错误

这些是最容易识别的。硬错误通常会导致立即且明显的问题，导致模型崩溃或产生无意义的结果。检测硬错误的一些方法包括：

架构验证：定义一个架构，指定每个字段的预期数据类型、格式和范围。根据架构验证传入的数据以发现任何违规行为。
数据分析：分析您的数据以识别可能表明存在硬错误的缺失值、异常值和其他异常。
基于规则的检查：实施规则来标记特定类型的错误，例如检查年龄字段中的负值或确保分类变量具有有效类别。

对于 LLM，总是会忍不住用大量可接受和不可接受的输入示例来微调你的 LLM，并让它们充当数据过滤。当涉及到处理硬错误时，我建议不要这样做。这可能需要更多的工作 - 但让传统的人工智能处理基于规则的检查更便宜、更准确，而且会可预测地失败（这是一个巨大的优势）。即使你的错误只是部分硬错误 - 使用基本检查可以很好地补充你的 LLM/深度学习。Deepmind的 AlphaGeometry 已经向我们展示了将两者融合的力量。

软错误

软错误更为微妙，可能不会立即导致模型失败。它们代表与预期数据分布或质量标准的偏差，但仍会影响模型性能并导致有偏差或不准确的预测。示例包括：

异常值：与其他数据有显著偏差的极端值。
数据不一致：数据中的小错误或不一致，例如拼写错误或格式问题。
特征分布变化：随着时间的推移，各个特征的分布发生变化。

检测软错误：

统计分析：分析数据和特征的分布以识别异常值、偏度和其他异常。
数据质量指标：跟踪完整性、一致性和准确性等指标来评估数据的整体质量。
机器学习技术：训练模型以检测数据中的异常或与预期模式的偏差。我们在几篇文章中介绍了可能的解决方案，我可能会在某个时候将所有内容汇总到一本指南中。

数据漂移：

数据漂移是指基础数据分布随时间的变化。这种情况可能是逐渐发生的，也可能是突然发生的，并且会导致模型性能下降，因为它不再针对当前数据分布进行优化。

检测漂移有多种方法：

监控统计属性：跟踪数据和特征的平均值、标准差和其他统计属性随时间的变化。
分布比较方法：使用 Kullback-Leibler (KL) 散度或 Jensen-Shannon 散度等技术将当前数据的分布与历史数据或参考分布进行比较。
机器学习模型：训练模型来检测数据分布中的变化或异常，发出潜在的漂移信号。

重要的是要记住，在灵敏度和稳定性之间需要权衡。这是不可避免的。

P8 描述了在他们的 NLP 模型中，频繁出现的单词的词汇表如何随时间而变化，迫使他们定期更新预处理器函数。我们的结论是，任何汇总数据的功能（无论是清理工具、预处理器、功能还是模型）都需要定期重新调整

因为数据是我们生活中如此重要的一部分，数据问题不止于此。相反，数据的技术问题给 MLE 带来了另一个问题。我们接下来再讨论这个问题——

警报疲劳：从噪声中分离信号

数据质量监控的一个常见陷阱是警报疲劳。当监控系统过于敏感或生成过多警报时，工程师会不堪重负、变得麻木不仁，我们可能会错过关键问题。

痛点在于处理警报疲劳和领域专业知识，以便知道在值班期间该采取什么行动。新成员在第一次值班时会感到紧张，所以每次轮换，我们都会安排两名成员。一名成员是影子，他们会问很多问题。

过于敏感的标记系统会导致警报疲劳。因此，解决警报疲劳的办法是，只在工程师被标记的次数内发送警报，以减轻他们的认知负担。

关注可操作警报：优先处理那些表明存在真正问题且需要立即关注的警报。过滤掉噪音和低优先级警报（将其写入日志）。
智能警报系统：使用机器学习或统计技术来识别警报中的模式并区分真实问题和误报（这是本文的一般主题）。
警报聚合和关联：将相关警报组合在一起，以提供潜在问题的更全面视图，并避免单独的通知让工程师感到不知所措。

警报疲劳与环境密切相关，解决它需要深入了解您的数据和领域。这让您能够为您的解决方案量身定制策略（ML 本质上是多学科的）。ML 的定制性创造了一个非常有趣的问题子类型 -

机器学习错误的长尾

ML 错误通常属于长尾分布，其中少数常见问题经常发生，但也有很多罕见且独特的错误，只存在于个别群体中。

虽然有些类型的错误被多位参与者讨论过……但访谈中向我们描述的绝大多数错误似乎都是定制的，参与者之间并没有共享。例如，P8 忘记在他们的语言模型中删除特殊字符（例如撇号）。P6 发现缺失特征的插补值曾经被破坏。P18 提到，非结构化数据类型（例如 JSON）的特征有一半的键值“很长时间”都缺失了。

这使得制定全面的测试和调试策略变得具有挑战性。然而，虽然可能存在多种类型的错误，但它们导致问题的方式只有几种（作者将其称为“不可预测的原因，可预测的症状”）。因此，处理长尾问题需要两个关键因素——对透明度的执着投资和上帝的祝福。投资透明的人工智能工具并让监控数据的不同部分变得容易（这部分很重要）是很重要的——

基本上没有万无一失的策略。我见过最接近的策略是人们将高度可观察性集成到管道的每个部分。首先要有非常好的原始数据、可观察性和可视化工具。查询能力。我注意到，你知道，很多这种 [临时错误探索] 只是——如果你降低 [调试] 的阻力，人们就会更多地这样做。因此，作为一个组织，你需要将调查数据实际情况的阻力降到非常低，[例如] 查看具体示例。

这是一个漫长的过程，但我们离终点线非常近了。最后让我们讨论一下 MLOps 反模式（“对反复出现的问题的常见响应，通常无效且可能适得其反”），这可能会阻碍您的进步。

常见的机器学习反模式

论文第 5.2 节阐明了一些常见的 MLOps 反模式。识别这些反模式对于构建强大而可靠的 ML 系统至关重要。

行业与课堂不匹配：许多 ML 工程师表示，离开学校后，他们感觉对生产 ML 的现实毫无准备。大学课程充其量只能教你理论概念（这最多算是一个很大的问题——我上的计算机科学课程没有教给我任何有用的东西）。课程不会教你如何处理现实世界的数据、解析不清楚的指令、与各种工具/库交互、理解权衡或许多其他工程挑战。大学教你如何成为研究人员，这是完全不同的一回事。如果你是个好学生，学术严谨和对理论的关注可以为你打下良好的基础，让你快速学习东西——但你仍然需要投入大量精力自学。

保持 GPU 温暖：多位受访者表示，他们会不断进行实验以利用他们的计算资源（“保持 GPU 温暖”）。他们后来意识到，正确的做法是明智地进行实验，并思考什么可以获得最高的投资回报率。一个人声称，他们意识到将他们的认知资源一次花在一个重要的想法上比将其分散在不同的地方更有成效。我有点困惑为什么这并不明显，我不确定作者是否在这里欺骗我们。如果不为了实验而进行实验不是一个明显的原则，请告诉我为什么。
改进解释：与上一点相反，这一点实际上非常重要。我想强调的一点是机器学习的理论脆弱性。我们所做的很多事情都没有坚实的基础——很多都是实验。通常，我们先找到可行的方法，然后再提出解释。这并不总是坏事——只要我们承认这一点。只有当我们对大多数充其量是有根据的猜测过于自信时，这才是问题。

未记录的部落知识：随着 ML 系统和团队的发展，有关特定模型、管道和数据复杂性的知识可能会集中在少数人手中，尤其是当这种“部落知识”可能造成瓶颈和依赖关系，阻碍协作并使系统难以随着时间的推移而维护和发展时。如果关键人员升职、解雇或因其他原因离开团队，这将成为一个巨大的问题。为了避免这种情况，请优先考虑文档、知识共享和交叉培训，以确保整个团队都可以访问关键信息。