协同过滤（Collaborative Filtering）是现今推荐系统中应
用最为成熟的一个推荐算法系类，它利用兴趣相投、拥有共同经验之群体的喜好来推荐使用者感兴趣的资讯，个人透过合作的机制给予资讯相当程度的回应（如评分）并记录下来以达到过滤的目的进而帮助别人筛选资讯（参考wiki，文字有点生硬，不过却很好的描述了协同过滤的一个互动性：用户参与用户获益）。
边整理边写了整整一天o(╯□╰)o
一、背景
1.1 基本思想
简单来说：
- 和你兴趣合得来的朋友喜欢的，你也很有可能喜欢；
- 喜欢一件东西
A，而另一件东西 B 与这件十分相似，就很有可能喜欢 B； - 大家都比较满意的，人人都追着抢的，我也就很有可能喜欢。
三者均反映在协同过滤的评级（rating）或者群体过滤（social filtering）这种行为特性上。
1.2 相关研究组织
协同过滤上比较经典著名的组织商业有：
1.3 优缺点
优点：主要从使用者角度来看：
- 能够过滤机器难以自动内容分析的资讯，如艺术品，音乐等。也就是基于用户标识等，可以自动归类；
- 共用其他人的经验，避免了内容分析的不完全或不精确，并且能够基于一些复杂的，难以表述的概念（如资讯品质、个人品味）进行过滤，直接后天间接性继承前辈经验；
- 有推荐新资讯的能力。可以发现内容上完全不相似的资讯，使用者对推荐资讯的内容事先是预料不到的。可以发现使用者潜在的但自己尚未发现的兴趣偏好。（基于相似用户推荐很好的能做到）
- 推荐个性化、自动化程度高。能够有效的利用其他相似使用者的回馈资讯。加快个性化学习的速度。
缺点：主要从设计与实现的角度
- 新使用者问题(New User Problem)： 系统开始时推荐品质较差 ；
- 新项目问题(New Item Problem) ：品质取决于历史资料集 ；
- 稀疏性问题（Sparsity）：系统历史数据过少，难以进行精确的模式查找匹配推荐 ；
- 系统延伸性问题（Scalability）：新加User或者Item时，系统需要增加计算负荷量大。
1.4 对于当前推荐系统的问题的一些尝试解决
本小节参考《Toward the next generation of recommender systems: A survey of the state-of-the-art and possible extensions》的2.2节翻译。
新用户问题
为了使推荐系统更加准确，系统必须从用户的评分中学习用户的偏好，有许多方法尝试这方面研究，它们大多数使用混合推荐模型，包含了基于内容以及协同过滤推荐方法。另外的一种方法是挖掘一些条目提供给新用户来进行评级，以便快速学习用户的偏好。这些挖掘条目的技术是基于项目的流行度，项目的熵，用户个性化，以及以上技术的糅合。
新项目问题
新的项目会经常添加到推荐系统中，协同过滤基本上是通过用户的偏好进行推荐，这样，直到新的项目被足够数量的用户进行评级，推荐系统才有可能推荐它，这个问题同样是通过混合推荐方法来解决。
数据稀疏性
在许多推荐系统中，已经获得到的评级数据相比整个待预测的项只是很小的一部分，那么从一个很小的样例数据集中高效的预测评分是很重要的。同样推荐系统的成功在于拥有足够数量的用户，列于，在电影推荐系统中，有很多电影只被小部分用户评级，而且这些电影会很少被推荐，即使那小部分用户给予很高评级。同样，对于那些有着不同品味的小众群体，找不到相同特定同口味的用户，也导致较差的推荐结果了。
一个克服数据稀疏性问题的方法，是通过使用用户资料信息来计算用户相似度。也就是，两个用户会被认为相似不只单在相同的电影评级类似，而且也有可能属于同一个人口统计区块（demographic），比如，用户的性别，年龄，居住地，教育情况，工作信息。这种基于传统协同过滤的扩展方法称为demographic filtering。详见M. Pazzani, 《A Framework for Collaborative, Content-Based, and Demographic Filtering, Artificial Intelligence Rev》
另外的一个尝试在于挖掘被推荐出的用户之间的相似性，在客户的历史交易和反馈数据中，通过关联检索框架，以及相关传播扩散算法来发现客户间的可传递性关联。
另外的一个途径解决思路是，是通过一种降维技术（ dimensionality reduction ），奇异值分解（SVD:Singular Value Decomposition ）,来降低稀疏矩阵的维度。SVD是目前一个已知的矩阵分解技术，来为原始矩阵求的最好的低维近似。详见B. Sarwar, 的《Application of Dimensionality Reduction in Recommender Systems—A Case Study》
二、分类概述
2.1 推荐系统概况
协同过滤作为推荐系统中的一个主流方法途径，在推荐系统中所处地位是怎么样的呢，下面主要对推荐系统的方法类别进行介绍，从两种不同的角度上，推荐系统中方法技术分类主要有以下两种分类：
从研究对象方法上的一种分类
首先参考Adomavicius, G的论文《Toward the next generation of recommender systems: A survey of the state-of-the-art and possible extensions》
推荐系统中的总体方法有:
- 基于内容的推荐（Content-based recommendations）：系统会基于用户上次喜欢的一个项目推荐相似的项目；
- 协同过滤推荐（Collaborative recommendations）：基于寻找相同评为与偏好的人群进行推荐；
- 混合推荐（Hybrid approaches）：融合基于内容以及协同过滤推荐方法。
并且论文中总结的现状技术分类概述如下图：
从应用算法架构上分类
参考Carleton College, Northfield, MN.官方网站上：
- 启发式推荐算法（Memory-based algorithms）：是系统过滤思想中的一种算法，每次推荐都需要调用这整个评级数据库的内容，即对于一个用户，计算与其他所有其他用户的相似度，对于用户没有遇到的新项目，将会利用相似度权重及其他用户的评分加权预测当前用户对于这个新项目的潜在评分。但这种每次计算量过大
- 基于模型推荐算法（Model-based algorithms）：从评级数据集中建立一个模型，也就是从数据库中抽取一个模型数据，然后每次推荐都是基于模型数据进行计算并推荐，这样不用每次都调用整个数据库，提高了速度与系统伸缩性。大致包括：
- 关联规则算法（Association Rules）：关联规则尝试发现不同项目之间的因果关系，一个关键规则本质上是一种（A1,
A2, A3, … =>B1, B2, B3,…） 的形式，尝试展示一个序列决定另外的一个序列。主要由两部分组成：一个是关联决策，一个是对应的置信度。 - 关联决策：即如果A
=> B, C, 那么如果Item A出现在某人的历史记录里面，那么可以推断B和C也很可能出现在那里。 - 置信度：表明对应的关联决策有多么可靠，范围为[0, 1]的一个区间，如果置为1，那么说明上述决策总能成立，如果为0，表明这个决策从来不会正确。
- 关联决策：即如果A
2.2 协同过滤基本分类
协同过滤实际上与推荐系统中的其他方法是交织叠加的，没有一个明确的界限，推荐系统的方法尝试都有结合协同过滤的思想因素去实现，参考wiki百科中协同过滤大体可以分为三类：
- 基于用户协同过滤（User – based）：基于计算相似用户用以推荐
- 基于项目协同过滤（Item – based）：基于计算相似项目用以推荐
- 基于模型协同过滤（Model- based）：基于原始数据中抽取出模型，基于模型计算并用以推荐
三、协同过滤三大分类
3.1 基于用户协同过滤(User-based)
用相似统计的方法得到具有相似爱好或者兴趣的相邻使用者，最早是在1994年由来自美国Minnesota大学Paul Resnick等人发表的《GroupLens: An Open Architecture for Collaborative Filtering of Netnews》一文中提出的。
方法基本步骤
1. 收集使用者资讯
收集可以代表使用者兴趣的资讯。概括主要分为两类：
- 主动评分（显式评分）：基于用户的直接打分数据，如评分，喜爱等级，like/dislike
- 被动评分（隐式评分）：是根据使用者的行为模式由系统代替使用者完成评价，不需要使用者直接打分或输入评价资料，如电子商务中的购买记录，视频网站用户观看记录、收藏记录，甚至是评论文本观点意见挖掘等进行广泛深度的数据挖掘。
2. 最近邻搜索(Nearest neighbor search, NNS)
以使用者为基础（User-based）的协同过滤的出发点是与使用者兴趣爱好相同的另一组使用者，就是计算两个使用者的相似度。
例如：寻找n个和A有相似兴趣使用者，把他们对M的评分作为A对M的评分预测。一般会根据资料的不同选择不同的算法。
目前较多使用的相似度算法有：
- 皮尔森相关系数：Person Correlation Coefficient
- 余弦相似度：Cosine-based Similarity
- 矫正余弦相似度：Adjusted Cosine Similarity
3. 产生推荐结果
有了最近邻集合，就可以对目标使用者的兴趣进行预测，产生推荐结果。
依据推荐目的不同形式的推荐，较常见的推荐结果有Top-N 推荐和关联推荐。
- Top-N 推荐：是针对个体使用者产生，对每个人产生不一样的结果，例如：透过对A使用者的最近邻使用者进行统计，选择出现频率高且在A使用者的评分项目中不存在的，作为推荐结果。
- 关联推荐：对最近邻使用者的记录进行关联规则(association rules)挖掘。
优缺点
- 优点：在数据集完善，内容丰富下，准确率较高，而且能够避开项目内容上的挖掘进行准确推荐，对够对项目关联性，用户偏好进行隐式透明的挖掘。
- 缺点：随着使用者数量的增多，计算的时间就会变长，新用户问题，以及数据稀疏性问题是导致效率与伸缩性上均不足
3.2 基于项目协同过滤（Item-based）
鉴于基于用户的协同推荐算法随着使用者数量的增多，计算的时间就会变长，最早是在2001年由Sarwar提出了基于项目的协同过滤推荐算法《Item-based Collaborative Filtering Algorithms》中所提出的。
基于项目协同过滤在于透过计算项目之间的相似性来代替使用者之间的相似性。
所建立的一个基本的假设：”能够引起使用者兴趣的项目，必定与其之前评分高的项目相似”，通俗的来说：基本上喜欢《长尾理论》的人，都会去看《世界是平的》，不知道你怎么想，反正豆瓣推荐系统就是这么认为的。
方法步骤：
1. 收集使用者资讯
同以使用者为基础（User-based）的协同过滤。
2. 针对项目的最近邻搜索
先计算己评价项目和待预测项目的相似度，并以相似度作为权重，加权各已评价项目的分数，得到待预测项目的预测值。
例如：要对项目 A 和项目 B 进行相似性计算，要先找出同时对 A 和 B 打过分的组合，对这些组合进行相似度计算，常用的算法同基于使用者（User-based）的协同过滤。
3. 产生推荐结果
在用户使用评价一个商品感兴趣后，会自动搜寻改商品相似度最大的前N项条目。
优缺点：
优点：以项目为基础的协同过滤不用考虑使用者间的差别，所以精度比较差。但是却不需要使用者的历史资料，或是进行使用者识别。对于项目来讲，它们之间的相似性要稳定很多，因此可以离线完成工作量最大的相似性计算步骤，从而降低了线上计算量，提高推荐效率，尤其是在使用者多于项目的情形下尤为显著。
缺点：但其仍有许多问题需要解决，最典型的有稀疏问题(Sparsity)和冷启动问题(Cold-start)，开始时效果较差。此外还有新使用者问题和算法健壮性等问题。
3.3 基于模型的协同过滤（Model- based）
以使用者为基础（User-based）的协同过滤和以项目为基础（Item-based）的协同过滤统称为以记忆为基础（Memory based）的协同过滤技术，他们共有的缺点是资料稀疏，难以处理大数据量下的即时结果，因此发展出以模型为基础的协同过滤技术。
以模型为基础的协同过滤(Model-based Collaborative Filtering)是先用历史资料得到一个模型，再用此模型进行预测。以模型为基础的协同过滤广泛使用的技术包括Latent Semantic Indexing、Bayesian Networks…等，根据对一个样本的分析得到模型。
四、相似度计算算法
4.1 概述
相似度计算算法可以用于计算用户或者项目相似度。
以项目相似度计算（Item Similarity Computation）为列，通性在于都是从评分矩阵中，为两个项目i，j挑选出共同的评分用户，然对这个共同用户的评分向量，进行计算相似度si,j，
(注意到是从i，j向量中抽出共有的评论，组成的一对向量，进行相似度计算)，
-
- 皮尔森相关系数：Person Correlation Coefficient
- 余弦相似度：Cosine-based Similarity
- 矫正余弦相似度：Adjusted Cosine Similarity
4.2 皮尔森相关系数
皮尔森相关系数也是一种基于相关系数的相似度计算方法，一般为了使计算结果精确，需要找出共同评分的用户。
记用户集U为既评论了 i 又评论了 j 的用户集，那么对应的皮尔森相关系数计算公式为：
（其中Ru,i
4.3 余弦相似度
两个项目 i ，j 视作为两个m维用户空间向量，相似度计算通过计算两个向量的余弦夹角，那么，对于m*n的评分矩阵，i ，j 的相似度sim(
（其中 " · "记做两个向量的内积）
4.4 矫正余弦相似度
余弦相似度计算并没有考虑到不同的用户的评分尺度差异性，也就是说有的用户评分更宽容普遍打分较高，有的用户评分更严格，普遍打分较低。矫正余弦相似度正式为了克服这一缺点，通过求出每位用户的平均打分，调整评分向量为评分偏差向量，再进行求解余弦相似度。
（其中带横杠的为第u个用户的平均评分）
4.5 基于项目相似度与基于用户相似度的差异
上述三个相似度公式是基于项目相似度场景下的，而实际上，基于用户相似度与基于项目相似度计算的一个基本的区别是，基于用户相似度是基于评分矩阵中的行向量相似度求解，基于项目相似度计算式基于评分矩阵中列向量相似度求解，然后三个公式分别都可以适用，如下图：
（其中，为0的表示未评分）
- 基于项目相似度计算式计算如Item3，Item4两列向量相似度；
- 基于用户相似度计算式计算如User3，User4量行向量相似度。
最终的计算公式方法均相同。具体可具体参考《Toward the next generation of recommender systems: A survey of the state-of-the-art and possible extensions》2.2节
4.6 相似度计算不足与改进
基于评分矩阵相似度计算所面临的一个性能问题，数据稀疏下，精度很差，因为相似度计算是基于寻找拥有共同用户评分的项目或者共同项目评分的用户，在数据稀疏下，两个向量中空值过多，导致计算共同评分维度过低，甚至就没有共同评分。
对于数据稀疏性这种情况下，一个尝试的途径是进行对评分矩阵进行填充。
填充规则有很多，一种通用的方法是，填充均分，具体如下两种：
- 基于用户均分：填充对应用户的平均打分
- 基于项目均分：基于对应项目的平均打分
五、协同过滤敏捷实践
5.1 概述
首先参考Slope one的wiki百科的一段话（此章节按照Slope one的wiki百科重新整理）：
当可以对一些项目评分的时候，比如人们可以对一些东西给出1到5星的评价的时候，协同过滤意图基于一个个体过去对某些项目的评分和（庞大的）由其他用户的评价构成的数据库，来预测该用户对未评价项目的评分。
In this context, item-based 协同过滤系统[根据其它项目的评分来预测某项目的分值，一般方法为
另外一种更好的方法是使用更简单一些的式子，比如 f(x) = x + b：实验证明当使用一半的回归量的时候，该式子（称为Slope One）的表现有时优于[2]
基于奥卡姆剃刀原则：“切勿浪费较多东西，去做‘用较少的东西，同样可以做好的事情’。”
基于项目相似度协同过滤的一种简化的思想Slope One算法也就反映出了更加实用之处。
附带一句，关于推荐系统等算法，敏捷开发实现，可以尝试看下《集体智慧编程》（Programming Collective Intelligence），Python实现。
5.2 Slope One算法
为了大大减少过适的发生，提升算法简化实现， Slope One 系列易实现的Item-based协同过滤算法被提了出来。本质上，该方法运用更简单形式的回归表达式(f(x) = x + b) 和单一的自由参数，而不是一个项目评分和另一个项目评分间的线性回归 (f(x) = ax + b)。 该自由参数只不过就是两个项目评分间的平均差值。甚至在某些实例当中，它比线性回归的方法更准确[2]，而且该算法只需要一半（甚至更少）的存储量。
基本原理
如下图评分矩阵：
基于UserA对Item1与Item2的评分，以及UserB对Item1的打分，Slope One算法思想对于UserB对于Item2的预测评分为 2 +（1.5-1）=2.5.
从这里可以看出，Slope One的思想是，每次只着眼两点，因为两点确定一条直线嘛，而且对于这两点Item 1与Item2，User A都经过，User B经过其中1点，Slope One思想假设User B与User A这条直线表现同一斜率：
应用场景
如下图评分矩阵
要预测Lucy对项目1的评分：
- 项目1与项目2间的均差值（5-3)+(3-4)/2 =0.5，（John线与Mark线）
- 项目1与项目3间的均差值（5-2）/1 =3（John线）
那么Lucy对于项目1的评分预测可以基于项目1与项目2，以及项目1与项目3的两个均差值，3项线来预测，项线几道对应均差值的权重上。也就有
rate（lucy，项目1）=（（0.5+2）*2+（3+5）*1）/（2+1）=4.33
想要实现 Slope One，只需要计算并存储“n”对评分间的平均差值和评价数目即可。
算法复杂度
设有“n”个项目，“m”个用户，“N”个评分。计算每对评分之间的差值需要n(n-1)/2 单位的存储空间，最多需要 m*n*n步.
假设用户已经评价了最多 y 个项目, 那么计算不超过n*n+m*y*y个项目间计算差值是可能的。
如果一个用户已经评价过“x”个项目，预测单一的项目评分需要“x“步，而对其所有未评分项目做出评分预测需要最多 (n-x)x 步. 当一个用户已经评价过“x”个项目时，当该用户新增一个评价时，更新数据库需要 x步。
可以通过分割数据（参照分割和稀疏存储（没有共同评价项目的用户可以被忽略）来降低存储要求。
还不想亲自实现？找开源吧
开源的Slope one的程序包
Python：
http://www.serpentine.com/blog/2006/12/12/collaborative-filtering-made-easy/
Java：
http://taste.sourceforge.net/
http://www.daniel-lemire.com/fr/documents/publications/SlopeOne.java
http://www.nongnu.org/cofi/
PHP：
http://sourceforge.net/projects/vogoo
http://www.drupal.org/project/cre
http://www.daniel-lemire.com/fr/documents/publications/webpaper.txt
5.3 Amazon的item-to-item专利算法
在更加普遍的场景中，人们并不总是能给出评分，当用户只提供二元数据（购买与否）的时候，就无法应用Slope One 和其它基于评分的算法。但是却有一个更简单更简单的方法：Amazon的
item-to-item算法是二元 item-based协同过滤应用的例子之一，该算法中用二元向量表示用户-项目购买关系的矩阵，并计算二元向量间的cosine相关系数。
如以下应用场景：
- 在本例当中，项目1和项目2间的cosine相关系数为：
- 项目1和项目3间的cosine相关系数为：
- 而项目2和项目3的cosine相关系数为：
于是，浏览项目1的顾客会被推荐买项目3,而浏览项目2的顾客会被推荐买项目3,浏览了项目3的会被推荐买1（并由1推荐2）。该模型只使用了每对项目间的一个参数（cosine相关系数）来产生推荐。因此，如果有n个项目，则需要计算和存储 n（n-1）/2次cosine相关系数。
六、算法评价指标
推荐系统，协同过滤领域，在科学研究上的一些评价指标主要有MAE，AUC，MAP，P@N，P·R·F曲线。而实际应用中还要考虑到系统伸缩性，算法复杂度，等等，那些就不说了，P·R·F指标参考我之前的一篇文章：《信息检索基本评价指标-P·R·F》
以下指标详细界定参考论文《Mining mood-specific movie similarity with matrix factorization for context-aware recommendation》及《New Approaches to Mood-based Hybrid Collaborative Filtering》
6.1 平均绝对误差 MAE（Mean Absolute Error）
通过计算预测的用户评分与实际的用户评分之间误差来度量。主要结合交叉验证来实现，公式如下：
（其中，g（authentic）为真实评分，g（prediction）为预测评分，Gtest，为整个待预测用户评分集）
6.2平均准确率MAP（Mean Aaverage Precision）
MAP是信息检索中解决P·R·F指标的不足，而提出的，其规范的定义是，设P(R)为系统在召回率为R时的准确率。
单个主题的平均准确率是每篇相关文档检索出后的准确率的平均值。主集合的平均准确率(MAP)是每个主题的平均准确率的平均值。 MAP 是反映系统在全部相关文档上性能的单值指标。系统检索出来的相关文档越靠前(rank 越高)，MAP就可能越高。
一个简单的比方就是（参考）：
设有两个主题，主题1有4个相关网页，主题2有5个相关网页。某系统对于主题1检索出4个相关网页，其rank分别为1, 2, 4, 7；对于主题2检索出3个相关网页，其rank分别为1,3,5。
对于主题1，平均准确率为(1/1+2/2+3/4+4/7)/4=0.83。
对于主题 2，平均准确率为(1/1+2/3+3/5+0+0)/5=0.45。
则MAP= (0.83+0.45)/2=0.64。
应用与协同过滤中的衡量时，也即是测量系统返回推荐项目对应真实用户喜爱偏好的排名的平均准确率。公式如下：
其中：U为测试用户集，|U|表示用户集的数目，| Ri
6.3 P@n测度
测量对于给定用户ui，前n推荐项目中相关项所占比率。如下公式
6.4 AUC（Area Under Curve）
对于用户u，推荐性能AUC 衡量指标计算公式如下：
其中h（x）是一个指标函数，即若参数值x>0或者逻辑真，着函数值为1，否则为0，Pair(u)是一组用户u待计算的配对集值：
其中Tr（u）是训练集中用户u已经有的项目集，Ts（u）为测试集中用户实际预期应该被推荐的项目，实际上，这里面的 n 也就是测试集不应该被推荐的项目。AUC取值[0,1]，最好的就是1了。
其实以上可以看出，AUC是相对其他准确率测度最不直接的一个，理由是AUC涉及到所有配对，包含相关的项目以及不相关的项目（那些即不出现在训练集，也不出现在测试集中），尽管如此，因为通常数据集中不相关的项目比相关项目多得多，表明了AUC可以对于项目排序的变化没有那么敏感。
1366
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
