《推荐系统实践》 第七章 推荐系统实例 读书笔记

从上面的结构可以看到，推荐系统要发挥强大的作用，除了推荐系统本身，主要还依赖于两个条件界 面展示和用户行为数据。关于如何设计推荐系统的界面，笔者没有太多的发言权。不过，如果我们看看目前流行的推荐系统界面，可以看到这些界面都有一些共性。

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

数据收集和存储

需要实时存取的数据存储在数据库和缓存中,而大规模的非实时地存取数据存储在分布式文件系统(如HDFS)中。

推荐系统架构

用户特征种类：
用户的特征种类非常多，主要包括如下几类。

• 人口统计学 特征包括用户的年龄、 性别、国籍和民族等用户在注册时提供的信息。

• 用户的行为 特征包括用户 浏览过什么物品、收藏过什么物品、给什么物品打过什么样的分数等用户行为相关的特征。同时，用户行为从时间上也可以分为用户近期的行为和长期的行为。

• 用户的话题特征可以根据用户 的历史行为利用话题模型( topic model)将电视剧和电影聚合成不同的话题，并且计算出每个用户对什么话题感兴趣。比如用户如果看了《叶问》《新龙门客栈》和《醉拳》,那么可以认为用户对“香港武侠电影”这个话题感兴趣。

推荐系统的推荐任务也有很多种，如下所示。.

• 将最新加入的物品推荐给用户。
• 将商业上需要宣传的物品推荐给用户。
• 给用户推荐不同种类的物品，比如亚马逊会推荐图书、音像、电子产品和服装等。
• 给用户混合推荐,有时需要将图书和音像制品放到一个推荐列表中展示给用户
• 对于不同的产品推荐不同新颖度的物品。比如在首页给用户展示比较热门的推荐结果，在推荐系统页面给用户展示长尾中的物品
• 考虑到用户访问推荐系统的上下文，比如当你在豆瓣音乐找到“李宗盛”时，右侧会有一个链接告诉你可以在豆瓣电台收听“李宗盛”。单击了这个链接后,豆瓣电台给你推荐的音乐就考虑了“李宗盛”这个上下文(如图7-7所示)。

如果要在一个系统中把上面提到的各种特征和任务都统筹考虑,那么系统将会非常复杂,而且很难通过配置文件方便地配置不同特征和任务的权重。因此,推荐系统需要由多个推荐引擎组成，每个推荐引擎负责一类特征和一种任务,而推荐系统的任务只是将推荐引擎的结果按照一定权重或者优先级合并、排序然后返回

这样做还有两个好处。

• 可以方便地增加/删除引擎,控制不同引擎对推荐结果的影响。对于绝大多数需求，只需要通过不同的引擎组合实现。
• 可以实现推荐引擎级别的用户反馈。每一个推荐引擎其实代表了一种推荐策略，而不同的用户可能喜欢不同的推荐策略。有些用户可能喜欢利用他的年龄性别作出的推荐，有些用户可能比较喜欢看到新加人的和他兴趣相关的视频，有些用户喜欢比较新颖的推荐,有些用户喜欢专注于-一个邻域的推荐，有些用户喜欢多样的推荐。我们可以将每- -种策略都设计成- -个推荐引擎,然后通过分析用户对推荐结果的反馈了解用户比较喜欢哪些引擎推荐出来的结果。从而对不同的用户给出不同的引擎组合权重。

推荐引擎的架构

上一节提到，推荐引擎使用一种或几种用户特征, 按照一种推荐策略生成一种类型物品的推荐列表。
推荐引擎架构主要包括3部分。

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

生成用户特征向量

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

• 用户行为的种类 在一个网站中，用户可以对物品产生很多不同种类的行为。用户可以浏览物品、单击物品的链接、收藏物品、给物品打分、购买物品、评论物品、给物品打上不同的标签、和好友分享物品.搜索不同的关键词等。这些行为都会对物品特征的权重产生影响，但不同行为的影响不同，大多时候很难确定什么行为更加重要，一般的标准就是用户付出代价越大的行为权重越高。比如，购买物品需要用户掏钱，所以用户一定会三思而后行，因此购买行为最为重要。相反，浏览物品的网页代价很小，所以这种行为对反映用户的真实兴趣的影响很小。
• 用户行为产生的时间 一般来说， 用户近期的行为比较重要,而用户很久之前的行为相对比较次要。因此，如果用户最近购买过某一个物品，那么这个物品对应的特征将会具有比较高的权重。
• 用户行为的次数 有时用户对一个物品会产生很多次行为。 比如用户会听一 首歌很多次，看一部电视剧的很多集等。因此用户对同一个物品的同一种行为发生的次数也反映了用户对物品的兴趣，行为次数多的物品对应的特征权重越高。
• 物品的热门程度 如果用户对一个很热门的物品产生了行为，往往不能代表用户的个性,因为用户可能是在跟风，可能对该物品并没有太大兴趣，特别是在用户对一个热门物品产生了偶尔几次不重要的行为(比如浏览行为)时，就更说明用户对这个物品可能没有什么兴趣，可能只是因为这个物品的链接到处都是,很容易点到而已。反之,如果用户对一个不热门的物品产生了行为，就说明了用户的个性需求。因此，推荐引擎在生成用户特征时会加重不热门物品对应的特征的权重。

特征-物品相关推荐

在得到用户的特征向量后,我们可以根据离线的相关表得到初始的物品推荐列表。离线相关表可以存储在MySQL中

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

在线使用的特征-物品相关表一 般都不止一 张。 以论文之间的相关表为例，计算论文之间相关性既可以使用第3章提出的协同过滤算法(即如果两篇论文的读者重合度很大说明两部电剧相似),也可以通过内容计算(比如有相同的作者、关键词、相似的标题等)。即使是协同过滤也可以根据不同的用户行为数据得到不同的相关表。比如可以根据用户的打分行为计算论文之的相关性,也可以根据用户的浏览行为计算论文之间的相关性。总之，对于一个推荐引擎可以配置文件中配置很多相关表以及它们的权重,而在线服务在启动时会将这些相关表按照配置的重相加，然后将最终的相关表保存在内存中，而在给用户进行推荐时，用的已经是加权后的相表了。

从上面的架构图可以看到，特征-物品相关推荐模块还可以接受一个候选物品集合。候选品集合的目的是保证推荐结果只包含候选物品集合中的物品。它的应用场合-般是产品需求希望将某些类型的电视剧推荐给用户。比如有些产品要求给用户推荐最近一周加入的新物品，那么选物品集合就包括最近一周新加的物品。

也许有读者会奇怪,为什么不在过滤模块中将候选集合外的电视剧过滤掉，而要在相关推荐模块中处理候选物品列表?这里举一个简单的例子说明原因。首先，一般来说对于协同过滤算法计算出的相关表,每个物品都会倾向于和比较热[门的物品具有较高的相似度。那么假设用户购过物品A，候选列表中包含了物品B, A和B相关，但A比B热门。那么，一般情况下，B在A的关物品列表中会排在靠后的位置(假设排在第10名),而A在B的相关物品列表中会排在靠前的置(假设排在第1名)。那么，如果推荐算法是给用户推荐和A最相关的5部电视剧,那么B就不会出现在用户的推荐列表中。但是，如果算法在给定候选列表时会用一种不同的方式进行推荐，比如如果用户看过和B最相关的5部电视剧中的某一部， 就将B推荐给用户，那么这种情况下B就出现在推荐列表中了。

一般来说，如果需要在一个小的候选物品集合中给用户推荐物品，那么可以考虑上述方法。但如果是要在一个很大的候选物品集合中给用户推荐物品,那么可以考虑直接在初始推荐列表中过滤掉不在候选物品集合中物品的方法。

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

下面的代码给出了相关推荐模块的大体工作流程。

过滤模块

排名模块

1.新颖性排名

新颖性排名模块的目的是给用户尽量推荐他们不知道的.长尾中的物品。虽然前面的过滤模块已经过滤掉了用户曾经有过行为的物品，保证了一定程度的新颖性,但是用户在当前网站对某个物品没有行为并不代表用户不知道这个物品，比如用户可能已经在别的途径知道这个物品了。要准确了解用户是否已经知道某个物品是非常困难的,因此我们只能通过某种近似的方式知道，比如对推荐结果中热门的物品进行降权，比如使用如下公式:

不过，要实现推荐结果的新颖性，仅仅在最后对热[门物品进行降权是不够的，而应在推荐引擎的各个部分考虑新颖性问题。本章提到的推荐系统架构主要是基于物品的推荐算法的，因此可以回顾一下 基于物品的推荐算法的基本公式：

2.多样性

多样性也是推荐系统的重要指标之一。增加多样性可以让推荐结果覆盖尽可能多的用户趣。当然，这里需要指出的是提高多样性并不是时时刻刻都很好。比如在个性化网络电台中，为用户某一固定时刻的兴趣是固定的，所以不希望听到不同曲风的歌曲，尽管这些曲风可能都是
用户之前表示喜欢的。不过,本节主要讨论如果要提高多样性，应该怎么提高。

第一种提高多样性的方法是将推荐结果按照某种物品的内容属性分成几类,然后在每个类中都选择该类中排名最高的物品组合成最终的推荐列表。比如，如果是电影，可以按照电影的类别(爱情片、动作片、科幻片等)对推荐结果中的电影分类,然后每种类别都选出几部电影组成最
终的推荐结果。这种方法的好处是比较简单直观，但这种方法也有严重的缺点。首先，选择什么样的内容属性进行分类对结果的影响很大。其次，就算选择了某种类别，但物品是否属于某个类别是编辑确定的，并不一定能够得到用户的公认。比如成龙的电影，有人认为是功夫片,有人认为是喜剧片，不同人看法不一。

因此，第二种提高推荐结果多样性的方法是**控制不同推荐结果的推荐理由出现的次数。**本章提出的推荐系统对于每个推荐出来的物品都有一个推荐理由,这个推荐理由一般是产生推荐结果的重要特征。那么，要提高推荐结果的多样性，就需要让推荐结果尽量来自不同的特征，具有不同的推荐理由，而不是所有的推荐结果都对应-一个理由 。

下面的代码根据推荐理由增加推荐结果的多样性，这里输人的recommendations是按照权重从大到小排序的，程序中每次拿出-一个推荐结果，如果这个结果已经被用过了，就会对推荐结果的权重除以2降权(这里具体除以几可以在实际应用中自己调整),最终将推荐结果重新按照权
重从大到小排序。.

时间多样性

时间多样性主要是为了保证用户不要每天来推荐系统都看到同样的推荐结果。在第5章已经提到，提高推荐系统的时间多样性要从两个地方着手。首先要保证推荐系统的实时性，在用户有新行为时实时调整推荐结果以满足用户最近的需求。如果用户有实时行为发生,那么行为提取和分析模块就能实时拿到行为数据并转化为新的特征，然后经过特征-物品相关模块转换成和新特征最相关的物品，因而推荐列表中就立即反应了用户最新行为的影响。提高推荐结果多样性的第二个方面是要在用户没有新的行为时，也要保证推荐结果每天都有变化。要实现这一点，只能通过如下方式。

• 记录用户每次登陆推荐系统看到的推荐结果。
• 将这些结果发回日志系统。这种数据不需要实时存储，只要能保证小于一天的延时就足够了。
• 在用户登录时拿到用户昨天及之前看过的推荐结果列表，从当前推荐结果中将用户已经看到的推荐结果降权。

用户反馈

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

如果推荐系统的目标是提高用户对推荐结果的点击率,那么可以利用点击模型( click model )预测用户是否会点击推荐结果。点击模型在很多领城得到了广泛应用,比如搜索结果的点击预测”、搜索广告的点击预测”、上下文广告的点击预测”。点击预测的主要问题是预测用户看到某个推荐
结果时是否会点击。那么要进行点击率预测，首先需要提取特征。在推荐系统的点击率预测中可以用如下特征预测用户u会不会点击物品i:

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

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