深度解析機器學習系統的八大坑

科技 03-02

作者 | 張相於

轉載自演算法算卦（ID:sg_sde_talks）

機器學習系統現在已經成為各種大數據應用中的標配，系統中沒有機器學習環節都不好意思跟人打招呼。教你如何做機器學習的資料也有很多，但是本文有所不同，本文的重點在於告訴你不要如何去做，也可以說是機器學習中的「反模式」。

機器學習系統就如同熱帶雨林，極其容易迷失其中，踩到各種大坑，讓你遍體鱗傷。本文摘選了我們團隊在實踐中踩過的一些坑，以及總結出來的經驗教訓，希望能夠充當一份指南，減少大家迷失其中的幾率。

0號坑：只見模型，不見系統

機器學習系統的核心是各種機器學習模型，但並不能說模型是系統的全部，甚至都不一定是系統中最重要的部分。如果把一個完整的機器學習系統比喻成一輛汽車，那麼模型可以算作是汽車的引擎，但是我們知道除了引擎以外，影響汽車最終性能的因素還有非常的多，從國外進口一台高級引擎並不代表就能造出世界一流的車來。

在機器學習系統中也是一樣，要想模型充分發揮作用，需要在系統構建時具有充分的大局觀意識，把模型當做系統的一部分來看待。在這裡我們強調其中一點，就是在注意優化模型的同時，更要注意模型的提升是否對系統整體最終效果產生了提升，如果沒有，那麼要從系統中模型以外的部分找問題。

下面舉一個廣告系統中的例子來說明問題。我們知道廣告展示的決策過程可以簡單分為物料召回和排序兩個部分，而機器學習經常被用來做排序部分的工作。但是最終的廣告點擊效果，不僅僅和排序模型的質量有關，同時和召回質量也有很大關係，如果召回的相關性不夠好，那麼無論怎麼排序，最終效果都不會好。這個時候如果眼睛只看到模型效果，是很難找到真正問題所在的。

所以在開發系統的過程中，不能只關注模型本身的好壞，例如AUC之類的評測指標，更重要的是要關注模型對系統最終影響，以調優系統為目標，而不是僅僅調優模型為目標。如果只看到模型而看不到系統，很可能會做出指標漂亮但是沒有實效的「花瓶系統」來。

1號坑：忽視模型過程和細節

很多人覺得機器學習模型是個神奇的黑盒子，只需要把樣本和特徵喂進去，就會有好用的模型參數生產出來，就像馬三立相聲中的牛肉罐頭機器一樣。這種黑盒子思維會讓人習慣性地忽略模型的細節——例如某個參數為何是這個取值，這個取值是否合理，這個取值對應的樣本數據是什麼樣子，等等——而是把精力都花在調一些外部參數之類的工作上。

這樣做的後果是，如果模型效果不好，不一定能夠通過調整外部參數來達到調優效果。例如，在樣本收集處理過程中，摻入了一些噪音數據沒有去除，那麼這些噪音數據會影響最終的模型參數，進而影響模型效果。這種問題通過調一些諸如正則化參數之類的參數是無法解決的，真正有效的解決方法是深入的具體參數中，找到表現異常的參數，然後深入到該參數對應的正負樣本及其特徵，這樣逐層滲透地查找問題。典型的LR模型作為當今最流行的模型，很多人只看到了訓練速度和擴展性這些優點，而沒有充分利用模型簡潔性這一特點。LR簡潔的參數形式非常適合使用上面描述的問題查找方法來定位問題。

當然，上面這個頗為複雜的查找流程，如果沒有趁手的工具幫助，是很難通暢執行的。所以需要構建一套可視化工具，來輔助這個過程。具體地說，以LR模型為例，這個系統要能夠支持：對於每個預測的case，能看到起作用的參數及其取值，能看到參與訓練這個參數的樣本以及特徵細節，等等。有了這樣一套系統，可能只需要點幾下滑鼠就能夠定位到問題，降低了查找問題的難度，提高了使用的積極性，從而有利於系統的持續提升。

所以，對於機器學習模型，要敢於破除「黑盒迷信」，對其進行「解剖」，有針對性地優化和查找問題，通過把控訓練過程細節來把控最終模型。

2號坑：不注重樣本精細化處理

大家都知道樣本是機器學習模型的「食物」，直接關係到模型效果的好壞。但是很多情況下，我們對待樣本的態度並沒有足夠認真，沒有像在乎特徵那樣在乎樣本的質量。以二分類問題為例具體來講，有兩種情況會比較常見。

第一種情況，是對負樣本的界定不夠細緻。負樣本的含義一般來說是曝光但是未點擊的樣本，但是「曝光」是一件需要仔細琢磨的事情。最粗暴的方式是用伺服器後台日誌中的數據作為曝光，但是這樣做會帶來一個顯然的問題，就是日誌中的item不一定全部真正「曝光」，也就是不一定真的被用戶看到了。更好的方式是通過頁面埋點來記錄真正曝光的東西，但是這種方法也會有問題，那就是即使頁面上曝光了，用戶也不一定真正看到了，或者說用戶的眼睛不一定掃到了曝光的區域，畢竟頁面那麼大，用戶的注意力不一定在哪裡。針對這種情況一種解決方法是把最後一個被點擊的商品以上的作為「真正曝光」的，因為用戶既然點擊了這一個，那麼可以認為這個以上的用戶都是看到了的。

第二種情況，也是更底層的一個問題，就是對樣本這個概念的理解不到位。統計機器學習的根本思路是根據歷史行為學習模式，從而預測未來。所以「樣本代表歷史」是很容易被接受的定義，但是在實際工作中，更好的樣本代表的應該是「我們希望的歷史」，而不一定是「真實的歷史」。那麼「我們希望的歷史」和「真實的歷史」之間差異在哪裡呢？

舉一個電商系統的例子。在電商系統的訪問記錄中，有這麼三種類型的數據：

有明確購買意圖用戶的數據

隨便逛逛用戶的數據

各種作弊用戶或爬蟲的數據

這三種用戶的行為模式是不一樣的，第一種目標明確，瀏覽的商品關聯性強；第二種目標不明確，看的東西相對發散；第三種在規律上明顯與正常人不同。這三種類型的數據夾雜在一起，格式完全相同，不做專門的分析是無法區分開的。三種數據混在一起進入模型訓練，當然也會得出一個模型，這個根據「真實數據」訓練出來的模型，其中的參數都在盡量擬合這三種數據的混合體。

但是讓我們現在停下來想一想，我們訓練模型出來，真正希望服務的用戶是哪種用戶？第三種肯定不是，第二種可能是，第一種一定是。如果我們真正希望服務的用戶只是第一種用戶，但是訓練數據中包含了另外兩種，那麼第一種用戶的體驗一定會受到影響。而如果我們只用第一種用戶的數據訓練模型出來，那麼這種「量身定做」的模型對目標用戶的效果一定是更好的。根據我們的實踐經驗證明，無論是AUC指標還是上線效果，都是有明顯提升的。

舉這兩個例子，目的是提醒大家，除了特徵工程，樣本工程也同樣重要，在某些情況下甚至會更重要。所以在進行訓練之前，以及模型調優的過程中，都要仔細思考樣本是否真正反映了你的需求，有必要時要對樣本做針對性選擇。

3號坑：過於依賴演算法

機器學習系統的核心是模型和演算法，基於模型和演算法的可擴展性也是機器學習系統的核心競爭力之一。但是這並不代表系統中的每個環節都一定要用演算法來處理，完全摒棄非演算法的、甚至手工的方法。很多機器學習系統中都會有一些核心的基礎數據，這些數據的數據量談不上海量，但是純手工處理也是有一定工作量的，這個時候人們第一反應往往是用演算法去處理這些數據，但是有的時候簡單粗暴的方法才是真正有效的方法。

我們在構建噹噹的機器學習系統時，需要對圖書文本做一個主體模型聚類，在此之前需要得到一份「乾淨」的原始文本數據。所謂「乾淨」數據指的是去除了諸如SEO詞、商家亂填寫的內容等等之後的一個類似詞表的數據。為了達到去除噪音詞的目的，我們嘗試過很多方法，簡單的高級的都試過，都有效果，但都達不到我們要的效果。經過ROI衡量，我們決定人工來處理這些數據，大概花了三個人一周左右的時間，人工處理之後，效果確實非常好。

這個例子並不是在宣傳反演算法，而是說要根據具體的問題選擇合適的方法。這個問題為什麼可以用人工方法去做呢？原因有很多，其中之一就是這個數據的變化幅度非常小，人工處理一遍之後可以用很久，如果是一份每天在變的數據顯然就不適合用人工來做了。這個問題或許存在更高級的演算法可以解決，但是考慮到數據的不變性，以及整體的ROI，從工程角度來講還是手工比較合算。

所以說，即使是在機器學習系統這種整體比較高大上的系統中，也要具體問題具體分析，需要搬磚的時候，該搬就得搬。

4號坑：核心數據缺乏控制

從數據流的角度來看，機器學習系統中的數據要經過樣本收集、特徵生成、模型訓練、數據評測等等這樣一個流程，在這樣一個比較長的流程中，不一定每個環節都是自己可控的，那麼在那些不可控的環節，就有可能出現風險，而更可怕的是，由於數據控制在別人手裡，出現了問題自己還不知道。

以樣本收集為例，在大公司里，這樣的工作很可能是由統一負責日誌收集的平台部門來做的，而演算法團隊只要拿來用就可以了。這種做法是把雙刃劍，好處很明顯，就是減輕了演算法團隊的負擔，但是也會帶來隱患，就是你拿到的數據不一定真的是你要的數據。

正確的數據只有一種，但是錯誤的數據卻有很多種錯誤方法。在樣本收集方面，前台發送過來的曝光數據也存在著多種可能性，例如可能是緩存起來的數據，也有可能是用來做SEO的數據，等等。這些數據在發送方來看，都是合理的數據，但對於演算法模型來看，都不是用戶真正看到的數據，而用戶真正看到的數據才是我們真正想要的數據。那麼作為這份數據的使用方，演算法模型很有可能就會受到這種錯誤數據的影響。

最可怕的是，這種錯誤並不是那種能讓程序崩潰的錯誤，讓我們能在第一時間發現，而是完全隱藏在正常數據中，只有你栽了跟頭返回來找問題時或許才能發現。

這種錯誤數據出現的原因是什麼呢？並不是一定日誌收集團隊不負責任，關鍵在於收集日誌的團隊不使用日誌，或者說出數據的人不用數據，那麼就很難要求他們來保證數據的質量。這種分離的狀態對於模型演算法這種高度依賴數據的應用是有風險的，所以最好能夠加強這部分數據的控制能力，如果不能完全自己來做，那麼就要有對應的監控機制，做到有問題能及時發現、及時處理，而不是完全交給別人，自己只管拿來用。

5號坑：團隊不夠「全棧」

全棧工程師是近年來很火爆的一個概念，在機器學習這樣一個複雜系統中，每個人都做到全棧未必現實，但是有一條基本要求應該努力做到，就是團隊級別的全棧。

機器學習系統的團隊一般主要由演算法工程師和系統工程師組成，往往會忽略其他角色，比較典型的就是掌握前端技能的工程師。前端技能在機器學習系統中有很重要的作用，例如在效果評測時的可視化展示方面，但是更重要的是，能夠一定程度上加強對數據流程的控制能力。例如在上面那個坑的例子中，說到前端曝光收集的問題，如果團隊中沒有熟悉前端技術的人，是很難找到這種數據發送的隱藏問題的。

當然，技術全棧只是解決問題的手段，更重要的是能關注全部系統的全局性思維。

6號坑：系統邊界模糊/巨型系統

機器學習系統與其他軟體系統相比，有一個顯著的特點，就是它是建立在實驗性、探索性開發的基礎上的。尤其是在初次搭建系統的時候，很難做到在完整設計的指導下開發，而大多是一邊探索嘗試一邊開發，到最後達到上線要求的時候，系統也就隨之成型了。

但是這樣構建出的系統，有個很大的問題，就是很容易做成一個邊界模糊、模塊耦合、結構複雜的「巨型系統」，這種系統的典型特徵包括：

模塊間不可拆分，樣本、特徵、訓練等步驟都偶合在一起。

很多實驗性、探索性代碼遍布其中，搞不清楚哪些在用，哪些已失效。

pipeline特別長，其中包括一些可能已經無用的流程。

為什麼會出現這樣的系統呢？重要原因之一就是前面提到過的，機器學習系統的探索式的本質。在剛開始做系統的時候，可能樣本處理、特徵處理這些都比較簡單，所以就都寫在了一起。隨著各個流程處理的精細化、複雜化，每個步驟都在變複雜，但是由於這種變化是在慢慢發生的，很容易形成「溫水煮青蛙」的效應，導致系統慢慢變得不可控，從技術債的角度來講，系統就是在慢慢地、不知不覺地欠債，而且是利息很高的債。

這樣的系統必然是難以維護、難以優化的，解決的方法就是逐步的重構，或者借鑒一些成熟的系統架構，然後再做適合自己的本地化。但這其中最關鍵的，還是要有一顆架構師的心，能夠時刻審視自己的系統，評估其健康狀況，並適時做出改變。關於機器學習系統技術債的更多詳細討論，可參見這篇文章[3]或這篇文章[4]。

7號坑：不重視基礎數據架構建設

數據是機器學習系統的血液，這裡面包括各種樣本數據，原始特徵數據，處理後的特徵數據，支撐數據等等，那麼提供這些數據的系統和架構就好比循環系統，循環系統的循環、代謝能力直接決定了這個系統的健康程度。

機器學習系統在構建初期，對待各種數據的態度往往是輔助性質的，認為這些數據只是為了模型服務的」燃料「，而沒有把它們本身作為嚴肅的子系統來對待，所以這些數據的架構往往缺乏設計，大多比較隨意，可能會有很多難以復用「一次性」代碼。這在初期沖模型效果的時候似乎是沒有問題的，但是到了系統搭建起來之後，需要頻繁地對各種數據進行調整、嘗試的時候，如果沒有經過精心設計的數據架構支持，每次數據調整都會非常耗費精力，工作量可能不亞於重新出一遍數據。尤其是在系統上線之後，修改數據變得不能那麼隨意之後，問題就更加嚴重。

這是一個嚴肅而複雜的問題，也不是一兩個簡單方法就可以解決的，而是需要從數據源開始做仔細的設計，設計時充分考慮數據可能的用法，並留有一定擴展性，保證數據的可用性和可探索性。具體實踐起來可以考慮微服務的做法，微服務是個性化推薦領先的Netflix公司最早提出並實踐的概念，它們實踐的場景也是圍繞個性化推薦展開的。

其中一個比較有趣的例子，是他們構建了一套「特徵時光機」系統[5]，以微服務的形式把不同時間維度的數據呈獻給演算法和研究人員，就好像擁有時光機一樣，能夠在不同時間中容易穿梭，獲取數據。此外，在通用的數據基礎架構方面，可以參考Stitchfix的做法[6]，其核心是將數據流程根據職責進行劃分，以求達到最高的團隊協作效率。