首先介绍推荐系统的外围架构,然后介绍推荐系统的架构,并对架构中每个模块的设计进行深入讨论.
外围架构
主要讨论推荐系统是如何和网站的其他系统接口的.
一般来说,每个网站都会有一个UI系统,UI系统负责给用户展示网页并和用户交互.网站会通过日志系统将用户在UI上的各种各样的行为记录到用户行为日志中.日志可能存储在内存缓存李,也可能存储在数据库中,也可能春初在文件系统中. 推荐系统通过分析用户的行为日志,给用户生成推荐列表,最终展示到网站的页面上.
从图中可以看到,推荐系统要发挥强大的作用,除了推荐系统本身,主要还依赖于两个条件—界面展示和用户行为数据.目前流行的推荐系统界面,都有一些共性:
- 通过一定方式展示物品,主要包括物品的标题/缩略图和介绍等;
- 很多推荐界面都提供了推荐理由,理由可以增加用户对推荐结果的信任度;
- 推荐界面还需要提供一些按钮让用户对推荐结果进行反馈,这样才能让推荐算法不断改善用户的个性化推荐体验.
数据收集和存储
个性化推荐算法依赖于用户行为数据,而在任何一个网站中都存在各种各样的用户行为数据.如何存取这些数据就是推荐系统需要解决的首要问题.
按照数据的规模和是否需要实时存取,不同的行为数据将被存储在不同的媒介中.一般来说,需要实时存取的数据存储在数据库和缓存中,而大规模的非实时地存取数据存储在分布式文件系统(如HDFS)中.
数据能否实时存取在推荐系统中非常重要,因为推荐系统的实时性主要依赖于能否实时拿到用户的新行为.只有快速达到大量用户的新行为,推荐系统才能够实时地适应用户当前的需求,给用户进行实时推荐.
推荐系统架构
推荐系统是联系用户和物品的媒介,而推荐系统联系用户和物品的方式主要有3种.
本质上,喜欢物品以及和与用户有相似兴趣的好友也可以看成一种特征,这样就可以统一为一种基于特征的推荐系统架构.
当新用户到来之后,推荐系统需要为用户生成特征,然后对每个特征找到和特征相关的物品,从而最终生成用户的推荐列表.因而,推荐系统的核心任务就被拆分成两部分,一个是如何为给定用户生成特征,另一个是如何根据特征找到物品. 用户的特征种类非常多,主要包括一下几类:
- 人口统计学特征 包括用户的年龄,性别,国籍和民族等用户在注册时提供的信息.
- 用户的行为特征 包括用户浏览过什么物品,收藏过什么物品,给什么物品打过评分等用户行为相关的特征.同时,用户行为从时间上也可以分为用户近期的行为和长期的行为.
- 用户的话题特征 可以根据用户的历史行为利用话题模型将电视剧和电影聚合成不同的话题,并且计算出每个用户对什么话题感兴趣.
推荐系统的推荐任务也有很多种:
- 将最新加入的物品推荐给用户;
- 将商业上需要宣传的物品推荐给用户;
- 给用户推荐不同种类的物品,比如亚马逊会推荐图书,音像,电子产品和服装等.
- 给用户混合推荐,有时需要将图书和音像放到一个推荐列表中展示给用户;
- 对于不同的产品推荐不同新颖度的物品.比如在首页展示比较热门的推荐结果,在推荐系统页面给用户展示长尾中的物品;
- 考虑到用户访问推荐系统的上下文.
如果将上面提到的各种特征和任务都在一个系统中统筹安排,那么系统将会非常复杂,而且很难通过配置文件方便地配置不同特征和任务的权重. 因此,推荐系统需要由多个推荐引擎组成,每个推荐引擎负责一类特征和一种任务,而推荐系统的任务只是将推荐引擎的结果按照一定权重或者优先级合并,排序然后返回.
这样做还有两个好处:
- 可以方便地增加/删除引擎,控制不同引擎对推荐结果的影响.对于绝大多数需求,只需要通过不同的引擎组合实现.
- 可以实现推荐引擎级别的用户反馈. 每个推荐引擎其实代表了一种推荐策略,不同的用户坑你喜欢不同的推荐策略.可以将每一种策略都设计成一个推荐引擎,然后通过分析用户对推荐结果的反馈了解用户比较喜欢哪些引擎推荐出来的结果,从而对不同的用户给出不同的引擎组成权重.
将推荐系统拆分成不同的推荐引擎后,如何设计一个推荐引擎变成了推荐系统的核心部分.
推荐引擎的架构
推荐引擎使用一种或几种用户特征,按照一种推荐策略生成一种类型物品的推荐列表。
推荐引擎架构主要包括3部分.
- 该部分负责从数据库或缓存中拿到用户行为数据,通过分析不同行为,生成当前用户的特征向量.该模块的输出是用户特征向量.
- 该部分负责*将用户的特征向量通过特征-物品相关矩阵*转换为初始推荐物品列表;
- 该部分负责对初始的推荐列表进行过滤,排名等处理,从而生成最终的推荐爱按结果.
生成用户特征向量
一般来说,用户的特征包括两种,一种是用户的注册信息中可以提取出来的,主要包括用户的人口统计学特征.另一种特征主要是从用户的行为中计算出来的.
一个特征向量由特征以及特征的权重组成.在利用用户行为计算特征向量时需要考虑:
- 用户行为的种类 不同的用户行为对物品的权重产生不同的影响,大多数时间不能确定哪些行为更加重要,一般的标准是用户付出代价越大的行为权重越高.比如购买行为比浏览行为更加重要,代价更高.
- 用户行为产生的时间 一般而言,近期行为比很久之前的行为相比,近期行为更加重要.
- 用户行为的次数 用户对同一个物品的同一种行为发生的次数反映了用户对物品的兴趣,行为次数越多的物品对应的特征权重越高.比如,对一首歌歌曲的单曲循环播放.
- 物品的热门程度 如果用户对一个不热门的物品产生了行为,能说明用户的个性需求. 推荐引擎在生成用户特征时会加重不热门物品对应的特征的权重.
特征-物品相关推荐
在得到用户的特征向量后,可以根据离线的相关表得到初始的物品推荐列表.离线相关表可以存储在MySQL中. 对每个特征,可以在相关表中存储和它最相关的N的物品的ID.在线使用的特征-物品相关表一般都不止一张. 对于一个推荐引擎可以在配置文件中配置很多相关表以及它们的权重,而在线服务在启动时会将这些相关表按照配置的权重相加,然后将最终的相关表保存在内存中,而在给用户进行推荐时,用的已经是加权后的相关表了。
特征-物品相关推荐模块还可以接受一个候选物品集合.候选物品集合的目的是保证推荐结果只包含候选物品集合中的物品.它的应用场合一般是产品需求希望将某些类型的电视剧推荐给用户。比如有些产品要求给用户推荐最近一周加入的新物品,那么候选物品集合就包括最近一周新加的物品。
特征—物品相关推荐模块除了给用户返回物品推荐列表,还需要给推荐列表中的每个推荐结果产生一个解释列表,表明这个物品是因为哪些特征推荐出来的。
过滤模块
按照产品需求对结果进行过滤,过滤掉那些不符合要求的物品.一般来说,会过滤掉以下物品:
- 用户已经产生过行为物品 保证推荐结果的新颖性
- 候选物品以外的物品 候选物品集合一般有两个来源,一个是产品需求,另一个是用户自己的选择.
- 某些质量很差的物品 这种过滤一般以用户的历史评分为依据,比如过滤掉平均分在2分一下的物品.
排名模块
经过过滤后的推荐结果直接展示给用户一般也没有问题,但如果对它们进行一些排名,则可以更好地提升用户满意度,一般排名模块需要包括很多不同的子模块.
新颖性排名
新颖性排名模块的目的是给用户尽量推荐他们不知道的、长尾中的物品。虽然前面的过滤模块已经过滤掉了用户曾经有过行为的物品,保证了一定程度的新颖性,但用户可能已经在别的途径知道这个物品了。 要准确了解用户是否已经知道某个物品是非常困难的,只能通过某种近似的方式知道,比如对推荐结果中热门的物品进行降权.比如使用如下公式: $p_{ui} = \frac{p_{ui}}{log(1+\alpha * popularity(i))}$
但要实现推荐结果的新颖性,仅仅在最后对热门物品进行降权是不够的,应在推荐引擎的各个部分考虑新颖性问题.
多样性
增加多样性可以让推荐结果覆盖尽可能多的用户兴趣。但是提高多样性并不是时时刻刻都很好。 第一种提高多样性的方法是将推荐结果按照某种物品的内容属性分成几类,然后在每个类中都选择该类中排名最高的物品集合组成最终推荐列表.方法的优点是比较简单直观,缺点是选择什么样的内容属性进行分类对结果影响很大,计算选择了某种类别,但物品是否属于某个种类是编辑确定的,并不一定能得到用户的公认. 第二种提高推荐结果多样性的方法是控制不同推荐结果的推荐理由出现的次数.要提高推荐结果的多样性,就需要让推荐结果尽量来自不同的特征,具有不同的推荐理由,而不是所有的推荐结果都对应一个理由。
时间多样性
时间多样性主要是为了保证用户不要每天来推荐系统都看到同样的推荐结果。提高推荐系统的时间多样性主要从两个地方着手.首先要保证推荐系统的实时性,在用户有新行为时实时调整推荐结果以满足用户最近的需求;另一个方面是要在用户没有新行为时,也要保证推荐结果每天都有变化.要实现这一点:
- 记录用户每次登陆推荐系统看到的推荐结果;
- 将这些结果发回日志系统.这种数据不需要实时存储,只要保证小于一天的延时;
- 在用户登录时拿到用户昨天及之前看过的推荐结果列表,从当前推荐结果中将用户已经看到的推荐结果降权.
用户反馈
排名模块最重要的部分就是用户反馈模块。用户反馈模块主要通过分析用户之前和推荐结果的交互日志,预测用户会对什么样的推荐结果比较感兴趣。
