本文最初發表在 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 供職。
原文鏈接：