推薦系統的初體驗（關聯規則，協同過濾）

最近接觸了一個推薦系統的建設項目，於是我順便回顧了一下之前零星學到的推薦知識，把一些困惑很久的問題弄明白了，所以來總結一下。

一般意義下的推薦系統是指個性化推薦，類似簡單的排行榜推薦或者關聯規則推薦被認爲是不夠個性化的。不過我困惑的問題也正在於這裏，所以我來描述一下關聯規則和協同過濾這兩個典型的推薦方法。

關聯規則是數據挖掘中的典型問題之一，又被稱爲購物籃分析，這是因爲傳統的關聯規則案例大多發生在超市中，例如所謂的啤酒與尿布傳說。事實上，“購物籃”這個詞也揭示了關聯規則挖掘的一個重要特點：以交易記錄爲研究對象，每一個購物籃（transaction）就是一條記錄。關聯規則希望挖掘的規則就是：哪些商品會經常在同一個購物籃中出現，其中有沒有因果關係。爲了描述這種“經常性”及“因果關係”，分析者定義了幾個指標，基於這些指標來篩選關聯規則，從而得到那些不平凡的規律。主要的指標包括：支持度support，置信度confidence，提升度lift。對於一個二項規則例如“A→B”，支持度是指A與B同時出現的概率，即P(A B)；置信度是B關於A的條件概率，即P(B | A)；提升度是B的概率的提升，即P(B | A) / P(B)。比較常見的例子是：

這些指標都很容易理解，他們在一定程度上保證了挖掘出來的規則的實用性。

儘管用來做關聯規則的Apriori算法被譽爲數據挖掘十大算法之一，我仍然曾經因爲覺得關聯規則如此簡單明白而忽視其實踐意義。尤其是在我知道協同過濾之後。

協同過濾也是很典型的推薦技術，他構造一個用戶與項目之間的關聯打分矩陣，像是這樣

打分矩陣很好地體現出協同的概念，其中的Ui代表了用戶，Ti代表了項目，相應位置的數值表示了用戶對項目的打分，有些情況下沒有具體分值的，通常用0/1來表示未購買與已購買（豆瓣電臺估計得是-1/0/1這樣的編碼）。協同過濾的基本想法就是根據相似性來做推薦，這可以分爲兩類：基於用戶相似性的推薦和基於項目相似性的推薦。這兩種推薦的假設基礎分別是：相似的用戶對同一個項目會有相似的偏好，同一個用戶對相似的項目會有相似的偏好。因此從計算的角度就是對上述的打分矩陣分別按行和按列計算相似度。

基於用戶的協同過濾可以簡單地通過對用戶的聚類以及KNN等方法實現，若U1與U2被歸爲一類，或者U2是距離U1最近的用戶，則向U1推薦U1沒購買過而U2已購買過的項目。當然這裏更標準的做法是計算用戶之間的相似度（用相關係數和歐氏距離等等的指標來衡量），然後根據相似度進行加權求和，得到每個用戶對每個項目的推薦得分。類似地，基於項目的協同過濾則是計算項目之間的相似度矩陣，像是這樣

然後可以根據原始的打分矩陣和這個相似度矩陣，來做一個類似加權求和的工作（其實就是矩陣相乘），得到每個用戶對每個項目的推薦得分。例如，U1對T2的推薦得分，就是（1,0,0,1）*（2,1,1,1）=（1*2 + 0*1 + 0*1 + 1*1）=3。這個例子中沒有涉及具體打分（只有0/1編碼），項目之間相似度的計算也比較簡單（距離公式和相關係數的定義有多種多樣複雜無比，並且還需要做一些標準化之類的處理），僅僅作爲例子來說明一下基於項目相似性來計算偏好的一種方法。

由於我對這兩種技術的學習都比較淺，所以存在很多困惑的地方，前段時間也跟老段交流過。主要的問題就在於：關聯規則跟協同過濾的相通點在什麼地方。（貌似我很喜歡探索這種問題，例如做信用評分模型的變量轉換時，用dummy變量跟用WOE編碼有何相通之處，以及WOE跟零售推薦裏的NRS的相似之處，這個等我弄明白了再總結吧。）

由於我上面協同過濾的這個例子太特殊，所以把關聯規則給混淆進來了。因爲其中計算項目相似度的方法跟關聯規則裏面的支持度support很類似，無非是數一下兩個項目同時出現的概率或次數，於是我就認爲關聯規則的本質也是在計算項目之間的相似度，於是我就把關聯規則理解爲一種特殊的協同過濾了。囧。

事實上今天我考慮了一下，這兩種方法確實還是有很大的不同。從形式上講，當然我忽略了關聯規則裏面的其他一些指標。從更接近本質的觀點來看，這兩種方法的出發點和邏輯思路也是截然不同的。一般地，關聯規則被劃分爲動態推薦，而協同過濾則更多地被視爲靜態推薦。

所謂動態推薦，我的理解是：推薦的基礎是且只是當前一次（最近一次）的購買或者點擊。譬如我在網站上看了一個趙麗蓉老師的小品，系統就找到與這個小品相關的關聯規則，然後根據這個規則向我進行推薦（例如趙麗蓉老師的另外一個小品="=）。而靜態推薦則是在對用戶進行了一定分析的基礎上，建立了這個用戶在一定時期內的偏好排序，然後在這段時期內持續地按照這個排序來進行推薦。

由此可見，關聯規則與協同過濾的策略思路是完全不同的類型。而造成這種差異的原因，則在於這兩種方法所面對的對象的性質的不同——關聯規則面向的是transaction，而協同過濾面向的是ID。關聯規則典型地是面向超市零售，在會員制度尚不完善的階段，沒辦法得到每個用戶的購買情況，而只能分析交易數據（小票），因此也就沒有“用戶偏好”這個概念，而只能從小票中分析出一些頻繁的關聯項，也因此關聯規則做推薦時無法應用用戶歷史數據，而只能基於當前的購買情況來做推薦，也因此關聯規則原本就不是跟推薦系統掛在一起，而是更多地強調交叉銷售。

但是這並不影響關聯規則在很多場合都具有良好的實踐效果，例如老段做的那個彩鈴推薦。事實上，即便在當下很多能夠拿到用戶ID的場景，使用動態的關聯規則推薦仍然是值得考慮的一種方法（尤其是我們經常把很多推薦方法的結果綜合起來做一個混合的推薦），因爲這種方法的邏輯思路跟協同過濾有着本質的不同，問題似乎僅僅在於：個人的偏好到底有多穩定，推薦到底是要迎合用戶的長期偏好還是用戶的當下需求。

當然啦，這兩種方法也有能夠結合在一起的機會（不是簡單地對推薦結果做並集），有助於應用關聯規則的一些良好性質在一定程度上彌補協同過濾的不足。IBM就介紹了這樣一種方法，主要的策略是用關聯規則來計算項目相似度，然後再應用基於項目相似性的協同過濾技術。在這種情況下，項目距離矩陣就不再是對稱的了，因爲關聯規則具有方向性。

這就是我的推薦系統初體驗了，可以算是基本瞭解了兩種方法的區別。

今天沒有代碼——（要麼參考一下阿穩《可能是史上代碼最少的協同過濾推薦引擎》）——所以從微博抄個笑話吧。

“個人覺得現在的數據挖掘做的很爛，我在網上買了一個鍋，結果下面推薦的都是鍋，同志，我已經買了一個了還這麼迫切的想買第二個麼？”

打完收工。