推薦系統(1)--splitting approaches for context-aware recommendation

來源:互聯網
上載者:User

標籤:

開篇語:大一的時候,在實驗室老師和師兄的帶領下,我開始接觸推薦系統。時光匆匆,轉眼已是大三,由於大三課甚是少,於是便有了時間將自己所學的東西做下總結。第一篇部落格,獻給過去三年裡帶我飛的老師和師兄們,感謝你們的無私協助與教導!

協同過濾演算法:

在傳統的協同過濾演算法中,演算法是基於一的使用者評分矩陣對使用者進行推薦的,其核心思想大致是利用相似使用者或者相似商品的資訊對使用者進行推薦,拿圖一舉例,在這裡我們要預測小紅對《了不起的蓋茨比》這部電影的評分是多少(1-5),一個最簡單的想法就是從所有使用者中找到跟小紅的品味相似的人,一眼望過去,小明跟小紅的品味最相近(都是小李子的粉絲?都比較喜歡看煽情一點的電影?),所以我們可以預測小紅對《了不起的蓋茲比》這部電影的評分應該是比較高的,所以在做電影推薦的時候,我們可以把《了不起的蓋茨比》這部電影推薦給小紅,這種利用相似使用者的資訊進行推薦的演算法叫做user-based(基於使用者的)協同過濾演算法,這種而相對應的,就有item-based(基於商品的)協同過濾演算法,基於商品協同過濾演算法思想大致是,那些跟使用者喜歡的商品相似的商品,在某種程度上說使用者也應該喜歡,放在這裡的話,小紅喜歡《泰坦尼克號》這部電影,由於《泰坦尼克號》跟《了不起的蓋茨比》比較相似,那麼小紅也理所當然地喜歡《了不起的蓋茨比》這部電影。有關協同過濾演算法,這篇部落格進行了詳細的介紹。


(圖一)

為了引出下文,這裡插個沒啥劇情沒啥品味的小故事:
A公司利用協同過濾演算法,為其下的每個使用者產生個人化的推薦之後,公司的營業額一天比一天高,而隨著資料越來越豐富,A公司除了擁有使用者對商品的評分這些資料外,還擁有各種上下文資訊(如小紅是在什麼時候看的這場電影,是跟什麼人一起看的,看完之後心情如何等等),老闆希望把這些內容相關的資訊都給利用上,但上面已經講到,傳統的協同過濾演算法僅僅是基於使用者對商品的評分對使用者進行推薦的,那麼,有沒有什麼辦法讓A公司在不換掉這套演算法的前提下,把這些上下文資訊給利用上呢?

Splitting:splitting的分類:
splitting方法分為item-splitting,user-splitting,UI-splitting三種。

splitting的基本思想:
對於某個事物X,如果它隨著環境(上下文)的改變,X也發生很大的變化,則應該認為X在不同的環境(上下文)中是屬於不同的事物,因此我們應該把它們分割開來,當成不同的事物對待。

splitting的做法:
這裡以item-splitting來舉例說明,item-splitting嘛,翻譯成中文就是“項目-分割”,字面意思就是對一個項目(商品)進行分割,將其分割成幾份,既然要分割,我們要拿什麼來分割?怎麼分割?分割成幾份?

分割???~~~

言歸正傳,先來看第一個和第二個問題,拿什麼來分割,怎麼分割?看回前面的小故事,我們會很自然而然地想到,這時候我們會用到內容相關的資訊來對item進行分割,在這裡,我們看圖二和圖三中的兩個矩陣:
(圖二)


(圖三)

圖三是使用者對泰坦尼克號的評分,而圖二是使用者在看這部電影時的一些上下文資訊,item-splitting方法的思想是利用某個上下文條件對項目嘗試進行分割,嘗試分割成兩個向量後,如果這兩個向量有顯著地不同,則應該把原來這個項目進行分割,假設上面的上下文條件中,“是否跟戀人”這個上下文條件可以讓泰坦尼克號這個列向量在分割之後有顯著地不同,則應該將其劃分為兩個向量,四:


(圖四)


在圖四中,依據“是否跟戀人”這個上下文條件對《泰坦尼克號》這個列向量進行分割後,形成了兩個不同的向量(跟戀人,不跟戀人),在item-splitting方法中,對應的其實是兩個不同的電影。

在這裡,引入一個新的問題,如何判斷一個向量在分割成兩個向量之後,這兩個向量有顯著的不同,即如何評判泰坦尼克號(跟戀人)和泰坦尼克號(不跟戀人)這兩個列向量有顯著的不同?

論文[1]中詳細地講解了splitting的整個過程,在這裡摘取其中一個評判兩個向量是否有顯著不同的公式:

(圖五)


該公式是兩個樣本的t檢驗,在p值滿足閾值(通常是p<=0.05滿足)的情況下,t值越大,這兩個向量越不同,其中,Ui是該電影的平均分,Si為該電影的評分方差,ni為該電影有多少個非零值,下標C和非C表示不同的上下文(跟戀人和不跟戀人)。

item-splitting的演算法虛擬碼(摘自論文[1])六所示:
(圖六)


將圖一的矩陣在執行item-splitting後,假設除了《了不起的蓋茨比》外,其他兩部電影都被splitting了,則將會變成七的矩陣:
(圖七)

利用上下文資訊得到七的矩陣後,可以在該矩陣上套用傳統的協同過濾演算法。

最後看一下上面說到的分割成幾份的問題,在上述過程中,對於每個item,我們都是劃分成2份,即是這個內容相關的和不是這個內容相關的,那麼,我們可以將其劃分成更多份嗎?比如對於圖二中的天氣這一個上下文維度,對每個項目劃分成4份,即晴,下雨,陰天,下雪這四個,可以是可以,但論文[1]有提到這樣劃分不僅會帶來時間成本的增加,也會導致評分矩陣過度稀疏,也會造成過擬合的問題。

splitting方法的優缺點及思考:首先說下優點,splitting方法可以把有價值的上下文資訊融入到傳統的協同過濾演算法中,從而提升推薦的效果。
再來說下缺點,從上面的虛擬碼來分析,我們可以知道,在內容相關的維度很高,且每個維度有很多值的情況下,整個splitting過程是十分耗時的,而且splitting耗費的這些時間不一定能很大幅度的提升推薦的效果,注意我上面說splitting的優點的時候, 有特別地說明“有價值的上下文資訊”,但是,什麼上下文資訊是有價值的呢?這又與業務背景有關,有人專門對內容相關的選取做過研究,發現並不是所有的上下文資訊都能提升推薦的效果的,有時候引入不恰當的上下文,反而會降低推薦的效果,因此,對於splitting過程中要用什麼上下文才能提升推薦效果,這也需要我們對業務背景有一定的瞭解。

在這裡推薦一個github上的有關上下文推薦系統相當不錯的項目:https://github.com/irecsys/CARSKit

參考學習資料:[1]L. Baltrunas and F. Ricci. Experimental evaluation of context-dependent collaborative filtering using item splitting.2013.
[2]Yong Zheng,Robin Burke,Bamshad Mobasher.Splitting Approaches for Context-Aware Recommendation: An Empirical Study.2014








推薦系統(1)--splitting approaches for context-aware recommendation

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.