推荐系统的初体验（关联规则，协同过滤）

最近接触了一个推荐系统的建设项目，于是我顺便回顾了一下之前零星学到的推荐知识，把一些困惑很久的问题弄明白了，所以来总结一下。

一般意义下的推荐系统是指个性化推荐，类似简单的排行榜推荐或者关联规则推荐被认为是不够个性化的。不过我困惑的问题也正在于这里，所以我来描述一下关联规则和协同过滤这两个典型的推荐方法。

关联规则是数据挖掘中的典型问题之一，又被称为购物篮分析，这是因为传统的关联规则案例大多发生在超市中，例如所谓的啤酒与尿布传说。事实上，“购物篮”这个词也揭示了关联规则挖掘的一个重要特点：以交易记录为研究对象，每一个购物篮（transaction）就是一条记录。关联规则希望挖掘的规则就是：哪些商品会经常在同一个购物篮中出现，其中有没有因果关系。为了描述这种“经常性”及“因果关系”，分析者定义了几个指标，基于这些指标来筛选关联规则，从而得到那些不平凡的规律。主要的指标包括：支持度support，置信度confidence，提升度lift。对于一个二项规则例如“A→B”，支持度是指A与B同时出现的概率，即P(A B)；置信度是B关于A的条件概率，即P(B | A)；提升度是B的概率的提升，即P(B | A) / P(B)。比较常见的例子是：

这些指标都很容易理解，他们在一定程度上保证了挖掘出来的规则的实用性。

尽管用来做关联规则的Apriori算法被誉为数据挖掘十大算法之一，我仍然曾经因为觉得关联规则如此简单明白而忽视其实践意义。尤其是在我知道协同过滤之后。

协同过滤也是很典型的推荐技术，他构造一个用户与项目之间的关联打分矩阵，像是这样

打分矩阵很好地体现出协同的概念，其中的Ui代表了用户，Ti代表了项目，相应位置的数值表示了用户对项目的打分，有些情况下没有具体分值的，通常用0/1来表示未购买与已购买（豆瓣电台估计得是-1/0/1这样的编码）。协同过滤的基本想法就是根据相似性来做推荐，这可以分为两类：基于用户相似性的推荐和基于项目相似性的推荐。这两种推荐的假设基础分别是：相似的用户对同一个项目会有相似的偏好，同一个用户对相似的项目会有相似的偏好。因此从计算的角度就是对上述的打分矩阵分别按行和按列计算相似度。

基于用户的协同过滤可以简单地通过对用户的聚类以及KNN等方法实现，若U1与U2被归为一类，或者U2是距离U1最近的用户，则向U1推荐U1没购买过而U2已购买过的项目。当然这里更标准的做法是计算用户之间的相似度（用相关系数和欧氏距离等等的指标来衡量），然后根据相似度进行加权求和，得到每个用户对每个项目的推荐得分。类似地，基于项目的协同过滤则是计算项目之间的相似度矩阵，像是这样

然后可以根据原始的打分矩阵和这个相似度矩阵，来做一个类似加权求和的工作（其实就是矩阵相乘），得到每个用户对每个项目的推荐得分。例如，U1对T2的推荐得分，就是（1,0,0,1）*（2,1,1,1）=（1*2 + 0*1 + 0*1 + 1*1）=3。这个例子中没有涉及具体打分（只有0/1编码），项目之间相似度的计算也比较简单（距离公式和相关系数的定义有多种多样复杂无比，并且还需要做一些标准化之类的处理），仅仅作为例子来说明一下基于项目相似性来计算偏好的一种方法。

由于我对这两种技术的学习都比较浅，所以存在很多困惑的地方，前段时间也跟老段交流过。主要的问题就在于：关联规则跟协同过滤的相通点在什么地方。（貌似我很喜欢探索这种问题，例如做信用评分模型的变量转换时，用dummy变量跟用WOE编码有何相通之处，以及WOE跟零售推荐里的NRS的相似之处，这个等我弄明白了再总结吧。）

由于我上面协同过滤的这个例子太特殊，所以把关联规则给混淆进来了。因为其中计算项目相似度的方法跟关联规则里面的支持度support很类似，无非是数一下两个项目同时出现的概率或次数，于是我就认为关联规则的本质也是在计算项目之间的相似度，于是我就把关联规则理解为一种特殊的协同过滤了。囧。

事实上今天我考虑了一下，这两种方法确实还是有很大的不同。从形式上讲，当然我忽略了关联规则里面的其他一些指标。从更接近本质的观点来看，这两种方法的出发点和逻辑思路也是截然不同的。一般地，关联规则被划分为动态推荐，而协同过滤则更多地被视为静态推荐。

所谓动态推荐，我的理解是：推荐的基础是且只是当前一次（最近一次）的购买或者点击。譬如我在网站上看了一个赵丽蓉老师的小品，系统就找到与这个小品相关的关联规则，然后根据这个规则向我进行推荐（例如赵丽蓉老师的另外一个小品="=）。而静态推荐则是在对用户进行了一定分析的基础上，建立了这个用户在一定时期内的偏好排序，然后在这段时期内持续地按照这个排序来进行推荐。

由此可见，关联规则与协同过滤的策略思路是完全不同的类型。而造成这种差异的原因，则在于这两种方法所面对的对象的性质的不同——关联规则面向的是transaction，而协同过滤面向的是ID。关联规则典型地是面向超市零售，在会员制度尚不完善的阶段，没办法得到每个用户的购买情况，而只能分析交易数据（小票），因此也就没有“用户偏好”这个概念，而只能从小票中分析出一些频繁的关联项，也因此关联规则做推荐时无法应用用户历史数据，而只能基于当前的购买情况来做推荐，也因此关联规则原本就不是跟推荐系统挂在一起，而是更多地强调交叉销售。

但是这并不影响关联规则在很多场合都具有良好的实践效果，例如老段做的那个彩铃推荐。事实上，即便在当下很多能够拿到用户ID的场景，使用动态的关联规则推荐仍然是值得考虑的一种方法（尤其是我们经常把很多推荐方法的结果综合起来做一个混合的推荐），因为这种方法的逻辑思路跟协同过滤有着本质的不同，问题似乎仅仅在于：个人的偏好到底有多稳定，推荐到底是要迎合用户的长期偏好还是用户的当下需求。

当然啦，这两种方法也有能够结合在一起的机会（不是简单地对推荐结果做并集），有助于应用关联规则的一些良好性质在一定程度上弥补协同过滤的不足。IBM就介绍了这样一种方法，主要的策略是用关联规则来计算项目相似度，然后再应用基于项目相似性的协同过滤技术。在这种情况下，项目距离矩阵就不再是对称的了，因为关联规则具有方向性。

这就是我的推荐系统初体验了，可以算是基本了解了两种方法的区别。

今天没有代码——（要么参考一下阿稳《可能是史上代码最少的协同过滤推荐引擎》）——所以从微博抄个笑话吧。

“个人觉得现在的数据挖掘做的很烂，我在网上买了一个锅，结果下面推荐的都是锅，同志，我已经买了一个了还这么迫切的想买第二个么？”

打完收工。