如何從先期的失敗中找到一條成功之路，本文試圖作了一番探討。——Caleb Kaiser寫於2020年4月24日。

作者 | Caleb Kaiser

編譯 | 蘇本如

出品 | AI科技大本營（ID:rgznai100）

2019年初，我們幾個人嘗試構建一個端到端的機器學習（ML – Machine Learning）框架。我們從這次嘗試中得到的基本體會是，構建機器學習管道是一個令人沮喪的、毫無邏輯的體驗，而且我們應該可以構建更好的東西。

這次嘗試並沒有按照原先計劃地進行。

我將在本文對這次嘗試作一個詳盡地介紹，下面先介紹大致情況：

• 我們使用Kaggle數據集爲機器學習管道的數據接收、訓練、部署等不同階段編寫了抽象。

• 我們將代碼庫開源並共享。一個月後，我們的項目登上了HN的首頁。每個人都喜歡那些改進機器學習用戶體驗的想法。

• 六個月後，我們只收獲了幾百顆GitHub星星，幾乎沒有人使用它。我們不得不將我們的傲氣擱到一邊，刪除了代碼庫中90%的代碼。

在經歷了以上這些過程後，我們構建了一個更好的項目 - Cortex，我們的模型服務基礎設施。對於任何對機器學習研究和/或應用感興趣的人來說，我們想讓這個過程成爲一種警示：

生產型機器學習系統確實需要更好的用戶體驗，但是機器學習生態系統是非常複雜和不斷變化的，這使得構建一個涵蓋大量用例的解決方案非常困難。

爲什麼想構建端到端的機器學習框架？

我們大多數人（Cortex的貢獻者）都有devops和web開發的背景，習慣於將應用程序的不同層抽象爲單個接口的框架。

當我們進入機器學習時，每個人都被工具的支離破碎所震驚。我們想構建推薦引擎和聊天機器人（或者更確切地說，會話代理），但在這樣做的過程中，我們發現自己不得不在不同的環境之間（Jupyter Notebook、終端、AWS控制檯等等）跳躍。然後把包含有膠水代碼和TensorFlow樣板文件的整個文件夾寫到一起，用一個稱爲“管道”的強力膠帶粘合起來。

如果我們可以用一個配置文件和命令粘合在一起來代替以上所有的步驟，比如：

    
      $ deploy recommendation_engine    
  

那顯然是個好的主意。

所以我們就這麼做了。我們構建了這樣的一個框架，它使用Python轉換數據，使用YAML構建管道，並使用一個CLI（命令行界面）控制所有步驟：

當你使用我們支持的窄技術堆棧，同時加上對API的限制，向它提供Kaggle數據集時，成爲了一個非常好的框架。

然而，如果你想嘗試在現實世界中使用它，基本上很可能它不會與你的技術堆棧一起工作。毫無疑問這是一個問題。雖然這個問題的其中一部分原因歸結於我們的設計，但很大一部分原因實際上是因爲構建端到端機器學習框架的固有侷限，我們只是在構建了這個端到端機器學習框架之後才發現這一點。

端到端機器學習框架的問題

簡單的一種說法是：對於端到端的框架來說，生產型機器學習生態系統太簡單，不可能既不靈活又正確無誤。

機器學習工程師希望使用更好的UX工具，這一點我們沒有錯。我們的錯誤在於我們以爲可以構建一個覆蓋多個用例的端到端機器學習框架（特別在只有幾個貢獻者的情況下）。

有一件事很值得去做（而在項目的早期被我們忽略了），那就是思考一下曾經給我們啓發的web框架，並記住他們第一次嶄露頭角的時候。

Rails、Django和Symfony，作爲web應用的新MVC框架浪潮的一部分，它們都是在2004年到2005年間發佈的。當時的web開發還不能稱爲“穩定”，尤其是考慮到自那以後它們是如何變得成熟的（在很大程度上要感謝那些框架），但是web開發人員所做的工作和現在相比仍然有高度的相似性。

事實上，Rails最早的口號之一是“你不是一片美麗而獨特的雪花”，正是基於這樣的一個事實：大多數web開發人員正在構建架構上類似的應用程序，這些應用程序可以在相同的配置上運行。

生產型機器學習系統還未發展到那個階段。一切仍在變化之中。數據科學家處理的數據類型、使用的模型體系結構、喜歡的語言/框架、應用程序的推斷要求，以及幾乎所有你能想象到的一切東西，都在不斷變化中。

而且，這個領域本身變化也很快。自18個月前Cortex首次發佈以來：

• PyTorch已經從一個僅僅前景看好的項目發展成爲最流行的機器學習框架，在此期間許多專門的機器學習訓練庫（如微軟的DeepSpeed）已經發布出來。

• OpenAI發佈了有史以來最大的模型，可以運行帶有15億個參數的GPT-2。此後，谷歌、Salesforce、微軟和Nvidia都發布了更大的機型（有些是同一數量級的）。

• 大量初創企業已經開始使用遷移學習（Transfer Learning）和預訓練模型來優化和部署具有少量數據的模型（比如說，並非每個人現在都需要一個100節點的Spark羣集）。

所有這些都在不斷變化中，所以試圖構建一個支持“合適”技術堆棧的端到端框架從一開始就註定了失敗。

每個人都會要求他們需要的“一個特性”，而沒有人有相同的要求。我們試圖構建一些通用的特性，但很快就發現這是不可行的，至少不是我們想象的那樣。

專注於模型服務基礎設施

構建一個端到端的機器學習框架是很困難的，因爲大部分的機器學習生態系統仍然是“蠻荒的西部”。然而，其中的“模型服務”已經具有了穩定性和一致性。

不管他們使用什麼堆棧，大多數團隊都是通過先將模型封裝在API中，然後部署到雲端（儘管他們不喜歡這樣做）來將其投入生產，。

數據科學家不喜歡它，因爲用於構建彈性web服務的工具，如 Docker、Kubernetes、EC2/GCE、負載均衡器等等，都不在他們的觸手可及之處。DevOps工程師對模型推斷的獨特之處感到惱火。

但是對我們來說，這是一個機會。“模型作爲微服務（model-as-a-microservice）”的設計模式對所有團隊來說是一致的，而它提供的工具，因爲它是基礎設施（而不是機器學習生態系統）的一部分，所以非常穩定。更有利的是，作爲軟件工程師，我們在構建生產型web服務方面比在構建機器學習管道方面更有經驗。

所以，我們想在模型服務上嘗試一下。我們應用了相同的設計原則，抽象了聲明性YAML配置和最小CLI背後的所有低層次的不同，並自動化了將一個經過訓練的模型轉換爲一個可伸縮的生產型web服務的過程：

通過專注於模型服務，我們可以對堆棧的其餘部不加理會（只要模型有Python綁定，Cortex就可以爲其服務）。因爲Cortex可以插入任何堆棧，所以我們對Cortex在底層使用的工具有了話語權，這又使得構建更高級別的特性變得更加容易。

例如，自從發佈用於模型服務的Cortex以來，我們增加了對GPU推斷、基於請求的自動縮放、滾動更新和預測監視的支持。我們不需要爲十幾個不同的容器運行時和集羣編排器實現這些功能。Cortex在底層使用Docker和Kubernetes，用戶從來不需要接觸它們中的任何一下。

到目前爲止，這種改變似乎正在發揮作用：

將web開發經驗應用到機器學習工具中

從哲學上講，網絡框架對我們如何看待Cortex有很大的影響。

Rails和Django之類的框架使得程序員的工作效率和幸福感倍增。要構建一個web應用程序，你不必擔心配置SQL數據庫、實現請求路由、或編寫自己的SMTP方法來發送電子郵件。所有這些都從直觀，簡單的界面中抽象出來。

簡而言之，這就是我們對Cortex的看法。數據科學家不必學習Kubernetes，他們應該專注於數據科學。軟件工程師們不必花上幾天的時間來研究如何避免5 GB的模型浪費他們的AWS賬單，他們應該可以自由地構建軟件。

希望隨着機器學習生態系統的成熟和穩定，我們能夠將這一理念擴展到堆棧的其餘部分。目前，模型服務是一個不錯的開始。

https://towardsdatascience.com/we-tried-to-build-an-end-to-end-ml-platform-heres-why-it-failed-190c0f503536

• 360金融首席科學家張家興：別指望AI Lab做成中臺

• 用 Python 實現手機自動答題，這下百萬答題遊戲誰也玩不過我！
  

• AI 世界的硬核之戰，Tengine 憑什麼成爲最受開發者歡迎的主流框架？

• 關於 Docker ，你必須瞭解的核心都在這裏了！

• 5分鐘！就能學會以太坊 JSON API 基礎知識