機器學習43條軍規：解密谷歌機器學習工程最佳實踐（上）
本文是對<Rules of Machine Learning: Best Practices for ML Engineering>一文的翻譯+解讀。看過我翻譯文章的同學知道我翻譯文章一般都不太老實，沒有那麼“忠於原著”，本篇也不例外，本篇對於原文的解讀大概有三種形式：
原文翻譯。對於作者本身闡述的比較好，而我也沒什麼可補充的部分，基本會原文翻譯。
半翻譯半解讀。有的條目我覺得有些自己的經驗和感想可以和大家分享，就會加一些自己的解讀在裡面。
省略。還有一些時候我覺得作者說的太仔（luo）細（suo），或者這個條目說得比較基本，無需太多解釋，我就會不同程度的省略原文。
這種形式對於有的同學來講可能會對原文信息有所損失，所以想要讀到原文的同學，可以在網上搜索。 或者去搜一些其他人比較忠於原著的翻譯。
作者介紹
什麼樣的NB人物寫東西敢起號稱”Rules of Machine Learning”這種不怕閃了腰的題目？首先我們來簡單介紹一下本文的作者Martin Zinkevich。
Martin Zinkevich現在是谷歌大腦的高級科學家，負責和參與了YouTube、Google Play 以及Google Plus等產品中的機器學習項目，本文也是基於作者在這三個產品上面做機器學習項目的各種經驗和教訓提煉而成。在加入谷歌之前是雅虎的高級科學家，曾在2010年和2011年兩度獲得雅虎的最高榮譽Yahoo Team Superstar Awards，對雅虎的廣告系統做出過很多傑出貢獻。
擁有如此NB的背景，我們有理由相信這哥們兒寫出來的東西還是具有足夠的參考價值的。
梗概介紹
本文把在產品中應用機器學習的過程從淺到深分成了三個大的階段，又在這三個大的階段中細分出了一些方面，以此對43條規則進行邏輯分類。簡單來說，如果你是從頭開始做機器學習系統，那麼就可以在不同階段參考這裡面對應的條目，來保證自己走在正確的道路上。
正文開始
To make great products:
do machine learning like the great engineer you are, not like the great machine learning expert you aren’t.
這句話一定程度上是對整篇文章（叫手冊可能更合適）的一個高度概括，ML在實際工作確實更多是工程問題，而不是算法問題。優先從工程效率中要效果，當把這部分榨乾後，再考慮算法的升級。
Before Machine Learning
Rule #1: Don’t be afraid to launch a product without machine learning.
規則1：不要害怕上線沒有機器學習的產品。
中心思想一句話概括：If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there.
Rule #2: First, design and implement metrics.
規則2：在動手之前先設計和實現評價指標。
在構建具體的機器學習系統之前，首先在當前系統中記錄儘量詳細的歷史信息，留好特徵數據。這樣不僅能夠留好特徵數據，還能夠幫助我們隨時瞭解系統的狀態，以及做各種改動時系統的變化。
Rule #3: Choose machine learning over a complex heuristic.
規則3：不要使用過於複雜的規則系統，使用機器學習系統。
簡單來講，複雜的規則系統難以維護，不可擴展，而我們很簡單就可以轉為ML系統，變得可維護可擴展。
ML Phase I: Your First Pipeline
構建第一個ML系統時，一定要更多關注系統架構的建設。雖然機器學習的算法令人激動，但是基礎架構不給力找不到問題時會令人抓狂。
Rule #4: Keep the first model simple and get the infrastructure right.
規則4：第一個模型要簡單，但是架構要正確。
第一版模型的核心思想是抓住主要特徵、與應用盡量貼合以及快速上線。
Rule #5: Test the infrastructure independently from the machine learning.
規則5：獨立於機器學習來測試架構流程。
確保架構是可單獨測試的，將系統的訓練部分進行封裝，以確保其他部分都是可測試的。特別來講：
測試數據是否正確進入訓練算法。檢查具體的特徵值是否符合預期。
測試實驗環境給出的預測結果與線上預測結果是否一致。
Rule #6: Be careful about dropped data when copying pipelines.
規則6：複製pipeline時要注意丟棄的數據。
從一個場景複製數據到另一個場景時，要注意兩邊對數據的要求是否一致，是否有數據丟失的情況。
Rule #7: Turn heuristics into features, or handle them externally.
規則7：將啟發規則轉化為特徵，或者在外部處理它們。
機器學習系統解決的問題通常都不是新問題，而是對已有問題的進一步優化。這意味著有很多已有的規則或者啟發式規則可供使用。這部分信息應該被充分利用（例如基於規則的推薦排序時用到的排序規則）。下面是幾種啟發式規則可以被使用的方式：
用啟發規則進行預處理。如果啟發式規則非常有用，可以這麼用。例如在垃圾郵件識別中，如果有發件人已經被拉黑了，那麼就不要再去學“拉黑”意味著什麼，直接拉黑就好了。
製造特徵。可以考慮從啟發式規則直接製造一個特徵。例如，你使用啟發式規則來計算query的相關性，那麼就可以把這個相關性得分作為特徵使用。後面也可以考慮將計算相關性得分的原始數據作為特徵，以期獲得更多的信息。
挖掘啟發式規則的原始輸入。如果有一個app的規則啟發式規則綜合了下載數、標題文字長度等信息，可以考慮將這些原始信息單獨作為特徵使用。
修改label。當你覺得啟發式規則中包含了樣本中沒有包含的信息時可以這麼用。例如，如果你想最大化下載數，同時還想要追求下載內容的質量。一種可行的方法是將label乘以app的平均star數。在電商領域，也常常用類似的方法，例如在點擊率預估的項目中，可考慮對最終下單的商品或者高質量的商品對應的樣本增加權重。
已有的啟發式規則可以幫助機器學習系統更平滑的過渡，但是也要考慮是否有同等效果更簡單的實現方式。
Monitoring
概括來講，要保持好的監控習慣，例如使報警是可應對的，以及建設一個Dashboard頁面。
Rule #8: Know the freshness requirements of your system.
規則8：瞭解你係統對新鮮度的要求。
如果模型延遲一天更新，你的系統會受到多大的效果影響？如果是一週的延遲呢？或者更久？這個信息可以讓我們排布監控的優先級。如果模型一天不更新收入就會下降10%，那麼可以考慮讓一個工程師全天候監控它。瞭解系統對新鮮度的要求是決定具體監控方案的第一步。
Rule #9: Detect problems before exporting models.
規則9：在模型上線之前檢測問題。
模型上線前一定要做完整性、正確性檢查，例如AUC、Calibration、NE等指標的計算確認等。如果是模型上線前出了問題，可以郵件通知，如果是用戶正在使用的模型出了問題，就需要電話通知了。
Rule #10: Watch for silent failures.
規則10：關注靜默失敗。
這是一個非常重要，而又經常容易被忽略的問題。所謂的靜默失敗指的是全部流程都正常完成，但是背後依賴數據出了問題，導致模型效果逐步下降的問題。這種問題在其他系統中並不常出現，但是在機器學習系統中出現機率會比較高。例如訓練依賴的某張數據表很久沒有更新了，或者表中的數據含義發生了變化等，再或者數據的覆蓋度忽然變少，都會對效果產生很大的影響。解決方法是是對關鍵數據的統計信息進行監控，並且週期性對關鍵數據進行人工檢查。
Rule #11: Give feature column owners and documentation.
規則11：給特徵組分配負責人，並記錄文檔。
這裡的feature column指的是一個特徵組，例如用戶可能屬於的國家這組特徵就是一個feature column。
如果系統龐大，數據繁多，那麼知道每組數據由誰生成就變得非常重要。雖然數據都有簡單描述，但是關於特徵的具體計算邏輯，數據來源等都需要更詳細的記錄。
Your Fist Objective
objective是模型試圖優化的值，而metric指的是任何用來衡量系統的值。
Rule #12: Don’t overthink which objective you choose to directly optimize.
規則12：不要過於糾結該優化哪個目標。
機器學習上線的初期，即使你只優化一個目標，很多指標一般都會一起上漲的。所以不用太糾結究竟該優化哪個。
雖然大佬這麼說，但是在我自己的實踐經驗中，只優化一個目標，系統的整體效果卻未必會上漲。典型的如推薦系統的CTR模型，上線之後CTR確實會提升，但是對應的CVR很有可能會下降，這時還需要一個CVR模型，兩個模型同時使用才能真正提升系統效果。究其原因，是因為每個目標只關注系統整個過程的一個子過程，貪心地去優化這個子過程，不一定能夠得到全局的最優解，通常需要把主要的幾個子過程都優化之後，才能取得整體效果的提升。
Rule #13: Choose a simple, observable and attributable metric for your first objective.
規則13：為你的第一個objective選擇一個簡單可觀測可歸因的metric。
objective應該是簡單可衡量的，並且是metric的有效代理。最適合被建模的是可直接觀測並被歸因的行為，例如：
鏈接是否被點擊？
軟件是否被下載？
郵件是否被轉發？……
儘量不要在第一次就建模非直接效果的行為，例如：
用戶第二天是否會訪問？
用戶在網站上停留了多久？
日活用戶有多少？
非直接指標是很好的metric，可以用ABTest來進行觀測，但不適合用作優化指標。此外，千萬不要試圖學習以下目標：
用戶對產品是否滿意？
用戶對體驗是否滿意？……
這些指標非常重要，但是非常難以學習。應該使用一些代理指標來學習，通過優化代理指標來優化這些非直接指標。為了公司的發展著想，最好有人工來連接機器學習的學習目標和產品業務。
Rule #14: Starting with an interpretable model makes debugging easier.
規則14：使用可解釋性強的模型可降低debug難度。
優先選擇預測結果有概率含義、預測過程可解釋的模型，可以更容易的確認效果，debug問題。例如，如果使用LR做分類，那麼預測過程不外乎一些相乘和相加，如果特徵都做了離散化，就只有加法了，這樣很容易debug一條樣本的預測得分是如何被計算出來的。所以出了問題很容易debug。
Rule #15: Separate Spam Filtering and Quality Ranking in a Policy Layer.
規則15：將垃圾過濾和質量排序的工作分離，放到策略層（policy layer）。
排序系統工作的環境中數據分佈是相對靜態的，大家為了得到更好的排序，會遵守系統制定的規則。但是垃圾過濾更多是個對抗性質的工作，數據分佈會經常變動。所以不應該讓排序系統去處理垃圾信息的過濾，而是應該有單獨的一層去處理垃圾信息。這也是一種可以推廣的思想，那就是：排序層只做排序層的事情，職責儘量單一，其他工作讓架構上更合適的模塊去處理。此外，為了提升模型效果，應該把垃圾信息從訓練數據中去除。
ML Phase II: Feature Engineering
前面第一階段的重點是把數據喂到學習系統中，有了基礎的監控指標，有了基礎的架構。等這一套系統建立起來後，第二階段就開始了。
整體來講，第二階段的核心工作是將盡量多的有效特徵加入到第一版的系統中，一般都可以取得提升。
Rule #16: Plan to launch and iterate.
規則16：做好持續迭代上線的準備。
簡單來說，就是要深刻認識到，系統優化永遠沒有終點，所以系統設計方面要對迭代非常友好。例如增加刪除特徵是否足夠簡單，正確性驗證是否足夠簡單，模型迭代是否可以並行運行，等等。
這雖然不是一條具體可行動的（actionable）規則，但是這種思想上的準備對整個系統的開發很有幫助。只有真正深刻意識到了系統持續迭代上線的本質，才會在設計在線和離線架構時為持續迭代最好相應的設計，並做好相應的工具，而不是做一錘子系統。
Rule #17: Start with directly observed and reported features as opposed to learned features.
規則17：優先使用直接觀測或收集到的特徵，而不是學習出來的特徵。
所謂學習出來的特徵，指的是用另外的算法學習出來的特徵，而非可以直接觀測或收集到的簡單特徵。學習出來的特徵由於存在外部依賴，或者計算邏輯複雜，不一定適用於你當前的模型，所以穩定性和有效性會有風險。而直接可觀測的特徵由於是相對比較客觀的，依賴較少的，所以比較穩定。
Rule #18: Explore with features of content that generalize across contexts.
規則18：探索使用可以跨場景的內容特徵。
中心思想是在說，要多利用可以在多個場景下使用的特徵，例如全局的點擊率、瀏覽量這些特徵，可以在多個場景下作為特徵使用。這樣可以在一些冷啟動或者缺乏有效特徵的場景下作為特徵使用。
Rule #19: Use very specific features when you can.
規則19：儘量使用非常具體的特徵。
如果數據量足夠大，那麼相比少數複雜特徵，使用海量簡單特徵是更簡單有效的選擇。
所謂非常具體，指的是覆蓋樣本量比較少的特徵，例如文檔的ID或者query的ID等。這樣的特徵雖然每個只覆蓋很少一部分特徵，但是隻要這一組特徵整體能夠覆蓋率比較高，例如90%，那就是OK的。而且還可以通過正則化來消除覆蓋率過低或者相關性差的特徵。這也是大家都偏愛大規模ID特徵的一個原因，現在很多大廠的排序模型特徵都大量使用了大規模ID特徵。
Rule #20: Combine and modify existing features to create new features in human-understandable ways.
規則20：用人類可理解的方式對已有特徵進行組合、修改來得到新特徵。
離散化和交叉是最常用的兩種特徵使用方式。其本質都是用特徵工程的方式，在不改變使用模型本身的情況下增加模型的非線性。這兩種方法本身沒什麼好說的，值得一致的是，在大規模ID類特徵的交叉時，例如一段是query裡的關鍵詞，另一端是文檔裡的關鍵詞，那就會產生很大量級的交叉特徵，這時有兩種處理方法：
點積。其實計算query和文檔共同包含的關鍵詞數量。
交集。每一維特徵的含義是某個詞同時出現在了query和文檔中，同時出現則該維特徵為1，否則為0。
所謂“人類可理解的方式”，我的理解就是離散化和交叉要基於對業務邏輯的理解，不能亂交叉。
Rule #21: The number of feature weights you can learn in a linear model is roughly proportional to the amount of data you have.
規則21：線性模型中可學到的特徵權重數量，與訓練數據的數量大體成正比。
這背後有複雜的統計原理做支撐，但你只需要知道結論就可以了。這個原則給我們的啟示，是要根據數據量來選擇特徵的生成方式，例如：
如果你的系統是一個搜索系統，query和文檔中有百萬級的詞，但是你只有千級別的標註樣本。那你就別用ID級關鍵詞特徵了，而是要考慮點積類特徵，把特徵數量控制在幾十個這個級別。
如果你擁有百萬級樣本，那麼可以將文檔和query的關鍵詞進行交叉特徵，然後用正則化進行特徵選擇。這樣你會得到百萬級特徵，但是正則化之後會更少。所以說，千萬級樣本，十萬級特徵。
如果你有十億級或者更高級別的樣本，那麼你可以使用query和文檔的ID級特徵，然後加上特徵選擇和正則化。十億級樣本，千萬級特徵。
總結起來就是，根據樣本決定特徵使用方式，樣本不夠就對特徵進行高層次抽象處理，指導和樣本量級相匹配。
Rule #22: Clean up features you are no longer using.
規則22：清理不再使用的特徵。
如果某個特徵已經沒有用，並且它與其他特徵的交叉也已經沒有用，就應該將其清理掉，保持架構的整潔性。
在考慮添加或保留哪些特徵時，需要統計一下特徵的樣本覆蓋率，例如一些整體覆蓋率很低的個性化feature column，只有很少用戶能覆蓋到，那麼大概率這組特徵作用不大。但另一方面，如果某個特徵覆蓋率很低，例如只有1%，但是其區分度非常大，例如90%取值為1的樣本都是正樣本，那麼 這個特徵就值得加入或保留。
未完待續……
本文作者：
張相於（[email protected]），現任轉轉推薦系統負責人，負責轉轉的推薦系統。曾任噹噹網推薦系統開發經理，多年來主要從事推薦系統以及機器學習相關工作，也做過反垃圾、反作弊相關工作，並熱衷於探索大數據技術&機器學習技術在其他領域的應用實踐。他正在招推薦算法和推薦架構工程師，有意請郵件發送簡歷聯繫。