[旧文搬迁]推荐系统资料整理之一：推荐方法

感谢IT牛人博客聚合上还能找到我之前博客的一些内容，因为之前主机没续费等各种原因，也懒得翻之前的备份文档了，就把那上面的文章直接拷过来整理一下好了，只搬迁一些还有意义的内容好了，其他的就让它随风而去吧。

基于内容的推荐系统

基于内容推荐是推荐系统中比较常见的一种做法，这种方法对于每个item基于其自身属性，抽取一些特征用来表示这个item的内容，从而推荐那些和当前item含有相同或相近特征的一些item。

这种推荐系统多用于一些资讯类的应用上，针对文章本身抽取一些tag作为该文章的关键词，继而可以通过这些tag来评价两篇文章的相似度。抽取tag经常采用的方案是基于TF-IDF得到的一系列权值较高的term，即认为：在一篇文章中，那些出现频率高的（除停用词）词，并且在其他文章中出现频率较低的词更能代表这篇文章的内容。经过TF-IDF公式计算，权重大于某一阈值的term作为该文章的tag。通常，也考虑tag的词性，一般来说名词和形容词更加适合作为tag。

这种推荐系统的优点在于易于实现，不需要用户数据因此不存在稀疏性和冷启动问题。基于item本身特征推荐，因此不存在过度推荐热门的问题。所涉及的技术都是搜索引擎中应用比较成熟的技术。

缺点在于抽取的特征既要保证准确性又要具有一定的实际意义，否则很难保证推荐结果的相关性。豆瓣网采用人工维护tag的策略，依靠用户去维护item的tag的准确性。

基于关联规则的推荐系统

基于关联规则的推荐更常见于电子商务系统中，并且也被证明行之有效。其实际的意义为购买了一些物品的用户更倾向于购买另一些物品。基于关联规则的推荐系统的首要目标是挖掘出关联规则，也就是那些同时被很多用户购买的物品集合，这些集合内的物品可以相互进行推荐。

目前关联规则挖掘算法主要从Apriori和FP-Growth两个算法发展演变而来。Apriori算法思路实现简单，通过迭代不断通过K-1元频繁项目集生成K元频繁项目集，直到不能生成为止，最终可以得到最大频繁项目集。Apriori算法存在的问题是每次迭代都要判断生成K元集合的K-1元子集是否都是频繁项目集，计算量巨大；并且Apriori算法是一个挖掘最大频繁项目集的算法，无法得到全部频繁模式集合。FP-Growth算法通过构建FP-Tree（频繁模式树），去发现频繁模式集。相比于Apriori算法，计算量较少，并且可以得出几乎所有的频繁项目集；但该算法实现起来要比Apriori复杂，并且FP-Growth需要将全部数据库事务加载到内存中，而Apriori虽然需要反复读取数据库事务，但是不需要全部载入内存。一般而言，FP-Growth要比Apriori快至少一个数量级。

关联规则挖掘中有两个主要的概念，支持度和置信度。支持度是指包含某频繁项目集的事务数和总数据库事务数的百分比。置信度指包含某频繁项目集的事务数和包含被推荐项目集的事务数的百分比。而最小支持度阈值和最小置信度阈值也是决定一个事务集合是否是频繁事务集和一个关联规则是否成立的决定因素。因此这两个阈值也决定了推荐系统的准确率和召回率。

基于关联规则的推荐系统一般转化率较高，因为当用户已经购买了频繁集合中的若干项目后，购买该频繁集合中其他项目的可能性更高。缺点在于计算量较大，但是可以离线计算，因此影响不大。同时基于关联规则的推荐系统由于采用用户数据，不可避免的存在冷启动和稀疏性问题。并且存在热门项目容易被过度推荐的问题。此外，基于item的推荐体系多采用1toN的推荐模式，因此实际的关联规则相当于从二元频繁项目集产生（即1to1的模式），1->1这种关联规则的相关性要远低于M->N这种最初关联规则的推荐形式。因此基于关联规则的推荐系统很少被应用于item的推荐体系。

基于协同过滤的推荐系统

协同过滤是一种在推荐系统中广泛采用的推荐方法。这种算法基于一个假设，喜欢相同item的用户更有可能具有相同的兴趣。基于协同过滤的推荐系统一般应用于有用户评分的系统之中，通过分数去刻画用户对于item的好恶。协同过滤被视为利用集体智慧的典范，不需要对项目进行特殊处理，而是通过用户建立项目与项目之间的联系。

经过发展演变，协同过滤逐渐分化为两种类型：基于用户(User-based)的协同过滤系统和基于项目(Item-based)的协同过滤系统。

User-based 协同过滤系统

采用这种方法的推荐系统通过比较当前用户和其他用户阅读的项目进行比较（其评分为权值），从而选择当前用户的TopN邻近用户，然后根据当前用户的临近用户，对当前用户的未评分项进行模拟评分，然后再将评分高的项目推荐给用户。

这种推荐系统的优点在于推荐项目之间在内容上可能完全不相关，因此可以发现用户的潜在兴趣，并且针对每个用户生成其个性化的推荐结果。缺点在于一般的Web系统中，用户的增长速度都远远大于项目的增长速度，因此其计算量的增长巨大，系统性能容易成为瓶颈。因此在业界中单纯的使用User-based协同过滤系统较少。

豆瓣网的“豆瓣猜”是一种个性化的推荐，因此推荐其背后可能采用了User-based协同过滤技术。但是可以看出，豆瓣猜页面上仍主要采用了基于tag的推荐技术，并且利用“友邻”代替了协同过滤技术中的临近用户计算，并且“豆瓣猜”也并非豆瓣网的主打推荐系统。

Item-based 协同过滤系统

这种协同过滤和User-based协同过滤相似，只不过是通过比较对当前item的用户评分和其他item的用户评分来选择当前item的相似item进行推荐。Item-based协同过滤可以看作是关联规则推荐的一种退化（尤其是进行1to1形式的推荐时），但由于协同过滤更多考虑了用户的实际评分，并且只是计算相似度而非寻找频繁集，因此可以认为Item-based协同过滤准确率较高并且覆盖率更高。

同User-based相比Item-based应用更为广泛，扩展性和算法性能更好。由于项目的增长速度一般较为平缓，因此性能变化不大。缺点就是无法提供个性化的推荐结果。

基于用户模型学习的推荐系统

这种推荐系统根据用户已阅读（或评分）项目进行监督学习，从而得到该用户的行为模型，继而根据该用户的模型去对用户未评分的项目进行分类预测，从而得到用户可能喜欢的项目。根据用户模型的学习算法，一般也需要抽取项目的一些特征。目前这种推荐系统的效果还没有生产环境应用的资料证实，因此尚无法判断其优缺点。

其他

推荐系统和搜索引擎都是海量信息的过滤器，因此有人提出利用搜索引擎的一些成熟技术去解决推荐系统的问题。例如，将item看作是一个doc，将对该item有过评价的用户看作是该doc的一个term，然后利用BM-25、TF-IDF等算法对item的相似度进行计算，这种方案可以避免热门问题，同时搜索引擎技术的发展相对要比推荐系统成熟。存在的问题就是，同基于用户模型学习的推荐系统并未有生产系统使用效果的资料。

除此之外还有基于效用和基于知识的推荐系统。

综述

推荐系统的未来发展方向不会是用单一方案解决问题，很有可能是通过组合以上几种推荐方法，来确定最终的推荐结果。可以采用加权、变换、混合、特征组合等方法综合考虑这些推荐方法。