未來，構建 ML 產品將更加有趣，并且這些系統會工作得更好。隨著 ML 自動化工具的不斷改進，數據科學家和 ML 工程師將把更多的時間花在構建優秀的模型上，而花在與生產級 ML 系統相關的繁瑣但必要的任務上的時間會更少。

[[315891]]

AI 是一個系統工程問題。

構建一個有用的機器學習產品需要創建大量的工程組件，其中只有一小部分涉及 ML 代碼。構建生產級 ML 系統涉及到很多工作，比如構建數據管道、配置云資源和管理服務基礎設施。

傳統上，ML 的研究主要集中于創建更好的模型，推動語言建模和圖像處理等領域前沿技術的發展。很少有人在系統層面關注設計和實現生產級 ML 應用程序的優秀實踐。盡管得到的關注較少，但是 ML 系統層面的設計和工程挑戰仍然非常重要——創建有用的東西比構建良好的模型需要的東西更多，它需要構建良好的系統。

真實世界的

ML2015 年，谷歌的一個團隊繪制了下面這幅圖：

它顯示了真實世界的 ML 系統中專門用于建模的代碼量(小黑框)與 ML 應用程序的支撐設施和管道所需的代碼的比較。這張圖表并沒有多么令人驚訝。對于大多數項目來說，構建一個生產系統所涉及到的大多數令人頭痛的問題并不是來自典型的 ML 問題，如過擬合或欠擬合，而是來自于在系統中構建足夠的結構以使模型可以按預期工作。

生產級 ML 系統

構建一個生產級 ML 系統可以歸結為構建一個工作流——從數據攝取到模型服務的一系列步驟，其中每個步驟前后串聯，并且足夠健壯，可以在生產環境中運行。

工作流從一些數據源開始，包括創建模型端點所需的所有步驟——輸入數據預處理、特征工程、訓練和評估模型、將模型推送到服務環境，以及在生產環境中持續監控模型端點。

這個工作流中的 特征工程>訓練>調優 部分通常被認為是機器學習的“藝術”。對于大多數問題，特征設計、模型架構構建和超參數調整，都有許許多多的方法，以至于數據科學家 /ML 工程師只能依賴于直覺和實驗的混合。建模過程也是機器學習的一個有趣部分。

建模與工程

在不同的應用場景和問題域中，這個建模過程都會有所不同。如果你訓練一個模型在 Netflix 上推薦內容，這個建模過程與你為客戶服務構建聊天機器人會有很大的不同。不僅底層數據的格式會不同(稀疏矩陣 vs 文本)，而且預處理、模型構建和調優步驟也會有很大的不同。但是，盡管建模過程在跨應用場景和問題域時基本上都是特有的，但工程上的挑戰很大程度上是相同的。

無論你將哪種類型的模型投入生產，圍繞該模型構建生產工作流的工程挑戰在很大程度上是相同的。

這些跨 ML 領域的工程挑戰的同質性是一個巨大的機會。 在未來(大部分是現在)，這些工程挑戰將在很大程度上實現自動化。將 Jupyter Notebook 中創建的模型轉換成生產級 ML 系統的過程將變得更加容易。不需要創建專門的基礎設施來解決這些挑戰，數據科學家 /ML 工程師已經使用的開源框架和云服務將在底層自動實現這些解決方案。

大規模數據攝取

所有生產級 ML 工作流都從一個數據源開始。通常，與數據來源相關的工程挑戰是圍繞大規模數據攝取展開的——我們如何從各種數據來源導入和預處理數據集，因為這些數據及太大，無法裝入內存。

開源機器學習框架通過開發數據加載程序，在很大程度上解決了這個問題。這些工具(包括 TensorFlow 的 tf.data API 和 PyTorch DataLoader 庫)將數據分段加載到內存中，并且幾乎可以用于任何大小的數據集。它們還提供動態特征工程，并且可以擴展到生產環境。

加速模型訓練

ML 社區做了大量的工作來減少訓練大型模型所需的時間。對于大型訓練工作，通常會將訓練工作分配給一組機器(訓練集群)。還有一種常見的做法是使用專門的硬件(GPU 和現在的 TPU)來進一步減少訓練模型所需的時間。

傳統上，在多臺機器和設備上分配訓練操作需要修改模型代碼，這并不簡單。為了能真正獲得使用機器集群和專用硬件所帶來的效率提升，代碼必須針對每個訓練步驟智能地分割矩陣操作并合并參數更新。

現代工具使這個過程變得更加容易。TensorFlow Estimator API 從根本上簡化了將模型代碼配置為在分布式集群上進行訓練的過程。使用 Estimator API，設置 一個參數 就可以將訓練圖自動分布到多臺機器 / 設備上。

像 AI Platform Training 這樣的工具能夠提供隨需應變的資源供應，實現分布式集群上的模型訓練?？梢允褂?bash shell 命令 為訓練作業提供多種機器和設備類型(高性能 CPU、GPU 設備、TPU)。

可移植、可擴展、可重復的 ML 實驗

創建一個既能實現快速原型設計又能夠標準化實驗過程的環境會面臨一連串的工程挑戰。

如果沒有一個清晰的方法來重復過去的實驗，并將模型元數據(參數值)與觀察到的評估指標關聯起來，超參數調優(更改模型參數的值以降低驗證錯誤)的過程就不可靠?？焖俚透咝н\行實驗的能力需要分布式和硬件加速器支持下的大規模訓練。此外，如果 ML 代碼不可移植，實驗過程將變得不可管理——其他團隊成員 / 涉眾無法復制實驗，并且隨著新數據的出現，生產中的模型也無法重新訓練。

就我個人而言，我在團隊中 為 AI Hub 構建容器，我們正在努力幫助解決這些挑戰。我們將 ML 算法(XGBoost、ResNet 等)的高性能實現構建為 Docker 容器。容器提供了對 AI 平臺的原生支持，并且會默認保存模型元數據，提供了一個可重復的過程來運行實驗。這些容器支持分布式訓練，可以在 GPU 或 TPU 設備上運行。它們還具有可移植性——只要安裝了 Docker，容器就可以在任何地方由任何人運行。

服務基礎設施

生產級 ML 系統兩端的規模都很大：大規模的數據攝取和模型訓練，以及大規模的模型服務。一旦一個模型被訓練過，它就必須被導出到一個環境中，用來生成推斷。正如消費者網站需要處理 Web 流量的巨大波動一樣，模型端點也必須能夠處理預測請求的波動。

像 AI Platform Prediction 這樣的云工具為模型服務提供了一個可擴展的解決方案。云服務的彈性特性允許服務基礎設施根據預測請求的數量伸縮。這些環境還允許對模型進行持續監控，并且可以編寫測試過程來檢查模型在生產過程中的行為。

未來更好的 ML 系統

未來，構建 ML 產品將更加有趣，并且這些系統會工作得更好。隨著 ML 自動化工具的不斷改進，數據科學家和 ML 工程師將把更多的時間花在構建優秀的模型上，而花在與生產級 ML 系統相關的繁瑣但必要的任務上的時間會更少。