“機器學習還是很難用！

機器學習仍然很難用，但情況開始有所改善了。

以下為譯文：

我是一名Cortex貢獻者，Cortex是一個用於在生產中部署模型的開源平臺。首先宣告，以下內容是基於我對一些機器學習團隊的觀察總結出來的，而不是一份針對該行業的學術調查。

用一個在軟體行業中無處不在的東西舉例子吧，就比如資料庫。建立一個資料庫意味著什麼？對於一名Postgres貢獻者來說，“建立一個資料庫”就像一百萬行C程式碼。對於一名Rails開發者來說，看起來就僅僅是一句rake db：create。

顯然，二者都沒錯，只不過它們代表的抽象級別不同，適用於不同工程師的不同側重點。

這就是軟體構建自己的方式。為現代應用程式提供支援的基本軟體——資料庫、Web伺服器、請求路由器、雜湊庫等等——在很大程度上得到了廣泛傳播，是因為它們的抽象層使得非專業人士也可以訪問它們。

機器學習歷來缺乏這種抽象層，這限制了它的採用率。但是現在，情況正在發生變化。新的一波專門致力於讓機器學習應用起來更容易的專案正在出現。

1.模型需要一個對開發人員來說更友好的介面

想要在生產環境中應用機器學習，你需要：

• 設計模型方面的專業知識
• 足夠的資料以及資金來訓練你的模型
• ML基礎架構知識（用於部署模型）

這樣的結果就是，任何使用ML的專案都需要由數名專家來親自執手。這個瓶頸亟待消除。

應該讓那些沒有機器學習背景的開發人員也能夠在生產中使用機器學習才對，就像一名開發人員可能沒有密碼學方面的背景，但仍然可以用雜湊庫來保護使用者資料一樣。

幸好，這終於要發生了。

2.彌補機器學習抽象的缺失

為了使ML的應用得到普及，開發人員必須能夠對機器學習有一個較高水平的瞭解——什麼是模型、微調、推論等等——並透過可用的抽象來構建應用。

許多必要的抽象已經在研究中了，它們屬於幾個關鍵的重點領域：

1.我們需要一種更簡單的方法來訓練模型

1. 現實情況是，對於許多應用機器學習的用例而言，根本不需要從頭開始訓練新模型。

例如，如果你正在開發一個會話代理，那麼幾乎可以肯定的一點就是，Google的Meena會表現得比你的模型更好。如果你正在開發一個文字生成器，那你應該去用OpenAI的GPT-2，而不是自己從頭開始構建。對於物件檢測來說，YOLOv3這樣的模型可能是你最好的選擇。

得益於轉移學習（transfer learning，將神經網路的“知識”微調到一個新領域的過程），你可以只用相對少的資料，就能依據你的任務來對這些開源的最新模型進行微調。

例如，有了gpt-2-simple這樣的新庫，你就可以使用簡單的命令列介面來微調GPT-2了：

$ gpt_2_simple finetune your_custom_data.txt

有了這一抽象層，開發人員就不需要深入瞭解ML的專業知識了，他們只需要知道如何微調就可以了。

而且可用的訓練抽象遠不止gpt-2-simple一個。Google Cloud AutoML為使用者提供了一個GUI（使用者圖形介面），可以讓使用者選擇自己的資料集並自動訓練一個新模型，無需編寫程式碼：

圖源：Google Cloud Vision

Sundar Pichai在一篇有關AutoML的文章中說：“當今需要彙集幾位博士才能設計新的神經網路，而我們希望AutoML在三到五年內能夠讓成千上萬的開發人員們都能為他們自己的特殊需求設計新的神經網路。”

2.從模型生成預測的過程必須要簡單

好的，假如說已經可以輕鬆地針對你的特定任務得到一個訓練好的模型了。你要如何根據該模型生成預測呢？

能夠提供模型服務功能的專案有很多，其中許多都與流行的ML框架相關。例如，TensorFlow有TF Serving，而ONNX有ONNX Runtime。
除了科技巨頭們之外，還有許多獨立的開源專案也在專注於解決這個問題。例如，Bert Extractive Summarizer專案可以讓使用Google的BERT提取文字摘要的過程變得更加輕鬆。以下是文件中的示例：

from summarizer import Summarizer



body = 'Text body that you want to summarize with BERT'

body2 = 'Something else you want to summarize with BERT'

model = Summarizer()

model(body)

model(body2)

使用該庫生成預測的過程就像使用一個import語句以及呼叫一次Summarizer（）一樣簡單。

隨著有越來越多這樣的專案的啟動以及開發，開發人員無需過多深入瞭解模型本身就能更輕鬆地用模型生成預測了。

3.模型的部署必須要簡單

最後的瓶頸是基礎架構。

為一個玩具應用程式提供預測是簡單而直接的，但是當你的程式需要擴大規模時，情況就會變得困難起來。以GPT-2為例：

• GPT-2大於5 GB。你需要一臺更大的，那麼也就必定更貴的伺服器來託管這麼大的模型。
• GPT-2非常吃算力。為了提供單個預測，GPT-2可以100％的利用率佔用CPU數分鐘。即使有GPU，單個預測仍可能需要花費數秒。對比之下，Web app只需用一個CPU就能夠為數百個併發使用者提供服務。
• GPT-2非常吃記憶體。除了巨大的磁碟空間和計算需求之外，GPT-2還需大量的記憶體才能保證執行而不會崩潰。

為了應對少量的使用者增長，你也需要將基礎架構擴充套件到應用程式的許多副本。這意味著需要使用Docker對模型進行容器化，使用Kubernetes對容器進行編排，以及透過你使用的雲平臺來配置自動擴充套件（autoscaling）。

你需要學會一整套工具才能搭建好用於處理機器學習部署的基礎架構，而大多數不具備專業背景的開發人員對其中很多工具都太不熟悉：

3.機器學習基礎架構技術棧

為了讓開發人員能夠使用機器學習，需要對機器學習的基礎結構進行抽象化。這就是像Cortex這樣的專案登場的時候了。（完整披露：我是一名Cortex貢獻者）。

Cortex透過一個配置檔案以及一個命令列介面對模型部署的基礎開發進行了抽象：

資料來源：Cortex Repo

Cortex這類專案的目標很簡單：拿出一個訓練後的模型，並將其轉化為任何開發人員都能用的預測API。

4.讓應用型機器學習輕鬆起來

我想講清的一點是，機器學習背後的數學原理將永遠都是很難懂的。只會呼叫個predict()函式的話，是不可能成為機器學習專家的。重點是，一名開發人員不必非得成為一名機器學習專家，就可以在自己的應用程式中使用ML。

機器學習的生態社群終於要將重心放在簡化應用型ML上了。僅會一點機器學習知識的開發人員可以對最新模型進行微調，將其包裝在API中，並使用開源，直觀的抽象將其部署在可擴充套件的基礎架構上。

結果就是，應用型機器學習將變得更加容易——而且透過這種擴充套件，幾乎所有開發者都能用得上機器學習了。