關於推薦的一個算法工程師訪談，有一些內容值得看看

http://www.csdn.net/article/2015-09-30/2825828

 

基於Spark GraphX，棄GBDT和LR用FM

發表於 2015-09-30 09:53| 9644次閱讀| 來源CSDN| 7 條評論| 做者楊鵬

 

摘要：9月29日20:30-21:30，算法工程師楊鵬在CSDN人工智能用戶羣分享了「世紀佳緣推薦和機器學習算法實踐」。他主要介紹了基於圖算法產生候選集、排序算法的選擇，以及建模過程當中的一些經驗心得。

如下爲楊鵬分享實錄：

你們好，我叫楊鵬，主要關注於推薦和機器學習方面。我今天分享一下世紀佳緣在推薦方面的嘗試和心得。

世紀佳緣推薦場景

先說一下咱們的推薦場景。咱們使用推薦的場景跟電影、商品推薦有很大的不一樣，商品的推薦可能只考慮到轉化就能夠了，咱們要考慮推薦鏈的更長一些。

咱們的狀況：用戶登陸網站，算法推薦出用戶可能感興趣的人，用戶發信，收信用戶看信。最大的不一樣點在於，咱們的item也是人，設計算法時也要考慮item的感覺。

拿亞馬遜來類比，亞馬遜可能只須要考慮把一本書推薦給某我的，咱們還要考慮這本書是否是想被推薦給這我的。舉一個極端的例子，若是咱們只是想提升男性用戶發信，咱們只須要給全部人推薦美女，這樣發信量必定會暴漲。可是這樣作會引起不少問題：1)美女一天不可能讀上千封信；2)美女對於一些條件很差的男性根本沒興趣；３)非美女收不到信。

因此不管是在產生候選，仍是在排序的時候，咱們都要同時考慮user和item。

以上是咱們在推薦場景上比較特殊的地方。

基於圖算法產生候選集

下面我主要說兩個主題，先說咱們如何產生推薦。今天主要說一下基於圖的算法，咱們的圖算法是在Spark上實現的，使用用戶歷史發信數據，計算獲得用戶的推薦列表。（世紀佳緣對Spark的理解，能夠參考這個文檔：世紀佳緣吳金龍：Spark介紹——編輯注）

咱們的數據很稀疏，在圖算法中，對於數據比較多的用戶使用一跳節點，對於數據少的用戶使用二跳甚至三跳節點的數據，這樣能夠避開CF中計算類似度的問題，對數據少的用戶也能產生足夠多的推薦。

當時遇到的主要問題是數據：一是數據太大，二是數據質量不高。

對那些出度（發信）和入度（收信）不少的點都要想辦法進行抽樣，不然會在計算時會耗盡內存。抽樣時也儘可能提升數據質量。

對於收信不少的用戶，抽樣方法很簡單，留下用戶看了的信，去掉沒看過的。對於發信的抽樣，固然也能夠只留下被看過的信，可是種方法有一點講不通，由於看不看信是站在item的角度考慮的，對發信抽樣，應該站在user的角度。

咱們嘗試了直接扔掉髮信過多的用戶，隨機抽樣，保留最近數據幾種方法。可是這樣的方法都是很盲目的。對於發信而言，最主要的度量應該是：發信那一刻，用戶是否是認真的。若是用戶發信是很隨意的，沒有通過篩選，那這個數據其實沒有多大意義。

解決這個問題固然也能夠作個模型，可是太複雜了，咱們使用了一種簡單的方法：根據用戶的發信間隔判斷，好比這封信與上一封信時間間隔10s以上，咱們就認爲用戶在用心的發信，保留這個數據，不然扔掉。方法很簡單，可是最終線上的效果卻很好。

我取了一個發信很隨意的用戶數據，統計了收信人在某個維度的分佈，以下圖所示。

如下則是一個認真發信的用戶，判斷標準就是剛纔說的時間間隔。

能夠明顯看出來，認真發信的用戶，只給符合本身要求的人發信，因此分佈會更集中一些。可是不認真的用戶，分佈就很散了。

排序算法的實現

第二個主題，說一下排序。主要是對上邊產生的候選集排序後把最終結果展現給用戶。用到的算法也是CTR預測中經常使用到的LR、FM、GBDT等。

前邊說過，咱們除了要考慮user發信，還要考慮item會不會看信，甚至item會不會回信。

所以一次排序一般會組合好幾個模型：點擊模型預測user從展現裏點item的機率，發信模型預測發信機率，讀信模型預測item讀信機率。而後對這幾種機率作個組合後獲得最終的權重值。

用到的工具，數據怎麼處理，都跟你們同樣，沒什麼要說的，這裏重點提一個咱們用到的評估方法。

大體就是上圖這條曲線，橫座標是預測機率的一個區間，縱座標是在這個區間內真實值的平均。好比圖中(0.45, 0.46)的點，計算方法是：

 

1. 取全部預測值在[0.445, 0.455)的真實值，記爲X；
2. avg(X)爲縱座標值；

 

這條曲線最完美的狀況應該是隻有(0, 0)，(1, 1)點有值，固然算法不可能作到這樣。次好的狀況，畫出來的線應該與 y=x 重合。

以前說過，咱們的排序是把多個算法出來的機率值做組合，因此對每一個算法的效果除了要求排序正確，還但願預測的機率值也儘可能接近真實值。

ROC、NDCG能夠很好的度量排序，可是無法度量真實值與預測值的誤差，這就是爲何咱們特別關注這條線。

經驗心得

最後說一下咱們幾回算法嘗試時遇到的問題。

1.測試Facebook論文中提到的用GBDT提取特徵的方法。

當時爲了方便，咱們直接把給LR的特徵做爲GBDT的特徵，而後把獲得的葉子節點做爲特徵，與原來的特徵組合到一塊兒再扔給LR。（能夠參考這篇博客：CTR預估中GBDT與LR融合方案——編輯注）

線下效果和線上效果都有提高，咱們推廣了這個方法，可是發現其中一個模型沒有任何效果。

排查問題的時候發現，這個模型對全部特徵做了離散化，出來的特徵值所有非0即1。GBDT原本就是個樹模型，能很好的處理非線性特徵，使用離散化後的特徵反而沒什麼效果。並且對於這種只有0、1值的狀況，GBDT出現了不收斂的現象。

2.不一樣的場景，使用不一樣的算法。

LR是咱們最常使用的，因此在作點擊模型時，天然也是先上了LR，可是線上效果並很差。後來上FM，效果卻好的出奇。

若是登陸過咱們的網站，很容易發現緣由：展現的場景，只能看到頭像、地區、年齡等幾個屬性，LR使用了大量用戶看不到的特徵，這些特徵對於模型來講是沒有意義的。

That's all，我今天分享就到這裏了。

Q&A

問：可否再詳細介紹一下推薦系統所採用的工具？

答：R的話，咱們主要用Liblinear；FM主要用SVDFeature；數據主要放Hive；Redis、Memcache和MongoDB都會用到；實時計算，會對接Kafka。

問：不實時計算能夠嗎？哪些方面是須要實時計算？

答：最主要的計算，仍是離線算好的。好比實時的排序，由於推薦列表動態生成，排序只能作成實時的。

問：請問主要的算法用得什麼語言開發的？

答：線上Java，線下的代碼就很隨意了，Python/Java/Shell/Hive，什麼方便用什麼。

問：作算法時，你覺的最大的障礙是啥？如何解決這些障礙？能夠談談具體實現上遇到的一些困難。

答：不少時候，一個模型效果很差，可是殊不知道從哪裏着手改進。不知道加什麼樣的特徵會有效，換模型也沒有效果，試過了能想到的全部方法。

問：對數學要求高嗎？

答：我本身主要作開發工做，數學有要求，可是不是那麼高，能看懂論文就好。

問：楊老師，大家對用戶的習慣有研究嗎？如何作的？

答：用戶習慣，咱們主要會統計一些數據，好比用戶常常給多少歲的人發信，而後把這個統計做爲特徵放到模型裏。

問：請問下，在使用算法的過程當中，對於對應算法的具體推演過程大家須要所有理解透麼。感受有時候一個算法對數學的要求好高啊，想理清原因難度蠻大的。

答：不須要所有理解透，至少我看了不少遍EM的推導，如今推，我仍是不會。可是我知道EM推導大概怎麼回事。

問：通常大家怎麼樣從爲解決某個問題，而選擇須要利用哪些維度，而後出發去構建模型的？

答：這個主要仍是我的經驗，作的多了，很容易就能找到最有效的特徵。

問：模型是基於已有的一些文章的仍是在實驗過程當中改進的，有專門的算法部？

答：模型主要仍是基於已有的，除非很不符合咱們的須要，不然不多去改。

問：一些經常使用算法的推導，特性，用法都的知道嗎？

答：經常使用算法確定是要知道的。

問：楊老師，你剛剛學習的時候，從哪一個簡單示例或者文檔入手的？

答：《集體智慧編程》。

問：可否介紹佳緣的推薦目前的實際效果，下一步的改進方向？

答：分算法和場景，總體上看，若是原來什麼算法都沒有，可能會有50%左右的提高。下一步的方向，主要是具體細分用戶，或者從其它維度細分算法。以前的只關注了按場景細分，之後細分的維度會拓寬些。

問：請問您認爲應屆生應該怎樣往機器學習方向發展呢？

答：環境是最重要的，若是真想作，找個真正作這個的公司。我一直想作遊戲，到如今都沒作成[Smile]。