《推荐系统实践》第七章推荐系统实例

如何设计一个真实的推荐系统处理不同的数据，根据不同的数据设计算法，并将这些算法融合到一个系统当中是本章讨论的主要问题。

7.1 外围架构

一般来说，每个网站都会有一个UI系统，UI系统负责给用户展示网页并和用户交互。网站会通过日志系统将用户在UI上的各种各样的行为记录到用户行为日志中。日志可能存储在内存缓存里，也可能存储在数据库中，也可能存储在文件系统中。而推荐系统通过分析用户的行为日志，给用户生成推荐列表，最终展示到网站的界面上。

推荐系统要发挥强大的作用，除了推荐系统本身，主要还依赖于两个条件——界面展示和用户行为数据。

如果我们看看目前流行的推荐系统界面，可以看到这些界面都有一些共性。
 通过一定方式展示物品，主要包括物品的标题、缩略图和介绍等。
 很多推荐界面都提供了推荐理由，理由可以增加用户对推荐结果的信任度。
 推荐界面还需要提供一些按钮让用户对推荐结果进行反馈，这样才能让推荐算法不断改善用户的个性化推荐体验。

数据收集和存储

个性化推荐算法依赖于用户行为数据，而在任何一个网站中都存在着各种各样的用户行为数据。那么如何存取这些数据就是推荐系统需要解决的首要问题。

按照前面数据的规模和是否需要实时存取，不同的行为数据将被存储在不同的媒介中。一般来说，需要实时存取的数据存储在数据库和缓存中，而大规模的非实时地存取数据存储在分布式文件系统（如HDFS）中。

7.2 推荐系统架构

推荐系统联系用户和物品的方式主要有3种方式，如果将这3种方式都抽象一下就可以发现，如果认为用户喜欢的物品也是一种用户特征，或者和用户兴趣相似的其他用户也是一种用户特征，那么用户就和物品通过特征相联系。

根据上面的抽象，可以设计一种基于特征的推荐系统架构。当用户到来之后，推荐系统需要为用户生成特征，然后对每个特征找到和特征相关的物品，从而最终生成用户的推荐列表。因而，推荐系统的核心任务就被拆解成两部分，一个是如何为给定用户生成特征，另一个是如何根据特征找到物品。

用户的特征种类主要包括如下几类。
 人口统计学特征，包括用户的年龄、性别、国籍和民族等用户在注册时提供的信息。
 用户的行为特征，包括用户浏览过什么物品、收藏过什么物品、给什么物品打过什么样的分数等用户行为相关的特征。同时，用户行为从时间上也可以分为用户近期的行为和长期的行为。
 用户的话题特征，可以根据用户的历史行为利用话题模型（topic model）将电视剧和电影聚合成不同的话题，并且计算出每个用户对什么话题感兴趣。

推荐系统的推荐任务也有很多种，如下所示。
 将最新加入的物品推荐给用户。
 将商业上需要宣传的物品推荐给用户。
 给用户推荐不同种类的物品。
 给用户混合推荐，有时需要将图书和音像制品放到一个推荐列表中展示给用户。
 对于不同的产品推荐不同新颖度的物品。比如在首页给用户展示比较热门的推荐结果，在推荐系统页面给用户展示长尾中的物品。
 考虑到用户访问推荐系统的上下文。

推荐系统需要由多个推荐引擎组成，每个推荐引擎负责一类特征和一种任务，而推荐系统的任务只是将推荐引擎的结果按照一定
权重或者优先级合并、排序然后返回。

这样做还有两个好处。
 可以方便地增加/删除引擎，控制不同引擎对推荐结果的影响。对于绝大多数需求，只需要通过不同的引擎组合实现。
 可以实现推荐引擎级别的用户反馈。每一个推荐引擎其实代表了一种推荐策略，而不同的用户可能喜欢不同的推荐策略。我们可以将每一种策略都设计成一个推荐引擎，然后通过分析用户对推荐结果的反馈了解用户比较喜欢哪些引擎推荐出来的结果，从而对不同的用户给出不同的引擎组合权重。

7.3 推荐引擎的架构

推荐引擎使用一种或几种用户特征，按照一种推荐策略生成一种类型物品的推荐列表。

推荐引擎架构主要包括3部分。
 该部分负责从数据库或者缓存中拿到用户行为数据，通过分析不同行为，生成当前用户的特征向量。不过如果是使用非行为特征，就不需要使用行为提取和分析模块了。该模块的输出是用户特征向量。
 该部分负责将用户的特征向量通过特征-物品相关矩阵转化为初始推荐物品列表。
 该部分负责对初始的推荐列表进行过滤、排名等处理，从而生成最终的推荐结果。

7.3.1 生成用户特征向量

一个特征向量由特征以及特征的权重组成，在利用用户行为计算特征向量时需要考虑以下因素。

 用户行为的种类：在一个网站中，用户可以对物品产生很多不同种类的行为。这些行为都会对物品特征的权重产生影响，但不同行为的影响不同，大多时候很难确定什么行为更加重要，一般的标准就是用户付出代价越大的行为权重越高。
 用户行为产生的时间：一般来说，用户近期的行为比较重要，而用户很久之前的行为相对比较次要。
 用户行为的次数：有时用户对一个物品会产生很多次行为。因此用户对同一个物品的同一种行为发生的次数也反映了用户对物品的兴趣，行为次数多的物品对应的特征权重越高。
 物品的热门程度：如果用户对一个很热门的物品产生了行为，往往不能代表用户的个性，因为用户可能是在跟风，可能对该物品并没有太大兴趣。反之，如果用户对一个不热门的物品产生了行为，就说明了用户的个性需求。因此，推荐引擎在生成用户特征时会加重不热门物品对应的特征的权重。

7.3.2 特征—物品相关推荐

对于每个特征，我们可以在相关表中存储和它最相关的N个物品的ID。

在线使用的特征-物品相关表一般都不止一张。对于一个推荐引擎可以在配置文件中配置很多相关表以及它们的权重，而在线服务在启动时会将这些相关表按照配置的权重相加，然后将最终的相关表保存在内存中，而在给用户进行推荐时，用的已经是加权后的相关表了。

特征—物品相关推荐模块还可以接受一个候选物品集合。候选物品集合的目的是保证推荐结果只包含候选物品集合中的物品。如果是要在一个很大的候选物品集合中给用户推荐物品，那么可以考虑直接在初始推荐列表中过滤掉不在候选物品集合中物品的方法。

特征—物品相关推荐模块除了给用户返回物品推荐列表，还需要给推荐列表中的每个推荐结果产生一个解释列表，表明这个物品是因为哪些特征推荐出来的。

7.3.3 过滤模块

一般来说，过滤模块会过滤掉以下物品。
 用户已经产生过行为物品：因为推荐系统的目的是帮助用户发现物品，因此没必要给用户推荐他已经知道的物品，这样可以保证推荐结果的新颖性。
 候选物品以外的物品：候选物品集合一般有两个来源，一个是产品需求。另一个来源是用户自己的选择，那么过滤模块需要过滤掉不满足用户需求的物品。
 某些质量很差的物品：为了提高用户的体验，推荐系统需要给用户推荐质量好的物品，那么对于一些绝大多数用户评论都很差的物品，推荐系统需要过滤掉。这种过滤一般以用户的历史评分为依据，比如过滤掉平均分在2分以下的物品。

7.3.4 排名模块

一般排名模块需要包括很多不同的子模块。

1. 新颖性排名

新颖性排名模块的目的是给用户尽量推荐他们不知道的、长尾中的物品。

要准确了解用户是否已经知道某个物品是非常困难的，因此我们只能通过某种近似的方式知道，比如对推荐结果中热门的物品进行降权，比如使用如下公式：

不过，要实现推荐结果的新颖性，仅仅在最后对热门物品进行降权是不够的，而应在推荐引擎的各个部分考虑新颖性问题。

基于物品的推荐算法的基本公式：

， $r_{uj}$ 在通过用户行为生成用户特征向量时计算，而 $w_{ji}$ 是离线计算的物品相似度。

如果使用ItemCF算法，根据前面的讨论可知计算出的相似度矩阵中，热门物品倾向于和热门物品相似。如果用户对一个热门物品j产生了很多行为，有很大的 $r_{uj}$ ，那么和这个热门物品相似的其他热门物品都会在用户的推荐列表中排在靠前的位置。因此，如果要提高推荐结果的新颖度，就需要对 $r_{uj}$ 进行降权，比如使用如下公式：

对于相似度部分，热门物品倾向于和热门物品相似，冷门物品倾向于和冷门物品相似。首先，考虑到推荐系统是为了给用户介绍他们不熟悉的物品，那么可以假设如果用户知道了物品j，对物品j产生过行为，那么和j相似的且比j热门的物品用户应该也有比较大的概率知道，因此可以降低这种物品的权重，比如：

此外，也可以引入内容相似度矩阵，因为内容相似度矩阵中和每个物品相似的物品都不是很热门，所以引入内容相似度矩阵也能够提高最终推荐结果的新颖度。

2. 多样性

增加多样性可以让推荐结果覆盖尽可能多的用户兴趣。当然，这里需要指出的是提高多样性并不是时时刻刻都很好。

第一种提高多样性的方法是将推荐结果按照某种物品的内容属性分成几类，然后在每个类中都选择该类中排名最高的物品组合成最终的推荐列表。

这种方法的好处是比较简单直观，但这种方法也有严重的缺点。首先，选择什么样的内容属性进行分类对结果的影响很大。其次，就算选择了某种类别，但物品是否属于某个类别是编辑确定的，并不一定能够得到用户的公认。

第二种提高推荐结果多样性的方法是控制不同推荐结果的推荐理由出现的次数。要提高推荐结果的多样性，就需要让推荐结果尽量来自不同的特征，具有不同的推荐理由，而不是所有的推荐结果都对应一个理由。

3. 时间多样性

时间多样性主要是为了保证用户不要每天来推荐系统都看到同样的推荐结果。

提高推荐系统的时间多样性要从两个地方着手。首先要保证推荐系统的实时性，在用户有新行为时实时调整推荐结果以满足用户最近的需求。第二个方面是要在用户没有新的行为时，也要保证推荐结果每天都有变化。要实现这一点，只能通过如下方式。

 记录用户每次登陆推荐系统看到的推荐结果。
 将这些结果发回日志系统。
 在用户登录时拿到用户昨天及之前看过的推荐结果列表，从当前推荐结果中将用户已经看到的推荐结果降权。

4. 用户反馈

用户反馈模块主要通过分析用户之前和推荐结果的交互日志，预测用户会对什么样的推荐结果比较感兴趣。

如果推荐系统的目标是提高用户对推荐结果的点击率，那么可以利用点击模型（click model）预测用户是否会点击推荐结果。点击预测的主要问题是预测用户看到某个推荐结果时是否会点击。那么要进行点击率预测，首先需要提取特征。在推荐系统的点击率预测中可以用如下特征预测用户u会不会点击物品i：

 用户u相关的特征，比如年龄、性别、活跃程度、之前有没有点击行为；
 物品i相关的特征，比如流行度，平均分，内容属性；
 物品i在推荐列表中的位置。用户的点击和用户界面的设计有很高的相关性，因此物品i在推荐列表中的位置对预测用户是否点击很重要；
 用户之前是否点击过和推荐物品i具有同样推荐解释的其他推荐结果；
 用户之前是否点击过和推荐物品i来自同样推荐引擎的其他推荐结果。

点击模型需要离线计算好，在线将模型加载到内存中。为了提高在线预测的效率，一般只可以使用线性模型。

7.4 扩展阅读

对Hulu推荐系统架构感兴趣的读者可以参考Hulu的技术博客（http://tech.hulu.com/blog/2011/09/19/recommendation-system/）。

MyMedia是一个比较著名的开源推荐系统架构。该框架同时支持评分预测和TopN推荐，全面支持各种数据和各种算法，对该项目感兴趣的用户可以访问该项目的网站http://www.mymediaproject.org/default.aspx。

本章提出的推荐系统架构基本上是从基于物品的推荐算法衍生出来的，因此本章的架构并不适合用来解决社会化推荐问题。如果要了解社会化推荐方面的架构，可以参考Twitter公开的一些文档。