shiftwa / cps4981

This is the code link for implementation a simple RS algorithm

CollaborativeFiltering(协同过滤算法)

协同过滤(Collaborative Filtering)算法， 基本**是根据用户之前的喜好以及其他兴趣相近的用户的选择来给用户推荐物品(基于对用户历史行为数据的挖掘发现用户的喜好偏向， 并预测用户可能喜好的产品进行推荐)， 一般是仅仅基于用户的行为数据（评价、购买、下载等）, 而不依赖于项的任何附加信息（物品自身特征）或者用户的任何附加信息（年龄， 性别等）。目前应用比较广泛的协同过滤算法是基于邻域的方法， 而这种方法主要有下面两种算法：

• 基于用户的协同过滤算法(UserCF): 给用户推荐和他兴趣相似的其他用户喜欢的产品
• 基于物品的协同过滤算法(ItemCF): 给用户推荐和他之前喜欢的物品相似的物品

关于理论的详细介绍， 可以参考博客：AI上推荐 之 协同过滤, 这里是UserCF和ItemCF的代码实践部分， 这个文件夹主要是把项亮《推荐系统实践》里面的协同过滤算法(UserCF和ItemCF)实现了一遍， 并做了详细的注释。

任务描述：

我们实现一下《推荐系统实践》里面的ItemCF和UserCF算法， 采用的数据集是GroupLens提供的MovieLens的其中一个小数据集ml-latest-small。 该数据及包含700个用户对带有6100个标签的10000部电影的100000条评分。 该数据集是一个评分数据集， 用户可以给电影评5个不同等级的分数(1-5)， 而由于我们主要是研究隐反馈数据中的topN推荐问题， 所以忽略了数据集中的评分记录。 TopN推荐的任务是预测用户会不会对某部电影评分， 而不是预测用户在准备对某部电影评分的前提下给电影评多少分。

数据集描述

该实验使用的数据集来自:http://grouplens.org/datasets/movielens/
数据集简介如下：

• MovieLens 100K Dataset
  Stable benchmark dataset. 100,000 ratings from 1000 users on 1700 movies. Released 4/1998.
• MovieLens 1M Dataset
  Stable benchmark dataset. 1 million ratings from 6000 users on 4000 movies. Released 2/2003.
• MovieLens 10M Dataset
  Stable benchmark dataset. 10 million ratings and 100,000 tag applications applied to 10,000 movies by 72,000 users. Released 1/2009.
• MovieLens 20M Dataset
  Stable benchmark dataset. 20 million ratings and 465,000 tag applications applied to 27,000 movies by 138,000 users. Released 4/2015.
• MovieLens Latest Datasets
  
  • Small: 100,000 ratings and 6,100 tag applications applied to 10,000 movies by 700 users. Last updated 1/2016.
  • Full: 22,000,000 ratings and 580,000 tag applications applied to 33,000 movies by 240,000 users. Last updated 1/2016.
• MovieLens Tag Genome Dataset
  11 million computed tag-movie relevance scores from a pool of 1,100 tags applied to 10,000 movies.

本次实验， 使用的是ml-latest-small。

代码的行文逻辑

不管是UserCF还是ItemCF， 行文逻辑都是下面的四个步骤：

1. 导入数据， 读取文件得到"用户-电影"的评分数据， 并且分为训练集和测试集
2. 计算用户(userCF)或者电影(itemcf)之间的相似度
3. 针对目标用户u， 找到其最相似的k个用户/产品， 产生N个推荐
4. 产生推荐之后， 通过准确率、召回率和覆盖率等进行评估。

编码小技巧： 倒排表和字典存储， 由于这种推荐数据非常稀疏， 所以采用了倒排表和字典存储的方式减少时间和空间复杂度，具体的可以参考实际代码。

结果的评估

由于UserCF和ItemCF结果评估部分是共性知识点， 所以在这里统一标识。 这里介绍评测指标：

1. 召回率
   对用户u推荐N个物品记为$R(u)$, 令用户u在测试集上喜欢的物品集合为$T(u)$， 那么召回率定义为：
   $$\operatorname{Recall}=\frac{\sum_{u}|R(u) \cap T(u)|}{\sum_{u}|T(u)|}$$
   这个意思就是说， 在用户真实购买或者看过的影片里面， 我模型真正预测出了多少， 这个考察的是模型推荐的一个全面性。
   

2. 准确率
   准确率定义为：
   $$\operatorname{Precision}=\frac{\sum_{u} \mid R(u) \cap T(u)}{\sum_{u}|R(u)|}$$
   这个意思再说， 在我推荐的所有物品中， 用户真正看的有多少， 这个考察的是我模型推荐的一个准确性。
   
   为了提高准确率， 模型需要把非常有把握的才对用户进行推荐， 所以这时候就减少了推荐的数量， 而这往往就损失了全面性， 真正预测出来的会非常少，所以实际应用中应该综合考虑两者的平衡。

3. 覆盖率 覆盖率反映了推荐算法发掘长尾的能力， 覆盖率越高， 说明推荐算法越能将长尾中的物品推荐给用户。
   $$\text { Coverage }=\frac{\left|\bigcup_{u \in U} R(u)\right|}{|I|}$$
   该覆盖率表示最终的推荐列表中包含多大比例的物品。如果所有物品都被给推荐给至少一个用户， 那么覆盖率是100%。

4. 新颖度 用推荐列表中物品的平均流行度度量推荐结果的新颖度。 如果推荐出的物品都很热门， 说明推荐的新颖度较低。 由于物品的流行度分布呈长尾分布， 所以为了流行度的平均值更加稳定， 在计算平均流行度时对每个物品的流行度取对数。

文件说明：

1. ml-latest-small/: 这里面是电影评分数据集
2. images/: 存放着ipynb里面需要的图片
3. ItemCF.ipynb, UserCF.ipynb: 非常详细解说ItemCF, UserCF算法的实现
4. ItemCF.py, UserCF.py: 把上面的代码封装成了一个类的形式
5. RecommendExample_GuessScore.ipynb: 博客链接里面猜测用户打分的代码例子， 具体可以参考上面的博客链接
6. 协同过滤.ipynb: 这是个参考文件

工业界推荐系统常见的问题

工业界协同过滤的流程

1. 数据处理

• 对行为少不活跃的用户进行过滤， 行为少的用户， 数据太过于稀疏， 召回难度大
• 对用户中热门物品进行过滤， 热门物品可能大部分用户都有过行为
• 非常活跃的用户， 用户协同可能会出现一种情况， 就是每个用户的topN相似用户里都有些非常活跃的用户， 所有需要适当过滤掉这些用户

2. 建立用户embedding和物品embedding， 或者可以像案例这样， 直接建立共现矩阵， 也可以训练embedding
3. 计算用户和N个用户的相似度， 保存N个相似用户曾经看过的TopK个物品
4. 模型（矩阵）进行定期更新， 这个要根据不同项目组的情况， 可能是一天更新一次， 也可能不是， 看具体的情况， 更新的时候使用前N天（N一般3-10）的活跃用户的数据进行更新
5. 每次召回一次N条， 刷完N条再继续召回

• 还有可能用户两次行为（上拉或者下滑）之间间隔很长时间， 也会进行重新召回
• 每次召回的数量， 需要根据召回通道以及各个召回通道配置的召回占比进行配置

6. 为了保证用户不疲劳， 一般情况下， 利用user-cf计算召回结果后， 会做一定的类别去重， 保证召回覆盖度
7. 实际过程中， 根据公司核心用户的数量大小， 考虑实现工具， 如果数据量较大， 可使用spark进行用户协同的结果计算
8. 如果用户量实在太过巨大， 可考虑使用稀疏存储的方式进行存储， 即只存储含有1(或者其他值）的位置坐标索引index以及对应的值

用户行为大多是隐性的

用户的行为大部分都不会直接表现出来，以新闻类网站为例，用户阅读一篇文章，都不能很明确的表现出用户喜欢这类物品，有时候需要综合用户的点击，曝光，收藏，分享，阅读时长，评论等行为，做一个加权，然后再归一化，最终计算出一个合理的值来表示用户的喜好，往往这类行为不容易收集，而且也是比较稀疏的，需要积累很长时间，才能积累到足够的数据

用户协同和物品协同的使用场景

• UserCF的推荐更社会化，反映了用户所在的小型兴趣群体中物品的热门程度；
• ItemCF的推荐更加个性化，反映了用户自己的兴趣传承

UserCF适合于新闻推荐

• 热门程度和时效性是个性化新闻推荐的重点，而个性化相对于这两点略显次要
• UserCF需要维护一个用户兴趣相似表，而ItemCF需要维护一个物品相似表，在新闻推荐系统中物品的更新速度是很快的，那么如果采用ItemCF的话，物品相似度表也需要很快地更新，这是难以实现的

ItemCF适合于图书、电子商务和电影网站

• 用户的兴趣是比较固定和持久的
• 这些系统中用户不太需要流行度来辅助他们判断一个物品的好坏，而是可以通过自己熟知的领域的知识自己判断物品的质量

UserCF的适用场合

• 用户较少的场合，如果用户很多，计算用户相似度度矩阵代价很大（新闻网站）
• 时效性较强，用户个性化兴趣不太明显的领域
• 不需要给出令用户信服的推荐解释

ItemCF的适用场合

• 适用于物品的数量明显小于用户的数量的场合，如物品很多（网站），计算物品的相似度矩阵代价很大
• 长尾物品丰富，用户个性化需求强烈的领域
• 需要利用用户的历史行为给用户做推荐解释，可以令用户比较信服

协同过滤的改进

• 基础算法 图1为最简单的计算物品相关度的公式， 分子为同时喜好itemi和itemj的用户数
• 对热门物品的惩罚 图1存在一个问题， 如果 item-j 是很热门的商品，导致很多喜欢 item-i 的用户都喜欢 item-j，这时 wij 就会非常大。同样，几乎所有的物品都和 item-j 的相关度非常高，这显然是不合理的。所以图2中分母通过引入 N(j) 来对 item-j 的热度进行惩罚。如果物品很热门， 那么N(j)就会越大， 对应的权重就会变小。
• 对热门物品的进一步惩罚 如果 item-j 极度热门，上面的算法还是不够的。举个例子，《Harry Potter》非常火，买任何一本书的人都会购买它，即使通过图2的方法对它进行了惩罚，但是《Harry Potter》仍然会获得很高的相似度。这就是推荐系统领域著名的 Harry Potter Problem。
  如果需要进一步对热门物品惩罚，可以继续修改公式为如图3所示，通过调节参数 α，α 越大，惩罚力度越大，热门物品的相似度越低，整体结果的平均热门程度越低。
• 对活跃用户的惩罚 同样的，Item-based CF 也需要考虑活跃用户（即一个活跃用户（专门做刷单）可能买了非常多的物品）的影响，活跃用户对物品相似度的贡献应该小于不活跃用户。图4为集合了该权重的算法。

推荐系统中常用的评估指标

目前工业界还没有什么好的评估指标去衡量一个推荐系统

现有的评估指标很难去衡量一个模型或者召回的好坏，只能通过看用户的行为数据，推荐的物品，用户点击的多，或者分享，评论，收藏等，通过数据表现，召回能力，曝光和点击数量，推荐物品覆盖度等一些指标，去判断召回的好坏。这些一般要根据公司实际业务，更侧重什么，去调整模型和算法。

比如更侧重曝光和点击，侧重用户体验，停留时长，召回多样性等。

新闻召回实例

目录中新添加了NewsRec， 是将协同过滤算法应用到了新闻推荐的召回， 采用了真实数据做了相关的召回实验，从实验结果上来看， 相比于YouTubeDNN， 效果要好很多。