深刻推薦引擎相關算法 - 協同過濾2

本系列的第一篇爲讀者概要介紹了推薦引擎，下面幾篇文章將深刻介紹推薦引擎的相關算法，並幫助讀者高效的實現這些算法。 在現今的推薦技術和算法中，最被你們普遍承認和採用的就是基於協同過濾的推薦方法。它以其方法模型簡單，數據依賴性低，數據方便採集 , 推薦效果較優等多個優勢成爲大衆眼裏的推薦算法「No.1」。本文將帶你深刻了解協同過濾的祕密，並給出基於 Apache Mahout 的協同過濾算法的高效實現。Apache Mahout 是 ASF 的一個較新的開源項目，它源於 Lucene，構建在 Hadoop 之上，關注海量數據上的機器學習經典算法的高效實現。

集體智慧和協同過濾

---

 

什麼是集體智慧

集體智慧 (Collective Intelligence) 並非 Web2.0 時代特有的，只是在 Web2.0 時代，你們在 Web 應用中利用集體智慧構建更加有趣的應用或者獲得更好的用戶體驗。集體智慧是指在大量的人羣的行爲和數據中收集答案，幫助你對整我的羣獲得統計意義上的結 論，這些結論是咱們在單個個體上沒法獲得的，它每每是某種趨勢或者人羣中共性的部分。 Wikipedia 和 Google 是兩個典型的利用集體智慧的 Web 2.0 應用：

• Wikipedia 是一個知識管理的百科全書，相對於傳統的由領域專家編輯的百科全書，Wikipedia 容許最終用戶貢獻知識，隨着參與人數的增多，Wikipedia 變成了涵蓋各個領域的一本無比全面的知識庫。也許有人會質疑它的權威性，但若是你從另外一個側面想這個問題，也許就能夠迎刃而解。在發行一本書時，做者雖然 是權威，但不免還有一些錯誤，而後經過一版一版的改版，書的內容愈來愈完善。而在 Wikipedia 上，這種改版和修正被變爲每一個人均可以作的事情，任何人發現錯誤或者不完善均可以貢獻他們的想法，即使某些信息是錯誤的，但它必定也會盡快的被其餘人糾正 過來。從一個宏觀的角度看，整個系統在按照一個良性循環的軌跡不斷完善，這也正是集體智慧的魅力。
• Google：目前最流行的搜索引擎，與 Wikipedia 不一樣，它沒有要求用戶顯式的貢獻，但仔細想一想 Google 最核心的 PageRank 的思想，它利用了 Web 頁面之間的關係，將多少其餘頁面連接到當前頁面的數目做爲衡量當前頁面重要與否的標準；若是這很差理解，那麼你能夠把它想象成一個選舉的過程，每一個 Web 頁面都是一個投票者同時也是一個被投票者，PageRank 經過必定數目的迭代獲得一個相對穩定的評分。Google 其實利用瞭如今 Internet 上全部 Web 頁面上連接的集體智慧，找到哪些頁面是重要的。

什麼是協同過濾

協同過濾是利用集體智慧的一個典型方法。要理解什麼是協同過濾 (Collaborative Filtering, 簡稱 CF)，首先想一個簡單的問題，若是你如今想看個電影，但你不知道具體看哪部，你會怎麼作？大部分的人會問問周圍的朋友，看看最近有什麼好看的電影推薦， 而咱們通常更傾向於從口味比較相似的朋友那裏獲得推薦。這就是協同過濾的核心思想。 協同過濾通常是在海量的用戶中發掘出一小部分和你品位比較相似的，在協同過濾中，這些用戶成爲鄰居，而後根據他們喜歡的其餘東西組織成一個排序的目錄做爲 推薦給你。固然其中有一個核心的問題：

• 如何肯定一個用戶是否是和你有類似的品位？
• 如何將鄰居們的喜愛組織成一個排序的目錄？

協同過濾相對於集體智慧而言，它從必定程度上保留了個體的特徵，就是你的品位偏好，因此它更多能夠做爲個性化推薦的算法思想。能夠想象，這種推薦策 略在 Web 2.0 的長尾中是很重要的，將大衆流行的東西推薦給長尾中的人怎麼可能獲得好的效果，這也回到推薦系統的一個核心問題：瞭解你的用戶，而後才能給出更好的推薦。

深刻協同過濾的核心

前面做爲背景知識，介紹了集體智慧和協同過濾的基本思想，這一節咱們將深刻分析協同過濾的原理，介紹基於協同過濾思想的多種推薦機制，優缺點和實用場景。 首先，要實現協同過濾，須要一下幾個步驟

• 收集用戶偏好
• 找到類似的用戶或物品
• 計算推薦

一、收集用戶偏好

要從用戶的行爲和偏好中發現規律，並基於此給予推薦，如何收集用戶的偏好信息成爲系統推薦效果最基礎的決定因素。用戶有不少方式向系統提供本身的偏好信息，並且不一樣的應用也可能大不相同，下面舉例進行介紹：

表 1 用戶行爲和用戶偏好

用戶行爲	類型	特徵	做用
評分	顯式	整數量化的偏好，可能的取值是 [0, n]；n 通常取值爲 5 或者是 10	經過用戶對物品的評分，能夠精確的獲得用戶的偏好
投票	顯式	布爾量化的偏好，取值是 0 或 1	經過用戶對物品的投票，能夠較精確的獲得用戶的偏好
轉發	顯式	布爾量化的偏好，取值是 0 或 1	經過用戶對物品的投票，能夠精確的獲得用戶的偏好。 若是是站內，同時能夠推理獲得被轉發人的偏好（不精確）
保存書籤	顯示	布爾量化的偏好，取值是 0 或 1	經過用戶對物品的投票，能夠精確的獲得用戶的偏好。
標記標籤 (Tag)	顯示	一些單詞，須要對單詞進行分析，獲得偏好	經過分析用戶的標籤，能夠獲得用戶對項目的理解，同時能夠分析出用戶的情感：喜歡仍是討厭
評論	顯示	一段文字，須要進行文本分析，獲得偏好	經過分析用戶的評論，能夠獲得用戶的情感：喜歡仍是討厭
點擊流 ( 查看 )	隱式	一組用戶的點擊，用戶對物品感興趣，須要進行分析，獲得偏好	用戶的點擊必定程度上反映了用戶的注意力，因此它也能夠從必定程度上反映用戶的喜愛。
頁面停留時間	隱式	一組時間信息，噪音大，須要進行去噪，分析，獲得偏好	用戶的頁面停留時間必定程度上反映了用戶的注意力和喜愛，但噪音偏大，很差利用。
購買	隱式	布爾量化的偏好，取值是 0 或 1	用戶的購買是很明確的說明這個項目它感興趣。

以上列舉的用戶行爲都是比較通用的，推薦引擎設計人員能夠根據本身應用的特色添加特殊的用戶行爲，並用他們表示用戶對物品的喜愛。 在通常應用中，咱們提取的用戶行爲通常都多於一種，關於如何組合這些不一樣的用戶行爲，基本上有如下兩種方式：

• 將不一樣的行爲分組：通常能夠分爲「查看」和「購買」等等，而後基於不一樣的行爲，計算不一樣的用戶 / 物品類似度。相似於噹噹網或者 Amazon 給出的「購買了該圖書的人還購買了 ...」，「查看了圖書的人還查看了 ...」
• 根據不一樣行爲反映用戶喜愛的程度將它們進行加權，獲得用戶對於物品的整體喜愛。通常來講，顯式的用戶反饋比隱式的權值大，但比較稀疏，畢竟進行顯示反饋的用戶是少數；同時相對於「查看」，「購買」行爲反映用戶喜愛的程度更大，但這也因應用而異。

收集了用戶行爲數據，咱們還須要對數據進行必定的預處理，其中最核心的工做就是：減噪和歸一化。

• 減噪：用戶行爲數據是用戶在使用應用過程當中產生的，它可能存在大量的噪音和用戶的誤操做，咱們能夠經過經典的數據挖掘算法過濾掉行爲數據中的噪音，這樣能夠是咱們的分析更加精確。
• 歸一化：如前面講到的，在計算用戶對物品的喜愛程度時，可能須要對不一樣的行爲數據進行加權。但能夠想象，不一樣行爲的數據取值可能相差很大，好比， 用戶的查看數據必然比購買數據大的多，如何將各個行爲的數據統一在一個相同的取值範圍中，從而使得加權求和獲得的整體喜愛更加精確，就須要咱們進行歸一化 處理。最簡單的歸一化處理，就是將各種數據除以此類中的最大值，以保證歸一化後的數據取值在 [0,1] 範圍中。

進行的預處理後，根據不一樣應用的行爲分析方法，能夠選擇分組或者加權處理，以後咱們能夠獲得一個用戶偏好的二維矩陣，一維是用戶列表，另外一維是物品列表，值是用戶對物品的偏好，通常是 [0,1] 或者 [-1, 1] 的浮點數值。

二、找到類似的用戶或物品

當已經對用戶行爲進行分析獲得用戶喜愛後，咱們能夠根據用戶喜愛計算類似用戶和物品，而後基於類似用戶或者物品進行推薦，這就是最典型的 CF 的兩個分支：基於用戶的 CF 和基於物品的 CF。這兩種方法都須要計算類似度，下面咱們先看看最基本的幾種計算類似度的方法。 類似度的計算 關於類似度的計算，現有的幾種基本方法都是基於向量（Vector）的，其實也就是計算兩個向量的距離，距離越近類似度越大。在推薦的場景中，在用戶 - 物品偏好的二維矩陣中，咱們能夠將一個用戶對全部物品的偏好做爲一個向量來計算用戶之間的類似度，或者將全部用戶對某個物品的偏好做爲一個向量來計算物品 之間的類似度。

下面咱們詳細介紹幾種經常使用的類似度計算方法：

• 歐幾里德距離（Euclidean Distance）

最初用於計算歐幾里德空間中兩個點的距離，假設 x，y 是 n 維空間的兩個點，它們之間的歐幾里德距離是： 能夠看出，當 n=2 時，歐幾里德距離就是平面上兩個點的距離。 當用歐幾里德距離表示類似度，通常採用如下公式進行轉換：距離越小，類似度越大

• 皮爾遜相關係數（Pearson Correlation Coefficient）

皮爾遜相關係數通常用於計算兩個定距變量間聯繫的緊密程度，它的取值在 [-1，+1] 之間。 sx, sy是 x 和 y 的樣品標準誤差。

• Cosine 類似度（Cosine Similarity）

Cosine 類似度被普遍應用於計算文檔數據的類似度：

• Tanimoto 係數（Tanimoto Coefficient）

Tanimoto 係數也稱爲 Jaccard 係數，是 Cosine 類似度的擴展，也多用於計算文檔數據的類似度：

類似鄰居的計算

介紹完類似度的計算方法，下面咱們看看如何根據類似度找到用戶 - 物品的鄰居，經常使用的挑選鄰居的原則能夠分爲兩類：圖 1 給出了二維平面空間上點集的示意圖。

• 固定數量的鄰居：K-neighborhoods 或者 Fix-size neighborhoods

不論鄰居的「遠近」，只取最近的 K 個，做爲其鄰居。如圖 1 中的 A，假設要計算點 1 的 5- 鄰居，那麼根據點之間的距離，咱們取最近的 5 個點，分別是點 2，點 3，點 4，點 7 和點 5。但很明顯咱們能夠看出，這種方法對於孤立點的計算效果很差，由於要取固定個數的鄰居，當它附近沒有足夠多比較類似的點，就被迫取一些不太類似的點做爲 鄰居，這樣就影響了鄰居類似的程度，好比圖 1 中，點 1 和點 5 其實並非很類似。

• 基於類似度門檻的鄰居：Threshold-based neighborhoods

與計算固定數量的鄰居的原則不一樣，基於類似度門檻的鄰居計算是對鄰居的遠近進行最大值的限制，落在以當前點爲中心，距離爲 K 的區域中的全部點都做爲當前點的鄰居，這種方法計算獲得的鄰居個數不肯定，但類似度不會出現較大的偏差。如圖 1 中的 B，從點 1 出發，計算類似度在 K 內的鄰居，獲得點 2，點 3，點 4 和點 7，這種方法計算出的鄰居的類似度程度比前一種優，尤爲是對孤立點的處理。

圖 1.類似鄰居計算示意圖

計算推薦

通過前期的計算已經獲得了相鄰用戶和相鄰物品，下面介紹如何基於這些信息爲用戶進行推薦。本系列的上一篇綜述文章已經簡要介紹過基於協同過濾的推薦算法能夠分爲基於用戶的 CF 和基於物品的 CF，下面咱們深刻這兩種方法的計算方法，使用場景和優缺點。

基於用戶的 CF（User CF） 基於用戶的 CF 的基本思想至關簡單，基於用戶對物品的偏好找到相鄰鄰居用戶，而後將鄰居用戶喜歡的推薦給當前用戶。計算上，就是將一個用戶對全部物品的偏好做爲一個向量 來計算用戶之間的類似度，找到 K 鄰居後，根據鄰居的類似度權重以及他們對物品的偏好，預測當前用戶沒有偏好的未涉及物品，計算獲得一個排序的物品列表做爲推薦。圖 2 給出了一個例子，對於用戶 A，根據用戶的歷史偏好，這裏只計算獲得一個鄰居 - 用戶 C，而後將用戶 C 喜歡的物品 D 推薦給用戶 A。

圖 2.基於用戶的 CF 的基本原理

基於物品的 CF（Item CF） 基於物品的 CF 的原理和基於用戶的 CF 相似，只是在計算鄰居時採用物品自己，而不是從用戶的角度，即基於用戶對物品的偏好找到類似的物品，而後根據用戶的歷史偏好，推薦類似的物品給他。從計算 的角度看，就是將全部用戶對某個物品的偏好做爲一個向量來計算物品之間的類似度，獲得物品的類似物品後，根據用戶歷史的偏好預測當前用戶尚未表示偏好的 物品，計算獲得一個排序的物品列表做爲推薦。圖 3 給出了一個例子，對於物品 A，根據全部用戶的歷史偏好，喜歡物品 A 的用戶都喜歡物品 C，得出物品 A 和物品 C 比較類似，而用戶 C 喜歡物品 A，那麼能夠推斷出用戶 C 可能也喜歡物品 C。

圖 3.基於物品的 CF 的基本原理

User CF vs. Item CF 前面介紹了 User CF 和 Item CF 的基本原理，下面咱們分幾個不一樣的角度深刻看看它們各自的優缺點和適用場景：

• 計算複雜度

Item CF 和 User CF 是基於協同過濾推薦的兩個最基本的算法，User CF 是很早之前就提出來了，Item CF 是從 Amazon 的論文和專利發表以後（2001 年左右）開始流行，你們都以爲 Item CF 從性能和複雜度上比 User CF 更優，其中的一個主要緣由就是對於一個在線網站，用戶的數量每每大大超過物品的數量，同時物品的數據相對穩定，所以計算物品的類似度不但計算量較小，同時 也沒必要頻繁更新。但咱們每每忽略了這種狀況只適應於提供商品的電子商務網站，對於新聞，博客或者微內容的推薦系統，狀況每每是相反的，物品的數量是海量 的，同時也是更新頻繁的，因此單從複雜度的角度，這兩個算法在不一樣的系統中各有優點，推薦引擎的設計者須要根據本身應用的特色選擇更加合適的算法。

• 適用場景

在非社交網絡的網站中，內容內在的聯繫是很重要的推薦原則，它比基於類似用戶的推薦原則更加有效。好比在購書網站上，當你看一本書的時候，推薦引擎 會給你推薦相關的書籍，這個推薦的重要性遠遠超過了網站首頁對該用戶的綜合推薦。能夠看到，在這種狀況下，Item CF 的推薦成爲了引導用戶瀏覽的重要手段。同時 Item CF 便於爲推薦作出解釋，在一個非社交網絡的網站中，給某個用戶推薦一本書，同時給出的解釋是某某和你有類似興趣的人也看了這本書，這很難讓用戶信服，由於用 戶可能根本不認識那我的；但若是解釋說是由於這本書和你之前看的某本書類似，用戶可能就以爲合理而採納了此推薦。 相反的，在現今很流行的社交網絡站點中，User CF 是一個更不錯的選擇，User CF 加上社會網絡信息，能夠增長用戶對推薦解釋的信服程度。

• 推薦多樣性和精度

研究推薦引擎的學者們在相同的數據集合上分別用 User CF 和 Item CF 計算推薦結果，發現推薦列表中，只有 50% 是同樣的，還有 50% 徹底不一樣。可是這兩個算法確有類似的精度，因此能夠說，這兩個算法是很互補的。 關於推薦的多樣性，有兩種度量方法： 第一種度量方法是從單個用戶的角度度量，就是說給定一個用戶，查看系統給出的推薦列表是否多樣，也就是要比較推薦列表中的物品之間兩兩的類似度，不難想 到，對這種度量方法，Item CF 的多樣性顯然不如 User CF 的好，由於 Item CF 的推薦就是和之前看的東西最類似的。 第二種度量方法是考慮系統的多樣性，也被稱爲覆蓋率 (Coverage)，它是指一個推薦系統是否可以提供給全部用戶豐富的選擇。在這種指標下，Item CF 的多樣性要遠遠好於 User CF, 由於 User CF 老是傾向於推薦熱門的，從另外一個側面看，也就是說，Item CF 的推薦有很好的新穎性，很擅長推薦長尾裏的物品。因此，儘管大多數狀況，Item CF 的精度略小於 User CF， 但若是考慮多樣性，Item CF 卻比 User CF 好不少。 若是你對推薦的多樣性還心存疑惑，那麼下面咱們再舉個實例看看 User CF 和 Item CF 的多樣性到底有什麼差異。首先，假設每一個用戶興趣愛好都是普遍的，喜歡好幾個領域的東西，不過每一個用戶確定也有一個主要的領域，對這個領域會比其餘領域更 加關心。給定一個用戶，假設他喜歡 3 個領域 A,B,C，A 是他喜歡的主要領域，這個時候咱們來看 User CF 和 Item CF 傾向於作出什麼推薦：若是用 User CF, 它會將 A,B,C 三個領域中比較熱門的東西推薦給用戶；而若是用 ItemCF，它會基本上只推薦 A 領域的東西給用戶。因此咱們看到由於 User CF 只推薦熱門的，因此它在推薦長尾裏項目方面的能力不足；而 Item CF 只推薦 A 領域給用戶，這樣他有限的推薦列表中就可能包含了必定數量的不熱門的長尾物品，同時 Item CF 的推薦對這個用戶而言，顯然多樣性不足。可是對整個系統而言，由於不一樣的用戶的主要興趣點不一樣，因此係統的覆蓋率會比較好。 從上面的分析，能夠很清晰的看到，這兩種推薦都有其合理性，但都不是最好的選擇，所以他們的精度也會有損失。其實對這類系統的最好選擇是，若是系統給這個 用戶推薦 30 個物品，既不是每一個領域挑選 10 個最熱門的給他，也不是推薦 30 個 A 領域的給他，而是好比推薦 15 個 A 領域的給他，剩下的 15 個從 B,C 中選擇。因此結合 User CF 和 Item CF 是最優的選擇，結合的基本原則就是當採用 Item CF 致使系統對我的推薦的多樣性不足時，咱們經過加入 User CF 增長我的推薦的多樣性，從而提升精度，而當由於採用 User CF 而使系統的總體多樣性不足時，咱們能夠經過加入 Item CF 增長總體的多樣性，一樣一樣能夠提升推薦的精度。

• 用戶對推薦算法的適應度

前面咱們大部分都是從推薦引擎的角度考慮哪一個算法更優，但其實咱們更多的應該考慮做爲推薦引擎的最終使用者 -- 應用用戶對推薦算法的適應度。 對於 User CF，推薦的原則是假設用戶會喜歡那些和他有相同喜愛的用戶喜歡的東西，但若是一個用戶沒有相同喜愛的朋友，那 User CF 的算法的效果就會不好，因此一個用戶對的 CF 算法的適應度是和他有多少共同喜愛用戶成正比的。 Item CF 算法也有一個基本假設，就是用戶會喜歡和他之前喜歡的東西類似的東西，那麼咱們能夠計算一個用戶喜歡的物品的自類似度。一個用戶喜歡物品的自類似度大，就 說明他喜歡的東西都是比較類似的，也就是說他比較符合 Item CF 方法的基本假設，那麼他對 Item CF 的適應度天然比較好；反之，若是自類似度小，就說明這個用戶的喜愛習慣並不知足 Item CF 方法的基本假設，那麼對於這種用戶，用 Item CF 方法作出好的推薦的可能性很是低。 經過以上的介紹，相信你們已經對協同過濾推薦的各類方法，原則，特色和適用場景有深刻的瞭解，下面咱們就進入實戰階段，重點介紹如何基於 Apache Mahout 實現協同過濾推薦算法。

基於 Apache Mahout 實現高效的協同過濾推薦

---

 

Apache Mahout 是 Apache Software Foundation (ASF) 旗下的一個開源項目，提供一些可擴展的機器學習領域經典算法的實現，旨在幫助開發人員更加方便快捷地建立智能應用程序，而且，在 Mahout 的最近版本中還加入了對 Apache Hadoop 的支持，使這些算法能夠更高效的運行在雲計算環境中。 關於 Apache Mahout 的安裝和配置請參考《基於 Apache Mahout 構建社會化推薦引擎》，它是筆者 09 年發表的一篇關於基於 Mahout 實現推薦引擎的 developerWorks 文章，其中詳細介紹了 Mahout 的安裝步驟，並給出一個簡單的電影推薦引擎的例子。 Apache Mahout 中提供的一個協同過濾算法的高效實現，它是一個基於 Java 實現的可擴展的，高效的推薦引擎。圖 4 給出了 Apache Mahout 中協同過濾推薦實現的組件圖，下面咱們逐步深刻介紹各個部分。

圖 4.組件圖

數據表示：Data Model

Preference 基於協同過濾的推薦引擎的輸入是用戶的歷史偏好信息，在 Mahout 裏它被建模爲 Preference（接口），一個 Preference 就是一個簡單的三元組 < 用戶 ID, 物品 ID, 用戶偏好 >，它的實現類是 GenericPreference，能夠經過如下語句建立一個 GenericPreference。 GenericPreference preference = new GenericPreference(123, 456, 3.0f); 這其中， 123 是用戶 ID，long 型；456 是物品 ID，long 型；3.0f 是用戶偏好，float 型。從這個例子咱們能夠看出，單單一個 GenericPreference 的數據就佔用 20 bytes，因此你會發現若是隻簡單實用數組 Array 加載用戶偏好數據，必然佔用大量的內存，Mahout 在這方面作了一些優化，它建立了 PreferenceArray（接口）保存一組用戶偏好數據，爲了優化性能，Mahout 給出了兩個實現類，GenericUserPreferenceArray 和 GenericItemPreferenceArray，分別按照用戶和物品自己對用戶偏好進行組裝，這樣就能夠壓縮用戶 ID 或者物品 ID 的空間。下面清單 1 的代碼以 GenericUserPreferenceArray 爲例，展現瞭如何建立和使用一個 PreferenceArray。

清單 1. 建立和使用 PreferenceArray

 PreferenceArray userPref = new GenericUserPreferenceArray(2); //size = 2 

 userPref.setUserID(0, 1L); 

 userPref.setItemID(0, 101L);  //<1L, 101L, 2.0f> 
 userPref.setValue(0, 2.0f); 
 userPref.setItemID(1, 102L);  //<1L, 102L, 4.0f> 
 userPref.setValue(1, 4.0f); 

 Preference pref = userPref.get(1);   //<1L, 102L, 4.0f>

爲了提升性能 Mahout 還構建了本身的 HashMap 和 Set：FastByIDMap 和 FastIDSet，有興趣的朋友能夠參考 Mahout 官方說明。 DataModel Mahout 的推薦引擎實際接受的輸入是 DataModel，它是對用戶偏好數據的壓縮表示，經過建立內存版 DataModel 的語句咱們能夠看出： DataModel model = new GenericDataModel(FastByIDMap<PreferenceArray> map); 他保存在一個按照用戶 ID 或者物品 ID 進行散列的 PreferenceArray，而 PreferenceArray 中對應保存着這個用戶 ID 或者物品 ID 的全部用戶偏好信息。 DataModel 是用戶喜愛信息的抽象接口，它的具體實現支持從任意類型的數據源抽取用戶喜愛信息，具體實現包括內存版的 GenericDataModel，支持文件讀取的 FileDataModel 和支持數據庫讀取的 JDBCDataModel，下面咱們看看如何建立各類 DataModel。

清單 2. 建立各類 DataModel

 //In-memory DataModel - GenericDataModel 
 FastByIDMap<PreferenceArray> preferences = new FastByIDMap<PreferenceArray>(); 

 PreferenceArray prefsForUser1 = new GenericUserPreferenceArray(10);  
 prefsForUser1.setUserID(0, 1L); 
 prefsForUser1.setItemID(0, 101L); 
 prefsForUser1.setValue(0, 3.0f);  
 prefsForUser1.setItemID(1, 102L); 
 prefsForUser1.setValue(1, 4.5f); 
… (8 more) 
 preferences.put(1L, prefsForUser1);   //use userID as the key 
… (more users) 

 DataModel model = new GenericDataModel(preferences); 

 //File-based DataModel - FileDataModel 
 DataModel dataModel = new FileDataModel(new File("preferences.csv"); 

 //Database-based DataModel - MySQLJDBCDataModel 
 MysqlDataSource dataSource = new MysqlDataSource(); 
 dataSource.setServerName("my_user"); 
 dataSource.setUser("my_password"); 
 dataSource.setPassword("my_database_host"); 
 JDBCDataModel dataModel = new MySQLJDBCDataModel(dataSource, "my_prefs_table", 
 "my_user_column", "my_item_column", "my_pref_value_column");

支持文件讀取的 FileDataModel，Mahout 沒有對文件的格式作過多的要求，只要文件的內容知足如下格式：

• 每一行包括用戶 ID, 物品 ID, 用戶偏好
• 逗號隔開或者 Tab 隔開
• *.zip 和 *.gz 文件會自動解壓縮（Mahout 建議在數據量過大時採用壓縮的數據存儲）

支持數據庫讀取的 JDBCDataModel，Mahout 提供一個默認的 MySQL 的支持，它對用戶偏好數據的存放有如下簡單的要求：

• 用戶 ID 列須要是 BIGINT 並且非空
• 物品 ID 列須要是 BIGINT 並且非空
• 用戶偏好列須要是 FLOAT

建議在用戶 ID 和物品 ID 上建索引。

實現推薦：Recommender

介紹完數據表示模型，下面介紹 Mahout 提供的協同過濾的推薦策略，這裏咱們選擇其中最經典的三種，User CF, Item CF 和 Slope One。 User CF 前面已經詳細介紹了 User CF 的原理，這裏咱們着重看怎麼基於 Mahout 實現 User CF 的推薦策略，咱們仍是從一個例子入手：

清單 3. 基於 Mahout 實現 User CF

 DataModel model = new FileDataModel(new File("preferences.dat")); 
 UserSimilarity similarity = new PearsonCorrelationSimilarity(model); 
 UserNeighborhood neighborhood = new NearestNUserNeighborhood(100, similarity, model); 
 Recommender recommender = new GenericUserBasedRecommender(model, 
 neighborhood, similarity);

1. 從文件創建 DataModel，咱們採用前面介紹的 FileDataModel，這裏假設用戶的喜愛信息存放在 preferences.dat 文件中。
2. 基於用戶偏好數據計算用戶的類似度，清單中採用的是 PearsonCorrelationSimilarity，前面章節曾詳細介紹了各類計算類似度的方法，Mahout 中提供了基本的類似度的計算，它們都 UserSimilarity 這個接口，實現用戶類似度的計算，包括下面這些經常使用的：

• PearsonCorrelationSimilarity：基於皮爾遜相關係數計算類似度
• EuclideanDistanceSimilarity：基於歐幾里德距離計算類似度
• TanimotoCoefficientSimilarity：基於 Tanimoto 係數計算類似度
• UncerteredCosineSimilarity：計算 Cosine 類似度

ItemSimilarity 也是相似的：

1. 根據創建的類似度計算方法，找到鄰居用戶。這裏找鄰居用戶的方法根據前面咱們介紹的，也包括兩種：「固定數量的鄰居」和「類似度門檻鄰居」計算方法，Mahout 提供對應的實現：
   • NearestNUserNeighborhood：對每一個用戶取固定數量 N 的最近鄰居
   • ThresholdUserNeighborhood：對每一個用戶基於必定的限制，取落在類似度門限內的全部用戶爲鄰居。
2. 基於 DataModel，UserNeighborhood 和 UserSimilarity 構建 GenericUserBasedRecommender，實現 User CF 推薦策略。

Item CF 瞭解了 User CF，Mahout Item CF 的實現與 User CF 相似，是基於 ItemSimilarity，下面咱們看實現的代碼例子，它比 User CF 更簡單，由於 Item CF 中並不須要引入鄰居的概念：

清單 4. 基於 Mahout 實現 Item CF

 DataModel model = new FileDataModel(new File("preferences.dat")); 
 ItemSimilarity similarity = new PearsonCorrelationSimilarity(model); 
 Recommender recommender = new GenericItemBasedRecommender(model, similarity);

Slope One 如前面介紹的，User CF 和 Item CF 是最經常使用最容易理解的兩種 CF 的推薦策略，但在大數據量時，它們的計算量會很大，從而致使推薦效率較差。所以 Mahout 還提供了一種更加輕量級的 CF 推薦策略：Slope One。 Slope One 是有 Daniel Lemire 和 Anna Maclachlan 在 2005 年提出的一種對基於評分的協同過濾推薦引擎的改進方法，下面簡單介紹一下它的基本思想。 圖 5 給出了例子，假設系統對於物品 A，物品 B 和物品 C 的平均評分分別是 3，4 和 4。基於 Slope One 的方法會獲得如下規律：

• 用戶對物品 B 的評分 = 用戶對物品 A 的評分 + 1
• 用戶對物品 B 的評分 = 用戶對物品 C 的評分

基於以上的規律，咱們能夠對用戶 A 和用戶 B 的打分進行預測：

• 對用戶 A，他給物品 A 打分 4，那麼咱們能夠推測他對物品 B 的評分是 5，對物品 C 的打分也是 5。
• 對用戶 B，他給物品 A 打分 2，給物品 C 打分 4，根據第一條規律，咱們能夠推斷他對物品 B 的評分是 3；而根據第二條規律，推斷出評分是 4。當出現衝突時，咱們能夠對各類規則獲得的推斷進行就平均，因此給出的推斷是 3.5。

這就是 Slope One 推薦的基本原理，它將用戶的評分之間的關係看做簡單的線性關係： Y = mX + b; 當 m = 1 時就是 Slope One，也就是咱們剛剛展現的例子。

圖 5.Slope One 推薦策略示例

Slope One 的核心優點是在大規模的數據上，它依然能保證良好的計算速度和推薦效果。Mahout 提供了 Slope One 推薦方法的基本實現，實現代碼很簡單，參考清單 5.

清單 5. 基於 Mahout 實現 Slope One

 //In-Memory Recommender 
 DiffStorage diffStorage = new MemoryDiffStorage(model, Weighting.UNWEIGHTED, false, 
 Long.MAX_VALUE)); 
 Recommender recommender = new SlopeOneRecommender(model, Weighting.UNWEIGHTED, 
 Weighting.UNWEIGHTED, diffStorage);  

 //Database-based Recommender 
 AbstractJDBCDataModel model = new MySQLJDBCDataModel(); 
 DiffStorage diffStorage = new MySQLJDBCDiffStorage(model); 
 Recommender recommender = new SlopeOneRecommender(model, Weighting.WEIGHTED, 
 Weighting.WEIGHTED, diffStorage);

1. 根據 Data Model 建立數據之間線性關係的模型 DiffStorage。 2. 基於 Data Model 和 DiffStorage 建立 SlopeOneRecommender，實現 Slope One 推薦策略。

總結

---

 

Web2.0 的一個核心思想就是「集體智慧」，基於協同過濾的推薦策略的基本思想就是基於大衆行爲，爲每一個用戶提供個性化的推薦，從而使用戶能更快速更準確的發現所需 要的信息。從應用角度分析，現今比較成功的推薦引擎，好比 Amazon，豆瓣，噹噹等都採用了協同過濾的方式，它不須要對物品或者用戶進行嚴格的建模，並且不要求物品的描述是機器可理解的，是中領域無關的推薦方 法，同時這個方法計算出來的推薦是開放的，能夠共用他人的經驗，很好的支持用戶發現潛在的興趣偏好。基於協同過濾的推薦策略也有不一樣的分支，它們有不一樣的 實用場景和推薦效果，用戶能夠根據本身應用的實際狀況選擇合適的方法，異或組合不一樣的方法獲得更好的推薦效果。 除此以外，本文還介紹瞭如何基於 Apache Mahout 高效實現協同過濾推薦算法，Apache Mahout 關注海量數據上的機器學習經典算法的高效實現，其中對基於協同過濾的推薦方法也提供了很好的支持，基於 Mahout 你能夠輕鬆的體驗高效推薦的神奇。 做爲深刻推薦引擎相關算法的第一篇文章，本文深刻介紹了協同過濾算法，並舉例介紹瞭如何基於 Apache Mahout 高效實現協同過濾推薦算法，Apache Mahout 做爲海量數據上的機器學習經典算法的高效實現，其中對基於協同過濾的推薦方法也提供了很好的支持，基於 Mahout 你能夠輕鬆的體驗高效推薦的神奇。但咱們也發現了在海量數據上高效的運行協同過濾算法以及其餘推薦策略這樣高複雜的算法仍是有很大的挑戰的。在面對這個問 題的過程當中，你們提出了不少減小計算量的方法，而聚類無疑是其中最優的選擇。因此本系列的下一篇文章將詳細介紹各種聚類算法，它們的原理，優缺點和實用場 景，並給出基於 Apache Mahout 的聚類算法的高效實現，並分析在推薦引擎的實現中，如何經過引入聚類來解決大數據量形成的海量計算，從而提供高效的推薦。 最後，感謝你們對本系列的關注和支持。