雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
大約一年前，我們中的一些人開始研究開源機器學習平台 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）