原文作者：Martin Zinkevich

整理：張相於

作者介紹

Martin Zinkevich現在是谷歌大腦的高級科學家，負責和參與了YouTube、Google Play 以及Google Plus等產品中的機器學習項目，本文也是基于作者在這三個產品上面做機器學習項目的各種經驗和教訓提煉而成。在加入谷歌之前是雅虎的高級科學家，曾在2010年和2011年兩度獲得雅虎的最高榮譽Yahoo Team Superstar Awards，對雅虎的廣告系統做出過很多杰出貢獻。

梗概介紹

本文把在產品中應用機器學習的過程從淺到深分成了三個大的階段，又在這三個大的階段中細分出了一些方面，以此對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的樣本都是正樣本，那么 這個特征就值得加入或保留。

Human Analysis of the System

在更進一步之前，我們需要了解一些機器學習課程上不會教你的內容：如何觀察分析模型，并改進它。用作者的話說，這更像是一門藝術 ，但仍然有一些規律可循。

Rule #23: You are not a typical end user.

規則23：你不是一個典型的終端用戶。

這條規則的中心思想是說，雖然吃自己的狗食是必要的，但也不要總是從工程師的角度來衡量模型的好壞。這不僅可能不值當，而且可能看不出問題。所謂不值當，是因為工程師的時間太貴了，這個大家都懂；而所謂看不出問題，是因為工程師自己看自己開發的模型，容易看不出問題，所謂“不識廬山真面目”。

所以作者認為合理的方法是讓真正的終端用戶來衡量模型或產品的好壞。要么通過線上ABTest，要么通過眾包的方式來做。

Rule #24: Measure the delta between models.

規則24：離線衡量模型之間的差異。

原文沒有說是離線，但我通過上下文理解他說的應該是離線。這一條規則說的是新模型在上線之前，需要先和老模型做差異對比。所謂差異對比，指的是對于同樣的輸入，新舊兩個模型給出的結果是否差異足夠大。例如對于同一個query，兩個排序模型給出的差異是否足夠大。如果離線計算發現差異很小，那也沒必要上線測試了，因為上線后差異肯定也大不了。如果差異比較大，那么還需要看差異是不是好的差異。通過觀察差異可以得知新模型究竟對數據產生了什么影響，這種影響是好是壞。

當然，這一切的前提是你需要有一個穩定的對比系統，起碼一個模型和他自己對比的話差異應該非常小，最好是零差異。

Rule #25: When choosing models, utilitarian performance trumps predictive power.

規則25：當選擇模型時，實用性指標比預測能力更重要。

這是一條很有用的經驗。雖然我們訓練模型時objective一般都是logloss，也就是說實在追求模型的預測能力。但是我們在上層應用中卻可能有多種用途，例如可能會用來排序，那么這時具體的預測能力就不如排序能力重要；如果用來劃定閾值然后跟根據閾值判斷垃圾郵件，那么準確率就更重要。當然大多數情況下這幾個指標是一致的。

除了作者說的這一點，還有一種情況是需要特別注意的，那就是我們在訓練時可能會對樣本做采樣，導致得到的預測值整體偏高或偏低。如果這個預測值是用來直接排序的，那么這個變化關系不大，但如果有其他用處，例如和另外的值相乘，典型的如廣告場景下的CTR*bid，或者電商推薦排序下的CTR*CVR，在這類場景下，預測值本身的準確性也很重要，就需要對其進行校準(calibrate)，使其與采樣前的樣本點擊率對齊。

Rule #26: Look for patterns in the measured errors, and create new features.

規則26：在錯誤中發現模式，并創建新特征。

這算是一種用來提升模型效果的通用思路。具體來說，指的是觀察訓練數據中模型預測錯誤的樣本，看看是否能夠通過添加額外特征來使得這條樣本被模型預測正確。之所以使用訓練集中的數據，是因為這部分數據是模型已經試圖優化過的，這里面的錯誤，是模型知道自己搞錯了，目前學不出來的，所以如果你給它足夠好的其他特征，它或許就能把這條樣本學對了。

一旦發現錯誤的模式，就可以在當前系統之外尋找新的特征。例如，如果你發現當前系統傾向于錯誤地把長文章排到后面，那么就可以加入文章長度這一特征，讓系統去學習文章長度的相關性和重要性。

Rule #27: Try to quantify observed undesirable behavior.

規則27：盡量將觀測到的負面行為量化。

如果在系統中觀察到了模型沒有優化到的問題，典型的例如推薦系統逼格不夠這種問題，這時應該努力將這種不滿意轉化為具體的數字，具體來講可以通過人工標注等方法標注出不滿意的物品，然后進行統計。如果問題可以被量化，后面就可以將其用作特征、objective或者metric。整體原則就是“先量化，再優化”。

多說一句，這里的優化，不一定是用模型來優化，而是指的整體優化。比如推薦系統逼格這種問題，模型可能很難優化，但是只要能量化出來，就可以通過其他方法來盡量減少，例如單獨去學習有逼格物品的特征，或者在召回階段進行一定傾斜。

Rule #28: Be aware that identical short-term behavior does not imply identical long--term behavior.

規則28：要注意短期內觀察到的類似行為不一定會長期存在。

假設你搞了個系統，通過學習每個具體的文檔ID和query ID，計算出了每個query下每個文檔的點擊率。通過離線對比和ABTest，你發現這個系統的行為和當前系統的行為一毛一樣，而這個系統又更簡單，所以你就把這個系統上線了。后面你會發現這個系統在任何query下都不會給出任何新的文檔。奇怪嗎？一點都不奇怪，因為你只讓它記住了之前的歷史數據，它對新數據沒有任何信息。

所以唯一能夠衡量一個系統是否長期有效的方法，就是讓它使用該模型在線上時收集到的真實數據上進行訓練。當然這有難度。

往大了說，作者這條規則其實說的是個系統或者模型的泛化能力，如果一個系統或者模型不能對新數據做出很好的預測，那么無論他的離線表現如何，都不能代表它的真正能力。再換個角度來看，一個系統必須具有持續學習適應新數據的能力，才能是一個合格的機器學習系統，否則就只是個學舌的鸚鵡。

Training-Serving Skew

訓練和服務之間的差異問題時一個大話題，主要原因包括訓練時與服務時數據獲取方式不同、訓練時與服務時數據分布不同以及模型和算法之間的反饋循環等。作者說這種差異在G家的多條產品線上出現過，都產生了負面影響。但要我說這絕對不僅僅是谷歌的問題，谷歌絕對是做的比較好的了，各種中小廠里面這種問題只多不少，所以這部分的經驗是非常寶貴的。解決這類問題的核心是對系統和數據的變化進行監控，確保一切差異都在監控之內，不會悄悄進入系統。

Rule #29: The best way to make sure that you train like you serve is to save the set of features used at serving time, and then pipe those features to a log to use them at training time.

規則29：保證服務與訓練一致性的最好方法是將服務時的特征保存下來，然后通過日志將特征喂到訓練過程中去。

這句話基本道出了保證差異最小化的核心套路。這種基于特征日志的方法可以極大提升效果，同時能夠減少代碼復雜度。谷歌的很多團隊也正在往這種做法上遷移。

Rule #30: Importance weight sampled data, don’t arbitrarily drop it!

規則30：對采樣樣本做重要性賦權，不要隨意丟棄！

這是作者唯一用了感嘆號的一條，可想而知背后的辛酸。當我們有太多訓練數據時，我們會只取其中的一部分。但這是錯誤的。正確的做法是，如果你給某條樣本30%的采樣權重，那么在訓練時就給它10/3的訓練權重。通過這樣的重要性賦權(importance weight)，整個訓練結果的校準性（calibration）就還能夠保證。

多說一句，這個校準性非常的重要，尤其對于廣告系統，或者多個預測值相加或相乘來得到最終結果的系統。如果單個值沒有校準，偏低或偏高，那么在相乘或相加之后其含義就會不正確。如果直接使用模型預測值進行排序，校準性就沒那么重要，因為校準性不會影響排序，只會影響具體的值。

Rule #31: Beware that if you join data from a table at training and serving time, the data in the table may change.

規則31：如果你在訓練時和服務時都在join一張表，那么要注意這張表的數據可能會發生變化。

比如說某張表里存著一些文檔的特征，你在離線訓練之前要去這個表里取這些特征用來訓練，但這里就有個風險，那就是這個表里的數據在你離線取的時候和在線服務的時候數據不一樣，發生了變化。最好的解決方式就是在服務端將特征記錄在日志中，這樣能保證數據的一致性。或者如果這張表的變化頻率比較低，也可以考慮對其做小時級或天級備份，以此來減少這種差異。但要記住這種方法并不能徹底解決這個問題。

Rule #32: Re-use code between your training pipeline and your serving pipeline whenever possible.

規則32：盡量在訓練pipeline和服務pipeline之間復用代碼。

訓練一般是離線批量進行的，而服務則是在線流式進行的，這兩者之間雖然在處理數據的方式上存在著較大差異，但仍然有很多代碼可以共享。這些代碼的共享可以從代碼層面介紹訓練和服務之間的差異。換句話說，日志記錄特征是從數據角度消除差異，那么代碼復用就是從代碼角度消除差異，雙管齊下，效果更好。

Rule #33: If you produce a model based on the data until January 5th, test the model on the data from January 6th and after.

規則33：如果訓練數據是1月5日之前的，那么測試數據要從1月6日開始。

這條規則的主要目的是讓測試結果與線上結果更加接近，因為我們在使用模型時就是在用服務當天之前的數據訓練，然后來預測當天的數據。這樣得到的測試結果雖然可能會偏低，但卻更加真實。

Rule #34: In binary classification for filtering (such as spam detection or determining interesting e-mails), make small short--term sacrifices in performance for very clean data.

規則34：在為過濾服務的二分類問題中（例如垃圾郵件過濾），可以為了干凈的數據犧牲一些短期效果。

在過濾類的任務中，被標記為負的樣本是不會展示給用戶的，例如可能會把75%標記為負的樣本阻攔住不展現給用戶。但如果你只從展示給用戶的結果中獲取下次訓練的樣本，顯然你的訓練樣本是有偏的。

更好的做法是使用一定比例的流量（例如1%）專門收集訓練數據，在這部分流量中的用戶會看到所有的樣本。這樣顯然會影響線上的真實過濾效果，但是會收集到更好的數據，更有利于系統的長遠發展。否則系統會越訓練越偏，慢慢就不可用了。同時還能保證至少過濾掉74%的負樣本，對系統的影響也不是很大。

但是如果你的系統會過濾掉95%或者更多的負樣本，這種做法就不那么可行了。即使如此，為了準確衡量模型的效果，你仍然可以通過構造一個更小的數據集（0.1%或者更小）來測試。十萬級別的樣本足夠給出準確的評價指標了。

Rule #35: Beware of the inherent skew in ranking problems.

規則35：注意排序問題中固有的數據偏置。

當新的排序算法對線上排序結果產生了重大改變時，你其實是改變了算法將來會看到的數據。這時這種偏置就會出現。這種問題有以下幾種方法來解決，核心思想都是更偏重模型已經看到過的數據。

• 對覆蓋更多query（或類似角色，根據業務不同）的特征給予更強的正則化。這樣模型會更偏重只覆蓋一部分樣本的特征，而不是泛化性特征。這樣會阻止爆品出現在不相關query的結果中。

• 只允許特征取正的權重值。這樣任何好特征都會比“未知”特征要好。

• 不要使用只和文檔相關的特征。這是第一條的極端情況，否則會導致類似哈利波特效應的情況出現，也就是一條在任何query下都受歡迎的文檔不會到處都出現。去除掉只和文檔相關的特征會阻止這種情況發生。

Rule #36: Avoid feedback loops with positional features.

規則36：使用位置特征來避免反饋回路。

大家都知道排序位置本身就會影響用戶是否會對物品產生互動，例如點擊。所以如果模型中沒有位置特征，本來由于位置導致的影響會被算到其他特征頭上去，導致模型不夠準。可以用加入位置特征的方法來避免這種問題，具體來講，在訓練時加入位置特征，預測時去掉位置特征，或者給所有樣本一樣的位置特征。這樣會讓模型更正確地分配特征的權重。

需要注意的是，位置特征要保持相對獨立，不要與其他特征發生關聯。可以將位置相關的特征用一個函數表達，然后將其他特征用另外的函數表達，然后組合起來。具體應用中，可以通過位置特征不與任何其他特征交叉來實現這個目的。

Rule #37: Measure Training/Serving Skew.

規則37：衡量訓練和服務之間的差異。

整體來講有多種原因會導致這種差異，我們可以將其進行細分為以下幾部分：

• 訓練集和測試集之間的差異。這種差異會經常存在，而且不一定是壞事。

• 測試集和“第二天”數據間的差異。這種差異也會一直存在，而這個“第二天”數據上的表現是我們應該努力優化的，例如通過正則化。這兩者之間差異如果過大，可能是因為用到了一些時間敏感的特征，導致模型效果變化明顯。

• “第二天”數據和線上數據間的差異。如果同樣一條樣本，在訓練時給出的結果和線上服務時給出的結果不一致，那么這意味著工程實現中出現了bug。

ML Phase III: Slowed Growth, Optimization Refinement, and Complex Models

一般會有一些明確的信號來標識第二階段的尾聲。首先，每月的提升會逐步降低。你開始在不同指標之間做權衡，有的上升有的下降。嗯，游戲變得有趣了。既然收益不容易獲得了，機器學習就得變得更復雜了。

在前兩個階段，大部分團隊都可以過得很開心，但到了這個階段，每個團隊都需要找到適合自己的路。

Rule #38: Don’t waste time on new features if unaligned objectives have become the issue.

規則38：如果objective沒有達成一致，不要在新特征上浪費時間。

當系統整體達到一個穩定期，大家會開始關注機器學習系統優化目標以外的一些問題。這個時候，目標就不如之前那么清晰，那么如果目標沒有確定下來的話，先不要在特征上浪費時間。

Rule #39: Launch decisions are a proxy for long-term product goals.

規則39：上線決策是長期產品目標的代理。

這句話讀起來有點別扭，作者舉了幾個例子來說明，我覺得核心就是在講一件事情：系統、產品甚至公司的長遠發展需要通過多個指標來綜合衡量，而新模型是否上線要綜合考慮這些指標。所謂代理，指的就是優化這些綜合指標就是在優化產品、公司的長遠目標。

決策只有在所有指標都在變好的情況下才會變得簡單。但常常事情沒那么簡單，尤其是當不同指標之間無法換算的時候，例如A系統有一百萬日活和四百萬日收入，B系統有兩百萬日活和兩百萬日收入，你會從A切換到B嗎？或者反過來？答案是或許都不會，因為你不知道某個指標的提升是否會cover另外一個指標的下降。

關鍵是，沒有任何一個指標能回答：“五年后我的產品在哪里”？

而每個個體，尤其是工程師們，顯然更喜歡能夠直接優化的目標，而這也是機器學習系統常見的場景 。現在也有一些多目標學習系統在試圖解決這種問題。但仍然有很多目標無法建模為機器學習問題，比如用戶為什么會來訪問你的網站等等。作者說這是個AI-complete問題，也常被稱為強AI問題，簡單來說就是不能用某個單一算法解決的問題。

Rule #40: Keep ensembles simple.

規則40：ensemble策略保持簡單。

什么叫簡單的ensemble？作者認為，只接受其他模型的輸出作為輸入，不附帶其他特征的ensemble，叫做簡單的ensemble。換句話說，你的模型要么是單純的ensemble模型，要么是普通的接收大量特征的基模型。

除了保持簡單，ensemble模型最好還能具有一些良好的性質。例如，某個基模型的性能提升不能降低組合模型的性能。以及，基模型最好都是可解釋的（例如是校準的)，這樣基模型的變化對上層的組合模型來說也是可解釋的。同時，一個基模型預測概率值的提升不會降低組合模型的預測概率值。

Rule #41: When performance plateaus, look for qualitatively new sources of information to add rather than refining existing signals.

規則41：當效果進入穩定期，尋找本質上新的信息源，而不是優化已有的信號。

你加了一些用戶的人口統計學特征，你加了一些文檔的文字特征，等等，但是關鍵指標上的提升還不到1%。現在咋整？

這時就應該考慮加一些根本上不同的特征，例如用戶再過去一天、一周看過的文檔歷史，或者另外一個數據源的數據。總之，要加入完全不同的維度的特征。此外也可以嘗試使用深度學習，但同時也要調整你對ROI的預期，并且要評估增加的復雜度換來的收益是否值得。

Rule #42: Don’t expect diversity, personalization, or relevance to be as correlated with popularity as you think they are.

規則42：多樣性，個性化或者相關性與流行度的相關性關系可能要比你想的弱很多。

多樣性意味著內容或者來源的多樣性；個性化意味著每個用戶得到不一樣的東西；相關性意味著一個query的返回結果相比其他query與這個query更相關。所以這三個指標的含義都是與普通不一樣。

但問題在于普通的東西很難被打敗。

如果你的衡量指標是點擊、停留時長、觀看數、分享數等等，你本質上是在衡量東西的流行度。有的團隊有時會希望學到一個多樣化的個性化模型。為此，會加入個性化特征和多樣化特征，但是最后會發現這些特征并沒有得到預期的權重。

這并不能說明多樣性、個性化和相關性不重要。像前文指出，可以通過后續的處理來增加多樣性或相關性。如果這時看到長期目標提升了，你就可以確定多樣性/相關性是有用的。這時你就可以選擇繼續使用后續處理的方式，或者根據多樣性和相關性直接修改要優化的objective。

Rule #43: Your friends tend to be the same across different products. Your interests tend not to be.

規則43：你在不同產品上的好友一般是一樣的，但你的興趣通常會不一樣。

谷歌經常在不同產品上使用同樣的好友關系預測模型，并且取得了很好的效果，這證明不同的產品上好友關系是可以遷移的，畢竟他們是固定的同一批人。但他們嘗試將一個產品上的個性化特征使用到另外一個產品上時卻常常得不到好結果。可行的做法是使用一個數據源上的原始數據來預測另外數據源上的行為，而不是使用加工后的特征。此外，用戶在另一個數據源上的行為歷史也會有用。

總結

從上面洋洋灑灑43條經驗之談中不難看出，大神作者認為，對于大多數機器學習應用場景來說，我們需要解決的問題大多數都是工程問題，解決這些工程問題需要的并不是復雜的理論，更多是對細節、架構、過程的仔細推敲和精致追求。而這些是我們非大神的普通人可以做到的，如果說大神做的是95分以上的系統，那么我們只要對工程架構、過程和細節做好足夠的優化，我們也可以做出至少80分的系統。