Auto Byte

专注未来出行及智能汽车科技

微信扫一扫获取更多资讯

Science AI

关注人工智能与其他前沿技术、基础学科的交叉研究与融合发展

微信扫一扫获取更多资讯

小舟、陈萍编译

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

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

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
入门博士生分享UC Berkeley
相关数据
数据分析技术

数据分析是一类统计方法,其主要特点是多维性和描述性。有些几何方法有助于揭示不同的数据之间存在的关系,并绘制出统计信息图,以更简洁的解释这些数据中包含的主要信息。其他一些用于收集数据,以便弄清哪些是同质的,从而更好地了解数据。 数据分析可以处理大量数据,并确定这些数据最有用的部分。

机器学习技术

机器学习是人工智能的一个分支,是一门多领域交叉学科,涉及概率论、统计学、逼近论、凸分析、计算复杂性理论等多门学科。机器学习理论主要是设计和分析一些让计算机可以自动“学习”的算法。因为学习算法中涉及了大量的统计学理论,机器学习与推断统计学联系尤为密切,也被称为统计学习理论。算法设计方面,机器学习理论关注可以实现的,行之有效的学习算法。

数据科学技术

数据科学,又称资料科学,是一门利用数据学习知识的学科,其目标是通过从数据中提取出有价值的部分来生产数据产品。它结合了诸多领域中的理论和技术,包括应用数学、统计、模式识别、机器学习、数据可视化、数据仓库以及高性能计算。数据科学通过运用各种相关的数据来帮助非专业人士理解问题。

超参数技术

在机器学习中,超参数是在学习过程开始之前设置其值的参数。 相反,其他参数的值是通过训练得出的。 不同的模型训练算法需要不同的超参数,一些简单的算法(如普通最小二乘回归)不需要。 给定这些超参数,训练算法从数据中学习参数。相同种类的机器学习模型可能需要不同的超参数来适应不同的数据模式,并且必须对其进行调整以便模型能够最优地解决机器学习问题。 在实际应用中一般需要对超参数进行优化,以找到一个超参数元组(tuple),由这些超参数元组形成一个最优化模型,该模型可以将在给定的独立数据上预定义的损失函数最小化。

验证集技术

验证数据集是用于调整分类器超参数(即模型结构)的一组数据集,它有时也被称为开发集(dev set)。

数据管理技术

数据管理是利用计算机硬件和软件技术对数据进行有效的收集、存储、处理和应用的过程,其目的在于充分有效地发挥数据的作用。

数据库技术

数据库,简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据运行新增、截取、更新、删除等操作。 所谓“数据库”系以一定方式储存在一起、能予多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

准确率技术

分类模型的正确预测所占的比例。在多类别分类中,准确率的定义为:正确的预测数/样本总数。 在二元分类中,准确率的定义为:(真正例数+真负例数)/样本总数

过拟合技术

过拟合是指为了得到一致假设而使假设变得过度严格。避免过拟合是分类器设计中的一个核心任务。通常采用增大数据量和测试样本集的方法对分类器性能进行评价。

查询技术

一般来说,查询是询问的一种形式。它在不同的学科里涵义有所不同。在信息检索领域,查询指的是数据库和信息系统对信息检索的精确要求

语言模型技术

统计式的语言模型是借由一个几率分布,而指派几率给字词所组成的字串。语言模型经常使用在许多自然语言处理方面的应用,如语音识别,机器翻译,词性标注,句法分析和资讯检索。

暂无评论
暂无评论~