谷歌發佈機器學習規則 (Rules of Machine Learning): 關於機器學習工程的最佳實踐(下)

雷鋒網 AI 研習社按,本文來源於谷歌開發者博客,雷鋒網獲其授權轉載。以下為下篇,內容為進行機器學習之前的第 21-43 條規則。相關術語及第1-20條規則參見谷歌發佈機器學習規則 (Rules of Machine Learning): 關於機器學習工程的最佳實踐(上)

第 21 條規則:您可以在線性模型中學習的特徵權重數目與您擁有的數據量大致成正比。

關於模型的合適複雜度方面,有各種出色的統計學習理論成果,但您基本上只需要了解這條規則。在某次談話中,曾有人表達過這樣的疑慮:從一千個樣本中是否能夠學到任何東西,或者是否需要超過一百萬個樣本,他們之所以有這樣的疑慮,是因為局限在了一種特定學習方式中。關鍵在於根據數據規模調整您的學習模型:

  1. 如果您正在構建搜索排名系統,文檔和查詢中有數百萬個不同的字詞,且您有 1000 個有標籤樣本,那麼您應該在文檔和查詢特徵、TF-IDF 和多個其他高度手動工程化的特徵之間得出點積。您會有 1000 個樣本,十多個特徵。

  2. 如果您有一百萬個樣本,則使用正則化和特徵選擇(可能)使文檔特徵列和查詢特徵列相交。這樣一來,您將獲得數百萬個特徵;但如果使用正則化,則您獲得的特徵會有所減少。您會有千萬個樣本,可能會產生十萬個特徵。

  3. 如果您有數十億或數千億個樣本,您可以使用特徵選擇和正則化,通過文檔和查詢標記組合特徵列。您會有十億個樣本,一千萬個特徵。統計學習理論很少設定嚴格的限制,但能夠提供很好的起點引導。

最後,請根據第 28 條規則決定要使用哪些特徵。

第 22 條規則:清理不再使用的特徵。

未使用的特徵會產生技術負債。如果您發現自己沒有使用某個特徵,而且將其與其他特徵組合在一起不起作用,則將其從您的基礎架構中刪除。您需要讓自己的基礎架構保持簡潔,以便儘可能快地嘗試最有可能帶來良好效果的特徵。如有必要,他人可以隨時將您的特徵添加回來。

在決定要添加或保留哪些特徵時,要考慮到覆蓋率。即相應特徵覆蓋了多少個樣本?例如,如果您有一些個性化特徵,但只有 8% 的用戶有個性化特徵,那效果就不會很好。

同時,有些特徵可能會超出其權重。例如,如果您的某個特徵只覆蓋 1% 的數據,但 90% 具有該特徵的樣本都是正分類樣本,那麼這是一個可以添加的好特徵。

對系統的人工分析

在繼續探討機器學習的第三階段之前,請務必重點了解一下在任何機器學習課程中都無法學到的內容:如何檢查現有模型並加以改善。這更像是一門藝術而非科學,但是有幾個有必要避免的反模式。

第 23 條規則:您不是典型的最終用戶。

這也許是讓團隊陷入困境的最簡單的方法。雖然 fishfood(在團隊內部使用原型)和 dogfood(在公司內部使用原型)有許多優點,但員工應該看看是否符合性能要求。雖然應避免應用明顯比較糟糕的更改,但在臨近生產時,應對任何看起來比較合理的更改進行進一步測試,具體方法有兩種:請非專業人員在眾包平台上回答有償問題,或對真實用戶進行在線實驗。

這樣做的原因有如下兩點。首先,您與代碼的關係太密切了。您關注的可能是帖子的某個特定方面,或者您只是投入了太多感情(例如確認偏差)。其次,您的時間很寶貴。考慮一下九名工程師開一個小時會議所花的費用可以在眾包平台上購買多少簽約的人工標籤。

如果您確實想獲得用戶反饋,請使用用戶體驗方法。在流程的早期階段創建用戶角色(請參閱比爾·布克斯頓的 Sketching User Experiences 一書中的描述),然後進行可用性測試(請參閱史蒂夫·克魯格的 Don』t Make Me Think 一書中的描述)。用戶角色是指創建假想用戶。例如,如果您的團隊成員都是男性,則有必要設計一個 35 歲的女性用戶角色(使用用戶特徵完成),並查看其生成的結果,而不是只查看 10 位 25-40 歲男性的結果。在可用性測試中請真實用戶體驗您的網站(通過本地或遠程方式)並觀察他們的反應也可以讓您以全新的視角看待問題。

第 24 條規則:衡量模型間的差異。

在向任何用戶展示您的新模型之前,您可以進行的最簡單(有時也是最有用)的一項衡量是,評估新模型的結果與生產有多大差別。例如,如果您有一項排名任務,則在整個系統中針對一批示例查詢運行這兩個模型,並查看結果的對稱差分有多大(按排名位置加權)。如果差分非常小,那麼您無需運行實驗,就可以判斷不會出現很大變化。如果差分很大,那麼您需要確保這種更改可以帶來好的結果。查看對稱差分較大的查詢有助於您了解更改的性質。不過,請確保您的系統是穩定的。確保模型與自身之間的對稱差分較低(理想情況下為零)。

第 25 條規則:選擇模型時,實用效果比預測能力更重要。

您的模型可能會嘗試預測點擊率。但歸根到底,關鍵問題在於您用這種預測做什麼。如果您使用該預測對文檔進行排名,那麼最終排名的質量比預測本身更重要。如果您要預測一個文檔是垃圾內容的概率,然後選擇一個取捨點來確定要阻斷的內容,那麼允許的內容的精確率更為重要。大多數情況下,這兩項應該是一致的:當它們不一致時,帶來的優勢可能會非常小。因此,如果某種更改可以改善對數損失,但會降低系統的性能,則查找其他特徵。當這種情況開始頻繁發生時,說明您該重新審視模型的目標了。

第 26 條規則:在衡量的錯誤中尋找規律,並創建新特徵。

假設您看到模型「弄錯」了一個訓練樣本。在分類任務中,這種錯誤可能是假正例,也可能是假負例。在排名任務中,這種錯誤可能是假正例和假負例,其中正例的排名比負例的排名低。最重要的是,機器學習系統知道自己弄錯了該樣本,如果有機會,它會修復該錯誤。如果您向該模型提供一個允許其修正錯誤的特徵,該模型會嘗試使用它。

另一方面,如果您嘗試根據系統不會視為錯誤的樣本創建一個特徵,該特徵將會被系統忽略。例如,假設某人在 Play 應用搜索中搜索「免費遊戲」。假設排名靠前的搜索結果中有一個是相關性較低的搞笑應用。因此,您為「搞笑應用」創建了一個特徵。但是,如果您要最大限度地增加安裝次數,並且用戶在搜索免費遊戲時安裝了搞笑應用,那麼「搞笑應用」特徵不會達到您想要的效果。

如果模型弄錯了您的某些樣本,請在當前特徵集之外尋找規律。例如,如果系統似乎在降低內容較長的帖子的排名,那麼添加帖子長度。不要添加過於具體的特徵。如果您要添加帖子長度,請不要試圖猜測長度的具體含義,只需添加十多個特徵,然後讓模型自行處理(請參閱第 21 條規則)。這是實現目標最簡單的方式。

第 27 條規則:嘗試量化觀察到的異常行為。

當現有的損失函數沒有捕獲您團隊中的部分成員不喜歡的某些系統屬性時,他們會開始有挫敗感。此時,他們應該竭盡所能將抱怨轉換成具體的數字。例如,如果他們認為 Play 搜索中顯示的「搞笑應用」過多,則可以通過人工評分識別搞笑應用。(在這種情況下,您可以使用人工標記的數據,因為相對較少的一部分查詢佔了很大一部分流量。)如果您的問題是可衡量的,那麼您可以開始將它們用作特徵、目標或指標。一般規則是「先量化,再優化」

第 28 條規則:請注意,短期行為相同並不意味着長期行為也相同。

假設您的新系統會查看每個 doc_id 和 exact_query,然後計算每個查詢的每個文檔的點擊概率。您發現在並排分析和 A/B 測試中,其行為與您當前系統的行為幾乎完全相同,考慮到它的簡單性,您發佈了它。不過,您發現它沒有顯示任何新應用。為什麼?那是因為您的系統僅根據自己的查詢歷史記錄顯示文檔,所以不知道應該顯示新文檔。

了解這種系統長期行為的唯一方法是,僅使用模型在線時獲得的數據對其進行訓練。這一點非常難。

訓練-應用偏差

訓練-應用偏差是指訓練效果與應用效果之間的差異。出現這種偏差的原因可能是:

  • 訓練管道和應用管道中數據的處理方式有差異。

  • 訓練時和應用時所用數據有變化。

  • 模型和算法之間有反饋環。

我們注意到 Google 的生產機器學習系統也存在訓練-應用偏差,這種偏差對性能產生了負面影響。最好的解決方案是明確進行監控,以避免在系統和數據改變時引入容易被忽視的偏差。

第 29 條規則:確保訓練效果和應用效果一樣的最佳方法是,保存在應用時使用的特徵集,然後將這些特徵通過管道傳輸到日誌,以便在訓練時使用。

即使您不能對每個樣本都這樣做,也對一小部分樣本這樣做,以便驗證應用和訓練之間的一致性(請參閱第 37 條規則)。採取了這項措施的 Google 團隊有時會對結果感到驚訝。 YouTube 首頁改用這種在應用時記錄特徵的做法后,不僅大大提高了質量,而且減少了代碼複雜度。目前有許多團隊都已經在其基礎設施上採用了這種方法。

第 30 條規則:按重要性對採樣數據加權,不要隨意丟棄它們!

數據過多時,總會忍不住採用前面的文件而忽略後面的文件。這是錯誤的做法。儘管可以丟棄從未向用戶展示過的數據,但對於其他數據來說,按重要性加權是最佳選擇。按重要性加權意味着,如果您決定以 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. 不選擇只處理文檔數據的特徵。這是第一條規則的極端版本。例如,即使指定應用是熱門下載應用(無論查詢是什麼),您也不想在所有地方都展示它。如果不選擇只處理文檔數據的特徵,這一點很容易做到。您之所以不想在所有地方展示某個特定的熱門應用,是因為讓用戶可以找到所有所需應用至關重要。例如,如果一位用戶搜索「賞鳥應用」,他/她可能會下載「憤怒的小鳥」,但那絕對不是他/她想要的應用。展示此類應用可能會提高下載率,但最終卻未能滿足用戶的需求。

第 36 條規則:通過位置特徵避免出現反饋環。

內容的位置會極大地影響用戶與其互動的可能性。如果您將應用放在首位,則應用獲得的點擊率更高,導致您認為用戶更有可能點擊該應用。處理此類問題的一種方法是添加位置特徵,即關於內容在網頁中的位置的特徵。您可以使用位置特徵訓練模型,使模型學習(例如)對特徵「1st­position」賦予較高的權重。因此,對於具有「1st­position=true」特徵的樣本的其他因素,模型會賦予較低的權重。然後,在應用時,您不向任何實例提供位置特徵,或為所有實例提供相同的默認特徵,因為在決定以怎樣的順序顯示候選實例之前,您就對其進行了打分。

請注意,因為訓練和測試之間的這種不對稱性,請務必在位置特徵與模型的其餘特徵之間保持一定的分離性。讓模型成為位置特徵函數和其餘特徵函數之和是理想的狀態。例如,不要將位置特徵與任何文檔特徵組合在一起。

第 37 條規則:測量訓練/應用偏差。

一般來說,很多情況都會引起偏差。此外,您可以將其分為以下幾個部分:

  • 訓練數據和預留數據的效果之間的差異。一般來說,這種情況始終存在,而且並非總是壞事。

  • 預留數據和「次日」數據的效果之間的差異。同樣,這種情況始終存在。您應該調整正則化,以最大程度地提升次日數據的效果。不過,如果與預留數據相比,次日數據效果下降明顯,則可能表明某些特徵具有時效性,而且可能會降低模型的效果。

  • 「次日」數據和實時數據的效果之間的差異。如果您將模型應用於訓練數據中的某個樣本,並在應用時使用同一樣本,那麼您得到的結果應該完全相同(請參閱第 5 條規則)。因此,此處的差異很可能表示出現了工程錯誤。

機器學習第三階段:緩慢增長、優化細化和複雜模型

第二階段即將結束時會出現一些信號。首先,月增長開始減弱。您將開始在指標之間做出取捨:在部分試驗中,您會看到一些指標上升了,而另一些指標下降了。情況變得有趣起來。由於越來越難實現增長,因此機器學習系統必須變得更加複雜。注意:相比之前兩個部分,本部分中會有較多的純理論性規則。我們見過許多團隊在機器學習的第一階段和第二階段非常滿意。但到了第三階段后,他們必須找到自己的道路。

第 38 條規則:如果目標不協調,並成為問題,就不要在新特徵上浪費時間。

當您的衡量結果穩定時,您的團隊會開始關注當前機器學習系統的目標範圍之外的問題。如前所述,如果現有算法目標未涵蓋產品目標,則您需要修改算法目標或產品目標。例如,您可以優化點擊次數、+1 次數或下載次數,但讓發佈決策部分依賴於人工評分者。

第 39 條規則:發佈決策代表的是長期產品目標。

Alice 有一個關於減少預測安裝次數的邏輯損失的想法。她添加了一個特徵。邏輯損失降低了。當她運行在線實驗時,看到安裝率增加了。但是,在發佈評審會上,有人指出,每日活躍用戶數減少了 5%。於是,團隊決定不發佈該模型。Alice 很失望,但現在她意識到發佈決策取決於多個條件,只有一部分條件可以通過機器學習直接得到優化。

事實上,現實世界並不是網游世界:沒有「生命值」來確定產品的運行狀況。團隊必須使用自己收集的統計信息來嘗試有效地預測系統未來的表現會如何。他們需要關注互動度、日活躍用戶數 (DAU)、30 日 DAU、收入以及廣告主的投資回報率。這些可在 A/B 測試中衡量的指標本身僅代表了以下更長期目標:讓用戶滿意、增加用戶數量、讓合作夥伴滿意以及實現盈利,進一步,您還可以認為它們代表了發佈優質且實用的產品,以及五年後公司繁榮發展。

唯一可以輕鬆做出發佈決策的情況是,所有指標都在變好(或至少沒有變差)。 如果團隊能夠在複雜的機器學習算法和簡單的啟髮式算法之間做出選擇,而對所有這些指標來說,簡單的啟髮式算法可以提供更好的效果,那麼應該選擇啟髮式算法。此外,並未對所有可能的指標值進行明確排名。具體而言,請考慮以下兩種情形:


如果當前系統是 A,那麼團隊不太可能會改用 B。如果當前系統是 B,那麼團隊不太可能會改用 A。這似乎與理性行為背道而馳;但是,對更改指標的預測可能會成功也可能不會,因此這兩種改變都蘊含著巨大的風險。每個指標都涵蓋了團隊所擔心的一些風險。

此外,沒有一個指標涵蓋團隊最關心的問題,即「五年後我的產品將何去何從」?

另一方面,個人更傾向於選擇可以直接優化的目標。 大多數機器學習工具也都青睞這樣的環境。在這樣的環境下,快速創建新特徵的工程師能穩定地進行一系列發佈。一種稱為「多目標學習」的機器學習已開始解決此問題。例如,您可以提出約束滿足問題,對每個指標設定下限,並優化指標的一些線性組合。不過,即使如此,也並不是所有指標都可以輕鬆框定為機器學習目標:如果用戶點擊了文檔或安裝了應用,那是因為相應內容展示出來了。但要弄清楚用戶為什麼訪問您的網站就難得多。如何預測整個網站未來的成功狀況屬於 AI 完備問題:與計算機視覺或自然語言處理一樣難。

第 40 條規則:保證集成學習簡單化。

採用原始特徵並直接對內容進行排名的統一模型是最易於進行調試和理解的模型。但是,集成學習模型(將其他模型的分數結合到一起的模型)可以實現更好的效果。為了簡單起見,每個模型應該要麼是僅接受其他模型的輸入的集成學習模型,要麼是接受多個特徵的基本模型,但不能兩者皆是。 如果在單獨訓練的模型之上還有其他模型,則組合它們會導致不良行為。

使用簡單的模型進行集成學習(僅將「基本」模型的輸出作為輸入)。此外,您還需要將屬性強加到這些集成學習模型上。例如,基本模型生成的分數的升高不應使集成學習模型的分數有所降低。另外,如果傳入的模型在語義上可解釋(例如,經過校準),則最理想,因為這樣一來,即使基本模型發生改變,也不會擾亂集成學習模型。另外,強制要求:如果基本分類器的預測概率增大,不會使集成學習模型的預測概率降低。

第 41 條規則:效果達到平穩后,尋找與現有信號有質的差別的新信息源並添加進來,而不是優化現有信號。

您添加了一些有關用戶的受眾特徵信息,也添加了一些有關文檔中字詞的信息。您探索了模板,並調整了正則化。但在幾個季度的發佈中,關鍵指標的提升幅度從來沒有超過 1%。現在該怎麼辦?

是時候開始為截然不同的特徵(例如,用戶在過去一天內、一周內或一年內訪問的文檔的歷史記錄,或者其他屬性的數據)構建基礎架構了。您可以使用維基數據條目或公司內部信息(例如,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 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 首頁團隊均使用機器學習模型對推薦視頻進行排名。「接下來觀看」會推薦在當前視頻播放完后觀看的視頻,而首頁向瀏覽首頁的用戶推薦視頻。

Google Play 概覽

Google Play 有許多解決各種問題的模型。Play 搜索、Play 首頁個性化推薦和「用戶還安裝了以下應用」都採用了機器學習技術。

Google+ 概覽

Google+ 在各種情況下採用了機器學習技術,例如對用戶可以看見的帖子「信息流」中的帖子進行排名時、對「熱門信息」中的帖子(目前非常熱門的帖子)進行排名時、對您認識的人進行排名時,等等。

原文地址:https://developers.google.cn/machine-learning/rules-of-ml/#human_analysis_of_the_system


想在手機閱讀更多Google資訊?下載【香港矽谷】Android應用
分享到Facebook
技術平台: Nasthon Systems