天天看點

搜狐基于Spark的新聞和廣告推薦實戰

原文:http://www.csdn.NET/article/1970-01-01/2825353

摘要:對一個媒體網站來講,一個比較重要的任務就是擷取使用者對于不同類型文章的興趣分布。使用者的興趣分布會被作為使用者屬性标簽,和其他類型的标簽(例如人口屬性等)一起用作推薦的模型特征。

李滔,中國科技大學博士畢業,現供職于搜狐大資料中心使用者推薦部,從事推薦和廣告算法研發工作。主要關注技術方向包括廣告技術、并行計算、大資料分析等。 李滔曾就職于理光北京研究是以及Teradata公司。在理光期間設計了理光相機的第一代人臉檢測/對焦系統。之後在Teradata公司從事大規模資料挖掘的算法設計開發,基于Teradata Aster的Map/Reduce和圖計算平台設計實作了多種機器學習/資料挖掘算法并成功應用于商業實踐。

以下為演講實錄

我今天的分享主要偏應用層面的,介紹一下我們團隊在新聞推薦和廣告方面的一些心得。從業務層面來講,我們主要接觸了廣告和新聞推薦。它們相似點是都可以看做一個點選率估計的任務。根據使用者的屬性,估計一下哪個廣告,哪個新聞使用者可能點選,把這個可能點選的推薦給使用者。

為了完成這個點選率預估,我們一般會收集特征,一般是從三個層面,一個是使用者層面,一般包括使用者的人口屬性以及興趣屬性。第二就是item層面,例如新聞的分類,關鍵字,topic。廣告也有一些屬性,廣告的類型,廣告的文字描述。第三個層面是上下文,這個使用者通路的時間是什麼,廣告位所在的内容頁屬性。是以整個特征的描述,會從這三個次元去比對,比對到一個最佳點,找到使用者最可能點選的廣告或者是新聞。

搜狐基于Spark的新聞和廣告推薦實戰

廣告系統架構圖

上面是各個來源的廣告請求。下面包括三個部分:左邊這塊主要是下面左邊這塊主要是資料準備,包括ctr模型,使用者定向标簽,内容頁屬性等。右邊是主要是廣告索引,根據廣告主定向條件和使用者定向标簽以及廣告位資訊檢索出可以參與競價的廣告。這一部分可能的侯選的廣告會進入到中間黃色的Ranking部分,綜合考慮到廣告的估計點選率和廣告主的出價對廣告做排序。Ranking下面的子產品主要是做廣告投放政策的控制,比如現在是出競價廣告還是出展示廣告。推薦系統架構也非常類似,大體上也可以分為使用者/頁面屬性,索引和排序三大子產品。

使用者興趣标簽的建立

對一個媒體網站來講,一個比較重要的任務就是擷取使用者對于不同類型文章的興趣分布。使用者的興趣分布會被作為使用者屬性标簽,和其他類型的标簽(例如人口屬性等)一起用作推薦的模型特征。這裡的問題在于使用者閱讀新聞的分布會集中在幾個熱點類别上。

搜狐基于Spark的新聞和廣告推薦實戰

上面是我們統計了手機搜狐網一個月的閱讀新聞分布。發現社會新聞,國内新聞,娛樂新聞這三大類加在一起就超過了50%的流量。具體原因首先是一些熱點新聞,基本上是屬于社會的熱點事件,這些是有巨大的點選量的。另外新聞的曝光也是有偏的曝光,得到了大量的曝光就會得到大的點選量。而一些相對反應個性的新聞曝光量比較少。

是以我們對使用者興趣的模組化不能建立在使用者閱讀新聞的絕對分布上,而應該是用個體的分布相對于所有使用者平均分布的偏移度來模組化。我們把一個月的使用者閱讀新聞做了聚類,挑出兩個有特點的類别,統計使用者通路新聞的分布,以及把它和所有使用者的平均分布做比較,下圖是其中兩個例子:

搜狐基于Spark的新聞和廣告推薦實戰

這兩個圖當中,藍色的線都是使用者的平均分布。左邊這個圖,紅色線我們稱之為是财經愛好者的群體。這個群體财經的點選量明顯高于平均曲線,而對新聞類(社會和國内新聞)差異并不太大。但如果按點選量絕對值的話财經、新聞兩類的點選量相似。右邊這個圖是軍事愛好者的閱讀者,同時對财經新聞的閱讀量也是比平均分布高一些,低于平均分布的也是娛樂和社會新聞。也就是說這類使用者和左邊有點像,相對财經和軍事閱讀量高,同時對娛樂和社會新聞感興趣的低一些。

使用者興趣評估

第二個問題是我們用來收集使用者興趣的話,我們必須考慮到使用者的長期興趣和短期興趣。比如使用者是體育迷或者是軍事迷,這是他的長期興趣。還有是受到一些突發事件的影響,例如奧運會,使用者短期的興趣會發生變化。是以我們要從短期和長期兩個角度評價他的興趣。下面這個圖示意了我們做使用者标簽計算的流程:

搜狐基于Spark的新聞和廣告推薦實戰

使用者的點選資料會放在日志系統(HDFS)裡,新聞的分類标簽資料(CMS标簽)存放在新聞資料庫(MySQL)。這些标簽首先會和使用者日志做一個join,得到一個(使用者,标簽)清單。計算出分布之後,會和平均點選分布在每個新聞類型的次元上計算一個偏離度,這個偏離度會被量化之後得到一個标簽權重值。這樣就得到了每個使用者的興趣标簽,然後存到Redis庫裡。

标簽的計算基于Spark實作。由于Spark提供了非常豐富的資料處理操作,像Map、reduce,filter,join,cogroup,以及Scala語言的簡潔性,使得代碼量大為減少。另外由于Spark是記憶體計算,整個流程的處理時間相對Hadoop減少5~10倍。

ctr預測

常用的ctr預測的算法包括LR(Logistic  Regression), FM(Factorization Machines), GBDT等等。像LR和GBDT, Spark Mllib都提供了相應的實作,另外台灣大學的Liblinear也有一個Spark版本的LR算法的實作。Mllib的LR是基于LBFGS的實作,而Liblinear是基于TRON的實作。實際當中我們測試過這兩個算法,發現優化的性能非常接近。

FM目前在Spark上有一個JIRA (SPARK-7008),但是目前還沒有正式release。LR是最常用的算法,好處是簡單明了,效果分析也相對容易,問題在于想要達到好的效果需要嘗試大量的特征組合,特征工程比較費勁。FM和GBDT都是非線性的分類器(FM可以看做二次的),省去了複雜的特征組合的過程,性能也往往較好,但是出了問題不太好分析原因。實際當中可以先嘗試LR,當性能不滿足要求時再試FM或GBDT。

FaceBook的一篇文章(Practical Lessons from Predicting Clicks on Ads at Facebook)提出先使用GBDT得到一個分類器,其中每棵樹的葉子節點作為特征再送入LR訓練分類器。解決了繁瑣的特征組合問題。使用LR還有一個原因是比較好處理探索和利用問題(Exploartion & Exploitation)。

由于每天都會有新的新聞産生,而對這些新聞一開始點選率估計可能不準确,是以需要通過适當的投放進而收集資訊以提升點選率的估計。這屬于犧牲短期利益以擷取長期利益的最大化。對于線性模型實作探索和利用有Yahoo的LinUCB以及微軟的OBPR。另外對FM,也可以通過Bayes化實作E&E (Bayesian factorization machines, 2011),但是實作要相對複雜一些。目前我們的模組化主要依賴spark平台。整個叢集規模目前約為500台機器,以Spark on yarn方式部署。除了廣告和推薦模組化外,還支撐使用者定向,廣告系統BI的任務。

繼續閱讀