为什么我们建立机器学习工程平台,而不是数据科学平台?
云栖号资讯:【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!
大约一年前,我们中的一些人开始研究开源机器学习平台 Cortex 。我们的动机很简单:鉴于从模型中构建应用程序是一种可怕的体验,充满了胶水代码和样板,我们需要一个工具,能将这些都予以抽象化。
虽然我们对自己在 Cortex 上的工作感到非常自豪,但我们只是过去一年来加速趋势的一部分,那就是机器学习工程生态系统的发展。公司雇佣机器学习工程师的速度比以往任何时候都要快,发布的项目也越来越好。
尽管这让我们感到很兴奋,但我们仍然经常听到这样一个问题:“什么是机器学习工程?”
在本文中,我想为读者们解释什么是机器学习工程,以及为机器学习工程师构建一个平台意味着什么。
什么是机器学习工程?为什么它不是数据科学?
让我们先从更多人熟悉的数据科学的背景来定义机器学习工程。
要给数据科学下一个定义,还不会让人愤怒评论,这很难,但我还是会试着下一个定义:
从广义上讲,数据科学是一门应用科学过程从数据中获得见解的学科。
机器学习工程是一门利用机器学习构建应用程序的学科。
显然,这里有很多重叠之处。两者都是封装了机器学习的学科。不同之处主要在于目标。顾名思义,数据科学是一门科学,而机器学习工程是一门工程学科。
这种区别在大多数学科中都存在。想一想生物学和生物医学工程。工程学科显然离不开科学家的工作:机器学习工程是建立在数据科学的工作基础上,但工程学是科学应用于世界的方式。
为了让这两者之间的区别更加具体,我们可以思考一个实际项目,并分解机器学习工程师与数据科学家的职责和需求,是有所帮助的。
从数据科学和机器学习工程的角度来看 Gmail 的 Smart Compose
Gmail 的 Smart Compose(智能撰写)是生产机器学习最普遍的例子之一,就我们的目的而言,它巧妙地阐明了机器学习工程的挑战。
让我们想象一下开发 Smart Compose。首先,我们要确定约束范围,根据 Gmail 的描述,这些约束包括:
Smart Compose 需要与 Gmail 编辑器的用户界面集成;
预测需要在小于 100 毫秒的时间内送达 Gmail 编辑器;
Smart Compose 需要扩展到 Gmail 的 14 亿用户。
这些约束中唯一涉及数据科学的是延迟需求。
训练一个足够准确和快速的模型,实际上是一个非常有趣的数据科学问题,团队通过设计一个混合模型解决了这个问题,该混合模型在准确性方面做出了很小的牺牲,但却在速度方面获得了巨大的提高(我建议读者们阅读完整的报告)。
以数据科学家的创新为基础,机器学习工程师现在必须采用这种模型,并将其转化为 Smart Compose。他们采用的方法是任何软件工程师都熟悉的:
- 定义架构
这个模型应如何与 Gmail 客户端集成?需要考虑的有以下几点:
模型过大,无法在本地部署到客户端;
相对而言,推理的计算成本昂贵;
Gmail 有 14 亿用户。
在这种情况下,最好的方法是做成微服务架构,在这种架构中,模型作为 Web API 进行部署,可以由 Gmail 客户端查询。这样,推理的计算开销就可以与应用程序的其他部分隔离开来,并且服务可以横向扩展。
然而,在这种架构中也存在一些挑战。
- 扩展模型微服务
在白板上绘制这种“模型即微服务”(model-as-a-microservice)架构很直观,但实际上,要实现它却是一项挑战。就背景而言,将这一过程自动化是我们构建 Cortex 的核心动机。
Gmail 团队并没有分享他们的推理基础设施的细节,但行业标准的做法是:
将微服务容器化;
将其部署到用于推理的 Kubernetes 集群;
除此之外,还有一系列基础设施的问题需要解决。Kubernetes 需要与设备插件集成才能识别 GPU/ASIC,这可能会带来自动缩放的问题。另外还需要监控模型性能。更新需要在不会使 API 崩溃的情况下进行。
构建所有这些云基础设施需要将许多不同的工具融合在一起:Docker、Kubernetes、云服务、Web 框架、服务库等等。在软件工程师向机器学习工程师过渡的过程中,这是最让我们感到沮丧的一步,但也是我们构建 Cortex 来实现自动化的一步:
- 实现目标延迟
即使使用可扩展的模型进行部署,但延迟仍然是一个问题。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://yqh.aliyun.com/zhibo立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK
原文发布时间:2020-06-30
本文作者:Caleb Kaiser
本文来自:“InfoQ ”,了解相关信息可以关注“[InfoQ](https://www.infoq.cn/article/o6CcX2mIhjhbmFWWOa1g)
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
“玄姐”,特立独行的架构师——对话阿里云 MVP孙玄
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 简介: 曾任58集团技术委员会主席、转转首席架构师的孙玄,一头飘逸长发,江湖人称“玄姐”。在职场风生水起时毅然辞去数百万年薪职位、放弃数千万期权。跟他聊过,我才直观体会到,原来梦想能有如此巨大的力量。 以下为孙玄的个人专访,推荐阅读(约4分钟)。 重新认识自己,扬帆再启航 从浙江大学毕业后,我进入百度成为一名后端研发工程师。像每一个应届生一样,最初在大厂的日子成长很快,尤其是前一两年能学到不少东西。后来我渐渐发觉自己的岗位所能涉及到的知识面很狭窄,而我内心渴望能在技术深度和广度方面有持续的提升,经过慎重思考,在2011年我离开百度,加入58集团。年少轻狂的我为了彰显个性,大学起就留了一头长发,入职时HR根据照片把我登记为女性。当时我在群里聊天很活跃,大家就称呼我为“玄姐”,到现在员工也会这么喊我。 其实在2011年,58的体量与百度相去甚远,入职初期,我感受到一些落差,公司请求并发量不算太大、技术老旧,也开始质疑自己的选择。当时老板给我安排的工作锻炼了我多维度的能力,比如项目管理、待人接...
- 下一篇
测一测|你的云原生架构几分熟?
云计算作为数字化转型至关重要的一环,正在重构整个 IT 产业,而作为云计算的服务新界面,以容器为代表的云原生技术成为充分释放云计算红利的关键。遗憾的是,在探索云原生的道路上只有少数企业获得成功。经过调研,企业遇到的难题大多相似:建设过程长、重复基础建设、应用平台割裂、缺少标准和规范,甚至对云原生及云原生架构的解释不尽相同。 那么,企业该从什么维度制定云原生架构的落地战略?云原生时代的企业该如何落地互联网分布式架构?这些问题都需要企业花费大量时间和成本去探索。鉴于此,越来越多企业希望能够通过云原生架构成熟度模型以指导数字化转型实践,并将之作为衡量转型成果水平的统一标准,提高转型效果。 因此,我们正式发布《云原生架构成熟度模型》并上线测试。 与此同时,我们将于 7 月上线《云原生架构白皮书》对《云原生架构成熟度模型》进行更加深入的解读,敬请期待!识别下方海报二维码或点击链接了解详情:https://jinshuju.net/f/XCU3lN。 “阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂...
相关文章
文章评论
共有0条评论来说两句吧...