推荐系统之--- 推荐系统实例

前面几章介绍了各类各样的数据和基于这些数据的推荐算法。在实际系统中，前面几章提到的数据大都存在，所以如何设计一个真实的推荐系统处理不一样的数据，根据不一样的数据设计算法，并将这些算法融合到一个系统当中是本章讨论的主要问题。本章将首先介绍推荐系统的外围架构，而后介绍推荐系统的架构，并对架构中每一个模块的设计进行深刻讨论。

 

一、外围框架

通常来讲，每一个网站都会有一个UI系统，UI系统负责给用户展现网页并和用户交互。

网站会经过日志系统将用户在UI上的各类各样的行为记录到用户行为日志中。日志可能存储在内存缓存里，也可能存储在数据库中，也可能存储在文件系统中。

而推荐系统经过分析用户的行为日志，给用户生成推荐列表，最终展现到网站的界面上。

 

从上面的结构能够看到，推荐系统要发挥强大的做用，除了推荐系统自己，主要还依赖于两个条件——界面展现和用户行为数据。

 经过必定方式展现物品，主要包括物品的标题、缩略图和介绍等。
 不少推荐界面都提供了推荐理由，理由能够增长用户对推荐结果的信任度。
 推荐界面还须要提供一些按钮让用户对推荐结果进行反馈，这样才能让推荐算法不断改善用户的个性化推荐体验。
在设计推荐界面时，咱们能够综合考虑其余网站的设计并结合本身网站的特色。

数据收集和存储

个性化推荐算法依赖于用户行为数据，而在任何一个网站中都存在着各类各样的用户行为数据。那么如何存取这些数据就是推荐系统须要解决的首要问题。表7-1展现了一个假想的电子商务网站上的典型用户行为数据。如表所示，从产生行为的用户角度看，有些行为是只有注册用户才能产生的，而有些行为是全部用户均可以产生的。从规模上看，浏览网页、搜索记录的规模都很大，由于这种行为全部用户都能产生，并且平均每一个用户都会产生不少这些行为。

购买、收藏行为规模中等，由于只有注册用户才能产生这种行为，但购买行为又是电商网站的主要行为，因此它们相对于评论来讲规模更大，但相对于网页浏览行为来讲规模要小得多，最后剩下的行为是注册用户里的一小部分人才有的，因此规模不会很大。从实时存取的角度上看，购买、收藏、评论、评分、分享等行为都是须要实时存取的，由于只要用户有了这些行为，界面上就须要体现出来，好比用户购买了商品后，用户的我的购买列表中就应当即显示用户购买的商品。而有些行为，好比浏览网页的行为和搜索行为并不须要实时存取。

 

推荐系统架构

根据上面的抽象，能够设计一种基于特征的推荐系统架构。如图7-3所示，当用户到来以后，推荐系统须要为用户生成特征，而后对每一个特征找到和特征相关的物品，从而最终生成用户的推荐列表。

于是，推荐系统的核心任务就被拆解成两部分，一个是如何为给定用户生成特征，另外一个是如何根据特征找到物品。

 

用户的特征种类很是多，主要包括以下几类。
 人口统计学特征 包括用户的年龄、性别、国籍和民族等用户在注册时提供的信息。

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

 用户的话题特征 能够根据用户的历史行为利用话题模型（topic model）将电视剧和电影聚合成不一样的话题，而且计算出每一个用户对什么话题感兴趣。好比用户若是看了《叶问》、《新龙门客栈》和《醉拳》，那么能够认为用户对“香港武侠电影”这个话题感兴趣。

推荐系统的推荐任务也有不少种，以下所示。
 将最新加入的物品推荐给用户。
 将商业上须要宣传的物品推荐给用户。
 给用户推荐不一样种类的物品，好比亚马逊会推荐图书、音像、电子产品和服装等。

 给用户混合推荐，有时须要将图书和音像制品放到一个推荐列表中展现给用户。
 对于不一样的产品推荐不一样新颖度的物品。好比在首页给用户展现比较热门的推荐结果，在推荐系统页面给用户展现长尾中的物品。
 考虑到用户访问推荐系统的上下文，好比当你在豆瓣音乐找到“李宗盛”时，右侧会有一个连接告诉你能够在豆瓣电台收听“李宗盛”。单击了这个连接后，豆瓣电台给你推荐的音乐就考虑了“李宗盛”这个上下文。

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

 

两个好处：
 能够方便地增长/删除引擎，控制不一样引擎对推荐结果的影响。对于绝大多数需求，只须要经过不一样的引擎组合实现。
 能够实现推荐引擎级别的用户反馈。每个推荐引擎其实表明了一种推荐策略，而不一样的用户可能喜欢不一样的推荐策略。有些用户可能喜欢利用他的年龄性别做出的推荐，有些用户可能比较喜欢看到新加入的和他兴趣相关的视频，有些用户喜欢比较新颖的推荐，有些用户喜欢专一于一个邻域的推荐，有些用户喜欢多样的推荐。咱们能够将每一种策略都设计成一个推荐引擎，而后经过分析用户对推荐结果的反馈了解用户比较喜欢哪些引擎推荐出来的结果，从而对不一样的用户给出不一样的引擎组合权重。
将推荐系统拆分红不一样推荐引擎后，如何设计一个推荐引擎变成了推荐系统设计的核心部分。

 

三、推荐引擎的架构

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

 

1）生成用户特征向量

通常来讲，用户的特征包括两种，一种是用户的注册信息中能够提取出来的，主要包括用户的人口统计学特征。除了这种特征，另外一种特征主要是从用户的行为中计算出来的，本节着重讨论如何生成特征。
一个特征向量由特征以及特征的权重组成，在利用用户行为计算特征向量时须要考虑如下因素：

 用户行为的种类 在一个网站中，用户能够对物品产生不少不一样种类的行为。用户能够浏览物品、单击物品的连接、收藏物品、给物品打分、购买物品、评论物品、给物品打上不一样的标签、和好友分享物品、搜索不一样的关键词等。这些行为都会对物品特征的权重产生影响，但不一样行为的影响不一样，大多时候很难肯定什么行为更加剧要，通常的标准就是用户付出代价越大的行为权重越高。好比，购买物品须要用户掏钱，因此用户必定会三思然后行，所以购买行为最为重要。相反，浏览物品的网页代价很小，因此这种行为对反映用户的真实兴趣的影响很小。
 用户行为产生的时间 通常来讲，用户近期的行为比较重要，而用户好久以前的行为相对比较次要。所以，若是用户最近购买过某一个物品，那么这个物品对应的特征将会具备比较高的权重。

 用户行为的次数 有时用户对一个物品会产生不少次行为。好比用户会听一首歌不少次，看一部电视剧的不少集等。所以用户对同一个物品的同一种行为发生的次数也反映了用户对物品的兴趣，行为次数多的物品对应的特征权重越高。

 物品的热门程度 若是用户对一个很热门的物品产生了行为，每每不能表明用户的个性，由于用户多是在跟风，可能对该物品并无太大兴趣，特别是在用户对一个热门物品产生了偶尔几回不重要的行为（好比浏览行为）时，就更说明用户对这个物品可能没有什么兴趣，可能只是由于这个物品的连接处处都是，很容易点到而已。反之，若是用户对一个不热门的物品产生了行为，就说明了用户的个性需求。所以，推荐引擎在生成用户特征时会加剧不热门物品对应的特征的权重。

 

2）特征—物品相关推荐

在获得用户的特征向量后，咱们能够根据离线的相关表获得初始的物品推荐列表。离线相关表能够存储在MySQL中，其存储格式如表7-2所示。

从上面的架构图能够看到，特征—物品相关推荐模块还能够接受一个候选物品集合。候选物品集合的目的是保证推荐结果只包含候选物品集合中的物品。

3)  过滤模块

在获得初步的推荐列表后，还不能把这个列表展示给用户，首先须要按照产品需求对结果进行过滤，过滤掉那些不符合要求的物品。

通常来讲，过滤模块会过滤掉如下物品。
 用户已经产生过行为物品 由于推荐系统的目的是帮助用户发现物品，所以不必给用户推荐他已经知道的物品，这样能够保证推荐结果的新颖性。
 候选物品之外的物品 候选物品集合通常有两个来源，一个是产品需求。好比在首页可能要求将新加入的物品推荐给用户，所以须要在过滤模块中过滤掉不知足这一条件的物品。

另外一个来源是用户本身的选择，好比用户选择了某一个价格区间，只但愿看到这个价格区间内的物品，那么过滤模块须要过滤掉不知足用户需求的物品。
 某些质量不好的物品 为了提升用户的体验，推荐系统须要给用户推荐质量好的物品，那么对于一些绝大多数用户评论都不好的物品，推荐系统须要过滤掉。这种过滤通常以用户的历史评分为依据，好比过滤掉平均分在2分如下的物品。

 

4) 排名模块

通过过滤后的推荐结果直接展现给用户通常也没有问题，但若是对它们进行一些排名，则能够更好地提高用户满意度，通常排名模块须要包括不少不一样的子模块，下面将对不一样的模块分别加以介绍。
1. 新颖性排名

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

对热门物品进行下降权重能够提升推荐的新颖度.

2. 多样性
多样性也是推荐系统的重要指标之一。增长多样性可让推荐结果覆盖尽量多的用户兴趣。

第一种提升多样性的方法是将推荐结果按照某种物品的内容属性分红几类，而后在每一个类中都选择该类中排名最高的物品组合成最终的推荐列表。好比，若是是电影，能够按照电影的类别（爱情片、动做片、科幻片等）对推荐结果中的电影分类，而后每种类别都选出几部电影组成最终的推荐结果。

所以，第二种提升推荐结果多样性的方法是控制不一样推荐结果的推荐理由出现的次数。本章提出的推荐系统对于每一个推荐出来的物品都有一个推荐理由，这个推荐理由通常是产生推荐结果的重要特征。那么，要提升推荐结果的多样性，就须要让推荐结果尽可能来自不一样的特征，具备不一样的推荐理由，而不是全部的推荐结果都对应一个理由。

下面的代码根据推荐理由增长推荐结果的多样性，这里输入的recommendations是按照权重从大到小排序的，程序中每次拿出一个推荐结果，若是这个结果已经被用过了，就会对推荐结果的权重除以2降权（这里具体除以几能够在实际应用中本身调整），最终将推荐结果从新按照权重从大到小排序。

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

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

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

若是推荐系统的目标是提升用户对推荐结果的点击率，那么能够利用点击模型（click model）预测用户是否会点击推荐结果。点击模型在不少领域获得了普遍应用，好比搜索结果的点击预测、搜索广告的点击预测、上下文广告的点击预测。点击预测的主要问题是预测用户看到某个推荐结果时是否会点击。那么要进行点击率预测，首先须要提取特征。在推荐系统的点击率预测中能够用以下特征预测用户u会不会点击物品i：
 用户u相关的特征，好比年龄、性别、活跃程度、以前有没有点击行为；
 物品i相关的特征，好比流行度，平均分，内容属性；
 物品i在推荐列表中的位置。用户的点击和用户界面的设计有很高的相关性，所以物品i在推荐列表中的位置对预测用户是否点击很重要；
 用户以前是否点击过和推荐物品i具备一样推荐解释的其余推荐结果；
 用户以前是否点击过和推荐物品i来自一样推荐引擎的其余推荐结果。
点击模型须要离线计算好，在线将模型加载到内存中。为了提升在线预测的效率，通常只可使用线性模型。

本章提出的推荐系统架构基本上是从基于物品的推荐算法衍生出来的，所以本章的架构并不适合用来解决社会化推荐问题。