推薦系統老司機的十條經驗

36大數據 ? 8年前掃碼分享

我是創始人李巖：很抱歉！給自己產品做個廣告，點擊進來看看。

推薦系統老司機的十條經驗

作者：刑無刀

一年一度的ACM Recsys會議在9月份已經勝利閉幕，留下一堆slides和tutorials等著我們去學習。

翻看今年的各種分享，其中老司機Xavier Amatriain的分享引起了我的興趣：Lessons Learned from Building Real--Life Recommender Systems。主要分享了作為推薦系統老司機的他，多年開車后總結的禁忌和最佳實踐，這樣的采坑實錄顯然是很有價值的。Xavier Amatriain，曾任Netflix的算法總監，現任Quora的工程副總裁。

Xavier Amatriain在recsys上的分享，是他在推薦系統領域的十條實踐經驗(這位老司機同樣的題目在不同渠道多次分享過，一共有三個版本，加起來去重后不止十條，同學們賺到了)，本文只針對他在Recsys2016上的分享一一解讀。

一、隱式反饋比顯式反饋要爽

所謂隱式反饋，就是用戶發出這些行為時并不是為了表達興趣/態度，只是在正常使用產品而已，反之，顯式反饋就是用戶在做這個操作時就是要表達自己的態度，如評分，投贊成/反對票。

Xavier Amatriain列舉了隱式反饋的以下好處：

數據比顯式反饋更加稠密。誠然，評分數據總體來說是很稀疏的，之前netflix的百萬美元挑戰賽給出的數據稀疏度大概是1.2%，畢竟評分數據是要消耗更多注意力的數據。

隱式反饋更代表用戶的真實想法，比如你不是很贊成川普的觀點，但是還是想經常看到他的內容(以便吐槽他)，這是顯式反饋無法捕捉的。而人們在Quora上投出一些贊成票也許只是為了鼓勵一下作者，或者表達一些作者的同情，甚至只是因為政治正確而投，實際上對內容很難說真正感興趣。

隱式反饋常常和模型的目標函數關聯更密切，也因此通常更容易在AB測試中和測試指標掛鉤。這個好理解，比如CTR預估當然關注的是點擊這個隱式反饋。

舉個例子，IMDB的電影排名，對比一下用票房排名和用評分排名，票房其實是一種隱式反饋的量化，表示“看過”，而評分則是顯式反饋。

推薦系統老司機的十條經驗

一些小眾電影的評分比較少，在依靠評分排名時不太占優勢，而依靠隱式反饋排名則會有所緩解。

雖然有諸多好處，但隱式反饋有個比較大的問題就是：短視。現在有很多手段來吸引用戶點擊，比如高亮的標題，還有一些“三俗”的圖片，都會吸引用戶點擊，這種利用了人性弱點的隱式反饋，對平臺的長期價值是有損的，所以也不能一味使用隱式反饋，而是需要隱式反饋和顯式反饋結合使用，兼顧短期利益和長期價值。

二、深刻理解數據

Xavier Amatriain舉了個例子，訓練一個分類器，用來自動識別優質答案或劣質答案。這個問題似乎很簡單，實際上你要思考，下面這些答案是好的還是不好的：

抖機靈的答案
某個領域的網紅給了個很短的答案
很長、很有料的答案，但是沒有人點贊
內容有料，但是錯別字多

這些都是需要我們去深入業務理解，到底什么樣的數據才是我們要找的。

三、為模型定義好學習任務

一個機器學習模型有三個因素構成：

訓練數據(隱式反饋或者顯式反饋)
目標函數(比如用戶閱讀一篇回答的概率)
衡量指標(比如準確率或者召回率)

假如現在有這么一個問題：用用戶的購物歷史以及歷史評分，去優化用戶走進電影院看完一部電影并且給出高分的概率，NDCG作為模型的評價指標，4分以上作為正樣本。

這樣就比較清晰的定義了學習任務的三元素：

訓練數據：用戶購物歷史和歷史評分
目標函數：用戶走進電影院看完電影且給出高分的概率
衡量指標：NDCG

如果定義評價指標時模糊不清，如不說明是4分以上的作為正樣本的話，就失去了顯式反饋的信息，失去了對平臺長期利益的關注。

還有個例子，Quora的興趣feed排序。

推薦系統老司機的十條經驗

Quora的首頁是結合了多個用戶隱式反饋的排序模型，給每一種用戶行為建立一個預測模型，預測它發生的概率，結合每一種行為帶來的長期價值大小，然后加權，即期望價值。這個例子里面的三元素也可定義清楚：

訓練數據：用戶的顯式反饋和隱式反饋
目標函數：一個story的展示價值，量化定義為用戶行為的期望價值
衡量指標：任何排序模型指標都可以

四、推薦可解釋比精準更有意義

這里其實就是說推薦要展示出理由給用戶，讓用戶知道每一項推薦的項目是怎么得到的。

比如Quora的feed推薦給出的“被你關注的人投票”的理由：

推薦系統老司機的十條經驗

比如Quora給出的推薦話題給出的“被你關注的人關注”的理由：

推薦系統老司機的十條經驗

比如Netflix給出的“因為看過給出好評的電影而推薦”的理由：

推薦系統老司機的十條經驗

五、矩陣分解大法好

Xavier Amatriain很推崇Matrix Factorization，因為它既有監督學習，又有無監督學習。

推薦系統老司機的十條經驗

兩種學習方法就這樣結合在一個算法里：

它可以用來降維，這部分通常是PCA這樣的無監督學習算法承擔的，矩陣分解得到的隱因子就是降維后的特征，可以直接作為其他學習算法的輸入;
它還可以做聚類，比如Non-negative Matrix Factorization就常常用來做聚類;
SVD就是一種回歸，標準的監督學習。

矩陣分解還有一些變種：ALS(交替最小二乘)，SVD++(結合特征的SVD)，FM(因子機)，TF(張量分解)。

總之，在推薦系統里，使勁壓榨矩陣分解的效果。

六、萬能的集成方法

Netflix的冠軍模型，那可是100多種算法集成在一起的，真是應了那句話：比你效果好的模型還比你更努力。

實際上任何推薦系統也不可能是單一算法在起作用，而是多種算法集成在一起。集成方法理論上不會比你其中那個最好的算法差。在推薦系統中，你至少可以集成基于內容推薦和協同過濾兩種。

本質上，集成算法是把某個模型的輸出變成另一個模型的特征。如果你很難決策到底用哪個算法時，千萬不要糾結，所有的都用，然后集成之。

集成還有一個好處就是：某個推薦算法可能更適合某個場景下，這樣被集成的算法就可以各自handle各自擅長的場景，最后集大成。

具體集成方法可選的很多，如logistic regression，GBDT，Random Forest，ANN。

七、推薦系統也不能免俗之特征工程

談機器學習必談特征工程，雖然深度學習的大火讓某些領域的機器學習應用更加端到端了，但是推薦系統這個王國里面，特征工程還是要談一談，

好的特征有以下特點：

可復用。可復用就是說不止一個模型可以用，換個模型一樣用。
可轉換。特征是既可以直接使用，也可以進行一些尺度轉換的，比如對數轉換等。
可解釋。特征的物理意義需要很清楚。
可靠。特征出現異常的話需要能及時監控到，也要容易調試。

Xavier以Quora的答案排序為例，舉了一些他們現在用到的特征算是好特征：

一個是答案本身的特征，如回答的質量;第二個是互動類型的特征，如投票，評論;還有用戶特征，如他在某個話題下的專業程度。

深度學習給了另一種全新的特征工程之路，也是值得探索的，或許是人工特征工程的終結者，拭目以待。

八、對你的推薦系統要了如指掌

推薦系統里面，模型對于很多人來說都是黑盒子，甚至對于算法工程師自己來說也是黑盒子，并不太清楚某個東西為什么被推出來，某個東西為什么用戶沒買帳或者買帳。

通常產品經理對推薦系統都有一定的預期，推薦的東西不能讓他們理解，解釋起來也比較麻煩，也是通常算法工程師和PM產生爭端的原因所在。對于黑盒一般的模型，我們要能夠做到可以回答任何人的任何問題。模型應該做到“可調試”(debuggability)。

舉個例子，一個決策樹算法，從根節點開始，一步一步經過了哪些決策節點得到了最終的預測結果呢?如果有工具可以直觀展現出來，我們就能知道哪些特征起了更重要的作用，是不是合理的。

推薦系統老司機的十條經驗

Xavier 提到在Quora內部就有個工具，可以看到某個人的首頁feed的每一個內容的分數，以及每個分數計算所依賴的特征，這樣就很清楚知道為什么你“看到/沒看到”某個人的回答或問題。

推薦系統老司機的十條經驗

九、數據和模型是重要，但正確的演進路徑更不容忽視

老司機說，這條經驗他很看重。這條經驗告訴我們，一個推薦系統的產品功能如何一步一步從0到上線的。

推薦系統老司機的十條經驗

通常，正確的演進路徑是這樣：

首先提出一個假設，可以通俗的說是對問題的一個猜想。

針對這個假設，我們要選擇用什么模型。

模型選定后訓練模型，離線測試，如果驗證通過就要上AB測試，否則要么換個模型，要么重新審視一下你的假設是不是站得住腳;

上AB測試，測試結果明顯提升的話就上線，否則滾回去再看看最開始你那個假設是不是靠譜。

這個過程有幾個地方比較難。

第一個就是離線模型評價指標的選擇， 不同的指標可能包含不同的意義，例如同樣是Learn to rank的排序評價，MRR和NDCG這兩個指標對于排序靠前的項目權重就會更大，而FCP(Fraction of Concordant Pairs)就更看重排序靠中間的項目。所以選擇什么指標要仔細思考，離線評價表現好才有機會有必要上AB測試。

推薦系統老司機的十條經驗

第二個就是離線評價 (通常是技術性或者學術性的，比如準確率)和在線產品指標(通常是商業性的，比如留存率)之間通常是存在鴻溝的。模型的離線評價效果可能很好，但是在線去測試，產品指標可能表現不好，可以離線的時候換一個與直接產品指標更相關的評價指標。

第三個就是AB測試的時候一定注意要有一個總體評價指標( Overall Evaluation Criteria) ，很多人(通常是產品經理)會同時關注一個AB測試的很多指標，點擊率上去了，多樣性又下去了，這種測試結果你很難說是該上線還是該下線，所以說需要一個 Overall Evaluation Criteria，如果你有多個目標，就想法把多個目標整合成一個數值指標，這樣才能夠最終決定AB測試是成功還是失敗。 Overall Evaluation Criteria通常是更接近商業目標和平臺長期價值的數值，要定義出來需要深度的思考。

最后提一下，AB測試并不是唯一確定新算法是否上線的方式，還有一種方法是bandit算法，見專治選擇困難癥——bandit算法。

十、別一言不合就要上分布式

Hadoop，spark，mapreduce，這些名詞背后有一個共同的概念：分布式。

現在，所謂的大數據項目也是言必稱分布式，那么是不是都需要分布式呢?尤其是模型部分?老司機Xavier認為，大多數推薦算法不需要分布式，畢竟我們的推薦系統中很少會有訓練計算機從海量視頻中識別什么是貓這樣的算法。

Xavier說，很多算法其實都是可以在單機上完成的(多核的單機)，那為什么大家又很少這樣做呢?究其原因有幾個：

分布式平臺的確降低了處理大數據的門檻，稍微寫點膠水代碼就可以操作成T上P的數據，工程師們不用懂太多分布式本身的知識;

一些在單機上并行處理數據的方法不為人知，比如像C++中的openmp這樣的庫，很多人并不知道，它可以充分發揮多核機器的作用。還有Linux本身有很多并行化的命令，比如grep，wc等;

掌握的數據采樣方法不夠不精。對全量數據采樣，以使之在單機上能夠計算且不明顯損失信息，這是一門精致的手藝，很多人并不掌握。

Xavier說在Quora，曾經用Spark實現了一個計算任務，需要15臺機器跑6小時才能跑完，而某個工程師花了四天時間研究spark慢在哪，然后用C++寫了一個單機版，只用10分鐘就跑完整個任務。說到這里，我也同樣的經驗，曾經用Spark跑協同過濾，四個小時沒有跑完，組內的董瑋博士用C++寫了一個單機版，用openmp庫把所有的核都用上，30分鐘就計算完了。

說到這里，常見的推薦算法有很多分布式的庫，比如Spark中就有MLib庫，但是也可以試試一些著名的單機版，如GraphChi。