[翻譯] Rules of Machine Learning: Best Practices for ML Engineering

原文來自 https://developers.google.cn/machine-learning/rules-of-ml/ , 作者是 Martin Zinkevich

 


這文件是想要幫助那些具備基本機器學習知識的人去得到機器學習領域中Google最佳實踐的好處。這文件的形式就像Google C++ Style Guide或是其它受歡迎的程式設計實作引導一樣。如果你有上過機器學習的課,或是曾經開發、使用過機器學習模型,那表示你有閱讀本文所需要的足夠背景知識。

Terminology 術語

底下的專有名詞在我們討論機器學習時會一再的出現:

  • Instance: 實例。
    你想要預測的東西。例如,你要對一個網頁分成「關於貓」或是「非關於貓」,這個網頁就叫instance。
  • Label: 標籤。
    一個預測任務的答案,不管是透過機器學習系統得到的,或是訓練資料集本身就有的正確答案。舉例來說,一個網頁的標籤可能是「關於貓」。
  • Feature: 特徵。
    用在預測任務的實例的屬性。例如,一個網頁可能會有一個特徵包含了「cat」這個字。
  • Feature Column: 特徵欄。
    相關特徵的集合,例如一個「使用者們可能居住的國家」所形成的集合。一個範本的特徵欄可能會包含了一個以上的特徵。這個詞是特別用在Google的,在Yahoo/Microsoft的VW系統上,同義於namespace,或field
  • Example: 樣本。
    一個包含特徵的實例與其標籤。
  • Model: 模型。
    一個預測任務的統計表達,你用範本去訓練一個模型,再用這個模型去做預測。
  • Metric: 量測、度量、指標。
    你關心的數字。不一定能被最佳化。
  • Objective: 目標。
    一個你的演算法嘗試要去最佳化的度量。
  • Pipeline: 系統流程。
    圍繞著機器學習演算法的基礎動作。包含了從前端收取資料、將收到的資料放入訓練資料檔、訓練一個或多個模型、把模型匯出到產品。
  • Click-through Rate: 點擊率。
    一個網頁有百分之幾的使用者點擊了廣告連結。

Overview

概觀

要做一個偉大的產品,表示:

用你高手工程師的身份去做機器學習,而不是以與你扯不上邊的機器學習專家身份去做機器學習。

很多你會遇到的問題其實是工程問題。即使你有機器學習專家所擁有的全部資源,你的收獲是來自好的特徵而不是好的機器學習演算法。所以,基本流程是

  1. 確定你的系統流程從端到端都是實在可靠的。
  2. 從一個合理的目標開始。
  3. 用簡單的方式加入一些合乎常理的特徵。
  4. 再次確認你的系統流程沒被你弄壞,依然實在可靠。

這個方法可以用很久,一直到你都得不到更好的結果,才去嘗試其它方法。增加複雜性只會拖慢你產品未來的發佈時程。

當你已經試遍了所有簡單的方法,尖端機器學習方法可能是你的未來方向,可以參考第三階段的機器學習專案。

這文件的結構如下:

  1. 首先我們幫你了解正確建立機器學習系統的時機。
  2. 再來是關於你的第一個系統流程的部署。
  3. 當新的特徵加入到你的系統流程中,要怎麼啟動與更新你的產品,還有如何評估模型與訓練應用偏差(training-serving skew)。
  4. 最後會講到當你遇到瓶頸時該怎麼辦。
  5. 最後的最後,有一份相關工作的列表跟附錄,會提到這文件中常用來當範例的系統的背景。

Before Machine Learning

在機器學習之前

Rule #1: Don’t be afraid to launch a product without machine learning.

第1條:不要害怕去發佈沒有機器學習功能的產品

機器學習很讚,但是需要很多資料。理論上,你可以從不同的問題中收集資料,然後為了新產品去調整模型,然而這可能會比你用基本經驗開發出來的版本還要差。如果你覺得機器學習會讓你有100%的提升,用你的經驗可以先讓你到達50%的地方。

舉例來說,如果你在app marketplace對app做排名,你可以用下載安裝率或是安裝數來當做啟發。如果你要偵測垃圾郵件,把曾發過垃圾郵件的發佈者先過濾掉。也不要害怕去用人手工編輯。如果你要對通訊錄做排名,最近使用的可以排第一,即使是按字母排名也可以。如果你的產品並不是絕對需要機器學習,那麼,一直到你有足夠資料之前,都不要去用。

Rule #2: First, design and implement metrics.

第2條:你該做的第一件事是設計並實作指標

在你規劃你的機器學習系統要做什麼之前,盡可能的記錄你目前的系統。有以下理由:

  1. 先從系統中的使用者取得授權是比較容易的。
  2. 如果你擔心未來某些事情會變成麻煩,最好先收集歷史資料。
  3. 如果你設計系統時有包含系統指標,未來會輕鬆多了。特別是,你絕對不會想要在一堆log檔裡面用grep找一堆字串來算出指標值。
  4. 你會注意到什麼東西會變,而什麼東西不會。例如,假設你要對一個單日活躍使用者直接做最佳化。然而,透過你對系統的操作,你可能會注意到那些關於使用者體驗的大幅度變化,對指標根本沒啥影響。

為了計算每個貼文的品質,Google Plus 團隊量測每次讀取的展開、分享、+1、評論、每個使用者的評論、分享等等。一個實驗性的框架是很重要的,你可以用這個框架來實驗使用者分群,還有做統計彙總,可以參照第12條規則。

對指標的收集越開放,你就能更明白你的系統。有發現問題?增加一個指標並追蹤它。對最後釋出的版本的某些數據變化有興趣? 增加一個指標並追蹤它。

Rule #3: Choose machine learning over a complex heuristic.

第3條:選擇機器學習方法而不是複雜的啟發

簡單的啟發方法就能把你的產品推出去,但是複雜的啟發方法會導致無法維護。當你已經有資料,而且對你要解決的問題有了基本想法,就改用機器學習吧。在大部份的軟體工程任務中,你都會想要持續的更新,不管是使用啟發、經驗或是使用機器學習,而且你會發現機器學習的模型,會讓產品比較容易更新與維護 (參見第16條)。


ML Phase I: Your First Pipeline

第一階段:你的第一個系統流程

關注你第一個系統流程的基礎工程架構。思考你將要使用的各種想像的機器學習,可能會很有趣吧,但是若你一開始就不信任你的系統流程,你會搞不清楚狀況。

Rule #4: Keep the first model simple and get the infrastructure right.

第4條:保持第一個模型簡潔同時確保基礎工程正確

最大幅度提升你產品的就是第一個模型,所以不必然要是最新的。然而你的基礎工程出狀況會比你想像還要多。在任何人使用你那新潮的新機器學習系統之前,首先要決定:

  • 如何為你的學習演算法取得資料。
  • 對你的系統而言,好壞怎麼分。
  • 如何跟你的應用程式整合你的模型。模型可以是線上即時應用,也可以是離線使用樣本來做計算,再將結果存在表格裡面。例如,你可能會先把網頁預分類並且把結果存在一個表格裡,但是你應該會想對即時通訊的訊息做即時線上分類。

選擇簡單的特徵可以比較容易確保下列幾件事情:

  • 特徵有正確符合你的演算法。
  • 模型學習到合理的權重。
  • 特徵有正確符合你伺服器上的模型。

一旦你的系統可靠的做到上述三點,你大部份的工作已經完成了。這個簡單模型讓你對指標、對行為有一個底線,讓你可以基於這些知識去測試更複雜的模型。有些團隊為了避免分心,對產品的第一版趨向「中立」,明確的降低機器學習產出的優先順序。

Rule #5: Test the infrastructure independently from the machine learning.

第5條:獨立於機器學習來去測試基礎工程

要確認基礎工程是可測試的,而且學習的部份是封裝起來的,這樣子你才能測試每個部份,明確的說:

  1. 測試為演算法取得資料。檢查需要擴展的特徵欄有做擴展。如果有取得授權,手動檢查訓練演算法的輸入資料。如果可能,檢查並統計一下對於同樣的資料,你的系統流程跟其它資料處理有什麼不同。
  2. 從訓練演算法中拿出模型做測試。確定在訓練環境中,跟在服務環境中,你的模型得分是一致的 (參見規則第37條)。

機器學習的一個成分就是不可預測性,所以要確定有測試過在訓練與服務的環境中建立樣本的程式碼,而且在服務環境中,你能正確載入跟使用固定的模型。另外,了解你的資料是很重要的,參見 Practical Advice for Analysis of Large, Complex Data Sets 。

Rule #6: Be careful about dropped data when copying pipelines.

第6條:複製系統流程時,要注意丟棄的資料

我們通常是複製一個現有的系統流程來建立新的(cargo cult programming),而原有的流程會丟棄新流程需要的資料。舉個例子,Google Plus的What’s Hot流程會把舊的貼文丟棄,因為它只排序新的貼文,當這個流程複製給Google Plus Stream時,其實對Stream來說,舊貼文是很有用的,然而這流程卻依然會丟棄舊貼文。另一個常見模式只對使用者看的到的資料做log記錄,結果這些log對於分析為什麼某些使用者看不到某些貼文時,就一點用也沒有,因為他看不到,所以本來就沒記錄。另一個類似的狀況出現在Play,Play Apps Home的新流程包含了Play Game的到逹頁(landing page)的範例,而且沒有什麼特徵可以用來區別這些範例的來源是Home還是Game。

Rule #7: Turn heuristics into features, or handle them externally.

第7條:把經驗轉成特徵,或在外部處理

機器學習要解決的問題通常不是全新的問題。排名、分類或其它問題早就有其它系統在做。這表示了我們其實有一堆的規則與經驗。這些經驗可以讓你在調校機器學習時助你一臂之力。你要從資訊中挖掘出經驗,有兩個理由,第一,轉換到機器學習系統會比較順暢;第二,這些規則往往包含了大量有關於系統的直覺,你不會想丟掉的。有四種使用已存在的經驗的方式:

  • 用經驗做前處理。如果特徵已經讚到不行,那這只是一個選項。例如,對於一個垃圾郵件過濾器,寄件人已經被列入黑名單,就不需要再去學習「黑名單」是什麼意思,直接把信擋掉就對了。這種方式在二分法的任務中很好用。
  • 建立特徵。能直接從經驗中建立特徵是很棒的。例如,如果你用經驗方法去計算一個查詢結果的關聯性評價,你可以把這評價當成是特徵的值,晚一點你可能會想用機器學習去調整這個值,例如把它轉換成離散值的一個有限集合,或跟其它特徵結合在一起,但是還是先從經驗產生的原始值開始吧。
  • 從經驗中挖掘原始輸入。如果有一個用在app的經驗,結合了安裝數、文字的字數、一週的第幾天等等,那就考慮把這些東西拆散,分開當成輸入值。有些整合的技巧也可以應用在這裡(參見規則第40條)。
  • 修改標籤。當你覺得經驗所捕捉到的資訊並沒有包含在標籤裡時,這是一個選項。例如,你想要強調下載數,所以用下載數當標籤,但你也希望有品質的內容,解決方法可能是把標籤乘上app星星數的平均值。這裡有很多迂迴的空間,可參照下面「你的第一個目標」。

在機器學習系統中使用經驗時,要想清楚增加的複雜性。在新的機器學習演算法裡頭使用舊有的經驗,可以幫助增加轉移的平順,但是還是要想想有沒有更簡單的方法能夠達到同樣成效。


Monitoring

監看

一般來說,實作好的警告機制,像是讓警告可行動化而且要有儀表。

Rule #8: Know the freshness requirements of your system.

第8條:了解你系統對新鮮程度的需求

用一天前的模型會讓效能衰減多少?一週前的呢?一季前的呢?這些資訊能幫助你決定你監看的優先順序。如果模型一天不更新就影響到產品品質,那你就要派一個工程師持續監看。大部份的廣告推播系統每天都有新的廣告要處理,每天都必須更新。舉例來說,如果Google Play Search的機器學習模型沒更新,一個月內一定會出現負面影響。Google Plus的What’s Hot有些模型沒有貼文識別碼(identifier),也就是跟貼文無關的,那這些系統就不定期匯出即可。具有貼文識別碼的模型就需要頻繁的更新。要注意到的是,新鮮程度會隨著時間改變,尤其是在特徵欄有新增或移除的情況下。

Rule #9: Detect problems before exporting models.

第9條:在匯出模型前偵測問題

許多機器學習系統都有一個步驟可以讓你匯出模型。當匯出的模型有狀況,就變成使用者要面對的狀況了。

在匯出模型之前先做合理性檢驗(sanity check)。確定模型在留存資料上有合理效能,反過來說,如果對資料一直有疑慮,就先不要匯出吧。許多團隊在匯出部署模型之前會持續做ROC曲線區域(或AUC)測試。還沒匯出的模型出了狀況,用一封e-mail警告就夠了,但若是讓使用者面對狀況,需要的可能是一整頁的道歉。所以,在震驚使用者之前最好是暫緩並確認。

Rule #10: Watch for silent failures.

第10條:監看沉默的失敗

相較於其它樣式的系統,這是一種在機器學習系統上更常發生的問題。假設某個要被JOIN的表格已經不再更新,機器學習系統會調整,行為現在看起來不錯但其實會慢慢變差。有時候你會發現好幾個月沒更新的表格,重新整理一下竟然會比整季其它更動帶來更大的效能改善。特徵的覆蓋度可能會因為實作的改變而改變,例如一個特徵欄可以擴展到範本的90%,卻突然掉到60%。Google Play有一次有一個表格,已經放著6個月沒動,只更新這個表以後就提升了2%的安裝率。如果你去追蹤資料的統計,不時手動檢查資料,你可以減少這種失敗。

Rule #11: Give feature columns owners and documentation.

第11條:給特徵欄擁有者與說明文件

如果系統很大,又有很多特徵欄,要知道是誰建立的,又是誰負責維護。如果發現了解某個特徵欄的人要離職了,要確保某個其它人擁有最新的資訊。雖然許多特徵欄已經具備了很好的名字,但是如果可以有更詳細的資訊讓我們知道特徵是什麼、從哪裡來的、預期有什麼用,那就更好了。


Your First Objective 你的第一個目標

對於你關心的東西,你有很多指標或是測量值,但你的機器學習演算法通常需要單一目標,也就是一個你的演算法要試著去最佳化的數字。在這裡我將目標跟指標區別開來,一個指標(metric)是你的系統報告出來的任何數字,可能重要也可能不重要,參照規則第2條。

Rule #12: Don’t overthink which objective you choose to directly optimize.

第12條:在選擇要直接最佳化的目標時,不要想太多

你要賺錢、你要讓使用者開心、你要讓世界更美好。你有一大堆的指標要關心,而且你應該全都要量測(參見規則第2條)。然而,在機器學習流程的初期,你會發現它們都在成長,即使是你沒有特別去做最佳化的也是。例如,假設你關心的是點擊數與停留時間,當你對點擊數最佳化時,很可能會發現停留時間也增加了。

所以,關於不同指標間的平衡,保持簡單而且不用想得太辛苦,你一樣可以輕易的改善全部的指標。但也不要過分應用這條規則,千萬別搞混了你的目標跟系統健全度(參見規則第39條)。如果你發現你最佳化的指標增加了,但是不打算發佈,那你的某些目標可能需要做修改。

Rule #13: Choose a simple, observable and attributable metric for your first objective.

第13條:為你的第一個目標選擇一個簡單的、可觀察的、可找到原因的指標

通常不會知道正確的目標是什麼。一開始你以為你知道,然後在你研究資料、分析舊系統與新機器學習系統後,就會開始想要改目標了。更慘的是,不同的團隊成員通常不同意真正的目標。機器學習的目標應該是可以容易量測而且是代表「真實」目標。實際上,通常沒有所謂的真實目標(參見規則第39條)。所以你就先挑個簡單的目標開始做訓練,考慮在最上層加一個「準則層(policy layer)」,讓你可以在做最終排名的時候,能把邏輯(希望是很簡單的)加進去。

對模型來說,最容易的事情就是可以直接被觀察、被歸因於系統動作的使用者行為:

  • 這個排名清單有被點擊嗎?
  • 這個排名物件有被下載嗎?
  • 這個排名物件有被轉寄、回覆或郵件傳送嗎?
  • 這個排名物件有被評價嗎?
  • 顯示的物件有被標記為垃圾/情色/冒犯嗎?

首先要避免對間接的影響做建模:

  • 使用者隔天有再來嗎?
  • 使用者訪問網站的時間有多長?
  • 如何定義每日活躍使用者?

間接的影響是很好的指標,可以用來做A/B測試或是發佈的決策參考。

最後,不要想靠機器學習去弄清楚這些事:

  • 使用者用這產品有開心嗎?
  • 使用者用起來有滿意嗎?
  • 產品有提升使用者的整體幸福感嗎?
  • 這如何影響公司的整體健全?

這些事情很重要沒錯,但是量測起來難如登天。相對的,用表徵來看,如果使用者開心,他就會留在網站上面比較久。如果使用者有滿意,他隔天就會再來。幸福感跟公司健全如果有要考慮,就必須用人類的判斷來連結機器學習的目標、你產品的特性與你的商業計畫。

Rule #14: Starting with an interpretable model makes debugging easier.

第14條:從一個可以解釋的模型開始,比較容易除錯

線性迴歸邏輯迴歸泊松回歸都是直接受機率模型啟發。每個預測都是可以用機率或一個期望值來解釋。跟使用目標的模型比起來,這樣的模型比較好除錯;使用目標的模型指的是利用0-1損失或various hinge losses之類的目標來直接對分類準確率或排名表現做最佳化的模型。例如,如果你有訓練資料的機率,這個機率跟產品的機率或跟並行預測的機率有偏差,那就表示可能有問題了。

再舉個例子,不管是線性迴歸、邏輯迴歸或是泊松,會有一個資料子集合,它的預測平均值會等於平均標籤值(用1-moment校準或是單純做校準)。這個假設為真的前提是,你沒有規則化而且你的演算法有收歛,在一般情況下幾乎也都是真。如果你有個特徵,在每個範本上不是1就是0,3個特徵是1的範本的子集合就可以被校準。同時,如果你有一個特徵,值都是1,整個範本集合都被校準了。

用簡單的模型可以容易處理回饋迴圈(參見規則第30條)。我們通常會基於機率預測來做決策,像是用遞增的期望值來對貼文做排序(被點擊、被下載之類的機率)。然而,請記住當選擇模型的時機來臨,決策會比模型的數據可能性更重要(參見規劃第27條)。

Rule #15: Separate Spam Filtering and Quality Ranking in a Policy Layer.

第15條:在準則層區別出垃圾郵件過澽與品質排名

品質排名是一門藝術,垃圾郵件過濾是一場戰爭。你用來判斷所謂「高品質貼文」的資訊會被使用你系統的使用者發現,然後他們就會依這個資訊去調整他們的貼文。因此,你的品質排名應該專注在本著真心來貼文的那些內容。如果你的品質排名學習器把垃圾排很前面,也不應該去貶低它。同樣地,不雅內容不應該由品質排名來處理。垃圾過濾是不一樣的事,你必須預期到,你需要產生的特徵會不斷改變。一般來說,系統之中會有明顯的規則(諸如「一篇貼文被認為是垃圾的投票數大於3,就不用擷取內容了」之類的)。任一個學習好的模型最久也要每天更新。貼文建立者的名聲會是非常重要的。

在某些情況下,這兩系統的輸出結果必須被整合。要記住,在搜尋結果中做垃圾過濾,會比在郵件中做垃圾過濾還要更積極。同時,在做品質分類的訓練時,標準作法就是先從訓練資料集合裡拿掉垃圾。


ML Phase II: Feature Engineering 第二階段:特徵工程

對於機器學習系統的生命週期的第一階段,重要的事情包含了怎麼把訓練資料餵給學習系統,怎麼量測感興趣的目標指標,怎麼建立服務建設。在你用單元測試或系統測試做完端到端的系統後,第二階段就開始了

在第二階段,有很多唾手可得的果實,各式各樣顯而易見的特徵都可以放進系統裡。因此,第二階段會是關於「放入盡可能多的特徵」與「用直覺的方式把這些特徵結合起來」。所有的指標在第二階段應該還是要提升的,產品會有很多次的發佈,這是個把許多能連接資料的工程師拉進來,讓你建立超讚學習系統的好時機。

Rule #16: Plan to launch and iterate.

第16條:做好發佈與迭代的計畫

不要期待你現在在做的這個模型就會是你的最後一個版本。所以要考慮你加進產品的複雜性會不會拖延未來的發佈。很多團隊是每季或每年發佈新的模型,有三個基本的理由:

  • 你拿到新的特徵。
  • 你在使用新的方法調整正規化並且結合舊的特徵。
  • 你正在改目標。

無論如何,給模型多一點關懷是件好事,檢查做為樣本的資料可以幫助找到新的、舊的、壞的訊號。所以在建模的時候,要想一想新增、移除、組合特徵的難易度如何,想一想複製一個系統流程跟驗證正確性的難易度如何,想一想能不能兩個或三個複本平行運作。最後,不要擔心35個特徵中的第16個在這個版本的系統裡有沒有用到,下一季你會了解的。

Rule #17: Start with directly observed and reported features as opposed to learned features.

第17條:相對於學習來的特徵,先用直接觀察與回報的特徵開始

這可能是個有爭議的點,但可以避開許多陷阱。首先,先講清楚「學習來的特徵」是什麼:一個學習來的特徵是指經由外部系統(例如非監督式分群)或是學習器本身(例如因子模型或是深度模型)產生出來的特徵。這些可能很有用,但也可能出很多包,所以不該出現在第一個模型中。

如果你用外部系統來產生特徵,請記住,這些外部系統有他們自己的目標,而這些目標跟你自己的目標可能相關性很微弱。如果你從外部系統弄個快照,可能就是個過期的東西。如果你更新了外部系統得來的特徵,意義可能不一樣。如果你用一個外部系統來產生特徵,要小心,需要特別去注意。

因子模型與深度學習的一個主要狀況是,他們是非凸的(nonconvex)。所以,不能保證會趨近最佳解或是找到最佳解,每次迭代所找到的局部最佳解還不一定相同。這種狀況會導致你難以判斷究竟你系統的某次變化的影響,是有意義的還是隨機的。所以,透過建立沒有深度特徵的模型,你可以得到一個效能的基準。有這個基準之後,就可以嘗試特殊的方法了。

Rule #18: Explore with features of content that generalize across contexts.

第18條:探索可以跨多種情境的內容特徵

通常機器學習只是大系統裡面的一個小部份,例如,想像一個留言可能會出現在 What’s Hot,但其實在他出現在What’s Hot之前,就已經被+1、分享或評論了。如果把這些統計丟給學習器,它就會去推廣新留言,即使這留言對它正在最佳化的情境來說是沒有資料可用的。Youtube的Watch Next可以透過搜尋找出觀看次數或接著看的次數(計算一個影片在其它影片被觀看後才被觀看的次數)。你也可以用明確的使用者評價。如果你有一個使用者行為,被你當成標籤來用,看看這個行為在不同情境下對同一個文件的表現,可以是個很好的特徵。這些特徵讓你得以在情境中帶進新的內容。這跟個人化無關:先弄清楚有人喜歡這內容,再弄清楚是誰比較喜歡。

Rule #19: Use very specific features when you can.

第19條:盡可能的使用明確特徵

資料量很大的時候,去學幾百萬個簡單特徵,會比去學少數複雜特徵,要來的簡單。被擷取的文件標識、正規化的查詢並沒有提供很泛用的東西,但是可以讓你排名的前幾名的標籤一致。如果你能把某些特徵群聚起來,即使每個特徵對應到很小部份的資料,整理卻涵蓋到90%的資料時,就勇敢的做群聚吧。至於那些只有極少樣本會用到的特徵,可以透過正規化(regularization)消除掉。

Rule #20: Combine and modify existing features to create new features in human­-understandable ways.

第20條:透過組合、修改現有特徵,以人類能理解的方式建立新特徵

有很多種方法可以組合、修改特徵。機器學習系統,像是TensorFlow允許你用轉換(transformation)來預處理你的資料。最標準的兩種做法是離散化跟混合。

離散化是指取出一個連續型特徵再把它變成一堆離散型特徵。舉個例子像是年齡好了,你可以建一個特徵是「小於18歲」,是就是1,然後再建一個特徵是「18到35歲」,諸如此類。界線怎麼取,不用想太多,基本的分位就會有最好的效果。

混合就是組合兩個以上的特徵。用TensorFlow的術語來說,一個特徵欄(feature column),就是一堆同質的特徵,例如{male, female}、{US, Canada, Mexico}。一個「混合」是由幾個特徵組成一個新的特徵欄,例如{male, female} × {US,Canada, Mexico},然後就會有個特徵是(male, Canada)。如果你用TensorFlow而且叫它建立這個混合,(male, Canada)這個特徵就會用來表示樣本中的男性加拿大人。需要注意的是,要使用3個、4個或更多特徵欄的混合,會需要將很大量的資料餵給學習模型。

產生大量特徵欄的混合,可能會導致過擬合。假設你在做某種搜尋,然後在查詢中包含了字所形成的特徵欄,在文件中也有由字所形成的特徵欄,你可以把這兩種特徵欄做混合,然後你就會得到一大堆的特徵(參見21條)。

在處理文字的時候有兩種備案,最嚴苛的是用內積法。最簡單的內積法是計算文字在查詢與文件中共同出現的次數,算完以後可以再做離散化。另一個方法是取交集,就是會有一個特徵來表示某個字,例如pony,有沒有同時出現在查詢與文件中,然後又會有另一個特徵來表示另一個字,有沒有同時出現在查詢與文件裡面。

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條:能夠從學習器學到的特徵權重的數量跟你的資料量有關

關於模型的複雜度多寡,有很多厲害的統計學習理論,但你需要知道的其實也就這條基本的就夠了。我有跟一些人聊過,這些人懷疑用一千個樣本就足以學出任何東西,總覺得需要一百萬個樣本才夠,那是因為這些人卡在某種學習方法上了。關鍵是你要依資料庫去縮放你的學習方法:

  1. 假設你在做一個搜尋排序系統,文件集跟查詢包含了百萬個不同的文字,你有一千個標記好的樣本,那你應該用的是查詢與文件的特徵做內積,像是TF-IDF跟其它人工製造的特徵。1000個樣本,十幾個特徵。
  2. 假設你的樣本有百萬個,那就對文件跟查詢的特徵欄取交集,再加上正規化甚至是特徵選取。這樣會讓你有百萬個特徵,搭配正規化會少一些。一千萬個樣本,十萬個特徵。
  3. 如果你的資料量大到十億個甚至是幾千億個,你可以對文件跟查詢的特徵欄做混合,再搭配正規化跟特徵選取。十億個樣本,一千萬個特徵。統計理論很難給出一個明確的界限,但從這個概念開始是很好的。

最後,用第28條來決定用哪些特徵。

Rule #22: Clean up features you are no longer using.

第22條:清掉你沒在用的特徵

沒用到的特徵會產生技術債。如果你發現有個特徵是沒用到的,而且把這個特徵跟其它特徵組合起來也沒用,直接從基礎架構那裡就丟掉它吧。保持基礎架構的簡潔,你才能盡快的嘗試最有希望的特徵。如有必要,總會有辦法把那個特徵加回去的。

在考慮新增或刪除特徵時,要考慮到覆蓋率。這特徵覆蓋到多少樣本?例如,假設你有某些個人化的特徵,但是只有8%的使用者會用到,這些特徵的效用就不明顯了。

同時,有些特徵可能會比權重更有力,例如你有一個特徵,只覆蓋到1%的樣本,但是呢,90%具有這個特徵的樣本都是正例(positive),那這個特徵就有加進來的價值。


Human Analysis of the System 系統的人為分析

在進入機器學習第三階段之前,有一個在任何機器學習課程都不會教的東西很值得關注:如何檢查現有的模型並改良它。跟科學比起來,這比較像是一種藝術,這幫助我們去避免很多反模式(antipatterns)。

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

第23條:你不是典型的終端用戶

這也許是最容易讓團隊卡關的方式了。使用fishfooding(在團隊中使用原型)跟dogfooding(在公司內使用原型)有很多好處,員工們應該觀察一下效能有沒有正確表現。當有一個爛到明顯的變更不應該被使用時,任何看起來合理接近最終產品的東西,都應該做進一步測試,看是要在眾籌平台上找外行人來測,還是用真實用戶來做實境測試。

有兩個理由。第一,你太了解你的程式碼了。你可能會查找貼文的一個特定方向,或是很單純的你的情感過度深入(確認偏誤)。第二是你的時間很寶貴,想像一下9個工程師坐一個小時開會的成本,跟能買下多少眾籌平台上簽約的人工標記。

譯注:在這裡提到了fishfooding跟dogfooding可能的由來。Dogfooding的由來是”eating your own dogfood”,自己設計的東西自己使用。Fishfooding是說在產品還沒開發完成就先自己使用。這個詞的由來是Google+團隊,Google+的codename是Emerald Sea,在開發初期,這東西還沒好到可以被稱為dogfood,所以叫做fishfood。

如果真的想要有使用者回饋,就用使用者體驗(user experience)的方法。先建立一個使用者人物表(就像Bill Buxton的文章講的)然後再做可用性測試(就像Steve Krug的文章講的)。使用者人物表的使用牽涉到建立虛擬使用者。舉例來說,如果你的團隊全都是公的,那你建立一個35歲的女性使用者就會很有幫助,與其看10個25到40歲的男性用戶結果,不如看這一個結果就好。帶入真正的使用者,在可用性測試中,觀察他們對你的網站的反應,可以帶給你新鮮的感受。

Rule #24: Measure the delta between models.

第24條:量測模型之間的差異

在任何使用者用你系統之前,一件你最簡單能做的事情,同時也可能是最有用的量測,就是去計算新的結果跟目前產品有什麼差異。例如,你有一個排序問題,用查詢出來的樣本搭配兩種模型帶入整個系統跑一遍,觀察排序位置加權後的兩種結果,看他們的對稱差(symmetric difference)有多大。如果差異很小,不用做實驗就知道不會有什麼差,相對的,如果差異很大,那你要先確定這種改變是好事。檢查導致差異很大的那些查詢,可以幫助你了解這些改變在品質上的意義。然而第一前提是系統是穩定的。同一個模型自己跟自己比的時候應該有很小(理想是零)的對稱差。

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

第25條:在選擇模型時,實用性優於預測能力

你的模型可能會去預測點擊率(click-through rate)。然而到了最後,關鍵問題是你要拿這些預測結果幹嘛。假如你要用來排序文件,那最後排序結果的品質比預測更重要。假如你要做的是對一個文件算出它是垃圾訊息的機率,並且決定要不要擋下來,那麼允許通過的精準度就很重要。大部份的時候,實用性跟預測能力應該一致,不一致的時候,可能只能有很小的獲益。因此呢,如果有某種改變,會改良準確率但是降低全系統的表現,那就去看看有沒有別的特徵可以用。當這狀況時常發生時,表示你該重新審視你的模型目標了。

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

第26條:在量測的誤差中尋找模式,然後建立新的特徵

假定你看到一個訓練樣本讓模型出錯。在分類任務上,可能是false positive或是false negative;在排序問題上,出錯是一組的,像是一個positive的排序低於一個negative。重點是,這是一個機器學習系統知道自己出錯,並在有機會的情況下去嘗試修正的範例。給這個模型一個可以修正錯誤的特徵,它就會試著用這特徵去修復。

另一方面,如果你試著基於系統不認為是錯誤的樣本中來建立一個特徵,這個特徵會被忽略掉。舉例來說,假設有個人在Play Apps Search上搜尋”免費遊戲”,假設排在前面的其中一個遊戲是比較不相關的趣味app(gag app),然後你為了趣味app建了一個特徵”gag app”。然而,若你想要最大化安裝數,而且人們在搜尋免費遊戲時,本來就可能會安裝一個趣味app,那你這個”gag app”特徵其實對你的目的一點影響也沒有。

一旦你有讓模型出錯的樣本,觀察超乎你目前特徵集合的趨勢。例如,如果系統對比較長的貼文似乎會降級,那就把貼文的長度加進去特徵集合。新增加的特徵不要太有針對性。如果你新增了貼文長度,就不要去管「長」是什麼意思,你就增加一堆特徵然後讓模型自己去理解要拿這些特徵做什麼用(參考第21條)。這會是最容易達成你目的的做法。

Rule #27: Try to quantify observed undesirable behavior.

第27條:嘗試去量化觀察到的負面行為

系統有些性質是你團隊的某些成員不喜歡的,而且也不會被你使用的loss function計算進去,這會讓他們很沮喪。同時,他們應該要盡其所能的把那些讓他們胃痛的東西轉成實際數字。舉例來說,如果他們覺得Play Search出現了太多”趣味app”,他們可以用人工評價去識別出這些app (在這個情況下,你可以使用人工標記的資料,因為相對少數的查詢其實負擔了大部份的流量)。如果你的狀況是可量測的,就把它們轉成特徵、目標、或是指標。通則就是「先量測再最佳化」。

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

第28條:注意短期行為相同並不表示長期行為也會相同

想像一個情境,你有一個新的系統,觀察每個doc_id跟exact_query,計算每個查詢回傳的每個文件的點擊機率。你發現在並列與A/B測試上,這個系統的行為與舊系統幾乎相同,因為新系統比較單純,所以你就發佈了新系統。然而,你注意到新的app沒有顯示出來,為什麼?好的,因為你的系統只會基於本身查詢歷史記錄來決定顯示文件,它沒辦法學會新的文件應該要顯示出來。

理解像這樣的系統如何長期工作的唯一方法,是只用這系統實況取得的資料來做訓練,然而這是很困難的。


Training-Serving Skew 訓練-服務偏差

訓練-服務偏差是訓練效能與服務效能的差異,這種差異可以由下列原因導致:

  • 你在訓練時期與服務時期對資料處理的不一致。
  • 你在訓練時與服務時的資料差異。
  • 你的模型跟演算法的反饋。

我們在Google有觀察到,有訓練-服務偏差的最後產品的機器學習系統,對效能有負面影響。最好的解決方案是明確的監視它,使得系統跟資料的改變不會引發沒被查覺的新偏差。

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條:要確保訓練跟服務一致的最佳方法,就是將服務時的特徵集合存起來,轉成log再給訓練時期使用

即使你沒辦法對每個樣本都這樣做,至少也要做到一小部份,你才能驗證服務跟訓練的一致性(參見第37條)。在Google做這量測的團隊有時候會被結果嚇到。YouTube首頁改成在服務時記錄特徵後,帶來大幅度的改善,還降低了程式碼的複雜度,許多團隊也跟進改成我們說的這種方式。

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

第30條:用重要性對採樣的資料加權,不要隨便丟棄!

當你有很多資料時,你會想要取檔案1-12然後忽略檔案13-99。這是錯的。雖然從未顯示給使用者的資料是可以被丟棄的沒錯,然而用重要性加權是對其餘資料最好的方法。重要性加權的意思是,假設你對樣本X有30%的機率做採樣,那就給它10/3的權重。有了重要性加權,第14條規則講的那些校準性質仍然是成立的。

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來取得資料,表格裡的資料可能是有改變的

假設你把doc id跟一個包含這些文件的特徵(像是回應數或點擊數)的表格做JOIN,在訓練時期與服務時期之間,表格裡的特徵可能是有改變的。你的模型在訓練時期跟服務時期的預期結果就會不一樣。要避免這問題的最容易方法是在服務時期記錄特徵(參見第32條)。如果表格的改變很慢,你可以每小時或每天對表格內容做快照,來取得合理的近似資料。要知道的是,這個方法並不能完全解決問題。

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

第32條:盡可能的重複使用訓練與服務的程式碼

批次處理跟在線處理不同。在線處理時,你要在收到要求時,就去處理它(你必須要對每個查詢做分別的查表),然而在批次處理時,你可以結合任務(像是做JOIN)。在服務時期,你做的是在線處理,而訓練是批次處理。然而,你可以做一些事來重複使用程式碼。例如,你可以為你的系統特別建一個物件,任意查詢或是JOIN的結果可以用某種易讀的方式來存,要偵測錯誤也比較容易。然後,當你收集到所有的資料,不管是訓練或服務時期,你可以用一個共通的方法做橋樑,介接你系統特定的那個易讀物件,跟機器學習系統期望收到的格式。這同時也會減少訓練-服務偏差的來源。進一步說,你要試著別在訓練和服務時使用兩種不同的程式語言,這會讓你非常難去分享程式碼。

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號之後的資料對模型做測試

一般來說,你的模型用某些資料做訓練,用新收集到的資料來量測模型的效能表現,能比較有效的反應你的系統在產品時期的行為。如果你的模型是基於1月5號前的資料,那就用1月6號之後的資料做測試。用新的資料,你預期效能不會跟之前一樣好,但也應該不會誇張的差。既然可能會受每天的影響,你可能不會去預測平均點擊率或轉換率,而是算曲線下的面積(也就是讓正例有比負例更高分數的機率),應該會蠻接近。

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

第34條:在做過濾的二分問題上(例是垃圾郵件偵測或感興趣郵件判斷),用短期的效能犧牲去換乾淨的資料

在過濾任務中,被標記為負(negative)的樣本不會顯示給使用者看。假設你有一個過濾器,在服務時,會阻擋75%的負樣本。你大概會想要從顯示給使用者的資料裡擷取出新的訓練資料。例如,你的過濾器放行了某個郵件,結果被使用者標記是垃圾,你大概會想從這封信做學習。

但是這方法會導致取樣偏差(因為有很多郵件早就被濾掉了)。有個方法可以取得乾淨的資料,在服務時,你把1%的流量標記成”保留”,然後把保留的樣本都送到使用者那裡顯示。現在你的過濾器至少能阻擋74%的負樣本,而這些保留的樣本可以用來做你的訓練資料。

如果你的過濾器會阻擋95%以上的負樣本,這方法的可行性就比較低了。即便如此,如果你想知道服務效能,你可以用個更小的採樣(0.1%或甚至0.001%)。一萬個樣本足以準確評估效能了。

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

第35條:注意排名問題中既有的偏差

當你換掉排名演算法結果有不同的結果跑出來,你同時也改變了你演算法未來能看到的資料。這種偏差一定會出現,你應該依這種狀況去設計你的模型。有很多種方法可以做,以下是那些會讓你的模型更偏愛已見過的資料的方法:

  1. 跟那些只覆蓋到一個查詢的特徵比起來,對那些覆蓋到比較多查詢的特徵做更高的正規化(regularization)。這樣,跟普遍化到所有查詢的特徵比起來,模型會偏好那些僅對應到少數查詢的特徵。這個方法可以避免讓某些熱門查詢結果出現在跟他們無關的查詢中。這個方法跟傳統建議相反,傳統建議是要你對包含獨特值的特徵欄做更多的正規化。
  2. 讓特徵只能有正的權重,好的特徵就會比未知的特徵更突出。
  3. 不要用只限於文件的特徵。這是第1條規則的極端版。舉例來說,即使有個app,不管查詢是什麼,它都是熱門下載,你還是不會想到處把它秀出來。而不使用只限於文件的特徵,讓實作這件事情變得比較簡單。你不想要到處秀特定的熱門app,就必須強調「所有想要的app能被搜尋到」的重要性。例如,有人搜尋”bird watching app”,他還是有可能會下載憤怒鳥,但是這某個程度上並不是他最先的意圖。把憤怒鳥秀出來可能會增加下載率,但是並沒有滿足使用者的需求。

Rule #36: Avoid feedback loops with positional features.

第36條:用位置特徵避免回饋循環

內容的位置大大的影響了使用者可能互動的方式。如果你把一個app放在優先位置,它被點到的次數會更多,你就會誤以為是這個app比較有可能被點。一個處理這種狀況的方法,是增加位置特徵,也就是「頁面中的內容的位置」的特徵。你用有位置特徵的資料去訓練模型,它會學到把像是”1stposition”這種特徵用力加權。模型會給其它因素比較低的權重,像是”1stposition=true”。在服務時期,就不必給實例任何位置相關特徵,或是給他們同樣的預設特徵,因為你己經在決定顯示順序之前就已經對候選項目評好分數了。

因為訓練與測試的不對稱,分離位置特徵跟其它特徵是很重要的。一個函數處理位置特徵,一個函數處理其它特徵,理想情況是讓模型變成這兩個函數的加總。例如,不要讓位置特徵跟文件特徵個混合。

Rule #37: Measure Training/Serving Skew.

第37條:量測訓練/服務偏差

在一般情況下,有很多東西都會導致偏差,我們進一步把它分成幾個部份:

  • 訓練資料與保留資料的效能差。一般來說,這永遠存在,也不一定是壞事。
  • 保留資料與「明日」資料的效能差。這也是永遠存在,你應該要調校正規化的方法來最大化明日的效能。然而,如果效能差很多,就表示了某些特徵是跟時間相關,也可能導致模型效能的下降。
  • 明日資料與即時資料的效能差。如果你把模型在訓練時期跟服務時期應用在同一筆樣本,結果應該要一樣才對(參見規則5)。如果不一樣,就表示你系統有工程錯誤。

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條:如果目標不能一致,就不要浪費時間在新的特徵上

當你的量測到了平緩期,你的團隊會開始去找系統目標範圍外所發生的狀況。如前面所講的,如果產品目的並沒有被包含在現有演算目標中,你要嘛改變目標,要嘛改變產品目的。例如,你可能會最佳化點擊率、+1、或下載,但是是基於人們的評價來決定要不要發佈產品。

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

第39條:發佈的決定代表了產品的長期目的

Alice有個想法,是關於降低預測下載數的邏輯損失(logistic loss)。她新增一個特徵,然後邏輯損失下降了。她做線上實驗時,發現下載率增加了。然而,當她在會議中,某人指出每日活躍用戶少了5%。這個團隊最終決定不要發佈這個模型。Alice很難過,但現在理解到發佈的決定是依賴於多個因素,只有一部份因素是可以直接用機器學習來最佳化的。

事實是,這個真實世界並不是龍與地下城:沒有血量來表示你產品的健康度。團隊必須要用收集來的統計數據來試著預測系統未來的表現如何。他們要關心認同度、單日活躍使用者、30日活躍使用者,還有廣告客戶的投資回報。這些可以用A/B測試計算的量測,只是產品更長期的目的的代言人:滿足使用者、增加使用者人數、滿足夥伴、賺錢。這也可以表示更高品質更有用的產品,還有五年後公司的興榮。

唯一容易做的發佈決定是在所有量測都變好(或至少沒變爛)的時候。假如團隊要在複雜的機器學習演算法,與簡單的啟發式計算之間做選擇,然後簡單的啟發式計算在所有量測上都表現比較好,那就應該選簡單的啟發式計算。進一步來說,沒有所有可能量測值的明確排名。我們看下面兩種情境:

Experiment Daily Active Users Revenue/Day
A 1 million $4 million
B 2 million $2 million

假設目前系統是A,團隊大概不會換成B,反之亦然。看起來好像不太合理,然而,量測的改變的預測可能成功也可能不會,每一個改變都是巨大的風險。每個量測都包含了團隊考慮到的風險。

然後,沒有一種量測能計算團隊的終極煩惱:「五年後我們的產品會怎麼樣?」

另一方面,個人會偏好能夠直接最佳化的目標。大部份的機器學習工具也偏好這樣的環境。一個快速產出新特徵的工程師可以在這環境下穩定的發佈。有一種機器學習叫做多目標學習,開始用來處理這種問題。例如,一個人可以規劃出具有每一種量測的下限的受限滿足問題,然後對量測的線性組合之類的做最佳化。然後,即使如此,也不是所有的量測都能表示成機器學習的目標:如果一個文件被點擊或是一個app被安裝了,是因為內容有被顯示出來,沒顯示出來當然不會被點。很難去知道為什麼一個使用者會跑來看你的網站。如何去預測一個網站未來的成功是一種AI-complete:就像電腦視覺或自然語言處理一樣難。

Rule #40: Keep ensembles simple.

第40條:讓整合模型簡潔

用原始特徵直接對內容排名的單一模型是最容易除錯跟理解的。然而,一個整合模型(結合多個模型分數的模型)可以做的更好。要讓事情單純,每個模型要嘛是當個整合模型,拿其它模型的結果來當成輸入,或是就當個基礎模型,拿特徵當輸入,千萬不要兩者兼具。如果你有一個在其它模型之上的模型,而且是分開訓練的,把他們組合起來只會帶來不好的結果。

用個簡單的模型來整合其它基礎模型。你也會想要強制這些模型的一些性質。例如,基礎模型產生的某個分數如果上升,那個分數在整合模型中就不該下降。同時,最好那些模型是語義上可以解釋的(例如有校準過),這樣一來,底層的模型的改變不會讓整合模型混淆。同時呢,要強制底層分類器的預測機率上升,不會導致整合模型的預測機率下降

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

第41條:效能平緩時,與其調整現有的訊號,不如從品質角度去檢查新的資訊來源以新增訊號

你已經新增了一些關於使用者的普查資料,你已對文件中的文字新增了資訊,你試過了各種樣版,調整了正規化,最近幾季你卻沒看到任何關鍵量測有超過1%的改善,怎麼辦?

該是時間來為大不相同的特徵建立系統的時機了,這些特徵像是使用者最近一天、一週、一年存取的文件歷史,或是不同的文件屬性。在你公司內部使用wikidata(例如Google的knowledge graph),用深度學習。開始調整你對投資回報的預期,並且隨之擴展你的付出。就像任何的工程專案一般,你必須要權衡增加新特徵的好處,跟複雜度的上升。

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

第42條:不要預期多樣性、個人化或相關性會跟熱門度的連結會跟你想像的一樣

一個內容集合的多樣性可以指很多東西,最常見的一種是內容來源的多樣性。個人化表示使用者可以得到他們自己的結果。相關性表示特定查詢的結果會比其它查詢得到的結果更好。因此這三個性質有不太平凡的含義。

問題是平凡是很難擊敗的。

如果你的系統會量測點擊率、耗費時間、觀看數、+1次數、分享次數等等,你是在量測內容的受歡迎程度。團隊有時候會試著在學習具有多樣性的個人化模型。要個人化,他們新增了可以讓系統個人化的特徵(某些可以呈現使用者興趣的特徵)或是多樣化的特徵(像是能表示這文件跟其它回傳的文件有沒有共同特徵,例如作者或內容),然後發現這些特徵的權重都小於他們的預期(有時甚至是負的)。

這並不表示多樣性、個人化或相關性沒有價值。在前面的規則提到的,你可以用一些後處理的手段來增加多樣性或相關性。如果你看到長期目標增加了,你可以宣稱除了熱門程度之外,多樣性、相關性是有價值的。你可以繼續用後處理,或是直接基於多樣性或相關性來修改目標。

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

第43條:在不同產品中,你的朋友不會變,但你的興趣會

Google的團隊從一個產品裡面預測朋友連結緊密度的模型取得進展,然後讓它在其它產品中也運作良好。你的朋友依然是你的朋友。另一方面,我看過很多團隊在產品分割後,為了那些個人化的特徵而掙扎。雖然感覺應該會正常工作,但是看起來並沒有。會正常的是用從某性質得到的原始資料,去預測其它性質的行為。同時,記住即使只是知道使用者在其它性質的歷史資訊,可能就會有幫助了。例如,目前使用者在兩個產品上的行為可能就指出了問題所在。


相關工作

有很多關於機器學習的文獻:

Acknowledgements

致謝

Thanks to 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, and Hrishikesh Aradhye for many corrections, suggestions, and helpful examples for this document. Also, thanks to Kristen Lefevre, Suddha Basu, and Chris Berg who helped with an earlier version. Any errors, omissions, or (gasp!) unpopular opinions are my own.

Appendix

附錄

這文件中提到了很多Google產品,為了讓你們更了解,我對最常見的幾個範例稍加解釋:

YouTube Overview

YouTube是個串流視訊服務。YouTubeWatch Next 跟 YouTube Home Page 團隊都使用機器學習的模型來排序推薦影片。Watch Next 推薦的是目前影片看完之後建議你看什麼,而Home Page是在使用者瀏覽首頁的時候提出建議。

Google Play Overview

Google Play有很多模型來解決多種問題。Play Search、Play Home Page Personalized Recommendations跟Users Also Installed這些app都有使用機器學習。

Google Plus Overview

Google Plus在很多情境下使用機器學習:使用者看到貼文的排序、”What’s Hot”貼文排序、你可能認識的人排序等等。

 

Leave a Reply

你的電子郵件位址並不會被公開。 必要欄位標記為 *