機器學習的規則:

機器學習工程的最佳做法

Martin Zinkevich

本文件旨在協助具備機器學習基本知識的使用者,協助他們充分運用 Google 的機器學習最佳做法。這種呈現機器學習的方式,類似於 Google C++ 樣式指南和其他實用程式設計指南。如果您參加了機器學習的相關課程、建構或開發了機器學習模型,則具備閱讀這份文件所需的背景。

Martin Zinkevich 運用了 10 項喜愛的機器學習規則請繼續閱讀下文,瞭解全部 43 項規則!

術語

我們在有效機器學習的討論中反覆出現下列字詞:

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

總覽

打造優質產品的方法如下:

機器學習專家的表現

事實上,您會遇到的大部分問題就是工程問題。就算是優秀的機器學習專家所有資源,大部分效益也都來自優異的功能,而非卓越的機器學習演算法。基本做法如下:

  1. 請確保管道保持穩定。
  2. 請先設定合理的目標。
  3. 以簡單方式新增常用功能。
  4. 請確保管道維持穩定。

這種方法適用於很長一段時間。只有在沒有較為簡單的技巧可以致勝時,才使用此方法。增加複雜性,拖慢日後發布的速度。

用完簡單的訣竅後, 頂尖的機器學習絕對是未來的發展方向。請參閱階段 3 機器學習專案一節。

本文件的編排方式如下:

  1. 第一部分應該可協助您瞭解建構機器學習系統的時間是否適合您。
  2. 第二部分是部署第一個管道。
  3. 第三個部分是在為管道新增功能、如何評估模型以及訓練服務偏移等作業時啟動及疊代。
  4. 最後部分是指抵達高原時該怎麼做。
  5. 之後還有相關工作附錄清單,其中有一些常見系統的背景,如本文件中做為範例使用。

在機器學習之前

規則 #1:不要因為機器學習而推出產品。

機器學習很酷,但需要資料。理論上,您可以從另一個問題中取得資料,然後調整新產品的模型,但這樣的效能可能會低於基本heuristics。如果認為機器學習可以獲得 100% 的提升,那麼經驗法則可讓您完成 50% 的調整。

舉例來說,如果您在應用程式市集中的應用程式排名,可以使用安裝率或安裝次數做為經驗法則。如果您要偵測到垃圾內容 請過濾掉先前傳送垃圾郵件的發布者不要害怕使用人為編輯如果您需要為聯絡人排名,請將最近使用的最高優先順序 (甚至按字母順序排列) 排名。如果產品並非必要機器學習,請勿在取得資料前使用。

規則 2:首先,設計並導入指標。

在正式部署機器學習系統之前,請盡可能在您目前的系統中追蹤。這麼做的原因如下:

  1. 從系統的使用者取得權限會變得更容易。
  2. 如果您認為日後可能會有疑慮,建議您立即取得歷來資料。
  3. 如果您是在設計系統時考量指標檢測作業,日後難免會有所改善。具體來說,您應該不會想上在記錄中不斷尋找字串,藉此檢測您的指標!
  4. 你會注意到哪些部分有所改變,哪些部分保持不變。例如,假設您想要直接最佳化單日活躍使用者。不過,在系統處理系統的早期操作期間,您可能會發現這項指標的大幅變化並未明顯改變。

Google Plus 團隊會測量每次讀取、每次讀取的 +1 次數、每次讀取、留言/讀取數、每位使用者的留言數,以及每位使用者的轉貼次數等,這些指標是用來計算放送期間的貼文效益。另請注意,實驗架構可讓您將使用者分組為值區,並藉由實驗匯總統計資料。請參閱規則 #12

藉由更充分地收集指標,您可以更全面地瞭解系統。發現問題嗎?新增指標即可追蹤!期待上一個版本 有一些量化的變化嗎?新增指標即可追蹤!

規則 #3:根據複雜的經驗法則選擇機器學習技術。

簡單的經驗法則能協助你將產品送達門口。複雜的經驗法則無法維護。取得相關資料並瞭解要達成的目標後,接著來看看機器學習。與大部分的軟體工程工作一樣,您會需要持續更新方法,無論是經驗法則或機器學習式模型,都會發現機器學習的模型較容易更新及維護 (請參閱規則 #16)。

機器學習階段 1:第一個管道

針對第一個管道,將重點放在系統基礎架構上。雖然要思考所有即將進行的創意機器學習是很有趣的事,但如果您未先信任管道,那就很難釐清情況。

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

第一個模型可為產品帶來最大的進步,因此不需要太昂貴。不過,您會遇到比預期的更多基礎架構問題。在任何人使用您嶄新的機器學習系統之前,您必須先決定:

  • 如何取得學習演算法的範例。
  • 首次切記,說明「良好」和「不良」的意義。
  • 如何將模型整合至應用程式中。您可以即時套用模型,也可以離線針對範例預先運算模型,然後將結果儲存至資料表。舉例來說,您可能想要預先分類網頁,並將結果儲存在資料表中,但也建議您即時將即時通訊訊息分類。

選擇簡單的功能之後,您就能更輕鬆地確保:

  • 這些功能會正確地與學習演算法搭配運作。
  • 模型會學習合理的權重。
  • 特徵可正確到達伺服器中的模型。

只要系統能可靠地執行這三項動作,您就完成了大部分的工作。簡易模型可提供基準指標和基準行為,讓您測試更複雜的模型。某些團隊的目標是達成「中立」的目標,也就是首次推出,明確降低機器學習學習成效,避免分心。

規則 #5:在機器學習之外單獨測試基礎架構。

請確定基礎架構可供測試,並已封裝系統的學習部分,以便測試所有層面。詳細說明:

  1. 測試從演算法取得資料。確認應填入資料的特徵欄。在隱私權許可的情況下,手動檢查訓練演算法的輸入內容。如果可以,請比較管道的統計資料和在其他處處理的相同資料的統計資料。
  2. 測試從訓練演算法中取得模型。請確保訓練環境中的模型與服務環境中的模型獲得相同的分數 (請參閱規則 #37)。

機器學習有一個難以預測的元素,因此請確保您已針對在訓練與提供過程中建立範例的程式碼進行測試,且您可以在提供期間載入及使用固定的模型。此外,解讀資料也很重要:請參閱分析複雜大型資料集的實用建議

規則 #6:複製管道時,請小心捨棄資料。

我們通常會複製現有管道 (即 cargo cult 程式設計) 來建立管道,而舊的管道會捨棄新管道所需的資料。例如,Google+ 熱門訊息管道會捨棄較舊的貼文 (因為這個管道會嘗試將新貼文的排名)。這個管道已複製為 Google Plus 訊息串使用,在這個串流中,較舊的貼文仍具有意義,但管道仍捨棄舊貼文。另一個常見的模式是只記錄使用者看到的資料。因此,如要模擬使用者看不到特定貼文的原因,且所有排除樣本都已捨棄,那麼這項資料就不會派上用場。Google Play 發生了類似問題。使用 Play 應用程式首頁時,新建立的管道包含 Play 遊戲到達網頁的範例,而沒有任何功能區分個別範例的來源。

規則 #7:將經驗法則轉換成功能,或在外部處理。

機器學習嘗試解決的問題通常並非完全新。您可以使用現有的排序/分類系統,或嘗試解決任何問題。這意味著有很多規則和經驗法則透過機器學習技術進行調整時,這些經驗法則有助於提升成效。您應依據資訊來構思經驗法則 原因有二首先,轉換至機器學習系統的過程更加順暢。其次,這些規則通常包含許多您不想捨棄的系統概念。使用現有的經驗法則有四種方式:

  • 使用經驗法則進行預先處理。如果這項功能非常棒 就會選擇這個功能例如,如果在垃圾郵件篩選器中,寄件者已被列入黑名單,請勿嘗試重新瞭解「列入黑名單」代表的意義。封鎖這類訊息。這種方法最適合用於二進位分類工作。
  • 建立地圖項目。建議您根據經驗法則直接建立地圖項目。舉例來說,如果您使用經驗法則計算查詢結果的關聯性分數,可以加入這個分數做為特徵的值。之後,您可能會想要使用機器學習技術來按摩該值 (例如將值轉換成一組有限的值,或是與其他特徵合併使用),但從經驗法則產生的原始值開始著手。
  • 挖掘經驗法則的原始輸入內容。如果應用程式有一個經驗法則,其中能結合安裝次數、文字中的字元數和星期幾,不妨考慮將這些文字分開,然後將這些輸入內容個別提供給學習。適用的部分技巧適用於此處 (請參閱規則 #40)。
  • 修改標籤。如果您覺得經驗法則擷取的資訊目前不在標籤中,請選擇這個選項。舉例來說,如果您想盡可能提高下載次數,但又想取得優質內容,那麼解決方法就是將標籤乘以應用程式平均獲得的星星數。這裡有很多空間。請參閱「您的第一個目標」。

在機器學習系統中使用經驗法則時,請務必留意增加的複雜度。在新的機器學習演算法中使用舊版經驗法則,有助於建立順暢的轉場效果,但請思考是否有更簡便的方法完成相同效果。

Monitoring

一般而言,建議做法是良好的快訊健康狀態,例如將快訊設為可做為行動依據,以及使用資訊主頁頁面。

規則 8:瞭解系統的更新要求。

如果我的模型是一日使用,效能會降低多少?一週 ?還是四分店?這些資訊可協助您瞭解監控的優先順序。如果某一天都沒有更新模型,導致產品品質下降,請讓工程師持續觀察。大多數廣告放送系統都有可每天處理的新廣告,而且必須每天更新。舉例來說,如果 Google Play 搜尋的機器學習模型未更新,則在一個月內可能會產生負面影響。「Google+ 熱門首選」的模型在模型中沒有張貼 ID,因此這些模型不常匯出這些模型。其他包含貼文 ID 的模型更新頻率較高。另請注意,更新間隔會隨著時間改變,特別是在模型新增或移除特徵欄時。

規則 #9:匯出模型前先偵測問題。

許多機器學習系統都有一個階段,可讓您將模型匯出至提供。如果匯出的模型有問題,表示為使用者遇到的問題。

在匯出模型前,先進行例行檢查。具體而言,請確保模型針對缺少的資料效能合理。如果您對資料有疑慮,請勿匯出模型。許多團隊會持續部署模型,然後再匯出前檢查 ROC 曲線 (或 AUC) 下的面積。若模型尚未匯出,您需要傳送電子郵件快訊,但面向使用者的模型若發生問題,可能需要有網頁。請耐心等候,務必在影響使用者前做好準備。

規則 #10:注意無訊息失敗的情形。

比起其他種類的系統,機器學習系統發生了這個問題。假設要彙整的特定資料表不再更新。機器學習系統會不斷調整,行為仍維持合理且逐漸衰減。您有時會發現已過時的資料表,而很簡單的更新方式比該季的其他推出成果更佳的效能!功能的涵蓋範圍可能會隨實作變更而改變:舉例來說,系統可能會在 90% 的範例中填入特徵欄,然後突然減少至 60% 的範例。您的遊戲曾經有 6 個月過時的資料表,光是重新整理資料表就使安裝率提升了 2%。如果您追蹤資料的統計資料,並在遇到的時候手動檢查資料,可以減少這些類型的失敗次數。

規則 #11:授予功能資料欄擁有者和說明文件。

如果系統較大,且有許多特徵欄,則知道每個特徵欄是由誰建立或維護。如果您發現瞭解特徵欄的使用者即將離開,請確認該欄已有人知道。雖然許多特徵欄的名稱都是描述性名稱,但建議您提供更詳盡的說明,以便說明功能的用途、來源和預期用途。

您的第一個目標

您關注的系統有很多指標或評估結果,但機器學習演算法通常需要單一目標,也就是演算法正在嘗試最佳化的數字。我來區分目標和指標:指標是您系統回報的任何數字,不一定重要。另請參閱規則 #2

規則 #12:千萬別想好要直接最佳化哪個目標,

因為要能創造收益、讓使用者感到滿意,並打造更美好的世界。您重視的眾多指標相當關注,因此應該好好評估 (請參閱規則 #2)。然而,早期機器學習程序也會持續運作,即便沒有直接最佳化也一樣。舉例來說,假設您關心網站的點擊次數和時間如果您是針對點擊次數最佳化,則可能發現花費的時間增加。

因此,保持指標簡單,在可以輕鬆增加所有指標時,也不必費心平衡不同的指標。不過,請不要過度遵循這項規則:請勿將目標與系統的終極健康狀態混淆 (請參閱規則 #39)。此外,如果您發現自己正在增加直接最佳化指標,但決定不推出,可能需要一些目標修訂版本。

規則 13:為您的第一個目標選擇簡單、可觀測且可歸因的指標。

通常您不知道真正的目標是什麼,但您也許會認為自己是該做的,但隨著您看著舊系統和新機器學習系統的資料和並列分析,就會發現想要調整目標。此外,不同團隊成員通常無法認同真正的目標。機器學習目標必須是易於評估的內容,且有助於達成「true」目標。事實上,這類目標通常沒有「true」(請參閱規則#39)。因此,訓練簡單的機器學習目標,並考慮在上層設定「政策層」,以便新增其他邏輯 (也許是非常簡單的邏輯) 來執行最終排名。

要進行模擬,最簡單的方式就是直接觀察到系統動作的使用者行為:

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

一開始請避免建立間接效果:

  • 使用者隔天是否造訪?
  • 使用者造訪網站的時間有多長?
  • 每日活躍使用人數為何?

間接效果能帶來出色的指標,可用於 A/B 測試和啟動決策。

最後,不要嘗試藉由機器學習瞭解:

  • 使用者對產品感到滿意嗎?
  • 使用者對於使用體驗是否滿意?
  • 這項產品是否能改善使用者的整體身心健康?
  • 這對公司的整體健康有何影響?

這些因素都很重要,但也很難進行評估。請改用 Proxy,如果使用者滿意,他們就能長時間停留在網站上。如果使用者感到滿意,他們明天就會再次造訪。鑑於身心健康和公司健康有顧慮,我們必須進行人工審查,將任何機器學習的目標連結至所售產品的性質和業務計畫。

規則 #14:從可解釋的模型開始著手,簡化偵錯作業。

線性迴歸、邏輯迴歸和帕松迴歸是由機率模型直接促成。每項預測都可解釋為機率或預期值。相較於使用目標 (零對損失、各種轉軸損失等) 且嘗試直接最佳化分類準確率或排名效能的模型,這樣做更容易偵錯。例如,如果訓練過程中的可能性與並排預測機率不同,或是經由檢查實際工作環境系統來檢查,這種偏差可能就會出現問題。

例如,在線性、邏輯或帕松迴歸中,「資料子集」會在預測出的預期等於平均標籤 (1 點校正,或剛校正) 的資料子集。這情況是假設您沒有正規化,且演算法已整合,且大致上並無任何現象。如果您每個樣本都有 1 或 0 的特徵,系統會針對該特徵 1 校正共 3 個範例。此外,如果您每個範例的特徵皆為 1,則所有範例組合都會校正。

使用簡易模型,即可輕鬆處理意見回饋循環 (請參閱規則 #36)。我們通常會使用這些機率預測來做決定,例如為預期值降低排名 (例如點擊/下載的機率等) 排名。不過,請記得在選擇要使用的模型時,決策的重要性高於指定模型資料的可能性 (請參閱規則 #27)。

規則 15:在政策層中區分垃圾郵件篩選和品質排名。

品質排名是一項美術,但垃圾內容過濾功能為戰爭。使用您系統的使用者會清楚辨別您用於判定優質貼文的信號,而這些信號也會調整貼文,使其具備這些屬性。因此,您的品質排名應著重在由出於善意發布的內容排名。建議您不要讓品質排名學習者在垃圾內容排名中過度折扣。同樣地,「兒童不宜」內容與品質排名應分開處理。垃圾內容篩選結果是兩種不同的情況。請放心,您需要產生的功能會持續變動。您經常需要在系統中設置明確的規則 (如果貼文的垃圾投票超過三票,就不要擷取此則通知)。任何學習模型都必須每天更新,否則速度不快內容創作者的聲譽 扮演著重要角色

在某些層面,這兩個系統的輸出內容必須整合在一起,請注意,在搜尋結果中過濾垃圾郵件應比過濾電子郵件中的垃圾郵件更為嚴格。此外,移除品質分類器訓練資料中的垃圾內容是一套標準做法。

機器學習階段 2:特徵工程

在機器學習系統生命週期的第一階段,重要的是將訓練資料匯進學習系統、取得任何感興趣的指標,以及建立服務基礎架構。在完成單元和系統測試檢測後,終端系統開始運作後,第二階段就會開始進行。

第二階段中有許多容易讓人停擺的水果。許多顯而易見的功能可導入系統。因此,機器學習的第二階段,包括盡可能提取所有功能,並以直覺的方式組合這些功能。在這個階段,所有指標都應仍處於增加狀態。我們會進行許多上市,現在是一大群工程師彙整資料所需的所有資料,協助您建立真正出色的學習系統。

規則 #16:計劃推出並不斷修正。

您絕對不會認為目前處理中的模型會是之後推出的最後一個模型,甚至您甚至會停止啟動模型。因此,請考慮透過這次推出加入的複雜度是否會導致日後的推出速度變慢。許多團隊已在每季或更長時間推出模型,而且已有多年時間。推出新模型有三個基本原因:

  • 你可以使用新功能
  • 您正在調整正規化,並以新的方式結合舊版功能。
  • 你正在調整目標,

無論如何,給予模型一點都很理想:查看範例中的資料,有助於找出新信號以及損毀的舊信號。因此,在建構模型時,請思考如何輕鬆新增或移除特徵。請考慮建立管道的新副本,並確認其正確性有多容易。並思考是否可以同時執行兩個或三個副本。最後,您不必擔心功能 35 的 16 是否實現了這個版本的管道版本。您下一季會繼續推出。

規則 #17:從直接觀察到回報的功能著手,而非實際瞭解的功能。

這可能是爭議性話題,但能避免發生許多錯誤。首先,讓我們說明學習的功能。學習特徵是指外部系統 (例如非監督式叢集系統) 或學習者本身 (例如透過因式模型或深度學習) 產生的功能。這兩種方法都很實用,但可能有很多問題,因此不應放在第一個模型中。

如果您使用外部系統建立功能,請記得外部系統有其專屬目標。外部系統的目標可能只與您目前的目標相關。擷取外部系統的快照之後,該系統可能會過時。如果更新外部系統的功能,其意義可能會改變。如果您使用外部系統來提供功能,請注意這種方法需要非常謹慎。

係數模型和深度模型的主要問題在於,它們並非對話。因此,無法保證能提供的最佳解決方案,而且每次疊代偵測到的本機最小值可能有所不同。這種變化版本很難判斷變更對系統的影響是有意義的還是隨機。只要建立沒有深度特徵的模型,就能達到極佳的基準效能。達到這個基準後,您可以嘗試更隱密的方法。

規則 #18:探索適用於各種情境的內容功能。

機器學習系統往往是整體概念的一小部分。舉例來說,假設您想像某則貼文可能會用於「趣事」,許多人會在貼文顯示於「趣事」中之前 +1、轉貼或留言。如果您將這些統計資料提供給學員,就能在最佳化情境中宣傳沒有資料的新貼文。YouTube「接下來請看」可根據 YouTube 搜尋產生的觀看數或共同觀看次數 (觀眾觀看另一部影片後觀看影片的次數)。你也可以使用明確的使用者評分最後,如果您將使用者動作做為標籤使用,在不同情境中查看該動作可能是一個非常實用的功能。只要使用這些功能,您就能將新內容帶入背景資訊。 請注意,這與個人化無關:先判斷是否有人喜歡在此情況下的內容,再判斷誰喜歡該內容。

規則 #19:請盡可能使用非常具體的功能。

由於擁有大量資料,要學習數百萬個簡單的功能也比簡單的特徵更加容易。所擷取文件和標準化查詢的 ID 無法提供全面性化,但可讓您依據標頭查詢上的標籤排名。因此,請別擔心每項功能只會套用到極一小部分的資料,但整體涵蓋範圍超過 90%。您可以使用正規化功能,排除不適用於太少範例的功能。

規則 #20:結合及修改現有功能,以人類清楚明瞭的方式建立新功能。

您可透過多種方式合併及修改功能。TensorFlow 等機器學習系統可讓您透過轉換預先處理資料。最標準的方法有兩種,分別是「獨立」和「交叉」。

分散包括採用連續功能,以及從該特徵建立許多獨立的特徵。考慮使用連續功能,例如年齡。您可以建立年齡小於 18 歲 (即年齡介於 18 至 35 歲) 的特徵,另一個功能則為 18 歲到 35 歲時 (以此類推)。不要過度思考直方圖的邊界 基本分位數可以帶來最大的影響

交叉符號可結合兩個以上的特徵欄。TensorFlow 術語中的特徵欄是一組同質特徵 (例如 {male, female}、{US, Canada, Mexico}, 等)。十字形是一個新的特徵欄,其中包含 {male, female} × {US,Canada, Mexico} 中的特徵。這個新的特徵欄將包含地圖項目 (加拿大男性)。如果您使用 TensorFlow,而且說出 TensorFlow 來建立這個交叉比對,這將出現代表男性加拿大男性的範例 (加拿大男性) 功能。請注意,這需要大量資料來學習包含三個、四個或多個基本特徵欄的模型。

產生非常大特徵欄的交叉線可能會過度配適。舉例來說,假設您正在執行某種搜尋,且您的特徵欄含有查詢中的文字,且您的特徵欄包含文件中的文字。您可以搭配使用交叉點與交叉符號,但會產生許多特徵 (請參閱規則 #21)。

處理文字時有兩種替代方式。最常見的女生是子產品最簡單形式的內形產品只會計算查詢與文件之間共同的字詞數量。接著,您可以減少這項功能。另一個方法是交集:因此,只有在文件和查詢中同時出現「pony」這個字詞時,以及「the」這個字詞同時出現在文件和查詢時,這個功能才會顯示。

規則 #21:您可在線性模型中學習的特徵權重,與擁有的資料量大致相同。

關於模型的適當複雜度,目前統計學習理論上相當著迷,但基本上,這項規則基本上就是您需要瞭解的。根據我對談到的說法,大家對於從一千個例子中學到什麼都很不悅,否則會需要超過一百萬個範例關鍵是根據資料規模擴大學習規模:

  1. 如果您使用的是搜尋排名系統,且文件和查詢中有數百萬個不同字詞,並有 1,000 個已加上標籤的範例,則您應該在文件和查詢功能 (TF-IDF) 和另外 50 萬個人工工程特徵之間使用內號產品。1, 000 個例子和十大特色
  2. 如果有數百萬個樣本,請使用正規化處理和可能的特徵選取交集文件和查詢特徵欄。這樣即可使用數百萬個功能,但正規化將會減少。也許有 1, 000 萬個樣本,或許是一百萬個特徵
  3. 如果您有數十億或數千億個樣本,可以透過特徵選取和正規化功能,跨特徵欄與文件和查詢符記交叉比對。您將有十億個樣本,以及 1, 000 萬個特徵統計學習理論雖然很少有緊密的邊界,但可提供完善的指引。

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

規則 22:清除不再使用的功能。

未使用的功能會造成技術債。如果發現其實並未使用任何功能,而且無法與其他功能合併使用,請將其從基礎架構中移出。您希望保持基礎架構簡潔,以便盡快嘗試 最具潛力的功能。如有必要,隨時有人能加回您的地圖項目。

在考慮要新增或保留的功能時,請考量涵蓋範圍。這項功能涵蓋多少個範例?舉例來說,如果您有部分個人化功能,但只有 8% 的使用者會使用任何個人化功能,這項功能的成效並不顯著。

同時,某些功能上的體重可能會超過其體重。舉例來說,如果您的特徵只涵蓋 1% 的資料,但有 90% 的範例為正面功能,就很適合新增功能。

系統人工分析

在機器學習的第三階段,我們必須先聚焦在任何機器學習類別中未介紹的內容,也就是如何查看現有模型並加以改善。這不只是科學,但還有幾項反面模式有助於避免。

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

這可能讓團隊最容易卡住。雖然進行魚類測試 (在團隊內使用原型) 和 Dogfood 測試 (在公司內部使用原型) 有很多好處,但員工應檢視效能是否正確。雖然顯然的變更內容明顯不佳,但不應使用,但對於合理接近實際工作環境的任何內容,應進一步測試,例如付費給多人在群眾外包平台上回答問題,或透過真人使用者進行即時實驗。

原因有兩種。首先是距離程式碼太近您可能會尋找貼文的特定層面,或者只是過度牽涉情緒 (例如確認偏誤)。其次是時間寶貴請考慮在一場一小時的會議中,9 位工程師的成本,然後思考在群眾外包平台上購買多少個約定標籤。

如果確實想提供意見,請使用使用者體驗方法。盡早在 Bill Buxton 的「Sketching User Experiences」中建立人物角色,稍後進行可用性測試 (其中一則說明位於 Steve Krug 的《Don’t Make Me Think》中)。包含建立假想使用者的使用者人物。舉例來說,如果您的團隊全都是男性,可能會有助於設計一個 35 歲的女性使用者人物角色 (具備使用者功能),然後查看產生的結果,而非 25 到 40 歲男性的 10 筆結果。透過可用性測試,讓實際訪客觀看他們對網站的反應 (不論是本機或遠端連線),這種做法也能讓您煥然一新。

規則 #24:測量模型之間的差異。

您可以在任何使用者查看新模型前,採取最簡單且最實用的測量方法之一,就是只計算新結果與實際工作環境的差異。舉例來說,如果您有排名問題,請透過整個系統的查詢樣本執行這兩種模型,然後查看結果的對稱差異大小 (根據排名位置加權)。如果差異很小,實驗也不會做些微改變。如果差異很大,建議您確認變更是否合理。查看對稱差異偏高的查詢可協助您瞭解變化。不過,請確認系統保持穩定。請確保與自己比較的模型出現低 (理想) 的對稱差異。

規則 #25:在選擇模型時,實用性高於預測能力。

您的模型可能會嘗試預測點閱率。不過,最後的關鍵問題就是您要如何處理這項預測。如果您使用此文件為文件排名,最終排名的品質就比預測本身重要。如果您預測文件為垃圾內容的可能性,並進一步裁定封鎖的內容,那麼允許內容的精確度就更重要。在多數情況下,您應該同意以下兩項:如果對方不同意,收益可能會稍微獲利。因此,如果有某些變更可以改善記錄遺失情形,但會降低系統效能,那麼要尋找其他功能。隨著這種情況頻繁發生,是時候重新審視模型的目標了。

規則 #26:找出評估錯誤的模式,並建立新功能。

假設您看到一個模型的訓練範例「錯誤」。在分類工作中,這個錯誤可能是偽陽性或偽陰性。在排名工作中,錯誤可能是正面排名低於負數的成對。最重要的是,這是機器學習系統發現錯誤的例子,如果找到這個機會,希望加以修正。如果您提供給模型的特徵可以修正錯誤,模型會嘗試使用。

另一方面,如果您嘗試根據系統認為錯誤的範例建立功能,系統會忽略該功能。例如,假設在 Play 應用程式搜尋中,有人搜尋「免費遊戲」。假設最佳搜尋結果的其中一項是關聯性較低的 GG 應用程式,因此您建立的是「資源庫應用程式」功能。然而,如果您想要提高安裝次數,且使用者在搜尋免費遊戲時安裝了 GAG 應用程式,則「 GAG 應用程式」功能將無法產生您想要的效果。

取得模型出錯的範例後,請找出目前特徵集外的趨勢。例如,如果系統認為較長的貼文排名,請加入貼文長度。不要太具體說明新增的功能如果您要增加文章長度,請不要猜測長遠的意思,只要加入十個特徵,模型就會推陳出去 (請參閱規則 #21)。這是取得所需內容最簡單的方法。

規則 #27:嘗試量化觀察到的不理想行為。

對於現有團隊屬性無法擷取的系統屬性,部分團隊成員會開始感到困擾。此時,他們應採取任何行動,才能將手電筒轉換成實數。舉例來說,如果他們認為 Play 搜尋中顯示的「GAg apps」(GAg 應用程式) 過多,就能請評估人員辨識時間差應用程式。(在此情況下,您或許仍能使用人工標籤資料,因為相對較小的查詢佔了大部分流量)。如果您的問題是可評估的,可以開始將其做為功能、目標或指標使用。一般規則是「先評估,再最佳化第二次」。

規則 #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 的極致版本。舉例來說,即使特定應用程式是熱門的下載項目,無論查詢內容為何,您都不會希望在任何位置顯示該應用程式。不提供僅限文件的功能您不想在所有位置顯示特定熱門應用程式的原因,是為了將所有所需的應用程式都設為可供存取的重要性。舉例來說,如果使用者搜尋「鳥賞應用程式」,可能會下載「生氣的鳥」;但這並不是他們的意圖。顯示這類應用程式可能可以提高下載率,但造成使用者最終不滿。

規則 #36:避免使用位置功能產生回饋循環。

內容的位置大幅影響使用者與其互動的可能性。如果您將應用程式放在最先的位置,就能提高其點擊次數,從而說服使用者點閱應用程式的可能性較高。其中一個做法是新增位置功能,例如有關網頁上內容位置的特徵。使用位置特徵訓練模型後,模型就會學習權重,例如「第 1 名」特徵。您的模型因此針對含有「1stposition=true」的範例,將權重較低。然後,您不會向任何執行個體提供位置功能,或為這些執行個體提供相同的預設功能,因為您必須先為候選項目評分,再決定它們顯示的順序。

請注意,由於在訓練和測試之間採用非對稱性,請務必將任何位置特徵與模型的其他部分分開。讓模型是位置特徵的函式總和,以及地圖項目其餘函式的總和,是理想的做法。例如,請勿與位置地圖項目重疊。

規則 #37:評估訓練/服務偏差。

某些事情在一般情況下可能造成偏移。此外,您也可以將出價分為多個部分:

  • 訓練資料的效能與保留資料的效能差異。一般來說,這會一直存在,不一定會是不良行為。
  • 保留資料的效能與「次日」資料的效能差異。同樣地,這個項目一律會存在。建議您調整正規化作業,盡可能提高次日成效。不過,保留資料與次日資料之間的效能大幅下降,可能代表部分功能具時效性,可能會降低模型效能。
  • 「次日」資料與即時資料的效能差異。如果您將模型套用至訓練資料中的範例,並在服務時套用相同的範例,則該模型應該會得到完全相同的結果 (請參閱規則 #5)。因此,這裡的資料差異可能表示發生工程錯誤。

機器學習第 3 階段:減緩成長速度、最佳化修正和複雜模型

有些跡象顯示表示第二階段即將接近。 首先,每月收益會開始下降。各指標之間會開始有優缺點:您會發現有些指標成長,有些則在一些實驗中下滑。這裡會特別有趣這樣效益更難達成,因此機器學習必須更加複雜。注意:本部分比前幾段的藍天規則更大。我們見過許多團隊參加階段 1 和階段 II 機器學習的快樂時光。在進入第 3 階段後,團隊必須找出自己的學習路徑。

規則 #38:如果因為目標不一致而造成問題,請不用浪費時間處理新功能。

隨著成效評估結果趨於穩定,您的團隊會開始檢視超出目前機器學習系統目標範圍的問題。如前文所述,如果現有的演算法目標未涵蓋產品目標,您就必須變更目標或產品目標。舉例來說,您可以最佳化點擊次數、+1 或下載次數,但部分評估者根據評估人員來決定產品上市決策。

規則 39:產品上市決策是長期產品目標的替代方法。

小莉對於如何降低預測安裝量的物流損失。並新增一項功能。邏輯損失也會下降。實際進行實驗時 她發現安裝率有所提升然而,在進行上市評論會議時,某人指出每日活躍使用者人數減少了 5%。團隊決定不發布模型。Alice 失望,但現在發現啟動決策取決於多項條件,其中只有部分條件可使用機器學習技術直接最佳化。

事實上,現實世界並不是地下和龍,因此沒有可以識別產品健康狀態的「命中點」。團隊必須運用收集到的統計資料,試圖有效預測系統的未來成效。他們需要關注參與度、1 天活躍使用者 (DAU)、30 天活躍使用者、收益和廣告客戶的投資報酬率。這些指標本身可以在 A/B 測試中衡量,只是表現出更長期目標的替代指標:滿足使用者、增加使用者人數、滿足合作夥伴和利潤需求,甚至可以考慮透過 Proxy 提供實用、高品質的產品,以及讓公司從現在五年後蓬勃發展。

只有在所有指標都變得更好 (或至少降低) 時,才容易啟動決策。如果團隊可以從精密的機器學習演算法和簡單的經驗法則中選擇,如果對所有指標而言,簡易經驗法則的表現較佳,就應該選擇經驗法則。此外,所有可能的指標值沒有明確的排名。具體而言,請考量以下兩種情境:

實驗功能 每日活躍使用者人數 每日收益
A 100 萬 $400 萬美元
B 200 萬 $200 萬美元

如果目前的系統是 A,團隊就不太可能切換至 B。如果目前的系統為 B,團隊不太可能切換至 A。這看起來似乎與有理行為發生衝突;不過,指標的預測不一定能跨越,因此會造成重大風險。每項指標都會涵蓋團隊有疑慮的部分風險。

此外,沒有指標涵蓋團隊的終極疑慮:「我的產品接下來 5 年後會在哪裡?」

另一方面,個別人員通常偏好可直接最佳化的目標。大多數機器學習工具都偏好這樣的環境。工程師若禁用新功能,就能在這類環境中穩定推出新功能。其中一種機器學習是一種多目標式機器學習, 可開始解決這個問題。舉例來說,其中一個可以形成每個指標的限制下限,並最佳化某些線性指標組合。不過,即便如此,並非所有指標都能輕易做為機器學習目標的框架:如果使用者點擊文件或安裝了應用程式,那是因為內容已顯示。但要知道使用者為何造訪您的網站並不容易。要如何預測整個網站的未來成效,便是 AI 工具:就像電腦視覺或自然語言處理一樣。

規則 40:簡單扼要。

採用原始功能和直接排名內容排名的統一模型是最容易偵錯和理解的模型。不過,整合多個模型的模型 (結合其他模型分數的「模型」) 有更好的效果。為了簡化細節,每個模型都應只接收其他模型的輸入內容,或是包含許多特徵的基礎模型,但請勿兩者並用。如果您的模型是以其他單獨訓練的模型為基礎,那麼合併這些模型可能會產生不良行為。

使用簡單的模型進行組合,只接受「基礎」模型的輸出內容做為輸入。您還想在這些組合模型上強制執行屬性。例如,基礎模型產生的分數增加不應降低整體分數。此外,如果傳入的模型在語意上可解釋 (例如經過校正),則最佳做法是這樣變更基礎模型時,不會混淆基礎模型。除此之外,強制執行基礎分類器的預測機率增加並不會降低組合的預測機率

規則 #41:成效出現波動時,從質感上尋找值得新增的資訊來源,而非修正現有信號。

您已新增使用者的部分客層資訊。您已新增文件中字詞的部分資訊。您已經逐步完成範本探索,並調整正規化內容。在幾季中,您並沒有發現一項推出作業,主要指標改善幅度超過 1%。以下提供一些入門指南

是時候開始建構適用於各種不同功能的基礎架構,例如這位使用者在過去一天、一週或一年內存取的文件歷史記錄,或來自不同資源的資料。請使用 wikidata 實體或貴公司內部的內容 (例如 Google 的知識圖)。善用深度學習開始調整預期投資報酬率的期望,據此擴大努力範圍。就像任何工程專案一樣,您必須衡量加入新功能的好處,以及增加的複雜程度。

規則 42:請勿預期多元性、個人化或關聯性等因素與熱門程度相關。

內容組合中的多元性可能有很多種,因為內容來源的多元性為最常見。這表示每位使用者都會取得自己的結果關聯性意味著特定查詢的結果比任何其他查詢更適合。因此,這三項屬性都定義為與一般屬性不同。

問題是一般難以跳動

請注意,如果您的系統評估的是點擊次數、時間、觀看、+1、轉貼等次數,就表示評估的是內容的熱門程度。團隊有時會嘗試學習多元性的個人模型。為了個人化,這些函式會新增功能,讓系統提供個人化服務 (某些代表使用者興趣的部分功能) 或多樣化的功能 (表示這份文件是否有任何與其他傳回的文件共通的功能,例如作者或內容),並會發現這些功能的權重較低 (或有時有所不同)。

然而,這並不代表多元性、個人化或關聯性都沒有價值。 如上一個規則所述,您可以進行後續處理,藉此提高多元性或關聯性。如果長期目標有所增加,除了熱門程度之外,您也可以聲明多元性/關聯性具有價值。接著,您可以繼續使用後置處理,或根據多樣性或關聯性直接修改目標。

規則 #43:好友在不同的產品中往往具有相同的年齡。一般人不會知道您的興趣。

Google 的團隊採用的模型,會預測某項產品間的連線緊密度,進而在另一項產品上運作順利,因此受到了很大的衝擊。你的好友就是他們的身分。另一方面,我看了幾個團隊 因產品不同的個人化功能而難以使用個人化功能是的,應該可以正常運作。但目前似乎看起來不太像。有時可行的方法是使用來自某屬性的原始資料來預測另一個屬性的行為。除此之外,即使知道使用者有其他資源的記錄,也有幫助。例如,是否出現使用者在兩項產品中的活動,可能就代表本身和本身有活動。

Google 和外部有許多文件都運用機器學習技術,

特別銘謝

借助 David Westbrook、Peter Brandt、Samuel Ieong、Chenyu Zhao、Li Wei、Michalis Potamias、Evan Rosen, Barry Rosenberg、Christine Robson、James Pine、Tal Shaked、Tushar Chandu 和 Jeremiah Ispir 的 許多文件另外,感謝 Kristen Lefevre、Sudha Basu 和 Chris Berg任何錯誤、疏漏,或 (氣喘!) 不受歡迎的意見都是我自己。

附錄

本文件中包含了多種 Google 產品。為提供更多背景資訊,我在下方簡單介紹最常見的範例。

YouTube 簡介

YouTube 是一項串流影片服務,YouTube「接下來請看」和 YouTube 首頁的團隊都使用機器學習模型,為影片推薦項目排名。「接下來請看」功能會在目前播放完畢後推薦影片,而首頁則會向瀏覽首頁的使用者推薦影片。

Google Play 總覽

Google Play 擁有許多模型,可解決各種問題。Google Play 搜尋、Google Play 首頁個人化推薦內容和「使用者也已安裝」的應用程式都採用機器學習技術。

Google+ 總覽

在各種情況下,Google+ 都會使用機器學習技術:為使用者看到的訊息「訊息串」中的訊息排名、為「趣事」訊息 (現在最熱門的貼文) 排名、為您認識的使用者排名。Google+ 已於 2019 年關閉所有個人帳戶,並於 2020 年 7 月 6 日替換為企業帳戶的 Google Currents。