搭建容易維護難！谷歌機器學習系統血淚教訓

做者 | Sculley等

譯者 | 核子可樂

編輯 | Debra

AI 前線導讀：2014 年，谷歌一篇探討機器學習背後暗藏高額技術債的論文曾火爆一時。今天，這篇論文又出現了知名技術社區 HackerNews 的頭條。看來，即便過了 4 年時間，人工智能進入新的春天，但困擾着機器學習研究者的問題仍是相似的問題。

本文做者表示，但願這篇論文可以爲在生產環境中採用機器學習系統的開發者與維護者提供一些實用建議。做者警告稱，雖然從零搭建機器學習系統還算輕鬆，但隨後的改進卻可能存在出乎意料的困難。在閱讀本文時，讀者會清晰感覺到其中的經驗源自做者在谷歌公司任職期間來之不易的艱辛積累。

AI 前線將帶你們一塊兒重溫這篇經典文章，文章部分經驗強調「與機器學習相關，並不表明着可以完全放棄良好軟件工程實踐」，也有部份內容屬於特定於機器學習的常見陷阱。考慮到全部但願創建「X+AI」業務的初創企業都面臨着這類潛在挑戰，所以文中提出的建議很是值得你們認真考量。

更多幹貨內容請關注微信公衆號「AI 前線」，（ID：ai-front）

本文提到的機器學習系統帶來的主要技術債類別包括：信息隱藏以及變化封閉帶來的挑戰 ; 膠水代碼與配置；以及不斷變化的外部世界以及分析模型結論對這一世界的理解誤差。

本文中最重要的看法之一，在於技術債務應當成爲工程師與研究人員們須要注意的問題。以大規模增長系統複雜性爲代價進行解決方案研究顯然不是什麼明智的做法。即便僅僅增長一到兩種看似無害的數據依賴關係，也有可能減緩進一步發展速度。雖然減小技術債務並不像證實新定理那樣使人振奮，但其仍然是保持強勁創新能力的重要動力。事實上，爲複雜的機器學習系統開發出全面且優雅的解決方案是一項極具現實意義的工做。

信息隱藏與變化封裝

……機器學習模型是一種創造複雜糾纏狀態的機器，且不可能有效地對其改進工做進行隔離分配。做爲證實，假設犈在一套模型當中使用特徵 x1，……Xn，那麼若是咱們改變 x1 中的值輸入分佈，那麼其重要性、權重或者剩餘特徵可能所有發生改變——不管模型是以批處理形式進行徹底從新訓練，仍是以在線方式進行逐步適應，狀況都是如此。而添加新特徵 xn+1 或者刪除任何特徵 xj，也均可能致使相似的變化。沒有任何輸入內容是真正獨立存在的。牧羊這將其稱爲 CACE 原則：即任何改變都將改變一切。

若是咱們瞭解到先驗的重要性，就不須要利用機器學習進行重複證實！所以，模型有點像一臺巨大的攪拌機器，咱們向其中投入大量信息並獲取結果，但對輸入內容中的各種變化的敏感度卻難以預測，且幾乎沒法進行影響隔離。面對這樣的難題，咱們該怎麼辦？雖然不存在百試百靈的方案，但做者給出了三種可能有所幫助的策略。

1. 你能夠隔離模型，轉而提供整體結論。不過，糾纏問題仍然存在於每個模型當中。此外，「在規模化狀況下，這種策略可能很難長期維持」。

2. 制定方法以深刻理解模型預測的行爲。你須要經過投資令模型再也不像黑匣子般難以捉摸——例如爲其配備更多可視化工具。此外，我還和多家企業進行過交流，其中一部分公司表示其可以解釋機器學習模型做出的決定——甚至包括監管要求，而這種能力亦是其商業模式中的重要組成部分。所以，請你們認真考慮這方面需求與實現途徑。

3. 使用更爲複雜的正則化方法，以便在訓練當中使用的目標函數可以反映出任何效能預測成本的上升跡象。「這種方法可能有用，但也只是可能。此外，其也許會增長系統複雜性進而帶來更多債務，這反而背離了咱們減小糾纏度的初衷。」

另外一種尋找偶然耦合的方式在於創建隱藏反饋迴路，這一點在未申報消費方當中體現得尤其明顯。經過未申報消費方，系統只是在單純消費建模產出的輸出結果，而咱們幾乎意識不到這些過程的存在。若是其根據影響模型的輸入參數信息採起了某些行動，則這種隱藏的反饋迴路很容易引起如下問題：

想象一下，在咱們的新聞標題點擊率預測系統當中，系統中的某一組件負責以「智能化方式」肯定用於標題的字體大小。若是此字體大小模塊開始將點擊率做爲輸入信號使用，且字體大小確實會影響用戶的點擊傾向，那麼字體大小當中將會包含一個由點擊率添加的新的隱藏反饋迴路。能夠想象，這樣一套系統會逐漸無休止地增長全部標題字號狀況。

數據依賴性問題

……儘管代碼依賴性能夠經過靜態分析以及連接圖等方法相對輕鬆地進行識別，但具有數據依賴性處理功能的分析工具卻不多見。所以，咱們能夠難以構建起可以解決大型數據依賴鏈的方案。

舉例來講，某些輸入信號會隨着時間推移而改變行爲。遵循 CACE 原則，即便將這些變化做爲改進方向，也很難對後果做出預測。另外一種數據依賴性則是模型中的特徵集合，其中一些可以在準確性方面提供很是有限的增量。咱們能夠經過多種方式利用本來未充分利用的依賴性——包括一部分已遭棄用的早期遺留特徵，一次性添加的多項特徵組合（而非僅僅挑出那些真正有做用的特徵），或者那些爲了追求準確率而添加、且沒法證實自身對複雜性的影響的特徵。按期對特徵進行清除將很是重要。

舉例來講，假設在團隊合併以後，爲了簡化而進行了一輪由舊產品編號到新產品編號的轉換，那麼兩套方案都將在系統中做爲特徵。其中新產品只能得到一個新編號，但舊產品可能同時擁有兩個編號。機器學習算法固然也會將舊編號歸入依賴關係當中。一年以後，有管理人員清理了使用舊編號填充的數據庫代碼。這種變化不會被迴歸測試所檢測到，由於清理以後舊編號直接再也不使用。這對機器學習系統的維護者而言顯然不是什麼好消息……

有能力理解數據依賴性的工具，將幫助咱們順利搞定特徵清理工做。谷歌公司的一支團隊就構建出一款自動化特徵管理工具：

自從採用以來，該方案幫助谷歌團隊每一個季度安全刪除數千行與特徵相關的代碼，同時自動驗證其中的版本及其它問題。該系統還可以有效防止意外使用新模型中不推薦或已經損壞的特徵。

最後一種數據依賴性管理方法，在於創建「校訂」機制以從新利用現有模型。經過這種方式，你可以快速得到初步成果 ; 但在另外一方面，你將來對該模型的分析與改進將面臨更高的成本。

其它 95%（膠水代碼與配置）

使人驚訝的是，學術界意識到在大多數機器學習系統當中，只有很小一部分代碼在實際進行「機器學習」。事實上，一套成熟的系統最終可能最多隻有 5% 的代碼負責機器學習，而其他 95% 甚至更多代碼只是起到粘合做用，從而經過從新實現（而非從新使用）改善本來笨拙的 API……

這裏須要解決的問題在於，不少機器學習庫都被封裝成了獨立的工件，這無疑會引入大量膠水代碼（例如從 Java 轉換至 R 或者 matlab）。若是你們沒法在更爲普遍的系統架構內找到適合本身的資源選項，那麼從新實現算法（5% 部分的代碼）可能更有意義，且可以有效減小膠水代碼的數量。

一大相關問題在於管道叢林——即過於複雜的數據準備管道。

管道叢林問題只能經過全面審視數據收集與特徵提取的方式來避免。清除管道叢林並從頭開始設計清理方法，確實是工程設計層面的一項重大投資，但這同時也可以顯著下降持續成本並加速進一步創新活動。

一旦系統因膠水代碼與管道叢林問題而變得僵化，不少朋友會忍不住調整生產代碼中的實驗代碼路徑以執行額外實驗。這樣作固然比較方便，但一旦頻率太高，其只會引起更大的混亂。

做爲典型實例，谷歌公司最近在對一套重要的機器學習系統進行清理時，發現其中存在着數以萬計的未使用實驗性代碼行。在利用更緊密的 API 進行重寫以後，這部分「遺產」可以大幅下降工做量、生產風險並控制系統複雜性，從而爲新算法的實驗鋪平道路。

在本節的最後，「配置每每是現實世界的混亂對美麗算法形成干擾的載體：」

請考慮如下例子。特徵 A 在 9 月 14 日到 9 月 17 日之間發生了記錄錯誤。特徵 B 直到 10 月 7 日才正式上線。因爲記錄格式發生了變化，用於計算特徵 C 的代碼必須對 11 月 1 日以前及以後的數據進行更改。特徵 D 並未用於生產，所以在現場調協中進行模型查詢時，必須使用替代性的 D’與 D」。若是特徵 Z 被使用，那麼全部訓練相關任務必須得到額外的內存配額，不然其訓練效率將顯著下降。最後，因爲延遲限制，特徵 Q 排除掉了特徵 R。全部這些混亂的條件使得配置難以正確修改且難以推理。此外，配置錯誤還可能引起高昂的代價——包括嚴重的時間浪費、計算資源損耗或者生產問題。

配置變動應該與代碼變動同樣獲得謹慎處理，並交由同行進行評審。

世界還將帶來怎樣的變化？

經驗代表，外部世界不多保持穩定。事實上，真實世界的性質變化正是機器學習當中技術債務的一大重要來源。

請不要手動設置決策閾值（例如顯示或不顯示廣告），而應考慮經過評估現有驗證數據以發現閾值此外，因果不明的相關特徵也可能引起問題：

這彷佛並非什麼主要問題：若是兩個特徵老是相關，但只有其中一個特徵屬於真正的因果關係，那麼彷佛仍能夠將信用歸於二者並經過觀察其共同現象得出結論。然而，若是外部世界中這兩種特徵的共生性忽然消失，那麼預測行爲可能發生顯著變化。用於區分相關效應的全面機器學習策略也將超出咱們的討論範圍 ;[Bottou 2013] 就此給出了一些極好的建議與參考。結合本文的關注點，咱們注意到非因果關係屬於隱藏債務的另外一種來源。

最後，實時監控系統相當重要。論文建議你們測量預測誤差，並在系統採起的行動數量超過某個閾值時發佈警報。

在一套按預期方式運做的系統中，預測標籤的分佈一般應該等同於觀察標籤的發佈。這不須要進行全面測試，由於其能夠經過單一空模型知足——即直接預測標籤出現平均值，而沒必要考慮輸入要素。然而，這種簡單的方法卻帶來了使人驚訝的良好效果，而此類度量指標的變化一般反映出須要注意的關鍵問題……

原文連接：

https://blog.acolyer.org/2016/02/29/machine-learning-the-high-interest-credit-card-of-technical-debt/

論文連接：

https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf