about云開發

 找回密碼
 立即注冊

QQ登錄

只需一步,快速開始

掃一掃,訪問微社區

查看: 324|回復: 0
打印 上一主題 下一主題

[推薦系統] 楊鵬談世紀佳緣推薦算法:基于Spark GraphX,棄GBDT和LR用FM

[復制鏈接]

393

主題

57

聽眾

0

收聽

版主

https://www.fcblog.top/

Rank: 7Rank: 7Rank: 7

積分
3214
跳轉到指定樓層
樓主
發表于 2019-7-4 08:18:51 | 只看該作者 回帖獎勵 |倒序瀏覽 |閱讀模式

問題導讀:

1.世紀佳緣推薦算法中運用什么算法產生候選集?
2.世紀佳緣推薦算法中排序算法怎樣實現的?



世紀佳緣推薦場景
先說一下我們的推薦場景。我們使用推薦的場景跟電影、商品推薦有很大的不同,商品的推薦可能只考慮到轉化就可以了,我們要考慮推薦鏈的更長一些。

我們的情況:用戶登錄網站,算法推薦出用戶可能感興趣的人,用戶發信,收信用戶看信。最大的不同點在于,我們的item也是人,設計算法時也要考慮item的感受。

拿亞馬遜來類比,亞馬遜可能只需要考慮把一本書推薦給某個人,我們還要考慮這本書是不是想被推薦給這個人。舉一個極端的例子,如果我們只是想提高男性用戶發信,我們只需要給所有人推薦美女,這樣發信量一定會暴漲。但是這樣做會引發很多問題:1)美女一天不可能讀上千封信;2)美女對于一些條件不好的男性根本沒興趣;3)非美女收不到信。

所以無論是在產生候選,還是在排序的時候,我們都要同時考慮user和item。

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

基于圖算法產生候選集

下面我主要說兩個主題,先說我們如何產生推薦。今天主要說一下基于圖的算法,我們的圖算法是在Spark上實現的,使用用戶歷史發信數據,計算得到用戶的推薦列表。(世紀佳緣對Spark的理解,可以參考這個文檔:世紀佳緣吳金龍:Spark介紹——編輯注)

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

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

對那些出度(發信)和入度(收信)很多的點都要想辦法進行抽樣,否則會在計算時會耗盡內存。抽樣時也盡量提高數據質量。

對于收信很多的用戶,抽樣方法很簡單,留下用戶看了的信,去掉沒看過的。對于發信的抽樣,當然也可以只留下被看過的信,但是種方法有一點講不通,因為看不看信是站在item的角度考慮的,對發信抽樣,應該站在user的角度。

我們嘗試了直接扔掉發信過多的用戶,隨機抽樣,保留最近數據幾種方法。但是這樣的方法都是很盲目的。對于發信而言,最主要的度量應該是:發信那一刻,用戶是不是認真的。如果用戶發信是很隨意的,沒有經過篩選,那這個數據其實沒有多大意義。

解決這個問題當然也可以做個模型,但是太復雜了,我們使用了一種簡單的方法:根據用戶的發信間隔判斷,比如這封信與上一封信時間間隔10s以上,我們就認為用戶在用心的發信,保留這個數據,否則扔掉。方法很簡單,但是最終線上的效果卻很好。

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



以下則是一個認真發信的用戶,判斷標準就是剛才說的時間間隔。




可以明顯看出來,認真發信的用戶,只給符合自己要求的人發信,所以分布會更集中一些。但是不認真的用戶,分布就很散了。

排序算法的實現

第二個主題,說一下排序。主要是對上邊產生的候選集排序后把最終結果展示給用戶。用到的算法也是CTR預測中常用到的LR、FM、GBDT等。
前邊說過,我們除了要考慮user發信,還要考慮item會不會看信,甚至item會不會回信。

因此一次排序通常會組合好幾個模型:點擊模型預測user從展示里點item的概率,發信模型預測發信概率,讀信模型預測item讀信概率。然后對這幾種概率做個組合后得到最終的權重值。

用到的工具,數據怎么處理,都跟大家一樣,沒什么要說的,這里重點提一個我們用到的評估方法。


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

  • 取所有預測值在[0.445, 0.455)的真實值,記為X;
  • 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]。



原文鏈接:http://www.csdn.net/article/2015-09-30/2825828


來源: 楊鵬談世紀佳緣推薦算法:基于Spark GraphX,棄GBDT和LR用FM
分享到:  QQ好友和群QQ好友和群 QQ空間QQ空間 騰訊微博騰訊微博 騰訊朋友騰訊朋友 微信微信
收藏收藏1 轉播轉播 分享分享1 分享淘帖 贊 踩 分享到微信分享到微信
https://www.fcblog.top/
您需要登錄后才可以回帖 登錄 | 立即注冊

本版積分規則

關閉

推薦上一條 /3 下一條

QQ|小黑屋|about云開發-學問論壇|社區 ( 京ICP備12023829號

GMT+8, 2019-8-8 09:19 , Processed in 0.357599 second(s), 30 queries , Gzip On.

Powered by Discuz! X3.2 Licensed

快速回復 返回頂部 返回列表
梭哈电子游艺