1. 程式人生 > >Mahout--(五)mahout疑問解答

Mahout--(五)mahout疑問解答

也會 基於用戶 現實 理由 行為 日誌 過濾 混合 rms

來源:http://www.douban.com/note/245740667/

提問1:

博濤前輩,您好!

打攪您了,我想請教您一些問題。我是一名在讀研一學生。研究推薦系統方面的知識。 我一直非常困惑,在實際應用中,給定一個應用系統。比如淘寶,或者給定一個應用系統積累的數據集,怎樣用推薦系統的思想著手分析,怎樣為系統設計一個好的推薦方法,又是怎樣一個流程去分析這類問題?我看了mahout in action書中recommendations章節chapter 5提到對於一個數據集的分析思路,先選擇effective recommender,再結合領域知識過濾推薦。再繼續分析解決新用戶和新對象問題等。

我不確定現實應用中是不是也是這樣分析的?還有對於推薦系統領域的一些疑難雜癥,在現實應用中是不是都能通過一些辦法解決?比方新用戶問題,借助用戶的註冊信息或者訪問cookie(您對還有一位讀者的回答中提到)解決,對於新對象問題。則借助content-based方法解決? 最後對於我自己眼下的狀況我非常疑惑,即作為一個學生。研究推薦系統知識,應該把重點放在算法改進研究上,還是對實際問題的分析解決上?我認為學術研究和實際應用還是有一定的差別的,並且我看了這塊領域中的一些算法改進的論文,我認為拿到現實中未必實用。

不好意思,提了這麽多問題,希望前輩能為我解惑!


回答:

我概括了下你的回復裏面有三個問題。

1. 怎樣為一個有數據積累的應用系統設計和構建一個推薦系統?2. 怎樣解決冷啟動問題?3. 對於剛了解推薦系統的同學的一些建議?這三個問題假設展開敘述,都能夠寫好幾篇博文了,所以在這裏,我僅僅是簡要的回答你,可能會有不全然的地方:)

原 Google 研究員張棟(@張棟_機器學習)對於推薦系統影響因素概括了 5 點,即:產品設計:30%。數據:30%,領域知識:20%,算法:10%,project優化:10%。我認為張棟老師概括的很好。從中能夠看到數據對於推薦系統的重要性。假設你有一個將要構建推薦系統的應用,數據僅僅是一個必備的前提,要真正實踐一個推薦系統。首先還是得從用戶的需求出發,依據用戶的需求明白推薦系統提供哪一些服務,所提供的這些服務想達到什麽樣的目標,即:做什麽?目標是什麽?。

比方。新浪微博在 09 年剛上線的時候肯定也面臨著怎樣構建推薦系統的問題,能夠肯定的是經過他們的一番思考後。他們抓住了用戶的兩點需求:(1)熱門話題和新聞一般會得到大家的高度關註;(2)好友之間的互動。他們的目標也非常easy(1)提高用戶的發微、轉發、評論的頻率,添加用戶對微博的黏性;(2)構建新浪微博的好友生態圈。大家如今去看看新浪微博,他們的推薦形式差點兒就這兩種,沒怎麽大變,可是效果確實越來越好。由於他們不斷的再實踐和優化。

知道了做什麽和目標,以下我們就討論下怎麽做。一般來說構建推薦系統基本流程是:用戶行為、數據分析建模 -> 推薦算法設計和相關性計算 -> 生成推薦結果(含推薦解釋)

1. 用戶行為、數據分析建模
假設你的數據分布在訪問日誌和數據庫的多個表中(比如訂單表、收藏記錄表、評價表、訂閱表),那麽一般須要把這些數據提取出來。並轉換成用戶的行為數據 user_behavior(user_id, item_id, behavior_type, behavior_content, behavior_weight)。

用戶的行為數據來源很廣,對於一個電子商務站點而言,購買、瀏覽、收藏、評價、訂閱等隱性行為,用戶問卷調查等顯性行為貢獻了大量的數據。還有一方面,註冊信息也是用戶的重要特征數據。



2. 推薦算法設計和相關性計算
相關性計算(也就是相似性計算)和推薦算法是密切聯系的。依據推薦算法的不同。我們須要計算用戶之間的相似性和物品之間的相似性。而用戶之間的相似性能夠是行為的相似性。也能夠是用戶屬性(年齡、性別、地域)的相似性。物品之間的相似性能夠是基於用戶反饋的相似性。也能夠是物品內容的相似性。



推薦算法包含 UserCF、ItemCF、Content-based、Demographic-based 等,應該說這些算法都各有長處和缺點,在應用中也會依據實際情況選擇當中的一種或多種方法。

通常。我們可以依據經驗排除某幾種或選擇某幾種。比如:微博的好友推薦主要使用的推薦算法是 UserCF 和 Hot-based。假設你已經使用微博一段時間,微博會依據你關註的用戶生成你的好友圈子推薦給你。假設你關註的用戶非常少,比方新用戶,那麽會推薦那些大 V 用戶給你,比方姚晨啊、開復老師啊。

另外一個典型的樣例,就是 Amazon。我們知道 ItemCF 是 Amazon 提出來的,在這之前 UserCF 已經用了好幾年,可是 Amazon 的project師在推薦系統的實踐中認為 UserCF 不適合他們,由於:(1)用戶的數量遠大於商品的數量,同一時候用戶的增長規模也大於商品的增長規模,所以 UserCF 的計算量會越來越大;(2)用戶的相似性是不穩定的。而商品的相似性卻要穩定的多,《Thinking in Java》和《Effective Java》是相似的兩本書。它們今天相似,過一個月後。過一年之後都是相似的,但兩個用戶 A 和 B,他們今天喜歡相同的書籍,我們覺得他們是相似的,但過了一天或一周後可能他們喜歡的書籍會發生非常大的變化導致他們不再相似,所這就要求 UserCF 要進行頻繁的計算;(3)UserCF 難以生成讓人信服的推薦理由,你買個東西告訴你是由於你和某某人相似,而你卻連這某某人是誰都不知道。

正由於這些原因 Amazon 的project師提出了 ItemCF 算法。



相似性計算的方法有非常多,余弦相似性、歐氏距離、皮爾森相關系數、內容相似性 等等,能夠參看我之前的 blog http://blog.csdn.net/bornhe/article/details/7425642

終於選取哪一種推薦算法和哪一種相似性。取決於評測的結果。通常,我們會實驗每一種方法。然後選擇最優的一種。這裏使用了機器學習裏面的監督學習方法。能夠看我之前的回復http://www.douban.com/note/208193209/#30908428

說那麽多。還了舉微博和 Amazon 的樣例,主要是為了說明推薦算法是一種領域性非常強的算法(你問題裏也提到了領域)。別的系統用的非常好的推薦算法,放到你的系統裏不一定會表現非常好,所以我們須要進行領域分析和推薦算法的評測,評測的方法有 RMSE(Netflix 用的離線評測指標)、precision、recall。這在 《Mahout in Action》Part 5 裏面也有具體的介紹。

3. 生成推薦結果(含推薦解釋)
前兩步的計算量非常大,一般都是離線完畢。

而生成推薦結果卻是實時的。用戶請求來,我們就匹配和用戶最相關的物品推薦給用戶。這一步我會進行結果的過濾、排序和推薦結果的解釋。

過濾處理非常easy,就是把用戶已經產生過行為的物品、質量差的物品過濾掉。而排序則要復雜的多,須要考慮推薦物品的相關性、新穎性、多樣性和時間上下文等多種因素,一個個性化的推薦系統。排序也要是個性化的,這意味著我們須要為每個用戶(或每個群體)訓練一個排序模型,訓練的過程也是離線完畢的,關於推薦系統的排序能夠參考我翻譯的 Netflix 推薦系統的 blog:http://blog.csdn.net/bornhe/article/details/8222497。最後。推薦解釋也是非常重要的。我們須要說清楚推薦結果是來源於用戶的那些行為或屬性,好的推薦解釋可以添加用戶對推薦結果的信任度。這樣用戶會更可能購買或評價。



補充一點:關於推薦算法的評測,離線評測是當中重要的一種,通常在實際場景中還會安排線上評測,也就是 A/B 測試。我們會把好幾種通過離線評測的算法和模型放到線上去經受用戶的考驗。終於挑出最優的幾種。關於 A/B 測試。也能夠參看 http://blog.csdn.net/bornhe/article/details/8222497的後面部分。

PS:有非常多 blog 在討論 #推薦系統構建# 這個話題的時候,都是環繞著怎麽做開始的,從中你能夠看到業界非常多公司使用的都不是單獨的一種推薦算法,而是一種混合的推薦算法,可是細節一般都秘而不宣。



------------------------------------------------------------------------
對於你的第二個問題:怎樣解決冷啟動?

事實上在你的問題裏面已經有了答案。

也就是對於新用戶,我們能夠使用 Demographic-based 和 Hot-based(排行榜)來解決冷啟動問題。對於新物品。能夠用 Content-based 來解決冷啟動問題。在這裏 http://www.douban.com/note/204399134/#30943588 有我之前詳細的回復。

------------------------------------------------------------------------
對於你的第三個問題:對於剛了解推薦系統的同學的一些建議?

事實上我也剛走出校園一年多,之前在學校的時候也有類似於你的困惑。

有一點,我認為要明白:無論是在學校,還是去企業裏面實習,都非常難有“實際問題分析解決”的機會,所以在學校能夠多利用自己的業余時間開闊自己的視野,能夠多關註一些大牛和知名公司的技術博客
Gren Linden(ItemCF 算法的提出者之中的一個) blog:http://glinden.blogspot.com/
項亮大牛的 blog:http://xlvector.net/blog/
谷文棟大牛的 blog:http://www.guwendong.com/archives
阿穩大牛的 blog:http://www.wentrue.net/blog/
Netflix 技術 blog:http://techblog.netflix.com/
項亮和谷文棟一起發起了 Resys China http://www.resyschina.com/,項亮的《推薦系統實踐一書》也相當推薦閱讀,在第 7 章——推薦系統實例。相信能給你對於 #推薦系統構建# 很多其它的答案。

另外也有非常多的實踐機會,網上有非常多的真實可用數據能夠供我們使用,《Mahout in Action》中介紹的 GroupLen 就是非常好的資源(並且這些數據都是經過提取和轉化處理的),用這些數據,結合自己的學習,不斷的實踐。相信能夠取得不小的進步。假設身邊有同興趣的同學。你們還能夠一起組隊參加 Netflix Prize 推薦系統大賽,項亮曾在 09 年參加過 Netflix Prize,並取得了第二名的好成績,詳見:http://www.netflixprize.com/leaderboard,這些都是非常好的實踐的機會。



總之,多讀論文多實踐。眼光長遠。相信你一定取得好成績。



提問2:

博濤,真的非常感激你為我認真耐心地解答疑惑,解答不僅內容具體、調理非常清晰,更是切中了困惑我非常久的問題!我認真研究了你寫的每個字,對鏈接也進行了深入的閱讀,並做了筆記。似乎我之前腦海中的一片糊塗開始變得清晰了,非常多知識我可能也知道,可是我沒有總體概念。對於細節和深入的本質更是模糊不清。有時候模糊的連自己的問題在哪裏都不知道,更別提查找資料解決這個問題了。

看了你的回答,我思路更清晰了,同一時候我也更明白作為一個在校學生,應該做什麽了!非常多時候我知道自己有非常多能夠選擇的路。可是由於沒有過來人的指點,總操心自己會迂回繞遠,這或許是非常多走在路上的人的困惑吧。另外。我還得打攪你一下,我整理知識過程中,發現我還有幾點不是非常明白:(1)線下計算大概是如何實現的?是將各種相似性矩陣結果提前計算好。存儲在文件系統或數據庫系統中。然後線上推薦時對相關信息進行讀取再計算推薦?(2)訓練集和測試集問題。《mahout in action》書中進行評測時是通過一個比例參數決定百分之多少為訓練集。剩余的百分之多少為測試集,groupLens的100k的數據集中有ua.base 和ua.test兩個數據文件,ua.base應該是用作訓練,ua.test應該是用作測試的(我看著應該是的),在評測時我怎麽先用ua.base訓練。再用ua.test測試呢?mahout支持這樣的輸入嗎?(weka中分類方法實驗時。分別載入訓練集和測試集的)(3)我看了一些文章,多數文章核心的部分是結合應用特征和屬性計算uesr對item的preference,而在你的還有一篇博文“Netflix 推薦系統:第二部分”中。提到Netflix不只使用預測評分。而是將熱門程度和預測評分進行線性加權f(u, v) = w1*p(v) + w2*r(u, v) + b,然後根據f(u,v)值進行排序。我想知道這個f(u,v)與預測評分有什麽本質的差別?是不是博文中的“預測評分”是單純的根據相似用戶或item的信息得出的評分預測,與其它應用相關的屬性無關?我個人認為f(u,v)是一種廣義上的評分預測。

不好意思,又寫了這麽多問題。再一次表達我的謝意*_*


回答:

關於你的第一個問題(1)線下計算大概是如何實現的?事實上你自己給的答案是正確的。我這裏簡單做下補充:這個問題能夠說是推薦系統最核心的問題。非常多公司對這部分內容一般都僅僅是介紹個大概。細節都秘而不宣,所以這部分所涉及的內容是非常多的,不管是計算量,還是技術難度都非常大。

普通情況下。一個成熟的推薦系統,都會有兩部分組成:離線部分和在線部分。

離線部分完畢的是相關性的計算,計算結果通常會持久化到 MySQL 或諸如 Redis 的 K-V 數據庫中,也能夠存儲到 HBase 這類分布式存儲系統中(據我了解到 facebook 推薦系統的相關性數據就是存儲到 HBase 中的)。當然詳細的存儲方式要視你的數據規模(存儲成本)和實際場景(如讀寫比例、系統結構等)而定。有了相關性數據,在線部分僅僅須要讀取用戶特征(如歷史行為中的商品),然後到相關表找查找匹配相關結果就能夠得到初始的推薦結果。另外要告訴你一點。業界各家公司的推薦系統,在線部分大部分是相似的,主要差別和創新主要都集中在離線部分。

關於你的第二個問題(2)訓練集和測試集問題?這主要是一個機器學習中的監督學習過程,這在我上面的回復中有具體的介紹。在 Mahout 中有一個 RecommenderEvaluator 的接口。通過接口中的 evaluate 方法。能夠完畢對某一個推薦算法的評估,也能夠依據這個接口進行自己定義的擴展。而在 grouplens 的 100k 的數據中,從 u1.base,u1.test 到 u5.base。u5.test 這 5 組數據集都是從 u.data 中依據 4:1 的比例抽取出來的,當中 .base 是訓練集。.test 是測試集。grouplens 的原文介紹是“The data sets u1.base and u1.test through u5.base and u5.test are 80%/20% splits of the u data into training and test data.” 。在訓練和測試過程中,第一步:使用 u1.base 進行訓練,說詳細一點就是基於 u1.base 構建一個 recommender。然後為 u1.base 中的全部 user 產生推薦結果,如果推薦結果集為 u1.result;第二步:比較 u1.result 和 u1.test 中的數據重合度。重合度越高說明算法的準確率越高。

如果是直接使用 Mahout 提供的 RecommenderEvaluator,那麽僅須要使用一個文件—— u.base,把 u.base 作為 DataModel 的 file。並指定 trainingPercentage 為 0.8,指定 evaluationPercentage 為 1.0 就能夠了。Mahout 會自己主動把 u.base split 成兩個文件。train 文件和 test 文件。源代碼為“splitOneUsersPrefs(trainingPercentage, trainingPrefs, testPrefs, userID, dataModel);”

關於你的第三個問題(3)推薦結果排序和預測評分的關系?在我的博文《Netflix 推薦系統:第二部分》中,f(u, v) 是一個排序分值函數(rank function)。而預測分值 p(v) 是函數 f 的一個維度,為什麽會這樣呢?由於在把推薦結果展現給用戶之前,通常須要對推薦結果進行排序,把用戶最有可能點擊或購買的物品排列在前。計算物品的排序須要綜合考慮評分預測值、物品的熱門程度、物品的新穎度等等因素。每個因素能夠看成是函數 f(u, v) 的一維。一般而言,會為每一個用戶都計算一個 f(u, v) 函數,由於一個個性化的推薦系統,排序也要是個性化的。計算的過程是離線完畢的。具體你再具體看下博文的原文。

Mahout--(五)mahout疑問解答