基于协同过滤的推荐算法及代码实现.doc

基于协同过滤的推荐算法及代码实现.doc

《基于协同过滤的推荐算法及代码实现.doc》由会员分享，可在线阅读，更多相关《基于协同过滤的推荐算法及代码实现.doc（34页珍藏版）》请在冰豆网上搜索。

基于协同过滤的推荐算法与代码实现

什么是协同过滤？

协同过滤是利用集体智慧的一个典型方法。

要理解什么是协同过滤 （CollaborativeFiltering, 简称 CF），首先想一个简单的问题，如果你现在想看个电影，但你不知道具体看哪部，你会怎么做？

大部分的人会问问周围的朋友，看看最近有什么好看的电影推荐，而我们一般更倾向于从口味比较类似的朋友那里得到推荐。

这就是协同过滤的核心思想。

协同过滤一般是在海量的用户中发掘出一小部分和你品位比较类似的，在协同过滤中，这些用户成为邻居，然后根据他们喜欢的其他东西组织成一个排序的目录作为推荐给你。

当然其中有一个核心的问题：

如何确定一个用户是不是和你有相似的品位？

如何将邻居们的喜好组织成一个排序的目录？

简单来说：

1.和你兴趣合得来的朋友喜欢的，你也很有可能喜欢；

2.喜欢一件东西A，而另一件东西B 与这件十分相似，就很有可能喜欢B；

3.大家都比较满意的，人人都追着抢的，我也就很有可能喜欢。

三者均反映在协同过滤的评级（rating）或者群体过滤（socialfiltering）这种行为特性上。

深入协同过滤的核心

首先，要实现协同过滤，需要一下几个步骤：

1.收集用户偏好

2.找到相似的用户或物品

3.计算推荐

（1）收集用户偏好

要从用户的行为和偏好中发现规律，并基于此给予推荐，如何收集用户的偏好信息成为系统推荐效果最基础的决定因素。

用户有很多方式向系统提供自己的偏好信息，而且不同的应用也可能大不相同，下面举例进行介绍：

以上列举的用户行为都是比较通用的，推荐引擎设计人员可以根据自己应用的特点添加特殊的用户行为，并用他们表示用户对物品的喜好。

在一般应用中，我们提取的用户行为一般都多于一种，关于如何组合这些不同的用户行为，基本上有以下两种方式：

将不同的行为分组：

一般可以分为“查看”和“购买”等等，然后基于不同的行为，计算不同的用户/物品相似度。

类似于当当网或者Amazon 给出的“购买了该图书的人还购买了 ...”，“查看了图书的人还查看了 ...”

根据不同行为反映用户喜好的程度将它们进行加权，得到用户对于物品的总体喜好。

一般来说，显式的用户反馈比隐式的权值大，但比较稀疏，毕竟进行显示反馈的用户是少数；同时相对于“查看”，“购买”行为反映用户喜好的程度更大，但这也因应用而异。

收集了用户行为数据，我们还需要对数据进行一定的预处理，其中最核心的工作就是：

减噪和归一化。

减噪：

用户行为数据是用户在使用应用过程中产生的，它可能存在大量的噪音和用户的误操作，我们可以通过经典的数据挖掘算法过滤掉行为数据中的噪音，这样可以是我们的分析更加精确。

归一化：

如前面讲到的，在计算用户对物品的喜好程度时，可能需要对不同的行为数据进行加权。

但可以想象，不同行为的数据取值可能相差很大，比如，用户的查看数据必然比购买数据大的多，如何将各个行为的数据统一在一个相同的取值范围中，从而使得加权求和得到的总体喜好更加精确，就需要我们进行归一化处理。

最简单的归一化处理，就是将各类数据除以此类中的最大值，以保证归一化后的数据取值在 [0,1] 范围中。

进行的预处理后，根据不同应用的行为分析方法，可以选择分组或者加权处理，之后我们可以得到一个用户偏好的二维矩阵，一维是用户列表，另一维是物品列表，值是用户对物品的偏好，一般是 [0,1] 或者 [-1,1] 的浮点数值。

（2）找到相似的用户或物品

当已经对用户行为进行分析得到用户喜好后，我们可以根据用户喜好计算相似用户和物品，然后基于相似用户或者物品进行推荐，这就是最典型的CF 的两个分支：

基于用户的CF 和基于物品的CF。

这两种方法都需要计算相似度，下面我们先看看最基本的几种计算相似度的方法。

相似度的计算

关于相似度的计算，现有的几种基本方法都是基于向量（Vector）的，其实也就是计算两个向量的距离，距离越近相似度越大。

在推荐的场景中，在用户-物品偏好的二维矩阵中。

我们可以将一个用户对所有物品的偏好作为一个向量来计算用户的相似度；或者将所有用户对某个物品的偏好作为一个向量来计算物品之间的相似度。

下面我们详细介绍几种常用的相似度计算方法：

相似邻居的计算

介绍完相似度的计算方法，下面我们看看如何根据相似度找到用户- 物品的邻居，常用的挑选邻居的原则可以分为两类：

下图给出了二维平面空间上点集的示意图。

固定数量的邻居：

K-neighborhoods 或者Fix-sizeneighborhoods

不论邻居的“远近”，只取最近的K 个，作为其邻居。

如上图中的A，假设要计算点1 的5-邻居，那么根据点之间的距离，我们取最近的5 个点，分别是点2，点3，点4，点7 和点5。

但很明显我们可以看出，这种方法对于孤立点的计算效果不好，因为要取固定个数的邻居，当它附近没有足够多比较相似的点，就被迫取一些不太相似的点作为邻居，这样就影响了邻居相似的程度，比如上图中，点1 和点5 其实并不是很相似。

基于相似度门槛的邻居：

Threshold-basedneighborhoods

与计算固定数量的邻居的原则不同，基于相似度门槛的邻居计算是对邻居的远近进行最大值的限制，落在以当前点为中心，距离为K 的区域中的所有点都作为当前点的邻居，这种方法计算得到的邻居个数不确定，但相似度不会出现较大的误差。

如上图中的B，从点1 出发，计算相似度在K 内的邻居，得到点2，点3，点4 和点7，这种方法计算出的邻居的相似度程度比前一种好，尤其是对孤立点的处理。

（3）计算推荐

经过前期的计算已经得到了相邻用户和相邻物品，下面介绍如何基于这些信息为用户进行推荐。

本系列的上一篇综述文章已经简要介绍过基于协同过滤的推荐算法可以分为基于用户的CF 和基于物品的CF，下面我们深入这两种方法的计算方法，使用场景和优缺点。

基于用户的CF（UserCF）

基于用户的CF 的基本思想相当简单，基于用户对物品的偏好找到相邻邻居用户，然后将邻居用户喜欢的推荐给当前用户。

计算上，就是将一个用户对所有物品的偏好作为一个向量来计算用户之间的相似度，找到K 邻居后，根据邻居的相似度权重以及他们对物品的偏好，预测当前用户可能喜欢的物品，计算得到一个排序的物品列表作为推荐（排序列表中每个物品都有相应的预测值）。

下图给出了一个例子，对于用户A，根据用户的历史偏好，这里只计算得到一个邻居用户C，然后将用户C 喜欢的物品D 推荐给用户A。

基于物品的CF（ItemCF）

基于物品的CF 的原理和基于用户的CF 类似，只是在计算邻居时采用物品本身，而不是从用户的角度，即基于用户对物品的偏好找到相似的物品，然后根据用户的历史偏好，推荐相似的物品给他。

从计算的角度看，就是将所有用户对某个物品的偏好作为一个向量来计算物品之间的相似度，得到物品的相似物品后，根据用户历史的偏好预测当前用户还没有表示偏好的物品，计算得到一个排序的物品列表作为推荐。

下图给出了一个例子，对于物品A，根据所有用户的历史偏好，喜欢物品A 的用户都喜欢物品C，得出物品A 和物品C 比较相似，而用户C 喜欢物品A，那么可以推断出用户C 可能也喜欢物品C。

UserCFvsItemCF

前面介绍了UserCF 和ItemCF 的基本原理，下面我们分几个不同的角度深入看看它们各自的优缺点和适用场景：

计算复杂度

ItemCF和UserCF 是基于协同过滤推荐的两个最基本的算法，UserCF 是很早以前就提出来了，ItemCF 是从Amazon 的论文和专利发表之后（2001 年左右）开始流行，大家都觉得ItemCF 从性能和复杂度上比UserCF 更优，其中的一个主要原因就是对于一个在线网站，用户的数量往往大大超过物品的数量，同时物品的数据相对稳定，因此计算物品的相似度不但计算量较小，同时也不必频繁更新。

但我们往往忽略了这种情况只适应于提供商品的电子商务网站，对于新闻，博客或者微内容的推荐系统，情况往往是相反的，物品的数量是海量的，同时也是更新频繁的，所以单从复杂度的角度，这两个算法在不同的系统中各有优势，推荐引擎的设计者需要根据自己应用的特点选择更加合适的算法。

适用场景

在非社交网络的网站中，内容内在的联系是很重要的推荐原则，它比基于相似用户的推荐原则更加有效。

比如在购书网站上，当你看一本书的时候，推荐引擎会给你推荐相关的书籍，这个推荐的重要性远远超过了网站首页对该用户的综合推荐。

可以看到，在这种情况下，ItemCF 的推荐成为了引导用户浏览的重要手段。

同时ItemCF 便于为推荐做出解释，在一个非社交网络的网站中，给某个用户推荐一本书，同时给出的解释是某某和你有相似兴趣的人也看了这本书，这很难让用户信服，因为用户可能根本不认识那个人；但如果解释说是因为这本书和你以前看的某本书相似，用户可能就觉得合理而采纳了此推荐。

相反的，在现今很流行的社交网络站点中，UserCF 是一个更不错的选择，UserCF 加上社会网络信息，可以增加用户对推荐解释的信服程度。

推荐多样性和精度

研究推荐引擎的学者们在相同的数据集合上分别用UserCF 和ItemCF 计算推荐结果，发现推荐列表中，只有50% 是一样的，还有50% 完全不同。

但是这两个算法居然有相似的精度，所以可以说，这两个算法是很互补的。

关于推荐的多样性，有两种度量方法：

第一种度量方法是从单个用户的角度度量，就是说给定一个用户，查看系统给出的推荐列表是否多样，也就是要比较推荐列表中的物品之间两两的相似度，不难想到，对这种度量方法，ItemCF 的多样性显然不如UserCF 的好，因为ItemCF 的推荐就是和以前看的东西最相似的。

第二种度量方法是考虑系统的多样性，也被称为覆盖率 （Coverage），它是指一个推荐系统是否能够提供给所有用户丰富的选择。

在这种指标下，ItemCF 的多样性要远远好于UserCF, 因为UserCF 总是倾向于推荐热门的，从另一个侧面看，也就是说，ItemCF 的推荐有很好的新颖性，很擅长推荐长尾里的物品。

所以，尽管大多数情况，ItemCF 的精度略小UserCF，但如果考虑多样性，ItemCF 却比UserCF 好很多。

如果你对推荐的多样性还心存疑惑，那么下面我们再举个实例看看 UserCF 和ItemCF 的多样性到底有什么差别。

首先，假设每个用户兴趣爱好都是广泛的，喜欢好几个领域的东西，不过每个用户肯定也有一个主要的领域，对这个领域会比其他领域更加关心。

给定一个用户，假设他喜欢3 个领域A、B、C，A 是他喜欢的主要领域，这个时候我们来看UserCF 和ItemCF 倾向于做出什么推荐：

如果用UserCF, 它会将A,B,C 三个领域中比较热门的东西推荐给用户；而如果用ItemCF，它会基本上只推荐A 领域的东西给用户。

所以我们看到因为UserCF 只推荐热门的，所以它在推荐长尾里项目方面的能力不足；而ItemCF 只推荐A 领域给用户，这样他有限的推荐列表中就可能包含了一定数量的不热门的长尾物品，同时ItemCF 的推荐对这个用户而言，显然多样性不足。

但是对整个系统而言，因为不同的用户的主要兴趣点不同，所以系统的覆盖率会比较好。

从上面的分析，可以很清晰的看到，这两种推荐都有其合理性，但都不是最好的选择，因此他们的精度也会有损失。

其实对这类系统的最好选择是，如果系统给这个用户推荐30 个物品，既不是每个领域挑选10 个最热门的给他，也不是推荐30 个A 领域的给他，而是比如推荐15 个A 领域的给他，剩下的15 个从B,C 中选择。

所以结合UserCF 和ItemCF 是最优的选择，结合的基本原则就是当采用ItemCF 导致系统对个人推荐的多