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 代码很麻烦。
图源：https://databricks.com/glossary/mlops
ML pipeline 框架须要与 DBMS 紧密结合，DBMS 知道 Task MLE 想要什么类型的触发器，了解数据考证并调整警报以拥有良好的精度和召回率，并且拥有可扩展性。也许这就是为什么我最近与之交谈的许多人似乎正在转向 Vertex AI—— 一种充当数据库的服务，可以做很多事情。
我应该从事一系列科学成绩并从事大量实验以得出结论，我的博士学位更像是一种探索，在那里我研究数据管理的工作原理，并尝试就它将如何在 MLE 生态系统中发挥作用提出看法。它给人一种扎根理论的感觉，我将不断地根据我学到的新信息更新我的观点。
原文链接：https://www.shreya-shankar.com/phd-year-one/?continueFlag=bfd381b12d97c9b15ebc46c66482df00