Slope one

Slope One 是一系列應用於協同過濾的演算法的統稱。由 Daniel Lemire 和 Anna Maclachlan 於 2005 年發表的論文中提出。 有爭議的是，該演算法堪稱基於專案評價的 non-trivial 協同過濾演算法最簡潔的形式。該系列演算法的簡潔特性使它們的實現簡單而高效，而且其精確度與其它複雜費時的演算法相比也不相上下。 . 該系列演算法也被用來改進其它演算法。.

協同過濾簡介及其主要優缺點

協同過濾推薦（Collaborative Filtering recommendation）在資訊過濾和資訊系統中正迅速成為一項很受歡迎的技術。與傳統的基於內容過濾直接分析內容進行推薦不同，協同過濾分析使用者興趣，在使用者群中找到指定使用者的相似（興趣）使用者，綜合這些相似使用者對某一資訊的評價，形成系統對該指定使用者對此資訊的喜好程度預測。

與傳統文字過濾相比，協同過濾有下列優點:

能夠過濾難以進行機器自動基於內容分析的資訊。如藝術品、音樂。
能夠基於一些複雜的，難以表達的概念（資訊質量、品位) 進行過濾。
推薦的新穎性。

儘管協同過濾技術在個性化推薦系統中獲得了極大的成功，但隨著站點結構、內容的複雜度和使用者人數的不斷增加，協同過濾技術的一些缺點逐漸暴露出來。

主要有以下三點:

稀疏性 (sparsity)：在許多推薦系統中，每個使用者涉及的資訊量相當有限，在一些大的系統如亞馬遜網站中，使用者最多不過就評估了上百萬本書的 1%~2%。造成評估矩陣資料相當稀疏，難以找到相似使用者集，導致推薦效果大大降低。
擴充套件性 (scalability)：“最近鄰居” 演算法的計算量隨著使用者和項的增加而大大增加，對於上百萬之巨的數目，通常的演算法將遭遇到嚴重的擴充套件性問題。
精確性 (accuracy)：透過尋找相近使用者來產生推薦集，在數量較大的情況下，推薦的可信度隨之降低。

Item-based 協同過濾 和 過適

當可以對一些專案評分的時候，比如人們可以對一些東西給出 1 到 5 星的評價的時候，協同過濾意圖基於一個個體過去對某些專案的評分和（龐大的）由其他使用者的評價構成的資料庫，來預測該使用者對未評價專案的評分。

例如：如果一個人給披頭士的評分為 5（總分 5）的話，我們能否預測他對席琳狄翁新專輯的評分呢？

這種情形下，item-based 協同過濾系統根據其它專案的評分來預測某專案的分值，一般方法為 線性迴歸 . 於是，需要列出 x^2 個線性迴歸方程和 2x^2 個迴歸量，例如：當有 1000 個專案時，需要列多達 1,000,000 個線性迴歸方程， 以及多達 2,000,000 個迴歸量。除非我們只選擇某些使用者共同評價過的專案對，否則協同過濾會遇到過適 (過擬合) 問題。

另外一種更好的方法是使用更簡單一些的式子，比如 ：實驗證明當使用一半的迴歸量的時候，該式子（稱為 Slope One）的表現有時優於線性迴歸方程。該簡化方法也不需要那麼多儲存空間和延遲。

Item-based 協同過濾只是 協同過濾的一種形式。其它還有像 user-based 協同過濾一樣研究使用者間的聯絡的過濾系統。但是，考慮到其他使用者數量龐大，item-based 協同過濾更可行一些。

電子商務中的 Item-based 協同過濾

人們並不總是能給出評分，當用戶只提供二進位制資料（購買與否）的時候，就無法應用 Slope One 和其它基於評分的演算法。

二進位制 item-based 協同過濾應用的例子之一就是 Amazon 的 item-to-item 專利演算法，該演算法中用二進位制向量表示使用者 - 專案購買關係的矩陣，並計算二進位制向量間的 cosine 相關係數。

有人認為 Item-to-Item 演算法甚至比 Slope One 還簡單，例如：

在本例當中，專案 1 和專案 2 間的 cosine 相關係數為：

,

專案 1 和專案 3 間的 cosine 相關係數為：

,

而專案 2 和專案 3 的 cosine 相關係數為：

.

於是，瀏覽專案 1 的顧客會被推薦買專案 3 (兩者相關係數最大), 而瀏覽專案 2 的顧客會被推薦買專案 3, 瀏覽了專案 3 的會首先被推薦買專案 1（再然後是專案 2, 因為 2 和 3 的相關係數小於 1 和 3）。該模型只使用了每對專案間的一個引數（cosine 相關係數）來產生推薦。因此，如果有 n 個專案，則需要計算和儲存 n（n-1）/2 個 cosine 相關係數。

Slope One 協同過濾

為了大大減少過適 (過擬合) 的發生，提升演算法簡化實現， Slope One 系列易實現的 Item-based 協同過濾演算法被提了出來。本質上，該方法運用更簡單形式的迴歸表示式 和單一的自由引數，而不是一個專案評分和另一個專案評分間的線性迴歸 。 該自由引數只不過就是兩個專案評分間的平均差值。甚至在某些例項當中，它比線性迴歸的方法更準確，而且該演算法只需要一半（甚至更少）的儲存量。

Image:Simplicity_diagram.png

例:

User A 對 Item I 評分為 1 對 Item J. 評分為 1.5
User B 對 Item I 評分為 2.

你認為 User B 會給 Item J 打幾分？* Slope One 的答案是：2.5 (1.5-1+2=2.5).

舉個更實際的例子，考慮下表：

在本例中，專案 2 和 1 之間的平均評分差值為 (2+(-1))/2=0.5. 因此，item1 的評分平均比 item2 高 0.5。同樣的，專案 3 和 1 之間的平均評分差值為 3。因此，如果我們試圖根據 Lucy 對專案 2 的評分來預測她對專案 1 的評分的時候，我們可以得到 2+0.5 = 2.5。同樣，如果我們想要根據她對專案 3 的評分來預測她對專案 1 的評分的話，我們得到 5+3=8.

如果一個使用者已經評價了一些專案，可以這樣做出預測：簡單地把各個專案的預測透過加權平均值結合起來。當用戶兩個專案都評價過的時候，權值就高。在上面的例子中，專案 1 和專案 2 都評價了的使用者數為 2, 專案 1 和專案 3 都評價了的使用者數為 1, 因此權重分別為 2 和 1.

我們可以這樣預測 Lucy 對專案 1 的評價：

於是，對 “n” 個專案，想要實現 Slope One，只需要計算並存儲 “n” 對評分間的平均差值和評價數目即可。

Slope One 的演算法複雜度

設有 “n” 個專案，“m” 個使用者，“N” 個評分。計算每對評分之間的差值需要 n (n-1)/2 單位的儲存空間，最多需要 m n2 步。計算量也有可能挺悲觀的：假設使用者已經評價了最多 y 個專案，那麼計算不超過 n2+my2 個專案間計算差值是可能的。 .

如果一個使用者已經評價過 “x” 個專案，預測單一的專案評分需要 “x” 步，而對其所有未評分專案做出評分預測需要最多 (n-x) x 步.

當一個使用者已經評價過 “x” 個專案時，當該使用者新增一個評價時，更新資料庫需要 x 步.

可以透過分割資料（參照分割和稀疏儲存（沒有共同評價專案的使用者可以被忽略）) 來降低儲存要求，

應用 Slope One 的推薦系統

hitflip DVD 推薦系統
How Happy
inDiscover MP3 推薦系統
RACOFI Composer
Value Investing News 股票新聞網站
AllTheBests 購物推薦引擎