漫谈协同过滤推荐算法（三）

       在上一篇文章中介绍了协同过滤算法的算法相关原理，在这一篇文章中基于个人的理解对算法中的可能遇到常见问题进行探讨。

冷启动

       在基于用户的协同过滤算法中需要计算用户之间的相似度，然而对一个新用户该如何提取特征呢？对于这个新用户，很有可能他的一些浏览记录、购买历史等信息都是为空的或者很稀少，这使得在寻找相似用户的过程中很难正确找到拥有相似喜好的人，或者找到一个其实相似度并不是很高的用户。这提醒我们，在利用相似度的时候可以设置一个最小阈值避免找到差异过大的邻居。另一方面，对于新用户或多或少会有一部分个人特征信息，同样可以根据这部分信息进行计算推荐：典型的如你附近的人都XXX，或者进行热门推荐，当然这可能带来较大的偏差，推荐效果有待商榷。
       在基于物品的协同过滤算法中这个问题同样存在。如果按照上一篇文章的方法计算相似度，那么一个新的物品与其他任何一个物品的相似度都为零，因为没人购买过。解决的方案之一就是引入另外的相似度，譬如基于内容的相似度，这个相似度在最开始可以简单的考虑物品的分类属性（物品属于某一大类下的某一小类）从而避免复杂的特征提取。实际上在运用中往往都不是单一的使用某种推荐算法的，就像这样可以对两种相似度进行一个加权混合提高准确性。

拓展性与效率

       在基于用户的协同过滤推荐中需要计算用户之间的相似度，这涉及到用户-物品评分表，计算的复杂度是和这张表的规模紧密相关的，在不同的应用场景中会有比较大的差异。譬如在新闻媒体网站上，内容的更新是比较快的，新内容产出量非常大，进而导致物品的数量远比用户的数量大，而在一个电商网站上情况则可能相反，新的商品更新速度相对较慢。同时，对单一用户而言，其涉及到的商品数量在整个商品库中必定是只占很小一部分的，意味着数据极其稀疏，为了提高推荐效率与利用稀疏性，可以只考虑有过购买行为的物品，而无关物品则不参与计算。但相似度矩阵仍然是需要耗费大量计算资源，在实际生产使用时往往使用离线计算好的缓存。
       实际上无论是采用哪种推荐算法都涉及到海量的用户、物品数据，推荐系统一方面要保证推荐质量，另一方面要保证实时数据的迅速计算,往往需要采用分层系统，其不再是单一的推荐系统而是多个系统的混合，在线端适当牺牲准确性来提高即时性，离线端则要保证算法的准确可靠，离线端的计算结果可以使用缓存技术为前端所用。

评分准则

       采用相似度的系统的一个前提是构建相关向量特征，特征构建的好坏直接决定了推荐结果的好坏。如何从用户的行为中挖掘用户的偏好特征呢？这取决于具体的应用场景，下面简单举个例子。还是以电商网站为例：

浏览次数：对一个商品浏览次数越多，说明关注度越高
浏览时间（页面停留时间）：同样的道理，停留时间长的说明关注度高
评论浏览次数/条数：理由同上
是否收藏/是否加入购物车/是否购买：理由仍然同上
…

       可以看出用户大大小小的行为其实都隐含表达出某种偏好，而诸如此类的行为特征应该根据根据具体场景去发掘，一个好的推荐系统应该能根据点点蛛丝马迹准确识别用户的意图。同时也应该注意，在收集数据的时候要对其进行去噪处理：一个用户在某个页面停留的时间未必就是浏览时间，也许他只是离开了，数据中必然存在着噪声。

多样性

       一个好的推荐系统，不应该总是推荐一些你可能已熟知的物品，或者总是同一类的物品。典型的一个例子就是基于物品的协同过滤，因为是基于物品的相似度，那么它的推荐列表很有可能就是同一类别下的物品，这带来一个问题就是推荐列表内的物品间相似度较高：用户买了一把A牌子的菜刀，再给他推荐B、C、D牌子的菜刀显然是没什么意义的。因而需要进一步的筛选来降低列表内的相似度，买了菜刀配个砧板才是个好主意。
       当使用基于相似用户的推荐时，其往往是倾向于热门推荐，因为热门商品受很多用户青睐。这可以通过某种混合手段来提高多样性：商品本身有其固有的分类属性，在进行推荐的时候需要考虑这一点，不能只考虑一个领域的商品，一种方法是在每个领域之中挑选几种与给定物品较相似的进行推荐。这不再是单纯的考虑物品的相似度，而是综合考虑了相似用户的偏好。