网站中有一个非常著名的原则,合肥高新城建设计院网站,建筑企业公司的投标简介,公司网站模版 dedecms文 | SHREYA SHANKAR编 | 小舟、陈萍源 | 机器之心很多同学在面临读博和工作的选择时会犹豫不决#xff0c;这篇文章也许能给你一点启发。机器学习领域近来受到大模型的冲击#xff0c;很多小公司表示难以承担大模型的训练费用。但行业中机器学习工程的发展具体是怎样的… 文 | 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我们都是在确保满足 SLOService-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/mlopsML pipeline 框架需要与 DBMS 紧密结合DBMS 知道 Task MLE 想要什么类型的触发器了解数据验证并调整警报以具有良好的精度和召回率并且具有可扩展性。也许这就是为什么我最近与之交谈的许多人似乎正在转向 Vertex AI—— 一种充当数据库的服务可以做很多事情。我应该进行一系列科学问题并进行大量实验以得出结论我的博士学位更像是一种探索在那里我研究数据管理的工作原理并尝试就它将如何在 MLE 生态系统中发挥作用提出看法。它给人一种扎根理论的感觉我将不断地根据我学到的新信息更新我的观点。后台回复关键词【入群】加入卖萌屋NLP、CV、搜推广与求职讨论群[1] https://www.shreya-shankar.com/phd-year-one/?continueFlagbfd381b12d97c9b15ebc46c66482df00
