杨鹏谈世纪佳缘推荐算法：基于Spark GraphX，弃GBDT和LR用FM
楊鵬談世紀佳緣推薦算法：基于Spark GraphX，棄GBDT和LR用FM
發表于2015-09-30 09:53| 1447次閱讀| 來源CSDN| 2 條評論| 作者楊鵬
機器學習推薦算法排序算法特征提取世紀佳緣 width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-09-30%2F2825828&type=3&count=&appkey=&title=9%E6%9C%8829%E6%97%A520%3A30-21%3A30%EF%BC%8C%E4%B8%96%E7%BA%AA%E4%BD%B3%E7%BC%98%E7%AE%97%E6%B3%95%E5%B7%A5%E7%A8%8B%E5%B8%88%E6%9D%A8%E9%B9%8F%E5%9C%A8CSDN%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD%E7%94%A8%E6%88%B7%E7%BE%A4%E5%88%86%E4%BA%AB%E4%BA%86%E2%80%9C%E4%B8%96%E7%BA%AA%E4%BD%B3%E7%BC%98%E6%8E%A8%E8%8D%90%E5%92%8C%E6%9C%BA%E5%99%A8%E5%AD%A6%E4%B9%A0%E7%AE%97%E6%B3%95%E5%AE%9E%E8%B7%B5%E2%80%9D%E3%80%82%E4%BB%96%E4%B8%BB%E8%A6%81%E4%BB%8B%E7%BB%8D%E4%BA%86%E5%9F%BA%E4%BA%8E%E5%9B%BE%E7%AE%97%E6%B3%95%E4%BA%A7%E7%94%9F%E5%80%99%E9%80%89%E9%9B%86%E3%80%81%E6%8E%92%E5%BA%8F%E7%AE%97%E6%B3%95%E7%9A%84%E9%80%89%E6%8B%A9%EF%BC%8C%E4%BB%A5%E5%8F%8A%E5%BB%BA%E6%A8%A1%E8%BF%87%E7%A8%8B%E4%B8%AD%E7%9A%84%E4%B8%80%E4%BA%9B%E7%BB%8F%E9%AA%8C%E5%BF%83%E5%BE%97%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1443703836837" frameborder="0" scrolling="no" allowtransparency="true">摘要：9月29日20:30-21:30，世紀佳緣算法工程師楊鵬在CSDN人工智能用戶群分享了“世紀佳緣推薦和機器學習算法實踐”。他主要介紹了基于圖算法產生候選集、排序算法的選擇，以及建模過程中的一些經驗心得。【編者按】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)的點，計算方法是：
這條曲線最完美的情況應該是只有(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]。
關于世紀佳緣推薦算法的更多詳情，可以參考下面這篇文章：
爭鳴：婚戀平臺的推薦系統，怎么做才能助人脫單？
總結
以上是生活随笔為你收集整理的杨鹏谈世纪佳缘推荐算法：基于Spark GraphX，弃GBDT和LR用FM的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2015年最值得学习的编程语言是？
- 下一篇： 相比薪酬，学习效率提升才是创业公司最有价