上週Resyschina公眾號粉絲數達到10000個，我們承諾給小夥伴們送福利（詳見：寫在ResysChina公眾號一萬訂閱使用者之際），恭喜@IF Young 和 @白大蝦的 ...兩位同學勇奪留言獲贊數狀元和榜眼！請兩位同學在後臺給我們留下收貨地址，一本嶄新的《深度學習：21天實戰Caffe》立即寄出。也非常感謝其他同學的關心和支援，請繼續關注Resyschina，我們持續分享原創文章，同時也不定期舉行交流活動。下面為大家呈上今天的原創文章。

一年一度的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列舉了隱式反饋的以下好處：

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

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

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

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

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

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

二、深刻理解資料

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

1. 抖機靈的答案

2. 某個領域的網紅給了個很短的答案

3. 很長、很有料的答案，但是沒有人點贊

4. 內容有料，但是錯別字多

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

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

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

1. 訓練資料（隱式反饋或者顯式反饋）

2. 目標函式（比如使用者閱讀一篇回答的概率）

3. 衡量指標（比如準確率或者召回率）

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

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

1. 訓練資料：使用者購物歷史和歷史評分

2. 目標函式：使用者走進電影院看完電影且給出高分的概率

3. 衡量指標：NDCG

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

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

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

1. 訓練資料：使用者的顯式反饋和隱式反饋

2. 目標函式：一個story的展示價值，量化定義為使用者行為的期望價值

3. 衡量指標：任何排序模型指標都可以

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

這裡其實就是說推薦要展示出理由給使用者，讓使用者知道每一項推薦的專案是怎麼得到的。

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

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

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

五、矩陣分解大法好

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

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

1. 它可以用來降維，這部分通常是PCA這樣的無監督學習演算法承擔的，矩陣分解得到的隱因子就是降維後的特徵，可以直接作為其他學習演算法的輸入；

2. 它還可以做聚類，比如Non-negative Matrix Factorization就常常用來做聚類；

3. SVD就是一種迴歸，標準的監督學習。

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

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

六、萬能的整合方法

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

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

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

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

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

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

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

好的特徵有以下特點：

1. 可複用。可複用就是說不止一個模型可以用，換個模型一樣用。

2. 可轉換。特徵是既可以直接使用，也可以進行一些尺度轉換的，比如對數轉換等。

3. 可解釋。特徵的物理意義需要很清楚。

4. 可靠。特徵出現異常的話需要能及時監控到，也要容易除錯。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 上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說，很多演算法其實都是可以在單機上完成的（多核的單機），那為什麼大家又很少這樣做呢？究其原因有幾個：

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

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

3. 掌握的資料取樣方法不夠不精。對全量資料取樣，以使之在單機上能夠計算且不明顯損失資訊，這是一門精緻的手藝，很多人並不掌握。

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

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

十一、要做就做能賺錢的推薦系統【推廣】

不得不承認，我們遇到的推薦系統都是這樣的：

推薦新聞，閱讀了就是推薦成功；

推薦音樂，加紅心或者聽完了就是推薦成功；

推薦商品，點選了就是推薦成功；

推薦好友，加關注了就是推薦成功；

推薦視訊，觀看了就是推薦成功；

...……

到底這些推薦系統產生了多大的商業價值，我們都無法確切知道，作為從業者的我們也無法確切知道自己工作的價值是多大。

看到這裡，你是不是有點沮喪？

難道沒有可以直接衡量推薦系統商業價值的產品嗎？

當然有！

點選“閱讀原文”瞭解更多詳情。

參考資料：

[1] http://www.slideshare.net/xamat/recsys-2016-tutorial-lessons-learned-from-building-reallife-recommender-systems

[2] http://www.slideshare.net/xamat/strata-2016-lessons-learned-from-building-reallife-machine-learning-systems

[3] https://chatbotnewsdaily.com/10-more-lessons-learned-from-building-real-life-ml-systems-part-i-b309cafc7b5e#.vmuuaznyk

[4] https://medium.com/@xamat/10-more-lessons-learned-from-building-real-life-machine-learning-systems-part-ii-93fe7008fa9#.e4p4bl23f

[5] https://www.youtube.com/watch?v=88tzDSOzVUQ