写点什么

为什么我们建立机器学习工程平台,而不是数据科学平台?

  • 2020-06-30
  • 本文字数:3214 字

    阅读完需:约 11 分钟

为什么我们建立机器学习工程平台,而不是数据科学平台?

本文最初发表在 Towards Data Science 博客上,经原作者 Caleb Kaiser 授权,InfoQ 中文站翻译并分享。


导读:如果将机器学习工程理解为一门学科的话,那么这个问题就迎刃而解了:为什么我们建立了机器学习工程平台而非数据科学平台?


大约一年前,我们中的一些人开始研究开源机器学习平台 Cortex。我们的动机很简单:鉴于从模型中构建应用程序是一种可怕的体验,充满了胶水代码和样板,我们需要一个工具,能将这些都予以抽象化。


虽然我们对自己在 Cortex 上的工作感到非常自豪,但我们只是过去一年来加速趋势的一部分,那就是机器学习工程生态系统的发展。公司雇佣机器学习工程师的速度比以往任何时候都要快,发布的项目也越来越好。


尽管这让我们感到很兴奋,但我们仍然经常听到这样一个问题:“什么是机器学习工程?”


在本文中,我想为读者们解释什么是机器学习工程,以及为机器学习工程师构建一个平台意味着什么。


什么是机器学习工程?为什么它不是数据科学?

让我们先从更多人熟悉的数据科学的背景来定义机器学习工程。


要给数据科学下一个定义,还不会让人愤怒评论,这很难,但我还是会试着下一个定义:


  • 从广义上讲,数据科学是一门应用科学过程从数据中获得见解的学科。

  • 机器学习工程是一门利用机器学习构建应用程序的学科。


显然,这里有很多重叠之处。两者都是封装了机器学习的学科。不同之处主要在于目标。顾名思义,数据科学是一门科学,而机器学习工程是一门工程学科。


这种区别在大多数学科中都存在。想一想生物学和生物医学工程。工程学科显然离不开科学家的工作:机器学习工程是建立在数据科学的工作基础上,但工程学是科学应用于世界的方式。


为了让这两者之间的区别更加具体,我们可以思考一个实际项目,并分解机器学习工程师与数据科学家的职责和需求,是有所帮助的。


从数据科学和机器学习工程的角度来看 Gmail 的 Smart Compose

Gmail 的 Smart Compose(智能撰写)是生产机器学习最普遍的例子之一,就我们的目的而言,它巧妙地阐明了机器学习工程的挑战。



让我们想象一下开发 Smart Compose。首先,我们要确定约束范围,根据 Gmail 的描述,这些约束包括:


  • Smart Compose 需要与 Gmail 编辑器的用户界面集成;

  • 预测需要在小于 100 毫秒的时间内送达 Gmail 编辑器;

  • Smart Compose 需要扩展到 Gmail 的 14 亿用户。


这些约束中唯一涉及数据科学的是延迟需求。


训练一个足够准确和快速的模型,实际上是一个非常有趣的数据科学问题,团队通过设计一个混合模型解决了这个问题,该混合模型在准确性方面做出了很小的牺牲,但却在速度方面获得了巨大的提高(我建议读者们阅读完整的报告)。


以数据科学家的创新为基础,机器学习工程师现在必须采用这种模型,并将其转化为 Smart Compose。他们采用的方法是任何软件工程师都熟悉的:


1. 定义架构

这个模型应如何与 Gmail 客户端集成?需要考虑的有以下几点:


  • 模型过大,无法在本地部署到客户端;

  • 相对而言,推理的计算成本昂贵;

  • Gmail 有 14 亿用户。


在这种情况下,最好的方法是做成微服务架构,在这种架构中,模型作为 Web API 进行部署,可以由 Gmail 客户端查询。这样,推理的计算开销就可以与应用程序的其他部分隔离开来,并且服务可以横向扩展。


然而,在这种架构中也存在一些挑战。


2. 扩展模型微服务

在白板上绘制这种“模型即微服务”(model-as-a-microservice)架构很直观,但实际上,要实现它却是一项挑战。就背景而言,将这一过程自动化是我们构建 Cortex 的核心动机。


Gmail 团队并没有分享他们的推理基础设施的细节,但行业标准的做法是:


  • 将微服务容器化;

  • 将其部署到用于推理的 Kubernetes 集群;

  • 将其公开为负载平衡器背后的 Web 服务。



来源:Cortex 部署架构


除此之外,还有一系列基础设施的问题需要解决。Kubernetes 需要与设备插件集成才能识别 GPU/ASIC,这可能会带来自动缩放的问题。另外还需要监控模型性能。更新需要在不会使 API 崩溃的情况下进行。


构建所有这些云基础设施需要将许多不同的工具融合在一起:Docker、Kubernetes、云服务、Web 框架、服务库等等。在软件工程师向机器学习工程师过渡的过程中,这是最让我们感到沮丧的一步,但也是我们构建 Cortex 来实现自动化的一步:



来源:Cortex 仓库


3. 实现目标延迟

即使使用可扩展的模型进行部署,但延迟仍然是一个问题。Gmail 团队开发的混合模型速度很快,但微服务仍然有“几百毫秒”的平均延迟。


为了将延迟降低到小于 100 毫秒,他们需要改进硬件。具体来说,他们使用的是 TPU,一种由 Google 开发的用于机器学习的 ASIC(特殊应用集成电路),而不是 CPU。在 TPU 上,平均延迟降至 10 毫秒左右。


尽管这在概念上很简单,但实际实现起来相当困难。部署到像 Google 的 TPU 或 Amazon 的 Inferentia 之类的 ASIC,需要进行相当多的配置。


译注:TPU ( tensor processing unit,张量处理器)是 Google 为 机器学习全定制的人工智能加速器专用集成电路,专为 Google 的深度学习框架 TensorFlow 而设计。Inferentia 是一个由 AWS 定制设计的机器学习推理芯片,旨在以极低成本交付高吞吐量、低延迟推理性能。Inferentia 将支持 TensorFlow、Apache MXNet 和 PyTorch 深度学习框架以及使用 ONNX 格式的模型。 Inferentia 可以与 Amazon SageMaker、Amazon EC2 和 Amazon Elastic Inference 一起使用。ASIC 是特殊应用集成电路(Application-specific integrated circuit),指依产品需求不同而客制化的特殊规格集成电路;相反地,非客制化的是应用特定标准产品(Application-specific standard product)集成电路。


例如,我们最近在 Cortex 内部开发了 Inferentia 的支持,并面临两个挑战:


  • 为了在 Inferentia 实例上的模型提供服务,Cortex 需要与 AWS 的 Neuron API 集成。Neuron 是用来编译模型的引擎,这些模型在 Inferentia 的“NeuronCores”上运行,并从编译后的模型提供预测。

  • 默认情况下,Kubernetes 不会将 Inferentia(或任何 ASIC)识别为资源。我们必须找到一个设备插件来允许 Kubernetes 与 Inferentia 一起使用。Inferentia 设备插件非常新,目前还处于 beta 测试阶段,因此我们花了很多时间来设计一个稳定的集成。


然而,建立这一切至少需要一个贡献者的长期的、全职的工作,并得到其他人的帮助。对于任何团队来说,必须在内部进行这样的实验,看看它是否能够充分降低延迟,这都是一种冒险的资源消耗。


为什么软件工程和数据科学的交叉如此激动人心

看完所有这些内容后,你可能会觉得,大多数问题都是软件工程问题。架构系统、编写 API、配置云基础架构等等,所有这些都不是纯粹的机器学习工作。


不过,所有的这一切,都还是机器学习特有的。


为部署的模型配置自动缩放,在概念上类似于为任何微服务做同样的事情,但由于推理的特殊性,它需要不同的资源和方法。同样的,用 Python 编写一个 REST API 对大多数软件工程师来说都很熟悉,但编写一个使用 top-k 过滤来解析模型预测的 REST API 却是一个机器学习特有的任务。


换句话说:


  • 数据科学工作流从数据中产生见解,强调有利于实验而不是生产的工具,如 Notebooks。

  • 另一方面,软件工程工作流一直以生产为中心,而不是特定于机器学习。


由于两者之间存在的差距,历来很少有团队能够将模型部署到生产中。机器学习工程填补了这一空白,随着生态系统的成熟,越来越多的团队能够使用模型来构建软件。


非营利组织可以使用图像分类实时抓捕偷猎者。独立工程师可以开发人工智能驱动的视频游戏。两人初创公司可以使用机器学习来“颠覆”电子商务物流。一个小团队可以在资金很少的情况下在美国多个城市推出机器学习驱动的癌症筛查


数据科学永远是推动前沿的力量,而机器学习工程则是连接实验室中的可能和生产中的实际之间的桥梁。


作者介绍:


Caleb Kaiser,Cortex Lab 创始团队成员,曾在 AngelList 工作,最初在 Cadillac 供职。


原文链接:


https://towardsdatascience.com/why-we-built-a-platform-for-machine-learning-engineering-not-data-science-54004d5b6e95


2020-06-30 19:002029

评论

发布
暂无评论
发现更多内容

关于TiDB数据脱敏的一些想法

TiDB 社区干货传送门

实践案例

TiDB在个推的落地实践 | 解决热点难题,提升性能超千倍

TiDB 社区干货传送门

性能调优

DM 分库分表 DDL “乐观协调”模式介绍

TiDB 社区干货传送门

迁移 TiDB 底层架构

分布式数据库TiDB在百融云创的探索与实践

TiDB 社区干货传送门

实践案例

大量 SET autocommit 导致的 TiDB Server CPU 高案例

TiDB 社区干货传送门

故障排查/诊断

TiDB4PG 之兼容 Gitlab

TiDB 社区干货传送门

TiDB架构浅析

TiDB 社区干货传送门

TiDB 底层架构

TiDB BR 备份至 MinIO S3 实战

TiDB 社区干货传送门

管理与运维

前缀索引在特殊场景下的优化尝试

TiDB 社区干货传送门

实践案例 TiDB 底层架构

专栏技术文章发布指南&奖励

TiDB 社区干货传送门

社区活动

TiDB学习之路

TiDB 社区干货传送门

实践案例

TiCDC 4.0.15 初体验

TiDB 社区干货传送门

实践案例

TiSpark On Kubernetes实践

TiDB 社区干货传送门

实践案例

记一次TiDB的临时救场

TiDB 社区干货传送门

实践案例

有关 TiDB 升级的二三事——教你如何快乐升级

TiDB 社区干货传送门

版本升级

5分钟搞定 MySQL 到 TiDB 的数据同步

TiDB 社区干货传送门

实践案例

TiSpark数据写入过程解析(源码解析)

TiDB 社区干货传送门

TiDB 底层架构

带着问题读 TiDB 源码:Power BI Desktop 以 MySQL 驱动连接 TiDB 报错

TiDB 社区干货传送门

故障排查/诊断 TiDB 源码解读

在TiDB中实现一个关键字——Parser篇

TiDB 社区干货传送门

TiDB 底层架构

TiDB监控Prometheus磁盘内存问题

TiDB 社区干货传送门

故障排查/诊断

探索TiDB Lightning源码来解决发现的bug

TiDB 社区干货传送门

TiDB 底层架构

TiDB 社区专栏:让技术人员成为更好的读者/作家

TiDB 社区干货传送门

新版本/特性发布 新版本/特性解读

回顾下Hackathon中的TiCheck

TiDB 社区干货传送门

实践案例

关于我作为前端报名 TiDB Hackthon 2021 然后被毫无悬念地淘汰这档事

TiDB 社区干货传送门

DBA之伤-truncate/drop

TiDB 社区干货传送门

使用 TiUP 安装部署 TiDB 集群实验流程

TiDB 社区干货传送门

版本升级 集群管理 管理与运维 安装 & 部署 扩/缩容

JOIN 查询的执行计划 比较

TiDB 社区干货传送门

性能调优 TiDB 底层架构

Ti-Click:通过浏览器快速搭建 TiDB 在线实验室 | Ti-可立刻团队访谈

TiDB 社区干货传送门

PlacementRules in SQL 初试

TiDB 社区干货传送门

x86和ARM混合部署下的两地三中心方案验证

TiDB 社区干货传送门

实践案例

Dumpling 导出表内并发优化

TiDB 社区干货传送门

性能调优 TiDB 底层架构 备份 & 恢复

为什么我们建立机器学习工程平台,而不是数据科学平台?_AI_Caleb Kaiser_InfoQ精选文章