軟件開發人員學習ML：是否是本末倒置了？

我還記得第一次學寫代碼的情景。當時我還在上高中，個人程序員父親打開文本編輯器，敲入了這些代碼：

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World.");
    }
}

我問他：「這段代碼幹嗎用的？」

他答道：「它會在屏幕上打印‘Hello World’。」

「public 是什麼？class 是什麼？static 是什麼？……」

「先不要在乎這些，它們都只是模板代碼。」

但這些所謂的模板代碼讓我感到很疑惑，因而我開始瞭解這些關鍵字的意思。事實證實，這些複雜而無聊的東西給我年輕的編程夢想蒙上了一層陰影。

如今學習軟件開發比我上高中時要容易得多，這要感謝像 codecademy.com 這樣的網站，它們提供了基本的開發環境，傾向於教授解釋型編程語言，好比 Python 和 Javascript。你能夠在幾分鐘內從對編程一無所知變成可以寫出第一條能夠在瀏覽器上執行的條件語句。沒有繁瑣的環境設置、安裝、編譯器或樣板代碼——你直接進入編程最有趣的部分。

這是人類最好的學習方式。首先，咱們被灌輸高層次的核心概念，而後開始理解具體細節。咱們先學習 Python，而後是 C 語言，而後是彙編，而不是反過來。

不幸的是，如今不少學習 ML 的人跟我第一次接觸 Java 時的狀況徹底同樣。他們最早被灌輸全部的底層細節——分層架構、反向傳播、dropout 等，而後會以爲 ML 很複雜，認爲須要先掌握線性代數，最後就想着要放棄。

這個有點遺憾，由於在不久的未來，大多數 ML 開發人員將再也不須要考慮或瞭解任何底層的東西，就像咱們一般不須要編寫彙編代碼或本身實現 TCP 協議棧或加密庫同樣，ML 將成爲咱們的工具，工具的實現細節交給一小部分專家就能夠了。到了這個時候——也就是在 ML 被「大衆化」以後——開發人員須要瞭解的不是實現細節，而是如何部署這些智能算法。

ML 發展到了什麼程度

如今，若是你想要開發一個神經網絡來識別照片中的貓或者預測你的下一條推文是否會被瘋傳，能夠學一下 TensorFlow 或 PyTorch。這些基於 Python 的深度學習庫是目前最流行的設計神經網絡的工具，它們都不到 5 歲。

在它短暫的生命週期中，TensorFlow 已經變得比 5 年前友好得多。在早期，要成爲一個高效的 TensorFlow 程序員，你不只要了解 ML，還要了解分佈式計算和圖架構。即便是寫一個簡單的打印語句也很費勁。

今年秋季，TensorFlow 2.0 正式發佈，它對開發人員更加友好。下面是使用 TensorFlow 2.0 構建一個「Hello World」模型的代碼：

model = tf.keras.models.Sequential([
    tf.keras.layers.Dense(512, activation='relu'),
    tf.keras.layers.Dropout(0.2),
    tf.keras.layers.Dense(32, activation='relu'),
    tf.keras.layers.Dense(1, activation='softmax')
])
model.compile(optimizer='adam',
                            loss='sparse_categorical_crossentropy'),
                            metrics=['accuracy']))
model.fit(x_train, y_train, epochs=5)
model.evaluate(x_test, y_test)

若是你之前設計過神經網絡，就很容易看懂上面這段代碼。但若是以前沒學過，或者正在學習，可能就會有一些問題。好比，dropout 是什麼意思？這些密集的層是什麼東西？你須要多少層，應該把它們放在哪裏？sparse_categorical_crossentropy 又是什麼？TensorFlow 2.0 確實簡化了構建模型時的一些繁文縟節，但並無將模型的實際架構設計抽離出去。

將來會怎樣

那麼，ML 工具的將來會是什麼樣子呢？谷歌、亞馬遜、微軟和蘋果公司的人都在花時間研究這個問題。另外，做爲谷歌的一名工程師，我也花了不少時間思考這個問題。

首先，咱們將會看到愈來愈多的開發人員使用預先訓練好的模型來完成常見的任務。也就是說，咱們將再也不本身收集數據和訓練神經網絡，而是使用谷歌、亞馬遜和微軟提供的模型。不少雲廠商已經在作相似的事情了。例如，你能夠經過調用谷歌雲的 REST 端點來使用預先訓練好的神經網絡，用它們來：

• 抽取圖像中的文本；
• 標記照片中的物體；
• 把語音轉成文本；
• 翻譯不一樣的語言；
• 識別文本的情感色彩；

• 其餘

你也可使用谷歌的 ML Kit 或蘋果的 Core ML 等工具在移動設備上運行預先訓練好的模型。

坦率地說，與本身使用 TensorFlow 構建的模型相比，預先訓練好的模型更加準確，由於它們是由谷歌研究人員基於整個互聯網的數據訓練出來的，他們使用了大量的 GPU 和 TPU。

預訓練模型的缺點是，它們解決的是通常性問題，好比識別圖像中的貓和狗，而不是特定領域的問題，好比識別裝配線上某個部件的缺陷。

但即便是爲特定領域的任務訓練特定的模型，ML 工具對咱們也很友好。

Teachable Machine——一個在瀏覽器中構建視覺、手勢和語音模型的工具

谷歌的 Teachable Machine 爲用戶提供了拖放式界面，能夠直接在瀏覽器中收集數據和訓練模型。今年早些時候，麻省理工學院發佈了一個相似的無代碼界面，用來構建在觸摸屏設備上運行的模型，這個界面是爲醫生等非編程人員設計的。微軟和一些初創公司（lobe.ai）也提供了相似的解決方案。Google Cloud AutoML 是一個企業級的自動化模型訓練框架。

如今要學些什麼

隨着 ML 工具變得愈來愈容易使用，（不須要成爲專家的）開發人員的技能也將發生變化。因此，你如今應該學些什麼？

要知道何時該用 ML 並不容易

ML 算法與其餘軟件的不一樣之處在於它們具備機率性。即便是一個高度精確的模型有時也會出錯，這意味着它並非不少問題的正確解決方案。以基於 ML 的語音到文本轉換算法爲例：有時候，你想讓 Alexa「關掉音樂」，它卻幫你把鬧鐘調到凌晨 4 點。若是醫學版的 Alexa 把醫生說的 Adderall（一種治療多動症的藥）誤解成 Enulose（一種緩瀉藥），那就糟糕了。

知道什麼時候以及如何在生產環境中使用 ML 模型始終是一個難題，在這些狀況下尤其如此：

1. 風險很高；
2. 人力資源有限；

3. 人類有偏見，預測不許確。

以醫學成像爲例。如今全球範圍內都很缺醫生，而 ML 模型在診斷疾病方面每每比訓練有素的醫生更準確，但你會但願讓一個算法來決定你是否患有癌症嗎？用於幫助法官判決刑期的 ML 模型也相似。模型是有偏見的，人也是。

知道何時可使用 ML 以及如何正確地部署 ML 模型並非一件容易的事情，而這個問題不會很快獲得解決。

可解釋性

衆所周知，ML 模型是不透明的，因此它們有時候也被叫做「黑匣子」。若是你只是把「這是個人神經網絡告訴個人」做爲惟一的證據，就不太可能說服你的副總裁作出重大的商業決策。另外，若是你不明白爲何你的模型會作出這樣的預測，也可能就意識不到它會作出有偏見的決定（例如，拒絕貸款給特定年齡層或屬於某個郵政編碼區域的人）。

正由於如此，ML 領域的不少參與者都專一於構建「可解釋的 AI」特徵工具——可讓用戶檢查模型使用了什麼特徵進行預測。但從整個行業的角度來看，咱們尚未徹底解決這個問題，不過咱們正在取得進展。11 月份，谷歌發佈了一套可解釋性工具和 Model Cards——一種幫助用戶理解 ML 模型侷限性的可視化指南。

谷歌的臉部識別 Model Card 顯示了該模型的侷限

創造性的應用

有些開發人員擅長機器學習，有些研究人員擅長神經科學，但不多有人同時精通這兩個領域。這個問題幾乎在任何複雜的領域中都存在。將來幾年，ML 的主要進步可能不是數學方法方面的改進，而是來自不一樣專業領域的人學會了足夠多的機器學習知識，並將其應用到他們的領域中。例如，醫學成像領域最使人感到興奮的突破——經過掃描就能發現有害疾病——並非由於應用了新的神經網絡架構，而是由於將標準模型應用在了新奇的問題上。所以，若是你是一名軟件開發人員，而且掌握了額外的專業知識，那你就已經走在了別人的前面。

若是我如今從頭開始學習 AI，至少會關注這些問題。我發現本身花在從頭構建模型上的時間愈來愈少，而是愈來愈多地使用高級工具，如 AutoML 和 AI API，並將注意力集中在應用程序開發上。