本文作者：周開拓，第四正規化推薦系統架構專家，推薦服務業務團隊（先薦）負責人。本科畢業於北京大學數學系，在 University Of Virginia 獲得統計學碩士，曾任職於世界最大的農業機械生產商 John Deere、負責利用機器學習技術進行農業經濟預測，後曾加入阿里巴巴，負責手機淘寶推薦系統。
首先，推薦系統的多樣性並不應該是一個推薦系統追求的終極目標。
多樣性，是手段，不是目標！
多樣性，是手段，不是目標！
多樣性，是手段，不是目標！
重要的事情重複三遍，為什麼不能作為目標呢？因為：
1. 多樣性很難量化。3個體育新聞+7個小姐姐和7個小姐姐+3個體育新聞，哪個更加多樣呢？
2. 多樣性不是越多越好，一次推薦 list 10 篇文章，各是不同的話題的，顯然比較多樣，但是你確定是更好的推薦結果嗎？你肯定會說，多樣性要“合適”就好，問題就在這裡，合適的點在哪裡呢？那一定是透過其他真正的結果指標來告訴你的。
3. 多樣性對於每個人，每個場景來說，是不一樣的，好壞的點不同。比如說我最近剛有了寶寶，那麼我恨不得淘寶給我推薦的商品全都是母嬰用品，多樣性並不是一個特別重要的事情。
哪些指標是合理的呢？
1. 使用者反饋（噴產品經理）後臺裡關於多樣性的反饋數量，別笑，這個指標至少是越少越好的，是一個非常可以量化的指標。不過這個訊號太稀疏了，不足以從中提取有統計意義的資訊。倒是有可能發現一些明顯的 bad case 或者 bug。
2. 使用者的點選率、閱讀時長、留存、分享、互動資料。這是推薦系統的 ground truth，如果你可以建立這些 ground truth 和多樣性之間的關係，那顯然可以去做一些工作。
記住，用一個真正的指標為準繩和目標去最佳化多樣性，不要為了多樣性而多樣性！
比如如果你的推薦系統的最佳化目標是閱讀時長，如果增加多樣性可以提升時長，就去做，如果增加多樣性不能夠提升時長，那你就不要這麼做。
多樣性真正的背後的問題，在於點選率預估模型也好、時長或者什麼 xx 預估模型也好，預測的是一個 point-wise 的問題。就是你給某個具有 x 屬性的使用者在 c 的上下文下看一個叫做 i 的內容，他的點選率、時長、xx 可能會是多少。
而實際中的問題叫做，你給某個具有 x 屬性的使用者在 c 的上下文下看一串叫做 <i1,i2,i3,i4…> 的內容列表，他的點選率、時長、xx 可能會是多少。
所以多樣性的問題就在於你的業務實際要最佳化一個排列組合，你最佳化的只是某一個點，那麼因為你的模型和你使用模型的業務場景不同，你拿到的結果自然不是最優。更通俗地說，你喜歡吃蝦，給你上一桌全是蝦的菜，大機率是一個失敗的選單，而一桌有魚有蝦有雞有鴨的菜可能會更好。因為你每個都不喜歡的機率大大降低了。
你肯定會問，為什麼不直接去建立一個模型，樣本就用 list，然後直接對所有候選集的可能排列組合進行打分然後選出最優的內容排列組合呢？
不妨先假設你已經訓練出了這樣一個模型，假設你是做短影片推薦資訊流的，當前推薦有100個可選候選集，那麼你推出一刷5個短影片，需要遍歷100*99*98*97*96這麼多種可能性才能找到最優的組合，這顯然是沒有計算可行性的。
而實際上，你訓練出這樣的一個模型，也對你的樣本量和計算基礎設施有非常高的要求。
那麼怎麼辦呢？
1. 老專家規則。比如說你一拍腦門，說一次推薦5條內容裡必須有至少1個影片，至少來自於3個不同的分類。接著你 abtest 了一下，這麼做的情況下，使用者的負反饋減少了、時長提升了。其實這是大多數推薦系統在使用的一個 good practice。老專家規則有很多，無非是一些啟發式的策略，你拍拍腦袋或者抄一抄別的推薦系統，就能得到答案，然後透過大量快速的 abtest 迭代測試找到對你的業務場景來說靠譜可行的策略（集合）。
2. 使用更長更豐富的召回拉鍊，保證更多樣的內容可以進入排序階段。只要系統不會掛，這往往是沒有什麼壞處的，除了你的雲伺服器賬單會增長得更快。但是僅僅增加召回拉鍊的數量，並不能徹底解決多樣性問題，因為你並沒有改變預估模型的邏輯，只是提供了更多的候選集。
3. 建立一個模型，用一些貪心的方法，比如要麼減少搜尋空間，要麼對這個空間的性質做一些理想假設來降維，來預測什麼樣的 list 組合是最優的。這裡有很多牛逼的方法，比如最近 youtube 的一篇論文，比如阿里現在在採用的一些 list-wise 模型策略。幾種樸素的方法：
① 分類的空間比 item 小多了，比如說你的內容一共也就10個分類，一刷10個，不考慮順序，再刪除掉一些完全不可能的組合，那麼組合的空間可以降低到幾十 - 幾百個，又回到了一個典型的機器學習線上預估問題。你可以先預測這一刷要給這個人看哪些分類的內容，各幾個。然後再有一個模型從這些分類裡取他可能更喜歡的內容。
② 對多樣性進行一個度量，比如說每個 item 透過模型或者某種東西 embedding 成一個64維向量，然後再設法降維到10。每一刷10個，那麼10行10維向量長成的空間的體積或者說這個矩陣的行列式就表達了這10個 item 的多樣性。你可以把這當成一個特徵去算每個人對這個多樣性的偏好。對於不同偏好的人，在最後 rerank 的時候設定一個閾值去進行裁剪。
③ 構造一個特別的樣本，特徵包含展示在每個 item 之前的幾個 item 的可以泛化的特徵 ( 比如說類目、term、tag )，列表生成的時候對候選集的 item 使用這個模型來從上到下打分生成。每個列表第一個就放全域性最後的 item1，第二個就用這個模型預測當第一個位置是 item1 ( 這樣的 item ) 的時候，item2 應該選哪個最好，以此類推。
④ 更多騷氣而你能想到的idea，都可以去實驗。
簡單總結一下：
1. 多樣性不是你追求的目標，但是多樣性確實可以幫助你提升你真的應該關注的指標：比如說更少的使用者投訴、更多的時長、點選。
2. 多樣性問題的本質是 ctr 或類似預估問題是對單點最優進行預測，而我們真實業務實際上往往給出的是一個列表。求列表最優的問題計算空間過大，所以我們會用一些歪門邪道，要麼直接拍個老專家規則，要麼降低空間的維度或者複雜度來取巧解決。