機器學習的規則：

機器學習工程的最佳做法

Martin Zinkevich

本文件旨在協助具備機器學習基礎知識的使用者，瞭解 Google 在機器學習方面的最佳做法。這份指南提供機器學習的樣式，類似於 Google C++ 樣式指南和其他實用程式設計的熱門指南。如果您曾修過機器學習課程，或是建立或使用機器學習模型，就具備閱讀本文所需的背景知識。

Martin Zinkevich 介紹他最喜歡的 10 項機器學習規則。請繼續閱讀，瞭解所有 43 條規則！

術語

在討論有效的機器學習時，以下術語會一再出現：

• 例項：您要進行預測的項目。舉例來說，您可能想將某個網頁分類為「關於貓」或「不關於貓」。
• 標籤：預測作業的答案，可能是機器學習系統產生的答案，或是訓練資料中提供的正確答案。舉例來說，網頁的標籤可能會是「關於貓」。
• 特徵：在預測工作中使用的執行個體屬性。舉例來說，網頁可能具有「包含字詞 'cat'」的功能。
• 特徵欄：一組相關特徵，例如使用者可能居住的所有可能國家/地區。一個範例可能在特徵欄中顯示一或多個特徵。「特徵欄」是 Google 專屬的術語。在 VW 系統 (Yahoo/Microsoft) 中，特徵欄稱為「命名空間」，在 欄中稱為「欄位」。
• 範例：一個執行個體 (及其特徵) 和一個標籤。
• 模型：預測工作的統計表示法。您會根據示例訓練模型，然後使用模型進行預測。
• 指標：您關心的數字。不一定會直接最佳化。
• 目標：演算法嘗試最佳化的指標。
• 管道：圍繞機器學習演算法的基礎架構。包括從前端收集資料、將資料放入訓練資料檔案、訓練一或多個模型，以及將模型匯出至實際環境。
• 點閱率：網頁訪客點按廣告中連結的百分比。

總覽

如何打造優質產品：

像優秀的工程師一樣進行機器學習，而不是像優秀的機器學習專家一樣。

您將面臨的大部分問題，其實都是工程問題。即使擁有優秀的機器學習專家提供的所有資源，大部分的成果都來自於優異的功能，而非優異的機器學習演算法。因此，基本做法如下：

1. 確保管道端到端運作順暢。
2. 先設定合理的目標。
3. 以簡單的方式新增常見功能。
4. 確保管道持續運作。

這種做法在長時間內都會有效。只有在沒有其他簡單技巧可讓您更進一步時，才改用這個方法。增加複雜性會導致日後版本的推出速度變慢。

當您已嘗試所有簡單的訣竅後，或許就該採用尖端機器學習技術了。請參閱「第 3 階段」機器學習專案相關說明。

本文件的安排方式如下：

1. 第一部分可協助您瞭解是否適合建構機器學習系統。
2. 第二部分將說明如何部署第一個管道。
3. 第三部分將說明如何在推出及迭代時，同時在管道中新增新功能，以及如何評估模型和訓練/服務偏差。
4. 最後一部分則是說明遇到停滯期時該怎麼做。
5. 接著，您會看到一張相關作品清單和附錄，其中包含本文件中常用系統的背景資訊。

在使用機器學習之前

規則 #1：不必擔心推出不含機器學習功能的產品。

機器學習很酷，但需要資料。理論上，您可以從其他問題中取得資料，然後針對新產品調整模型，但這可能會比基本啟發法的表現差。如果您認為機器學習可帶來 100% 的效益，則啟發式搜尋可為您帶來 50% 的效益。

舉例來說，如果您要在應用程式市集中為應用程式排名，可以使用安裝率或安裝次數做為啟發式。如果您偵測到垃圾內容，請篩除先前曾傳送垃圾內容的發布商。也不要害怕使用人工編輯。如果需要為聯絡人排序，請將最近使用的聯絡人排在最高 (甚至可依字母順序排序)。如果產品並非絕對需要機器學習，請等到有資料時再使用。

規則 #2：首先設計並導入指標

在正式定義機器學習系統的功能之前，請盡可能在目前的系統中追蹤相關資料。原因如下：

1. 這樣一來，您就能更輕鬆地在早期獲得系統使用者的許可。
2. 如果您認為未來可能會遇到問題，建議您現在就取得歷來資料。
3. 如果您在設計系統時考量到指標檢測，日後就能獲得更好的結果。具體來說，您不希望在記錄檔中使用 grep 尋找字串，以便評估指標！
4. 您會發現哪些項目有所變更，哪些項目則維持不變。舉例來說，假設您想直接針對單日活躍使用者進行最佳化。不過，在您初步操作系統時，可能會發現，即使大幅調整使用者體驗，這個指標也不會有明顯變化。

Google Plus 團隊會評估每個閱讀次數、每個閱讀次數的轉貼次數、每個閱讀次數的 +1 次數、每個閱讀次數的留言次數、每位使用者的留言次數、每位使用者的轉貼次數等指標，並據此計算貼文在放送時間的優良程度。此外，請注意，實驗架構非常重要，因為您可以將使用者分組成不同的群組，並依實驗匯總統計資料。請參閱規則 #12。

您可以更自由地收集指標，進一步瞭解系統的整體運作情形。發現問題嗎？新增指標來追蹤這項指標！您是否對上次發布版本的某些量化變更感到興奮？新增指標來追蹤這項指標！

規則 #3：選擇機器學習，而非複雜的啟發式。

只要使用簡單的啟發式，就能讓產品順利上市。複雜的啟發式無法維護。取得資料並對要達成的目標有基本概念後，請繼續使用機器學習。如同大多數的軟體工程工作，您應該要持續更新方法，無論是啟發式或機器學習模型皆然。您會發現，機器學習模型更容易更新和維護 (請參閱「規則 #16」)。

機器學習第 1 階段：您的第一個管道

請專注於第一個管道的系統基礎架構。雖然您可以盡情發揮想像力，思考要進行哪些機器學習，但如果您不先信任管道，就很難瞭解發生了什麼事。

規則 #4：讓第一個模型保持簡單，並確保基礎架構正確無誤。

第一個模型可為產品帶來最大的提升，因此不必太花俏。但您會遇到比預期更多的基礎架構問題。在任何人都能使用您新穎的機器學習系統之前，您必須先決定下列事項：

• 如何取得學習演算法的範例。
• 針對系統中「好」和「壞」的定義，先進行初步篩選。
• 如何將模型整合至應用程式。您可以即時套用模型，也可以離線對範例預先計算模型，並將結果儲存在表格中。舉例來說，您可能會想預先分類網頁並將結果儲存在表格中，但也可能會想即時分類即時通訊訊息。

選擇簡單的功能，可更輕鬆地確保：

• 特徵正確傳送至學習演算法。
• 模型會學習合理的權重。
• 特徵正確傳送至伺服器中的模型。

只要您擁有可可靠執行這三項作業的系統，就已完成大部分工作。簡易模型會提供基準指標和基準行為，可用於測試更複雜的模型。有些團隊會以「中立」的首次發布為目標：首次發布時，明確降低機器學習成果的優先順序，以免分心。

規則 #5：將基礎架構與機器學習分開測試。

請確認基礎架構可供測試，且系統的學習部分已封裝，以便您測試周遭的所有內容。詳細說明：

1. 測試將資料輸入演算法。檢查是否已填入應填入的特徵欄。在隱私權允許的情況下，請手動檢查訓練演算法的輸入內容。請盡可能檢查管道中的統計資料，並與其他地方處理相同資料的統計資料進行比較。
2. 測試從訓練演算法中取得模型。請確認訓練環境中的模型與服務環境中的模型得分相同 (請參閱「規則 #37」)。

機器學習有不可預測的元素，因此請務必測試用於訓練和服務建立範例的程式碼，並確保您可以在服務期間載入及使用固定模型。此外，請務必瞭解您的資料：請參閱分析大型複雜資料集的實用建議。

規則 #6：複製管道時，請留意資料遺漏。

我們通常會複製現有管道來建立管道 (即貨物崇拜程式設計)，而舊管道會捨棄新管道所需的資料。舉例來說，Google Plus「熱門內容」管道會刪除較舊的貼文 (因為它會嘗試為最新貼文進行排名)。這個管道已複製用於 Google Plus 串流，其中舊文仍有意義，但管道仍會刪除舊文。另一個常見的模式是只記錄使用者看到的資料。因此，如果我們想模擬使用者為何未看到特定貼文，這類資料就毫無用處，因為所有負面範例都已刪除。Play 也發生類似問題。在處理 Play 應用程式首頁時，我們建立了新的管道，其中也包含 Play 遊戲的首頁範例，但沒有任何功能可釐清每個範例的來源。

規則 #7：將推論法轉換為功能，或在外部處理。

一般來說，機器學習要解決的問題並非完全新穎。現有系統可用於排名、分類或解決您要解決的問題。也就是說，系統會使用一連串的規則和經驗法則。透過機器學習微調，這些同樣的經驗法則也能帶來提升效果。您應該針對啟發法的所有資訊進行挖掘，原因有二：首先，轉換至機器學習系統的過程會更順暢。其次，這些規則通常包含許多您不想捨棄的系統直覺。您可以透過四種方式使用現有的啟發法：

• 使用經驗法則進行預處理。如果這項功能非常棒，那麼這就是一個選項。舉例來說，如果垃圾郵件篩選器已將寄件者列入黑名單，請勿嘗試重新學習「黑名單」的意思。封鎖訊息。這種方法最適合用於二元分類工作。
• 建立功能。直接從啟發法建立功能非常棒。舉例來說，如果您使用經驗法則來計算查詢結果的關聯性分數，可以將分數納入特徵的值。之後，您可能會想使用機器學習技術來處理值 (例如將值轉換為有限集合的離散值之一，或與其他特徵結合)，但請先使用啟發式產生的原始值。
• 挖掘啟發法的原始輸入內容。如果應用程式有結合安裝次數、文字中的字元數量和星期幾的啟發式，建議您將這些部分分開，並分別將這些輸入內容提供給學習模型。適用於集成的部分技巧也適用於這裡 (請參閱規則 #40)。
• 修改標籤。當您認為啟發式擷取的資訊目前不在標籤中時，可以使用這個選項。舉例來說，如果您想盡量提高下載次數，但也希望提供優質內容，那麼解決方法或許是將標籤乘以應用程式收到的平均星數。這裡有許多彈性。請參閱「第一個目標」。

在 ML 系統中使用推論法時，請留意增加的複雜度。在新的機器學習演算法中使用舊的經驗法則，有助於順利過渡，但請思考是否有更簡單的方法可達到相同效果。

監控

一般來說，請採用良好的警示衛生措施，例如讓警示可供採取行動，並提供資訊主頁。

規則 #8：瞭解系統的最新資料要求。

如果您有一個一天前的模型，效能會下降多少？一個星期？四分之一？這項資訊可協助您瞭解監控作業的優先順序。如果模型未更新一天，就會導致產品品質大幅下降，建議請工程師持續監控模型。大多數廣告放送系統每天都會處理新的廣告，因此必須每天更新。舉例來說，如果 Google Play 搜尋的 ML 模型未更新，可能會在一個月內產生負面影響。Google Plus 熱門內容模型中有些模型沒有貼文 ID，因此這些模型的匯出頻率可能不高。其他具有貼文 ID 的模型更新頻率則會高出許多。另外也請注意，新鮮度可能會隨時間變動，尤其是在模型中新增或移除特徵欄時。

規則 #9：在匯出模型前偵測問題。

許多機器學習系統都有一個階段，可讓您將模型匯出供服務使用。如果匯出的模型有問題，則是使用者面臨的問題。

在匯出模型前，請先進行合理性檢查。具體來說，請確認模型在保留資料上的表現是否合理。或者，如果您對資料有疑慮，請不要匯出模型。許多持續部署模型的團隊會在匯出前檢查 ROC 曲線 (或 AUC) 下面積。未匯出的模型問題需要透過電子郵件警示通知，但面向使用者的模型問題可能需要透過網頁通知。因此，建議您在影響使用者前先等待，確認一切無誤。

規則 #10：留意無聲失敗。

相較於其他類型的系統，機器學習系統更容易發生這類問題。假設要彙整的特定資料表不再更新。機器學習系統會進行調整，行為也會持續維持在合理水準，並逐漸衰退。有時您會發現資料表已過時好幾個月，只要簡單更新，就能比該季任何其他推出作業更有效地提升成效！特徵的涵蓋率可能會因實作變更而改變：例如，特徵欄可能會在 90% 的範例中填入資料，但突然降至 60% 的範例。Play 曾經有一個已停用 6 個月的資料表，單單只是重新整理這個資料表，安裝率就提升了 2%。如果您追蹤資料的統計資料，並偶爾手動檢查資料，就能減少這類失敗情形。

規則 #11：為功能欄指定擁有者和說明文件。

如果系統很大，且有許多地圖項目欄，請瞭解每個地圖項目欄的建立者或維護者。如果您發現瞭解某個功能資料欄的人員即將離職，請務必確保有人掌握相關資訊。雖然許多特徵欄都有說明性名稱，但最好能更詳細說明特徵為何、來自何處，以及預期的效益。

第一個目標

您有許多指標或系統評估項目，但機器學習演算法通常需要單一目標，也就是演算法「嘗試」最佳化的數字。我會在此區分目標和指標：指標是系統回報的任何數字，可能重要也可能不重要。另請參閱規則 2。

規則 #12：不要過度思考要直接最佳化的目標。

您想賺錢、讓使用者滿意，並讓世界變得更美好。您會關心許多指標，因此應評估所有指標 (請參閱「規則 2」)。不過，在機器學習流程初期，您會發現所有轉換次數都會上升，即使是未直接最佳化的轉換次數也是如此。舉例來說，假設您想瞭解點擊次數和網站停留時間，如果您以點擊次數為最佳化目標，則花費的時間可能會增加。

因此，請保持簡單，如果您仍可輕鬆提高所有指標，就不要過度思考如何平衡各項指標。不過，請勿過度解讀這項規則：請勿將目標與系統的最終健康狀況混淆 (請參閱「規則 #39」)。如果您發現自己提高了直接最佳化指標，但決定不推出，可能需要進行一些目標修訂。

規則 #13：為第一個目標選擇簡單、可觀察且可歸因的指標。

您可能不清楚真正的目標為何，雖然您認為自己知道，但當您仔細查看資料，並將舊系統和新 ML 系統並排分析時，就會發現自己想調整目標。此外，不同團隊成員通常無法就真正的目標達成共識。機器學習目標應為易於評估的項目，並可做為「實際」目標的代理。事實上，通常並沒有「真正的」目標 (請參閱 第 39 條)。因此，請訓練簡單的 ML 目標，並考慮在頂層建立「政策層」，以便新增其他邏輯 (最好是簡單的邏輯) 來進行最終排名。

最容易模擬的使用者行為，是直接觀察到且可歸因於系統動作的行為：

• 這個排名連結是否有人點選？
• 這個排名物件是否已下載？
• 這個排名物件是否已轉寄/回覆/傳送電子郵件？
• 這個排名物件是否已評分？
• 系統是否已將這個顯示物件標示為垃圾內容/色情內容/令人反感的內容？

一開始請避免模擬間接效果：

• 使用者是否在隔天造訪？
• 使用者造訪網站的時間長度為何？
• 每日活躍使用者為何？

間接影響是優質指標，可用於 A/B 版本測試和發布決策期間。

最後，請勿嘗試讓機器學習技術判斷下列內容：

• 使用者是否滿意產品？
• 使用者是否滿意這項體驗？
• 產品是否有助於改善使用者的整體健康狀況？
• 這會對公司的整體健康狀況有什麼影響？

這些都是重要的指標，但也非常難以評估。請改用代理程式：如果使用者滿意，他們會在網站上停留更久的時間。如果使用者滿意，他們會在明天再次造訪。就福祉和公司健康而言，人類必須做出判斷，才能將任何機器學習目標與您販售的產品性質和業務計畫連結。

規則 #14：從可解釋的模型開始，可簡化偵錯作業。

線性迴歸、邏輯迴歸和 Poisson 迴歸直接受到機率模型的影響。每項預測結果都可以解讀為機率或預期值。相較於使用目標 (零-一損失、各種轉折損失等) 的模型，這類模型可直接改善分類準確度或排名成效，因此更容易進行偵錯。舉例來說，如果訓練中的機率與並列或檢查實際系統時預測的機率有所出入，這種差異可能會顯示問題。

舉例來說，在線性、邏輯或 Poisson 迴歸中，有部分資料的平均預測預期值等於平均標籤 (1 刻度校正或剛校正)。假設您沒有規則化，且演算法已收斂，這項說法就成立，而且一般來說也大致正確。如果每個示例的特徵值為 1 或 0，則會校正該特徵值為 1 的 3 個示例組合。此外，如果每個範例的特徵都是 1，則所有範例的集合都會經過校正。

使用簡單的模型，更容易處理回饋迴圈 (請參閱規則 #36)。我們通常會使用這些機率預測結果來做出決策，例如依據預期價值 (即點擊/下載等機率) 將貼文依序排序。不過，請記得，在選擇要使用的模型時，決定因素比資料在模型中出現的可能性更重要 (請參閱規則 #27)。

規則 #15：在政策層中區分垃圾內容篩選和品質排名。

雖然品質排名是門藝術，但垃圾內容篩除卻是一場戰爭。使用者會清楚瞭解您用來判斷高品質貼文的信號，並調整貼文以符合這些屬性。因此，您的品質排名應著重於排名以善意發布的內容。您不應因為品質排名學習器將垃圾內容排名較高而將其視為次要。同樣地，應將「色情」內容與品質排名分開處理。垃圾郵件過濾功能則不然。您必須預期需要產生的功能會不斷變動。通常，您會在系統中設定明顯的規則 (例如如果某則貼文獲得三次以上垃圾票，就不要擷取該貼文)。任何學習模型都必須每天更新，甚至更快。內容創作者的聲譽將扮演重要角色。

在某種程度上，這兩個系統的輸出內容必須整合。請注意，搜尋結果中的垃圾郵件篩選標準，可能比電子郵件中的垃圾郵件篩選標準更嚴格。此外，為品質分類器移除訓練資料中的垃圾內容，也是標準做法。

機器學習階段 II：特徵工程

在機器學習系統生命週期的前一個階段，重要的問題是將訓練資料導入學習系統、取得任何感興趣的指標，以及建立服務基礎架構。在您擁有可運作的端對端系統，並完成單元和系統測試後，第 II 階段就會開始。

在第二階段，我們發現許多容易入手的目標。系統中可導入的功能有很多，因此，機器學習的第二階段就是盡可能擷取所有特徵，並以直覺的方式加以結合。在這個階段，所有指標都應持續上升。這時將有許多發布活動，因此是個不錯的時機，可以邀請許多工程師加入，協助您整合所有必要資料，打造出真正出色的學習系統。

規則 #16：規劃推出和迭代。

請勿認為您目前正在處理的模型會是最後一個推出的模型，甚至不會停止推出模型。因此，請考量這次發布作業所增加的複雜度是否會拖慢日後的發布作業。許多團隊多年以來，每季或更頻繁地推出模型。推出新模型有三個基本原因：

• 您正在推出新功能。
• 您正在調整正規化，並以新的方式結合舊功能。
• 您正在調整目標。

無論如何，為模型提供一點愛心也許是好事：檢視輸入範例的資料，有助於找出新的信號，以及舊的、已損壞的信號。因此，在建構模型時，請考量新增、移除或重新組合功能的難易程度。請想想建立管道的新副本並驗證其正確性有多麼簡單。思考是否可以同時執行兩或三個副本。最後，請放心，第 35 個功能是否會納入此版本的管道。您會在下個季度收到。

規則 #17：先從直接觀察和回報的特徵開始，而非學習的特徵。

這可能會引起爭議，但可以避免許多陷阱。首先，讓我們說明什麼是學習特徵。學習特徵是指由外部系統 (例如無監督的聚類系統) 或學習器本身 (例如透過因式分解模型或深度學習) 產生的特徵。這兩種方法都很實用，但可能會產生許多問題，因此不應用於第一個模型。

如果您使用外部系統建立功能，請注意，外部系統有其自身的目標。外部系統的目標可能與您目前的目標僅有微弱的關聯。如果您擷取外部系統的快照，該快照可能會過時。如果您從外部系統更新功能，這些意義可能會有所變動。如果您使用外部系統提供功能，請注意，這項做法需要格外小心。

因子化模型和深度模型的主要問題是，它們是非凸的。因此，我們無法保證能近似或找到最佳解，而且每次迭代中找到的局部極小值也可能不同。這種變化會讓您難以判斷系統變更的影響是否具有意義或隨機。建立不含深層特徵的模型，即可獲得出色的基準成效。達到這個基準後，您可以嘗試更專業的做法。

規則 #18：探索可在不同情境中通用的內容功能。

機器學習系統通常只是更大系統的一小部分。舉例來說，假設有篇貼文可能會用於「熱門內容」，許多人會在貼文顯示於「熱門內容」之前，先按讚、轉貼或留言。如果您向學習器提供這些統計資料，學習器就能在所要最佳化的情況中，宣傳沒有資料的新貼文。YouTube「接著看」功能可使用YouTube 搜尋結果中的觀看次數或共觀看次數 (在觀看某部影片後，觀看另一部影片的次數)。您也可以使用明確的使用者評分。最後，如果您有使用者動作做為標籤，在不同情境中看到文件上的該動作，這可能會是一項很棒的功能。所有這些功能都讓您將新內容加入情境。請注意，這不是個人化功能：請先找出某人是否喜歡這個情境中的內容，然後找出喜歡或不喜歡的人。

規則 #19：盡可能使用特定功能。

有大量資料時，學習數百萬個簡單特徵比學習少數複雜特徵更容易。擷取的文件 ID 和標準化查詢不會提供太多一般資訊，但會將您的排名與主查詢標籤保持一致。因此，請放心使用一組特徵，其中每個特徵只適用於資料的一小部分，但整體涵蓋率超過 90%。您可以使用正規化功能，排除只適用於少數範例的特徵。

規則 #20：結合及修改現有功能，以人類可理解的方式建立新功能。

您可以透過多種方式組合及修改功能。您可以透過 TensorFlow 等機器學習系統，透過轉換預先處理資料。最常見的兩種方法是「離散化」和「交叉」。

離散化是指取連續特徵，並從中建立許多離散特徵。請考慮年齡等連續特徵。您可以建立一個特徵，當年齡小於 18 歲時為 1，當年齡介於 18 到 35 歲之間時為 1，以此類推。請勿過度思考這些直方圖的邊界：基本分位數就會產生最大影響。

交叉運算可合併兩個以上的特徵欄。在 TensorFlow 的術語中，特徵欄是一組同質特徵 (例如 {male, female}、{US, Canada, Mexico} 等等)。交叉是指包含特徵的新特徵欄，例如 {male, female} × {US,Canada, Mexico}。這個新特徵欄將包含特徵 (男性、加拿大)。如果您使用 TensorFlow，並要求 TensorFlow 為您建立此交叉，則代表加拿大男性的範例中會出現這項 (男性、加拿大) 特徵。請注意，如果模型包含三個、四個或更多基本特徵欄的交叉，就需要大量資料才能學習。

產生非常大型特徵欄的交叉可能會過度擬合。舉例來說，假設您正在執行某種搜尋作業，且查詢中含有字詞的功能欄，以及文件中含有字詞的功能欄。您可以將這些元素與交叉線結合，但最終會產生大量功能 (請參閱「規則 #21」)。

使用文字時，有兩種替代做法。最嚴格的做法是使用點積運算式。最簡單的點積是計算查詢和文件之間的共同字詞數量。這項功能隨後可進行離散化處理。另一種方法是交集：因此，我們會建立一個功能，只有在文件和查詢中同時出現「pony」這個字詞時才會出現，以及另一個功能，只有在文件和查詢中同時出現「the」這個字詞時才會出現。

規則 #21：在線性模型中，您可以學習的特徵權重數量大致與資料量成正比。

關於模型的適當複雜度，統計學習理論有許多有趣的結果，但您只需要知道這項規則。我曾與許多人討論過這個問題，他們懷疑從一千個範例中學習任何東西，或需要超過一百萬個範例，因為他們陷入某種學習方法的困境。關鍵在於根據資料規模調整學習方式：

1. 如果您正在建構搜尋排名系統，且文件和查詢中含有數百萬個不同的字詞，且您有 1000 個標記範例，則應在文件和查詢功能之間使用點積乘積、TF-IDF 和半打其他高度人為設計的功能。1000 個示例，十幾個特徵。
2. 如果您有百萬個示例，請使用正規化和可能的特徵選取功能，交叉檢查文件和查詢特徵欄。這會產生數百萬個特徵，但經過規格化後，就會減少。一千萬個示例，也許有十萬個特徵。
3. 如果您有數十億或數百億個示例，可以使用特徵選取和正規化，將特徵欄與文件和查詢符號交叉比對。您將擁有 10 億個示例和 1, 000 萬個功能。統計學習理論很少提供嚴格的界線，但可提供很好的起點指引。

最後，請使用規則 #28 決定要使用哪些功能。

規則 #22：清理不再使用的功能。

未使用的功能會產生技術負債。如果您發現自己沒有使用某項功能，且將該功能與其他功能結合後無法正常運作，請將該功能從基礎架構中移除。您希望基礎架構保持乾淨，以便盡快嘗試最有潛力的功能。如有需要，其他人隨時可以重新加入您的功能。

考慮新增或保留哪些功能時，請留意涵蓋範圍。這項功能涵蓋多少個範例？舉例來說，如果您提供一些個人化功能，但只有 8% 的使用者使用個人化功能，那麼這項功能的效果就不會太好。

同時，部分功能可能會超越預期。舉例來說，如果您有一個特徵只涵蓋 1% 的資料，但 90% 的示例都包含該特徵，那麼這項特徵就非常適合加入。

系統的人工分析

在進入機器學習的第 3 階段前，請務必先專注於機器學習課程未教導的內容：如何查看現有模型並加以改善。這項工作更像是藝術而非科學，但仍有幾種反模式可協助您避免發生這種情況。

規則 #23：您不是一般使用者。

這可能是團隊最容易陷入困境的方式。雖然「魚食」(在團隊內使用原型設計) 和「狗食」(在公司內使用原型設計) 有許多好處，但員工仍應檢查效能是否正確。雖然不應使用明顯不良的變更，但任何看起來與實際生產環境相去不遠的變更，都應進一步測試，例如付費讓一般使用者在群眾外包平台上回答問題，或是對真實使用者進行實驗。

原因有兩個。第一個原因是您太接近程式碼。你可能會尋找貼文的特定面向，或是過度投入情感 (例如確認偏誤)。第二點是，您的時間太寶貴。請考量九位工程師參加一小時會議的成本，以及在群眾外包平台上購買多少合約人力標籤。

如果您確實想取得使用者意見回饋，請採用使用者體驗方法論。在過程初期建立使用者人物角色 (Bill Buxton 的《Sketching User Experiences》有相關說明)，並在之後進行可用性測試 (Steve Krug 的《Don’t Make Me Think》有相關說明)。使用者人物角色是指虛構使用者。舉例來說，如果您的團隊全是男性，不妨設計一位 35 歲女性使用者人物角色 (完整的使用者特徵)，並查看系統產生的結果，而非 25 至 40 歲男性的 10 個結果。在可用性測試中，邀請實際使用者 (在本機或遠端) 觀看他們對網站的反應，也可以讓您獲得全新的觀點。

規則 #24：評估模型之間的差異。

在任何使用者查看新模型之前，您可以進行最簡單且有用的評估之一，就是計算新結果與實際生產環境的差異。舉例來說，如果發生排名問題，請在整個系統中針對查詢的樣本執行這兩種模型，並查看結果的對稱差異大小 (以排名位置加權)。如果差異很小，您不必執行實驗，就能知道結果不會有太大變化。如果差異很大，您就需要確保變更是正確的。查看對稱差異值偏高的查詢，有助於您從質的角度瞭解變更情形。不過，請務必確認系統穩定。請確認模型與自身比較時，對稱差異值偏低 (理想上為零)。

規則 #25：選擇模型時，實用效能勝過預測能力。

模型可能會嘗試預測點閱率。不過，關鍵問題還是在於您要如何運用預測結果。如果您是用來為文件排序，那麼最終排名的品質比預測本身更重要。如果您預測文件為垃圾內容的機率，並且設有封鎖門檻，那麼允許通過的內容精確度就更為重要。在大多數情況下，這兩者應一致：如果不一致，則可能只會帶來微幅的收益。因此，如果某些變更可改善記錄遺失率，但會降低系統效能，請尋找其他功能。當這種情況開始頻繁發生時，就該重新檢視模型的目標了。

規則 #26：在已測量的錯誤中找出模式，並建立新特徵。

假設您看到模型判斷錯誤的訓練範例。在分類工作中，這類錯誤可能是偽陽性或偽陰性。在排名任務中，錯誤可能發生在正面結果排名低於負面結果的情況。最重要的是，這就是機器學習系統知道自己出錯，並希望在有空時修正的例子。如果您為模型提供可修正錯誤的功能，模型就會嘗試使用該功能。

另一方面，如果您嘗試根據系統不認為是錯誤的範例建立功能，系統會忽略該功能。舉例來說，假設有人在 Play 應用程式搜尋中搜尋「免費遊戲」。假設其中一個熱門結果是與主題不太相關的惡作劇應用程式，因此您為「惡作劇應用程式」建立了一個功能。不過，如果您想盡量提高安裝次數，而使用者在搜尋免費遊戲時安裝了惡搞應用程式，則「惡搞應用程式」功能就無法發揮預期效果。

找到模型判斷錯誤的範例後，請找出目前特徵集以外的趨勢。舉例來說，如果系統似乎會將較長的貼文降級，請增加貼文長度。請勿過度著重於新增的功能。如果您要新增貼文長度，請不要試著猜測「長」的意思，只要新增幾個功能，讓模型自行判斷如何處理即可 (請參閱規則 #21)。這是取得所需內容最簡單的方式。

規則 #27：嘗試量化觀察到的不良行為。

您的團隊中，有些成員會開始對系統中不受現有損失函式擷取的屬性感到不滿。此時，他們應該盡力將抱怨轉化為實際數字。舉例來說，如果他們認為 Play 搜尋中顯示的「惡作劇應用程式」太多，可以請人為評估人員找出惡作劇應用程式。(在這種情況下，您可以使用人工標記資料，因為查詢中只有一小部分會產生大量流量。)如果問題可評估，您就可以開始將問題用作功能、目標或指標。一般來說，您應該先評估，再進行最佳化。

規則 #28：請注意，相同的短期行為不一定會導致相同的長期行為。

假設您有一個新系統，可查看每個 doc_id 和 exact_query，然後計算每個查詢的每個文件點擊機率。您發現在並排和 A/B 測試中，這項系統的行為幾乎與目前的系統相同，因此您決定推出這項系統，因為它很簡單。但您會發現系統不會顯示任何新應用程式。這是因為由於系統只會根據該查詢的自身記錄顯示文件，因此無法得知應顯示新文件。

要瞭解這類系統的長期運作方式，唯一的方法就是讓系統只根據模型上線時取得的資料進行訓練。這很困難。

訓練/應用偏差

訓練/提供偏移是訓練期間與應用期間的效能差異。造成這種偏差的原因可能包括：

• 資料在訓練和提供管線中處理方式的差異。
• 訓練資料與服務資料之間的變化。
• 模型和演算法之間的意見回饋循環。

我們發現 Google 的實際機器學習系統有訓練/服務偏差，這會對效能造成負面影響。最佳解決方案是明確監控，以免系統和資料變更導致偏差。

規則 #29：如要確保訓練方式與服務方式一致，最佳做法是儲存在服務時間點使用的特徵組合，然後將這些特徵傳送至記錄檔，以便在訓練時使用。

即使您無法對每個範例執行這項操作，請對其中的一小部分進行驗證，以便確認服務和訓練之間的一致性 (請參閱「規則 #37」)。在 Google 進行這項評估的團隊有時會對結果感到意外。YouTube 首頁已改為在服務時間記錄功能，不僅大幅改善品質，也降低程式碼複雜度，許多團隊也正在改用基礎架構。

規則 #30：請勿隨意捨棄重要性加權的取樣資料！

當資料過多時，您可能會想使用檔案 1 到 12，並忽略檔案 13 到 99。這是錯誤的做法。雖然從未向使用者顯示的資料可以捨棄，但其他資料則建議使用重要性權重。重要性權重表示，如果您決定以 30% 的機率抽樣 X 個範例，則可為其指定 10/3 的權重。有了重要性權重，規則 #14 中討論的所有校正屬性仍會保留。

規則 #31：請注意，如果您在訓練和服務期間彙整資料表中的資料，資料表中的資料可能會變更。

假設您要將文件 ID 與包含這些文件功能 (例如註解或點擊次數) 的資料表彙整。在訓練和應用期間，表格中的功能可能會有所變更。在這種情況下，模型對同一份文件的預測結果可能會在訓練和服務期間有所差異。避免這類問題最簡單的方法，就是在服務時間記錄功能 (請參閱「規則 #32」)。如果資料表變動緩慢，您也可以每小時或每天擷取資料表快照，以取得較為接近的資料。請注意，這仍無法完全解決問題。

規則 #32：盡可能在訓練管道和服務管道之間重複使用程式碼。

批次處理與線上處理不同。在線上處理作業中，您必須在收到每項要求時處理 (例如，您必須為每項查詢執行個別查詢)，而在批次處理作業中，您可以合併工作 (例如，進行彙整)。在放送時間，您會進行線上處理，而訓練則是批次處理工作。不過，您可以採取一些做法來重複使用程式碼。舉例來說，您可以建立專屬於系統的物件，讓任何查詢或彙整的結果以人類可讀的方式儲存，方便測試錯誤。接著，在收集所有資訊後，您可以在服務或訓練期間執行常用方法，在系統專屬的供人閱讀物件與機器學習系統預期的格式之間建立橋樑。這樣就能避免訓練提供偏移。因此，請盡量避免在訓練和服務之間使用兩種不同的程式設計語言。這項決定幾乎會讓您無法分享程式碼。

規則 #33：如果您根據 1 月 5 日前的資料產生模型，請針對 1 月 6 日之後的資料測試模型。

一般來說，請根據您用來訓練模型的資料後所收集的資料，評估模型的成效，這樣更能反映系統在實際工作環境中的運作情形。如果您根據 1 月 5 日前的資料產生模型，請使用 1 月 6 日以後的資料測試模型。您會預期新資料的效能不會那麼好，但不應大幅下降。由於可能會有每日影響，您可能無法預測平均點擊率或轉換率，但曲線下方的面積 (代表給予正面範例的分數高於負面範例的可能性) 應會相當接近。

規則 #34：在篩選的二元分類 (例如垃圾郵件偵測或判斷有興趣的電子郵件) 中，為了取得非常乾淨的資料，可以犧牲短期效能。

在篩選工作中，系統不會向使用者顯示標示為負面示例。假設您有一個篩選器，可在提交時封鎖 75% 的負面示例。您可能會想從向使用者顯示的例項中擷取其他訓練資料。舉例來說，如果使用者將電子郵件標示為垃圾郵件，但篩選器卻讓郵件通過，您可能就會從中學習。

但這種做法會產生取樣偏誤。您可以改為在放送期間將 1% 的所有流量標示為「保留」，並將所有保留的範例傳送給使用者，以便收集更清晰的資料。篩選器現在會封鎖至少 74% 的負面示例。這些保留的示例可成為訓練資料。

請注意，如果篩選器封鎖的負面範例達 95% 以上，這種做法就會變得不可行。即便如此，如果您想評估放送成效，可以使用更精簡的樣本 (例如 0.1% 或 0.001%)。十萬個示例就足以準確估算成效。

規則 #35：留意排名問題的內在偏差。

當你大幅變更排名演算法，導致顯示不同的結果時，就等於有效地變更了演算法日後會看到的資料。這類偏差會顯示出來，您應根據這類偏差設計模型。您可以採取多種做法。這些方法都是偏好模型已見過的資料。

1. 針對涵蓋更多查詢的功能，採用更高的規則化，而非僅針對單一查詢的功能。這樣一來，模型會偏好一或少數查詢專屬的功能，而非適用於所有查詢的功能。這種做法有助於避免熱門結果流入不相關的查詢。請注意，這與傳統建議相反，後者建議針對具有更多不重複值的特徵欄，進行更多規則化。
2. 只允許特徵具有正權重。因此，任何優質特徵都會比「未知」特徵來得好。
3. 不提供僅限文件的功能。這是 #1 的極端版本。舉例來說，即使某個應用程式無論搜尋查詢為何都很受歡迎，您也不會想在所有地方顯示該應用程式。不使用僅限文件的功能，就能簡化這項作業。您不想在所有地方顯示特定熱門應用程式，是因為讓所有所需應用程式都能存取，是相當重要的一件事。舉例來說，如果使用者搜尋「鳥類觀察應用程式」，可能會下載「Angry Birds」，但這絕非使用者的意圖。雖然顯示這類應用程式可能會提高下載率，但最終仍無法滿足使用者需求。

規則 #36：避免使用位置功能的迴圈回饋。

內容的位置會大幅影響使用者與內容互動的可能性。如果將應用程式放在第一個位置，使用者點擊的頻率就會提高，您也會認為應用程式更有可能獲得點擊。解決這個問題的方法之一，是新增位置特徵，也就是內容在網頁中的位置。您可以使用位置特徵訓練模型，讓模型學習權重，例如「1st­position」特徵的權重較高。因此，對於「1st­position=true」的範例，模型會將較少權重給予其他因素。接著，在放送時，您不會為任何例項提供位置功能，或為所有例項提供相同的預設功能，因為您是在決定候選項目的顯示順序之前為其評分。

請注意，由於訓練和測試之間存在不對稱性，因此請務必將任何位置特徵與模型的其他部分分開。理想情況下，模型應是位置特徵函式和其他特徵函式的總和。例如，請勿將位置特徵與任何文件特徵交叉。

規則 #37：評估訓練/應用偏差。

一般來說，有幾個因素可能會造成偏差。此外，您也可以將其分成幾個部分：

• 訓練資料和保留資料的成效差異。一般來說，這類問題總是存在，但不一定是壞事。
• 保留資料和「隔日」資料的成效差異。再次強調，這個值一律會存在。您應調整正規化方式，盡可能提高隔天的成效。不過，如果在保留資料和隔天資料之間出現大幅的效能下滑，可能表示部分功能會受到時間影響，並可能降低模型效能。
• 「隔日」資料和即時資料的成效差異。如果您將模型套用至訓練資料中的範例，以及在服務時的相同範例，應該會得到完全相同的結果 (請參閱「規則 #5」)。因此，如果這裡出現差異，可能表示有工程錯誤。

機器學習第 III 階段：成長趨緩、最佳化精進和複雜模型

我們會提供一些指標，讓您知道第二階段即將結束。首先，每月收益會開始減少。您會開始在指標之間做出取捨：在某些實驗中，您會看到部分指標上升，其他指標下降。這就是有趣的地方。由於收益較難達成，機器學習必須更精密。注意：本節的規則比前幾節更為嚴格。我們發現許多團隊都經歷了機器學習第 1 階段和第 2 階段的快樂時光。進入第 III 階段後，團隊必須自行尋找路徑。

規則 #38：如果目標不一致，請不要浪費時間開發新功能。

當評估結果趨於穩定時，您的團隊就會開始著手處理目前機器學習系統目標範圍以外的問題。如前所述，如果現有演算法目標無法涵蓋產品目標，您就需要變更目標或產品目標。舉例來說，您可以針對點擊次數、加成目標或下載次數進行最佳化，但在決定推出前，請先參考人為評分。

規則 #39：發布決策是長期產品目標的代理值。

Alice 有個想法，可以減少預測安裝次數時的邏輯損失。她新增了一個功能。邏輯損失會降低。她進行實驗後，發現安裝率有所提升。不過，當她參加發布審查會議時，有人指出每日活躍使用者人數下降了 5%。團隊決定不推出模型。Alice 感到失望，但她現在意識到，發布決策取決於多項條件，其中只有部分條件可直接使用機器學習進行最佳化。

事實上，現實世界並非《龍與地下城》：沒有「命中率」可用於判斷產品的健康狀況。團隊必須使用所收集到的統計資料，嘗試有效預測系統未來的表現。他們需要關心參與度、1 天活躍使用者 (DAU)、30 天活躍使用者 (DAU)、收益，以及廣告主的投資報酬率。這些在 A/B 測試中可評估的指標，只是長期目標的代理指標：滿足使用者、增加使用者、滿足合作夥伴和獲利。即使如此，您仍可將這些指標視為代理指標，以便在五年後擁有實用、高品質的產品和蓬勃發展的公司。

只有當所有指標都改善 (或至少沒有惡化) 時，才容易做出推出決策。如果團隊要選擇複雜的機器學習演算法和簡單的啟發法，如果簡單的啟發法在所有這些指標方面表現得更好，則應選擇啟發法。此外，所有可能的指標值並未明確排序。具體來說，請考慮以下兩種情況：

實驗	每日活躍使用者人數	收益/天
A	100 萬	$4 百萬美元
B	200 萬	$2 百萬美元

如果目前的系統是 A，團隊就不會改用 B。如果目前的系統是 B，團隊不太可能改用 A。這似乎與理性行為相衝突；不過，變更指標的預測結果不一定會實現，因此兩種變更都存在重大風險。每個指標都涵蓋團隊關注的某些風險。

此外，沒有任何指標能涵蓋團隊的終極疑問：「我的產品在五年後會是什麼樣子？」

另一方面，個人通常會偏好直接可進行最佳化的目標。大多數機器學習工具都偏好這種環境。在這種環境中，工程師可以持續推出新功能。有一種機器學習技術，也就是多目標學習，可以開始解決這個問題。舉例來說，您可以制定限制滿足問題，為每個指標設定較低的下限，並最佳化某些指標的線性組合。不過，即使如此，並非所有指標都容易歸類為機器學習目標：如果使用者點選文件或安裝應用程式，是因為系統顯示了相關內容。但要找出使用者造訪網站的原因，難度就高得多。如何預測網站整體未來成效，是AI 完整性的一部分：就像電腦視覺或自然語言處理一樣困難。

規則 #40：保持組合簡單。

統合模型會擷取原始特徵並直接為內容排序，是修正和瞭解最容易的模型。不過，集合模型 (結合其他模型的分數的「模型」) 可能會更有效。為簡化操作，每個模型應為只接收其他模型輸入內容的集合模型，或接收多個特徵的基本模型，但不能同時為這兩者。如果您在其他已訓練的模型上建立模型，將兩者結合可能會導致不良行為。

使用簡易模型進行集成，只採用「基本」模型的輸出內容做為輸入內容。您也想對這些集成模型強制執行屬性。舉例來說，基本模型產生的分數增加，不應降低集成模型的分數。此外，最好是輸入的模型可透過語意解讀 (例如校正)，以免基礎模型的變更會讓集成模型感到困惑。此外，強制規定基礎分類器的預測機率增加，不會降低集成的預測機率。

規則 #41：當成效停滯不前時，請尋找新的資訊來源，而不是改善現有信號。

您已新增使用者的部分客層資訊。您已在文件中新增了一些關於字詞的資訊。您已完成範本探索，並調整了正則化。您在幾個季度內，沒有看到任何推出活動可讓主要指標提升超過 1%。現在該怎麼辦？

接下來，您可以開始為截然不同的功能建構基礎架構，例如這個使用者在過去一天、一週或一年內存取的文件記錄，或是來自其他資源的資料。使用 wikidata 實體或公司內部資訊 (例如 Google 的知識圖譜)。使用深度學習。開始調整對投資報酬率的預期，並據此加強努力。如同任何工程專案，您必須權衡新增新功能的好處，以及增加複雜性的成本。

規則 #42：不要以為多元、個人化或相關性與熱門程度的關聯性會如你預期般一致。

內容組合中的多元化涵義廣泛，其中最常見的多元化是內容來源的多元化。個人化功能會讓每位使用者取得各自的結果。相關性表示特定查詢的結果比其他結果更適合該查詢。因此，這三個屬性都定義為與一般屬性不同。

問題是，一般人往往很難勝出。

請注意，如果系統會評估點擊次數、花費時間、觀看次數、+1 次數、重新分享次數等，代表您在評估內容的人氣。團隊有時會嘗試學習多樣化的個人模型。為了提供個人化服務，他們會新增可讓系統提供個人化服務 (某些特徵代表使用者的興趣) 或多樣化服務 (特徵可指出此文件是否與其他傳回的文件有任何共同特徵，例如作者或內容) 的特徵，並發現這些特徵的重量低於預期 (或有時會出現不同的符號)。

但這並不表示多元化、個人化或相關性不重要。如前述規則所述，您可以進行後製，提高多樣性或相關性。如果長期目標有顯著成長，您可以宣稱除了熱門程度之外，多元性/相關性也具有價值。接著，您可以繼續使用後製程序，或是直接根據多樣性或相關性修改目標。

規則 #43：不同產品的使用者通常是相同的。但你的興趣通常不會。

Google 團隊在使用模型預測某項產品中連結的密切程度，並讓模型在另一項產品中順利運作後，獲得了許多進展。你的好友就是他們自己。另一方面，我見過許多團隊在不同產品之間，努力處理個人化功能的問題。是的，看起來應該可以運作。目前看來似乎沒有。有時，使用某項資源的原始資料來預測另一項資源的行為，有助於解決問題。此外，請注意，即使您知道使用者在其他資源上有記錄，也能提供協助。舉例來說，如果兩項產品都出現使用者活動，這本身就可能具有指標性。

相關工作

在 Google 和外部，都有很多關於機器學習的文件。

• 機器學習密集課程：機器學習應用簡介。
• 如要瞭解機器學習領域，請參閱 Kevin Murphy 的著作「Machine Learning: A Probabilistic Approach」。
• 良好的資料分析：一種思考資料集的資料科學方法。
• Deep Learning (深度學習) 一書，作者為 Ian Goodfellow 等人，可用於學習非線性模型。
• Google 的技術債相關論文，其中提供許多一般建議。
• Tensorflow 說明文件。

特別銘謝

感謝 David Westbrook、Peter Brandt、Samuel Ieong、Chenyu Zhao、Li Wei、Michalis Potamias、Evan Rosen、Barry Rosenberg、Christine Robson、James Pine、Tal Shaked、Tushar Chandra、Mustafa Ispir、Jeremiah Harmsen、Konstantinos Katsiapis、Glen Anderson、Dan Duckworth、Shishir Birmiwal、Gal Elidan、Su Lin Wu、Jaihui Liu、Fernando Pereira 和 Hrishikesh Aradhye 提供許多修正、建議和實用範例，協助我們完成這份文件。另外，也要感謝 Kristen Lefevre、Suddha Basu 和 Chris Berg 協助完成先前版本。任何錯誤、遺漏或 (天啊！) 不受歡迎的意見，都屬於我。

附錄

本文件中包含許多 Google 產品的參照資料。為了提供更多背景資訊，我將在下方簡短說明最常見的例子。

YouTube 簡介

YouTube 是一項串流影片服務。YouTube 接著看和 YouTube 首頁團隊都會使用 ML 模型來為推薦影片排序。「接著看」會推薦可在目前播放的影片結束後觀看的影片，而「首頁」則會推薦影片給瀏覽首頁的使用者。

Google Play 簡介

Google Play 提供多種解決各種問題的模式。Play 搜尋、Play 首頁個人化推薦內容，以及「使用者也安裝」的應用程式，都會使用機器學習技術。

Google+ 簡介

Google Plus 在多種情況下使用機器學習技術，例如在使用者看到的「動態」中為貼文進行排名、為「熱門貼文」(目前非常熱門的貼文) 進行排名、為您認識的人進行排名等等。Google Plus 已於 2019 年關閉所有個人帳戶，並於 2020 年 7 月 6 日由 Google Currents 取代商家帳戶。