《推荐系统》--协同过滤推荐

《Recommender System An Introduction》，第二章，协同过滤推荐。

定义

协同过滤推荐方法的主要思想是，利用已有用户群过去的行为或意见预测当前用户最可能喜欢哪些东西或对哪些东西感兴趣。此类型的推荐系统当前在业界广泛使用。

纯粹的协同方法的输入数据只有给定的用户-物品评分矩阵，输出数据一般有以下几种类型：

（1）表示当前用户对物品喜欢或不喜欢程度的预测数值；

（2）n项推荐物品的列表。

用户行为的统一表示：

user id	产生行为的用户的唯一标识
item id	产生行为的对象的唯一标识
behavior type	行为的种类（比如是购买还是浏览）
context	产生行为的上下文，包括时间和地点等
behavior weight	行为的权重（如果是观看视频的行为，那么这个权重可以是观看时长；如果是打分行为，这个权重可以是分数）
behavior content	行为的内容（如果是评论行为，那么就是评论的文本；如果是打标签的行为，就是标签）

基于用户的最近邻推荐

主要思想

这是一种早期方法，user-based nearest neighbor recommendation 。其主要思想简述如下：

首先，给定一个评分数据集和当前（活跃）用户的ID作为输入，找出与当前用户过去有相似偏好的其他用户，这些用户有时也被成为对等用户或最近邻；

然后，对当前用户没有见过的每个产品p，利用其近邻对p的评分计算预测值。

这种方法的假设是：（1）如果用户过去有相似的偏好，那么他们未来也会有相似的偏好；（2）用户偏好不会随时间而变化。

计算步骤

假设我们要对用户a进行推荐，计算步骤大致如下：

（1）首先，我们要计算用户a和所有其他用户的相似度；计算这个相似度时，可用算法很多，比如，改进余弦相似度、Spearman秩相关系数、均方差等，实验分析显示，对于基于用户的推荐系统来说，Pearson相关系数比其他算法更胜一筹；Pearson算法计算相似度时，其值在-1和1之间；

（2）选择近邻；我们只会选择和当前用户有正向关联的用户，降低近邻集合规模的通常方法是为用户相似度定义一个具体的最小阀值，或者将规模大小限制为一个固定值，而且只考虑k个最近邻。这两种选择近邻方法的潜在问题：

a、第一种：如果相似度阀值过高，近邻规模就会很小，这就意味着很多物品没法预测（降低覆盖率）；相反，如果阀值太低，近邻规模就不会显著降低。

b、第二种：k值（近邻规模）的选择不会影响覆盖率。但是如何发现一个好k值呢？当近邻个数k太高，太多只有有限相似度的近邻会给预测带来额外的“噪声”；当k太小，预测质量也可能收到负面影响。研究发现，在大多数实际情况下，20-50个近邻似乎比较合理。

（3）预测评分；考虑最相思的k个近邻与用户a评价评分的偏差，预测用户a对所有物品的评分。

（4）优化；更好的相似度和赋权体系。

a、很多领域，有一些广受喜爱的物品，让两个用户对用争议的物品达成共识，会比对广受欢迎的物品达成共识更有价值，但Pearson这样的相似度方法无法将这种情况考虑在内。于是有人提出对物品的评分进行变换，降低对广受欢迎物品有同样看法的相对重要性，即“反用户频率（iuf）”。也有人通过“方差权重因子”解决了同样的问题，该方法提高了高方差评分值物品，也就是具有争议的物品的作用。

b、两位用户仅同时对很少的物品评分（也可能只是碰巧意见相同），或者他们是否对很多物品都意见一致。事实上，基于近邻评分的预测方法，在遇到当前用户只为非常少的共同物品评分时会出错，导致不准的预测。为此，有人提出另外一种赋权因子，即“重要性赋权”。

c、还有通过精细调整预测权重来提供推荐准确度的方法，“样本扩展”。指的是强调那些接近+1和-1的值，对于原始数值乘以一个常量来调整近邻的权值。

注：

（1）关于皮尔逊相关系数等计算公式、计算用户a对物品的评分的数学公式，都是固定而通用的，也有很多算法框架预先帮我们实现好了，这里就不对算法进行描述了。

（2）实际的生产中，优化部分考虑较少，先实现最基本的功能为主。

基于物品的最近邻推荐

主要思想

在大型电子商务网站中，用户数量巨大，物品数量较小，因此，经常采用一种不同的技术：基于物品的推荐。计算量小，在评分矩阵非常大的情况下，也能做到实时计算推荐。

基于物品算法的主要思想是利用物品间相似度，而不是用户间相似度来计算预测值。

计算步骤

基于物品的最近邻推荐，计算步骤大致如下；

（1）计算物品间的相似度，通常采用余弦相似度或者改进余弦相似度算法；在一些只具备了最基本的推荐系统，没有个性化推荐的电商推荐系统中，到这一步就完成了推荐的计算，根据物品的相似度推荐出物品，对所有的用户都是同样的推荐结果；

（2）选择近邻；

（3）预测用户对物品的评分；

（4）优化：考虑到内存要求，N个物品的相似度矩阵理论上会有N^2项，但实际项数会极低，而且还可以采取进一步的方法降低复杂度。

相对于用户相似度而言，物品相似度更稳定，这种预处理计算不会过于影响预测准确度。

UserCF和ItemCF对比

UserCF和ItemCF优缺点的对比：

	UserCF	ItemCF
性能	适用于用户较少的场合，如果用户很多，计算用户相似度矩阵代价很大；比如新闻推荐；	适用于物品数明显小于用户数的场合，如果物品很多（网页），计算物品相似度矩阵代价很大
领域	时效性较强，用户个性化兴趣不太明显的领域	长尾物品丰富，用户个性化需求强烈地领域
实时性	用户有新行为，不一定造成推荐结果的立即变化	用户有新行为，一定会导致推荐结果的实时变化
冷启动	在新用户对很少的物品产生行为后，不能立即对他进行个性化推荐，因为用户相似度表是每隔一段时间离线计算的； 新物品上线后一段时间，一旦有用户对物品产生行为，就可以将新物品推荐给和对它产生行为的用户兴趣相似的其他用户；	新用户只要对一个物品产生行为，就可以给他推荐和改物品相关的其他物品； 但没有办法在不离线更新物品相似度表的情况下将新物品推荐给用户；
推荐理由	很难提供令用户信服的推荐解释；	利用用户的历史行为给用户做推荐解释，可以令用户比较信服；

关于评分

显示评分：用户之间反馈对物品的喜好；explicit;

隐式评分：通过网站日志收集用户的行为，比如电子商务网站的View/Cart/Collect/Buy等；implicit;

显性反馈数据和隐性反馈数据的比较：

	显性反馈数据	隐性反馈数据
用户兴趣	明确	不明确
数量	较少	庞大
存储	数据库	分布式文件系统
实时读取	实时	有延迟
正负反馈	都有	只有正反馈

数据稀疏和冷启动问题

实际生产中，由于用户一般只会评价（或购买）少量商品，评分矩阵一般都非常稀疏。

这种情况下的挑战是用相对较少的有效评分得到准确的预测。直接做法就是利用用户的附加信息，比如性别、年龄、教育、兴趣等，因此相似用户集合不只是根据评分，也会根据外部信息，貌似不再是“纯粹”的协同方法了。尽管如此，在刚上线推荐服务的扩张阶段，这种技术对于获取协同方法所需的大量关键用户还是很有帮助的。

为了解决冷启动和数据稀疏问题，有人提出了基于图的方法，其主要思想是利用假定用户品味的“传递性”，并由此增强额外信息矩阵。这里就不详细学习了，实际的生产中，对于冷启动问题，可以采用其他的推荐方法来补充数据，比如基于内容的推荐。

更多推荐方法

（1）矩阵因子分解。关键词：降维、奇异值分解（SVD）、潜在语义索引（LSI）、主成分分析（Eigentaste）。

（2）关联规则挖掘。是一种在大规模交易中识别类似规则关系模式的通用技术。这种技术的典型应用是从超市里经常同时购买的商品中发掘成对或成组的商品。一个典型的规则是“如果用户买了婴儿食品，那他/她买尿布的可能性会是70%”。知道了这种关系，就可以利用这一知识进行推销和交叉销售，也可以用来设计商店的布局。

（3）基于概率分析的推荐方法。贝叶斯算法、聚类。

（4）Slope One预测方案。推荐质量不同，算法本身的复杂度也有差别。最早的基于记忆算法在实现方面相对直接，但其他方法却要以来复杂的预处理和模型更新技术。许多方法虽然可以用数学软件库，但还是需要一些深度的数学技巧（所用方法计算发杂，算法必须被优化时尤其需要这些技巧），这也许会限制这些方法的实际使用，尤其对小规模企业。Slope One预测方案是一种相对简单的推荐技术，虽然非常简单，但也能得到适当的推荐质量。其思想很简单，基于作者所谓的“热门度差异”，也就是对用户来说物品相互之间的评分差异。

（5）Google新闻个性化推荐引擎。关键词：概率潜在语义索引（PLSI）、MinHash、伴随浏览量。如果我们有一组大规模数据集且数据频繁变化，在算法、设计及并行方面需要很大力气才有可能应用现有技术和实时推荐。纯基于记忆的方法不能直接使用，对于基于模型额方法来说，必须解决模型的连续更新问题。

讨论和小结

（1）协同过滤是当今最流行的推荐系统。其流行的最重要原因是：有实际环境作为改进的基准，而且用于分析生成推荐的数据结构（用户物品评分矩阵），非常简单。其他算法，就不会这么简单，比如通过会话交互的推荐应用会在会谈中询问用户的偏好，并且还会融入一些额外的领域知识。

（2）从使用角度来看，基于物品的协同过滤能处理非常大规模的评分数据，并能生成质量良好的推荐。

（3）协同过滤不可能应用于每个领域：例如一个没有购买历史的汽车销售系统，或需要更多用户偏好细节的系统。同样，协同过滤技术要求用户社区处于某个特定规模，这意味着即使在书籍和电影领率，如果没有足够的用户或评分数据，也无法应用这些技术。

（4）当然，能够克服这些缺陷的推荐方法必然要付出代价，比如基于内容的推荐就需要进一步的开发和维护。