Netflix 推薦系統(part three)-個性主頁生成
本文主要總結和翻譯自 ofollow,noindex">Learning a Personalized Homepage 。但這並不是完全和完整的翻譯稿。
正如我們在之前的部落格文章中所描述的那樣，在Netflix，我們廣泛使用個性化，並努力抓住向超過5700萬用戶中的每一個呈現正確內容的機會。 使用者與我們的推薦互動的主要方式是通過主頁，當他們在任何支援的裝置上登入Netflix時，他們會看到主頁。 主頁的主要功能是幫助每個成員輕鬆找到他們喜歡的東西。 我們面臨的一個問題是，我們的目錄包含的視訊數量超過了單個頁面上顯示的數量，每個成員都有自己獨特的興趣。 因此，一個演算法挑戰是如何最好地定製每個成員的主頁以使其涵蓋他們的興趣和觀看意圖，並且仍然允許他們探索其它內容。
這類問題並非Netflix所獨有，而是其它新聞網站，搜尋引擎和線上商店等共有的。 任何需要從大量可用可能性中選擇專案然後以連貫且易於導航的方式呈現專案的站點將面臨同樣的一般挑戰。 當然，優化Netflix主頁的問題有其獨特的方面，比如介面限制，以及與其他媒體相比如何消費電影和電視的差異。
目前，大多數裝置上的Netflix主頁由視訊（電影和電視節目）組成，這些視訊被組織成以二維佈局呈現的主題連貫行。 使用者可以在一行中水平滾動以檢視該行中的更多視訊，也可以垂直滾動以檢視其他行。 因此，我們個性化方法的關鍵部分是我們如何選擇要在主頁上顯示的行。 這包括弄清楚如何選擇與每個使用者最相關的行，如何用視訊填充這些行，以及如何在有限的頁面區域上排列它們，以便選擇要觀看的視訊是直觀的。 在本文的其餘部分，我們將重點介紹我們認為這個問題最相關和最有趣的方面，以及我們如何解決其中的一些問題。
Why Rows Anyway?
我們將主頁組織成一系列行，以便使用者輕鬆瀏覽我們目錄的大部分內容。 通過連續呈現連貫的視訊組，為每行提供有意義的名稱，並以有用的順序呈現行，使用者可以快速決定連續的整組視訊是否可能包含他們有興趣觀看的內容。 這允許使用者更深入地潛水並在主題中查詢更多視訊或跳過它們並檢視另一行。
將視訊分組的一種自然方式是按genre或subgenre(這個概念在之前的文章中提到過)或其他視訊元資料維度（如釋出日期）。 當然，連續視訊之間的關係不一定是元資料，也可以是行為資訊（例如協同過濾演算法），我們認為使用者可能觀看的視訊，甚至是一段朋友觀看的視訊 因此，每行可以為使用者提供唯一且個性化的目錄片段以供導航。 建立個性化主頁的挑戰和樂趣的一部分是找出建立有用的視訊分組的新方法，我們一直在嘗試這些方法。
一旦我們為頁面考慮了一組可能的視訊組，我們就可以開始從它們組裝主頁了。為此，我們首先根據我們瞭解的使用者查詢可能與使用者相關的候選分組。這還涉及提供證據（或解釋）以支援一行的呈現，例如該成員先前在一種型別中觀看的電影。接下來，我們會過濾每個群組以處理成熟度等級的問題，或者刪除之前觀看過的視訊。在過濾之後，我們根據適合行的排名演算法對每個組中的視訊進行排名，該排序演算法產生視訊的排序，使得組中成員的最相關視訊位於行的前面。從這組行候選中，我們可以應用行選擇演算法來組裝整頁。在頁面組裝完成後，我們會執行額外的過濾，例如重複資料刪除，以刪除重複視訊並將行格式化為適合裝置的大小。
Page-level algorithmic challenge
我們的個性化和推薦方法主要目的是幫助我們的user找到新的東西，我們稱之為discovery。但是，我們還希望讓user能夠輕鬆觀看節目的下一集或重新觀看他們過去觀看的內容，這些內容通常不屬於推薦範圍。我們希望我們的建議準確，但它們也需要多樣化。我們希望能夠突出我們目標中的深度，以及我們在其他領域的廣度，以幫助我們的成員探索甚至找到新的興趣。我們希望我們的建議是新鮮的，並對user action例如觀看節目，新增到列表或評級做出響應;但我們也想要一些穩定性，以便人們熟悉他們的主頁，並且可以輕鬆找到他們最近推薦過的視訊。最後，我們需要放置面向任務的行，例如“我的列表”。
每個裝置都有不同的硬體功能，可以限制任何時候顯示的視訊或行數以及整個頁面的大小。 因此，在生成頁面時必須知道它正在為其建立頁面的裝置的約束，包括行數，行的最小和最大長度，頁面的可見部分的大小，以及某些行是否不適用於某個裝置。
Building a page algorithmically
我們可以通過幾種方法在演算法上構建我們的主頁。 最基本的是基於規則的方法，我們使用了很長時間。 這裡有一組規則定義了一個模板，該模板指示所有成員在頁面上的某些位置可以進入哪些行型別。 例如，規則可以指定第一行是“keep watching”（如果有的話），然後是Top Picks（如果有的話），然後是Netflix上的Popular，然後是5個個性化的genre行，依此類推。 這種方法中唯一的personalization是以個性化的方式選擇候選行，例如包括“Because you watched <video>”行。 要選擇每種型別中的特定行，我們使用簡單的啟發式和抽樣演算法。 我們使用A / B測試來演化此模板，以瞭解為所有user放置行的合適位置。
這種方法對我們很有幫助，但它忽略了我們認為對頁面質量很重要的許多方面.模板的規則隨著時間的推移而增長，變得過於複雜，無法處理各種行以及它們應如何放置。
為了解決這些問題，我們可以考慮在主頁上個性化行的排序。 這樣做的最簡單方法是將行視為排名問題中的專案，我們將其稱為行排名方法。 對於這種方法，我們可以為行開發評分函式，將應用於所有候選行，按該函式排序，然後選擇最優先的一些行來填充頁面，從而利用大量現有的推薦方法。 然而，這樣做會導致缺乏多樣性，有人會得到一個微小變化的頁面，例如頁面上的每一行看起來主題不同，但其實都充滿了不同變體的喜劇：late-night, family, romantic, action等。
新增多樣性的一種簡單方法是使用評分函式從行排名方法切換到逐級方法，該評分函式既考慮行又考慮其與先前行和先前已為頁面選擇的視訊的關係。 在這種情況下，可以採用簡單的貪心方法，選擇最大化此函式的行作為要使用的下一行，然後將下一個位置的所有行重新評分。 這種貪心的選擇可能無法產生最佳頁面。 使用具有k行前瞻的分階段方法可以產生比貪心選擇更優化的頁面，但是它帶來了增加的計算成本。
然而，即使是階段式演算法也不能保證產生最佳頁面，因為固定的時間範圍可能會限制在頁面下方填充更好的行的能力。 如果我們可以定義整頁評分函式，我們可以嘗試通過適當選擇行和視訊來填充頁面來優化它。 當然，頁面組合的搜尋空間很大，因此直接優化定義整個頁面質量的函式在算力上是很難實現的。
使用任何這些方法解決頁面優化問題時，還需要考慮之前提到的各種約束，例如重複資料刪除，過濾和特定於裝置的約束。 這些約束中的每一個都增加了優化問題的複雜性。
在形成主頁時，考慮成員如何瀏覽頁面也是重要的，即，考慮他們可能在會話中注意頁面上的哪些位置。 將最相關的視訊放置在最有可能被看到的位置（通常是左上角），可以減少成員查詢與觀看相關的內容的時間。 然而，在二維頁面上建模導航是困難的，特別是考慮到不同的人可能導航模式不同，人們的導航模式可能隨時間而變化，基於互動設計在不同裝置型別之間存在導航差異，並且導航 顯然取決於所顯示內容的相關性。 通過精確的導航模型，我們可以更好地瞭解視訊和行的位置以及頁面上的重點。
Machine Learning for page generation
構建個性化頁面的核心是評分功能，可以評估行或頁面的質量。 雖然我們可以使用啟發式或直覺來構建這樣的評分函式並使用A / B測試進行調整，但我們更願意從資料中學習一個好的函式，以便我們可以輕鬆地合併新的資料來源並平衡主頁的各個不同方面。 為此，我們可以使用我們為user建立不同的主頁，他們實際看到的內容，他們的interactions以及他們的playback進行訓練，從而用機器學習演算法建立評分功能。
我們可以使用大量features來represent rows。由於行包含一組視訊，因此我們可以在行表示中聚合使用這些視訊的features。這些feature可以是簡單的元資料或更有用的基於model的features，它們表示給使用者推薦特定視訊的理想程度。當然，我們有許多不同的推薦方法，可以使用ensemble方法把它們聚合起來。我們還可以檢視與行相關的一些feature，例如對於對特定genre感興趣的user有多少，以及當前user過去是否已消耗該行或類似行。我們還可以新增簡單的描述性feature，例如這一行連續多少個視訊，該行放置在頁面上的位置，以及我們在過去顯示該行的頻率。我們還可以通過檢視行與其餘行的相似程度或行中的視訊與其餘部分的視訊相似程度，將多樣性納入評分。
用於行評分的機器學習模型存在若干挑戰。一個挑戰是處理presentation bias，由於使用者只能在我們顯示的主頁上選擇視訊播放，沒被顯示的訓練資料就可能產生偏差。更復雜的是，頁面上某行的位置會極大地影響user是否能實際看到該並選擇從中進行播放。為了處理這些presentation和position bias，我們需要非常小心地選擇訓練資料。關於如何在模型中選擇視訊歸屬的行也存在挑戰;視訊可能在過去的某一行中播放過，但這是否意味著如果該視訊被放置在不同的行的第一個位置，該user會選擇相同的視訊？多樣性的引入也具有挑戰性，因為頁面上不同位置的潛在行的特徵空間已經很大，但當頁面的其餘部分考慮到多樣性時，可能的特徵空間變得更大也更難以搜尋。
Page-level metrics
與任何演算法方法一樣，要應對這些挑戰，選擇一個好的指標非常重要。 在頁面生成中最重要的是如何評估在離線實驗期間由特定演算法產生的頁面的質量。 雖然我們最終將在A / B測試中線上測試任何潛在的演算法改進，但我們希望能夠將我們寶貴的A / B測試資源集中在我們有證據可能提高頁面質量的演算法上。 我們還需要能夠在A / B測試之前調整這些演算法的引數。
為了提出頁面級質量指標，我們從一維列表中的指標中獲取靈感，並建立了在二維佈局上工作的指標。例如，考慮一個簡單的指標，如Recall @ n，我們可以將它擴充套件為兩個維度為Recall @ m-by-n，現在我們計算頁面前m行和n列中相關專案的數量除以相關專案的總數。因此，Recall @ 3-by-4可以表示裝置上視窗中顯示的視訊質量，該裝置最初一次可以顯示3行和4個視訊。以這種方式定義的召回的一個很好的屬性是它可以自動處理像重複視訊或短行這樣的corner case。我們還可以將其中一個值n（或m）固定並掃過另一個來計算，例如，當user向下滾動頁面，視窗中的視訊增加時。
當然，Recall是一個基本指標，需要選擇m和n的值，但我們同樣可以擴充套件指標如NDCG或MRR到二維情況。 我們還可以調整導航模型例如Expected Reciprocal Rank，以在頁面中包含二維導航。 通過定義這樣的page-level metrics，我們可以使用它們來評估用於生成頁面的任何演算法方法的變化，不僅僅是algorithms for ordering the rows，還有selection, filtering, 和ranking algorithms。
Other Challenges
在設計主頁時，不乏挑戰性的問題。 例如：何時考慮其他上下文變數（例如一天中的時間或裝置），以及我們如何填充主頁？ 我們如何在找到最佳頁面和計算成本之間找到適當的權衡？ 我們如何在user關鍵的前幾個會話期間形成主頁，而這恰恰是在我們獲得最少資訊的時候？ 我們需要考慮並權衡每個問題的重要性，以便不斷改進Netflix主頁。
Conclusion
個性化頁面生成是一個具有挑戰性的問題，涉及平衡多種因素，我們認為這只是一個開始。