1. 前言
说完基于用户的协同过滤后，趁热打铁，我们来说说基于物品的协同过滤：“看了又看”，“买了又买”。
如果说协同过滤在推荐系统的召回策略中，占据着非常重要的地位，那么基于物品的协同过滤ItemCF，就是协同过滤的重心。
协同过滤算法诞生于1998年，由亚马逊首先提出，论文是：Item-Based Collaborative Filtering Recommendation
Algorithms。该论文被授予“时间检验奖”，理由就是：该论文深深的影响了实际应用。历经二十多年，至今仍发光发热，为推荐系统的演化，做出了不可磨灭的贡献。
有的小伙伴可能会问：有了UserCF，还要什么ItemCF？存在即合理，在总结了UserCF后，大家有没有想过它的缺点呢？
- 用户的数量很大，计算起来，很耗时
- 用户的兴趣和口味会随着时间而变化
- 数据稀疏，用户间的消费会受热门物品的影响，很难发现用户真正的兴趣
而针对以上UserCF的缺点，ItemCF很好的解决了该问题。原因在于，构建物品-用户的倒排表，先去计算物品间的相似度，然后对用户已经消费过的物品进行规则过滤，那么这样的话，用户的兴趣就能很好的体现出来，此外，物品上通常比用户基数少，在计算方面相应的会缩短计算时间。
接下来，我们就详细的说说ItemCF。
2. 原理&计算&改进
跟用户的协同过滤很像，物品的协同过滤，也需要用户-物品的共现矩阵，区别于UserCF利用相似度计算方法去计算用户间的相似度，ItemCF是计算物品间的相似度，然后根据物品的相似度，再去加权评分给用户推荐。
当然，也可以直接对相似物品进行排序，直接把相似性高的物品，推荐给用户，作为召回结果。具体根据效果来判定使用哪种方式。
同UserCF计算相似度的方法一样，ItemCF的相似度计算也可以根据共现矩阵的特点去针对性的选择余弦相似度、杰卡德、皮尔逊等方法。此处，更新下变种的余弦相似度计算方法：
\]
分母\(|N(i)|\)是浏览 i 的用户数，分子\(|N(i)\cap N(j)|\)是一个月内同时浏览过 i 和 j 的用户数。在计算完相似度后，可以直接使用：
\]
公式的核心思想如下：
要预测一个用户 u 对一个物品 i 的分数，遍历用户 u 评分过的所有物品，假如一共有 m个，每一个物品和待计算物品 i 的相似度乘以用户的评分，这样加权求和后，除以所有这些相似度的总和，就得到了一个加权平均评分，作为用户 u 对物品 i 的分数预测。
在实际的工作中，相似度的计算都是拿前一天的用户数据离线计算完成后，直接存储在redis或hbase中，供后续排序阶段使用。
当然，相似度的计算方法有很多种，主要是根据业务实际情况来选择，还有Slope One算法，以及考虑序列跨度的相似度算法。此外，常规的改进思路有：在评分体系中，可以用矩阵中物品的分数，减去物品的均值分数。这样做的目的就是为了减少个人倾向所造成的影响。
3. 总结
关于协同过滤的总结到这里就告一段路，后续会继续总结其他召回通路，其实对于推荐召回侧来说，主要的就是与业务相关策略的实现，而排序侧主要就是算法为主了。
在实际的工作中，sklearn通常作为调试使用，如果数据量大，可以通过spark分布式计算框架来缩短计算量，但spark的底层一般不好修改，所以业界在大规模数据时，会以TensorFlow或Pytorch来训练模型。
对于推荐系统来说，不管数据量多大，使用什么平台工具，其根本就是就是思想和理念，所以一定要把召回侧、排序侧的实现原理搞懂，剩下的工具，不需太过担心，唯熟练尔。
最后，对于协同过滤来说，不管是UserCF还是ItemCF，无非就是三个过程：输入端的数据处理，中间过程的相似度计算方法，输出端的相似性词典和推荐得分。另外，根据不同的特征，选择不同的方法，组合拼接就可以实现最基本的推荐召回，一点也不难。
继续加油！