行业现状令人失望，工作之后我又回到UC伯克利读博了

文 | SHREYA SHANKAR
编 | 小舟、陈萍
源 | 机器之心

很多同学在面临读博和工作的选择时会犹豫不决，这篇文章也许能给你一点启发。

机器学习领域近来受到大模型的冲击，很多小公司表示难以承担大模型的训练费用。但行业中机器学习工程的发展具体是怎样的？

Shreya Shankar 是一位曾在初创公司、谷歌大脑和 Facebook 等担任工程师的机器学习从业者。现在她选择从产业回归学术研究，回到学校攻读博士学位。

▲SHREYA SHANKAR

她撰写了一篇博客分享自己在行业工作中的见闻和感想。在这篇博客中，我们能够看到当前机器学习工程的现状。以下是博客原文。

人们一直在讨论机器学习工程（MLE）是否应该算作软件工程的一个子集。之前我曾从数据工程的角度思考 MLE，但这并不合适。即使是针对特定的预测任务，自动化端到端机器学习（ML）的生命周期也很难预估。

在机器学习工程中，有 Task MLE 和 Platform MLE 两种关键业务职位。

Task MLE 负责在生产中维持特定的 ML 流水线（或一小部分 ML 流水线），关注关键任务的特定模型。当 top-line 指标下降时，这些关键任务被分页，以「修复」某些东西。Task MLE 可能会告诉你模型上次重新训练的时间、评估结果等。

Task MLE 的工作太繁琐了。数据科学家对模型进行原型设计并提出功能创意，Task MLE 则需要「生产」这些创意。这需要编写 pipeline 将数据转换为模型输入、训练和重新训练模型、评估模型，并将预测结果转储到某处。Task MLE 需要分阶段监督部署，并快速诊断和对 ML 相关错误做出响应。

我曾经就是一个 Task MLE，这些工作令我非常痛苦。我对很多细节都抱有疑问，例如为什么在模型重新训练时，训练集会自动刷新而评估集保持不变，必须有人手动刷新评估集？

我从来不希望自己在科学上不严谨，但我经常发现自己的实验代码中包含模型开发期间就评估不成立的训练假设，更不用说部署了。

有时，我又太科学了，以至于公司赔钱。我自动化了一个超参数调整过程，该过程根据时间将训练集和验证集分成多个子集，并选择了在所有集合中性能平均最佳的超参数。事后才意识到这是多么愚蠢，我应该采用为最新评估集生成最佳模型的超参数。

我现在已经对生产 ML 进行了足够的研究，知道简单地过拟合最新数据并不断重新训练是值得的。成功的公司就是这样做的。

当人们说小公司因为没有预算而无法每天重复训练时，我感到很困惑。重新训练许多 xgboost 或 scikit-learn 模型最多只需要花费几美元，大多数模型并不是大型语言模型。我询问了许多小型公司的 Task MLE 是否以及如何监督他们的 pipeline 并进行分配，他们中的大多数人都提到了按小时、天或周安排训练。

「我知道这并没有真正解决数据漂移（data drift）问题」，我询问的 Task MLE 害羞地说道。

我认为这些问题是非常重要且有趣的，可悲的是，现在只有有趣。最终所有的问题都导致一个结果：数据不一致，模型表现不佳，业务指标受到影响。

第二种 MLE 是 Platform MLE，他们负责帮助 Task MLE 自动化其繁琐的工作部分。Platform MLE 构建支持多个任务的 pipeline（包括模型），而 Task MLE 负责解决特定任务。这类似于在软件工程（SWE）中构建基础设施与在基础设施之上构建软件。但我称它们为 Platform MLE 而不是 Platform SWE，因为我认为如果不充分了解 ML，就不可能实现 ML 「保姆级」自动化。当一个机构拥有多个 ML pipeline 时，就会产生对 Platform MLE 的需求。Platform MLE 和 Task MLE 的主要区别包括

Platform MLE 负责 pipeline 功能的创建，Task MLE 负责 pipeline 使用功能；
Platform MLE 负责模型训练框架，Task MLE 负责编写模型架构的配置文件和重新训练；
Platform MLE 负责触发 ML 性能下降警报，Task MLE 对警报采取行动。

对无效数据进行重新训练没有任何价值

Platform MLE 不仅存在于渴望达到 FAANG 规模（FAANG 是美国市场上五大最受欢迎和表现最佳的科技股的首字母缩写）的公司中。它们通常存在于任何具有多个 ML 任务的公司中。我认为，MLOps 目前被认为是非常有利可图的。每个 ML 公司都需要功能、监控、可观察性等。Platform MLE 更容易构建这些服务 —— 编写一个每天刷新功能表的 pipeline，标准化所有 ML 工具的日志记录，保存和版本数据集快照。具有讽刺意味的是，MLOps 初创公司寻求用付费服务来取代 Platform MLE，不过这些公司也会要求 Platform MLE 将此类服务集成到他们的公司中。

目前，我最感兴趣的 Platform MLE 功能是监控和调试突然的数据漂移。Platform MLE 具有局限性，即无法更改模型、输入或输出，但其可以用来确定这些信息何时以及如何被破坏。目前 SOTA 解决方案是监控覆盖范围的变化（即部分缺失）和单个特征（即输入）的分布以及模型输出随时间的变化。这称为数据验证，当这些变化超出某个阈值（例如，覆盖率下降 25%）时，Platform MLE 会触发警报。

数据验证实现得到了很好的召回率。我认为至少 95% 的数据漂移（主要是由工程问题引起的）会被数据验证警报捕获。但精度比较低（大多数任务都低于 20%），并且它需要一个 Task MLE 来枚举所有特征和输出的阈值。在实践中，精度可能会更低，因为 Task MLE 具有警报疲劳，还有可能导致大多数警报静音。

我们可以用召回来换取精度吗？并非如此，高召回率是监控系统的重点，可以用来捕获 bug。我们不必做到监控每个特性和输出，但是警报必须具有等级，否则它们将无法对 Task MLE 进行操作。重新训练来解除警报也是不可取的，因为对无效数据进行重新训练没有任何价值。

有一段时间，我认为数据验证是准确率、精度、召回率等 ML 指标监控的等效物。由于缺乏真值标签，我们几乎不可能实时进行 ML 指标监控。许多机构只能每周或每月获得标签，这样一来时间太长了。此外，并非所有数据都被标记，数据标记也是一个浩大的工程。我认为唯一需要监控的是模型输入和输出。

然而我大错特错。假设 Task MLE 能够监控实时 ML 指标，数据验证仍然非常重要。一方面，不同任务的模型可以从相同的功能中读取。如果 Platform MLE 可以正确触发损坏的功能警报，则多个 Task MLE 可以受益。

其次，在现代数据堆栈时代，模型特征以及输出（即特征存储）经常被数据分析师使用。我曾经在 Snowflake 中匆忙执行了一堆查询，却没想到与年龄相关的列有一半是负值，年龄怎么会有负值呢？然而我没有检查就交给了 CEO。我认为犯这样的错误是可以理解的，这是大数据的问题，信息有对有错。

博士一年，我的研究更像是一种探索

现在，我已经读完了博士一年级。我意识到无论是 Task MLE 还是 Platform MLE，我们都是在确保满足 SLO（Service-Level Objectives，服务水平目标，通常是一个百分比，并与一个时间范围挂钩）。这让我想起了数据工程，简单地说，数据工程师负责向其他员工提供数据，ML 工程师负责确保这些数据及其相关的应用程序 (例如 ML 模型) 不是垃圾。

我想了很多关于什么是好的模型质量的问题。我讨厌质量这个词。这是一个定义模糊的术语，但实际上每个组织都有不同的定义。

有了数据 SLO，我们可以认为数据验证是一个成功的概念，因为它以二进制方式清楚地定义了每个模型输入和输出的质量。以上述年龄查询为例，年龄要么是正数，要么不是。记录要么匹配预定义的模式，要么不匹配，要么满足 SLO，要么不满足。

假设每个组织都能够清楚地定义他们的数据和模型质量 SLO，在 ML 设置中，我们应该在哪里验证数据？传统上，以数据为中心的规则是由 DBMS 执行的。在 Postgres 的论文中，美国计算机科学家 Stonebraker 简明扼要地阐述了数据库执行规则的必要性：在应用程序层很难执行规则，因为应用程序通常需要访问比事件所需的更多的数据。

一年前，我的导师告诉我一个短语「constraints and triggers for ML pipeline health」，我没有完全理解其中的含义。在 ex-Task MLE 中，我认为这个短语意味着使用代码检测 ML pipeline 组件以记录均值、中值以及输入和输出的各种聚合，并在数据验证检查失败时抛出错误 —— 这也是我在工作中所做的事情。

现在我已经有了更多的 Platform MLE 经验，Platform MLE 拥有数据管理器，Task MLE 拥有应用程序或 ML pipelines 的下游部分。Platform MLE 应该在特征表中强制执行规则（例如，数据验证），以便在查询是否有任何错误时提醒 Task MLE。Platform MLE 应该执行触发器，就像各种临时后处理 Task MLE 在将预测呈现给客户之前对预测所做的那样。

我还想了很多关于如何让研究者更容易指定和理解模型质量的问题。ML 公司拥有自己的生产 ML 框架（例如 TFX）—— 有些是开源的，有些是不公开的。作为 MLOps 初创公司的一部分，许多新框架即将问世。我曾经认为人们不会切换到新框架的原因是因为重写所有 pipeline 代码很麻烦。