构建推荐系统-CSDN博客

本文链接：https://blog.csdn.net/weixin_42385782/article/details/122602456

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

外围架构

这一节主要讨论推荐系统是如何和网站的其他系统接口的。图7-1表示了推荐系统和网站其他系统的关系。一般来说，每个网站都会有一个UI系统，UI系统负责给用户展示网页并和用户交互。网站会通过日志系统将用户在UI上的各种各样的行为记录到用户行为日志中。日志可能存储在内存缓存里，也可能存储在数据库中，也可能存储在文件系统中。而推荐系统通过分析用户的行为日志，给用户生成推荐列表，最终展示到网站的界面上。
从上面的结构可以看到，推荐系统要发挥强大的作用，除了推荐系统本身，主要还依赖于两个条件——界面展示和用户行为数据。

数据收集和存储

个性化推荐算法依赖于用户行为数据，而在任何一个网站中都存在着各种各样的用户行为数据。那么如何存取这些数据就是推荐系统需要解决的首要问题。
按照前面数据的规模和是否需要实时存取，不同的行为数据将被存储在不同的媒介中。一般来说，需要实时存取的数据存储在数据库和缓存中，而大规模的非实时地存取数据存储在分布式文件系统（如HDFS）中。
数据能否实时存取在推荐系统中非常重要，因为推荐系统的实时性主要依赖于能否实时拿到用户的新行为。只有快速拿到大量用户的新行为，推荐系统才能够实时地适应用户当前的需求，给用户进行实时推荐。

推荐引擎架构

推荐引擎使用一种或几种用户特征，按照一种推荐策略生成一种类型物品的推荐列表。下图示了每个具体推荐引擎的架构。
在这里插入图片描述
如图所示，推荐引擎架构主要包括3部分。
A部分负责从数据库或者缓存中拿到用户行为数据，通过分析不同行为，生成当前用户的特征向量。
B部分负责将用户的特征向量通过特征-物品相关矩阵转化为初始推荐物品列表。
C部分负责对初始的推荐列表进行过滤、排名等处理，从而生成最终的推荐结果。

生成用户特征向量

一般来说，用户的特征包括两种，一种是用户的注册信息中可以提取出来的。另一种特征主要是从用户的行为中计算出来的，这里着重讨论如何生成特征。
一个特征向量由特征以及特征的权重组成，在利用用户行为计算特征向量时需要考虑以下因素。

用户行为的种类权重。一般的标准就是用户付出代价越大的行为权重越高。比如，购买物品需要用户掏钱，所以用户一定会三思而后行，因此购买行为最为重要。相反，浏览物品的网页代价很小，所以这种行为对反映用户的真实兴趣的影响很小。
用户行为产生的时间，一般来说，用户近期的行为比较重要，而用户很久之前的行为相对比较次要。
用户行为的次数，有时用户对一个物品会产生很多次行为。行为次数多的物品对应的特征权重越高。
物品的热门程度，如果用户对一个很热门的物品产生了行为，往往不能代表用户的个性，因为用户可能是在跟风，可能对该物品并没有太大兴趣。反之，如果用户对一个不热门的物品产生了行为，就说明了用户的个性需求。因此，推荐引擎在生成用户特征时会加重不热门物品对应的特征的权重。

特征-物品相关推荐

在得到用户的特征向量后，我们可以根据离线的相关表得到初始的物品推荐列表。离线相关表可以存储在MySQL中，其存储格式如表所示。
在这里插入图片描述
对于每个特征，我们可以在相关表中存储和它最相关的N个物品的ID。
在线使用的特征-物品相关表一般都不止一张。对于一个推荐引擎可以在配置文件中配置很多相关表以及它们的权重，而在线服务在启动时会将这些相关表按照配置的权重相加，然后将最终的相关表保存在内存中，而在给用户进行推荐时，用的已经是加权后的相关表了。
从上面的架构图可以看到，特征-物品相关推荐模块还可以接受一个候选物品集合。候选物品集合的目的是保证推荐结果只包含候选物品集合中的物品。它的应用场合一般是产品需求希望将某些类型的电视剧推荐给用户。
也许有读者会奇怪，为什么不在过滤模块中将候选集合外的电视剧过滤掉，而要在相关推荐模块中处理候选物品列表？这里举一个简单的例子说明原因。首先，一般来说对于协同过滤算法计算出的相关表，每个物品都会倾向于和比较热门的物品具有较高的相似度。那么假设用户购买过物品A，候选列表中包含了物品B，A和B相关，但A比B热门。那么，一般情况下，B在A的相关物品列表中会排在靠后的位置（假设排在第10名）,而A在B的相关物品列表中会排在靠前的位置(假设排在第1名)。那么，如果推荐算法是给用户推荐和A最相关的5部电视剧，那么B就不会出现在用户的推荐列表中。但是，如果算法在给定候选列表时会用一种不同的方式进行推荐，比如如果用户看过和B最相关的5部电视剧中的某一部，就将B推荐给用户，那么这种情况下B就出现在推荐列表中了。
一般来说，如果需要在一个小的候选物品集合中给用户推荐物品，那么可以考虑上述方法。但如果是要在一个很大的候选物品集合中给用户推荐物品，那么可以考虑直接在初始推荐列表中过滤掉不在候选物品集合中物品的方法。
特征-物品相关推荐模块除了给用户返回物品推荐列表，还需要给推荐列表中的每个推荐结果产生一个解释列表，表明这个物品是因为哪些特征推荐出来的。

过滤模块

在得到初步的推荐列表后，还不能把这个列表展现给用户，首先需要按照产品需求对结果进行过滤，过滤掉那些不符合要求的物品。一般来说，过滤模块会过滤掉以下物品。

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

排名模块

经过过滤后的推荐结果直接展示给用户一般也没有问题，但如果对它们进行一些排名，则可以更好地提升用户满意度，一般排名模块需要包括很多不同的子模块，下面将对不同的模块分别加以介绍。

新颖性排名
新颖性排名模块的目的是给用户尽量推荐他们不知道的、长尾中的物品。虽然前面的过滤模块已经过滤掉了用户曾经有过行为的物品，保证了一定程度的新颖性，但是用户在当前网站对某个物品没有行为并不代表用户不知道这个物品，比如用户可能已经在别的途径知道这个物品了。
2.多样性
多样性也是推荐系统的重要指标之一。增加多样性可以让推荐结果覆盖尽可能多的用户兴趣。当然，这里需要指出的是提高多样性并不是时时刻刻都很好。比如在个性化网络电台中，因为用户某一固定时刻的兴趣是固定的，所以不希望听到不同曲风的歌曲，尽管这些曲风可能都是用户之前表示喜欢的。
时间多样性
时间多样性主要是为了保证用户不要每天来推荐系统都看到同样的推荐结果。提高推荐系统的时间多样性要从两个地方着手。首先要保证推荐系统的实时性，在用户有新行为时实时调整推荐结果以满足用户最近的需求。如果用户有实时行为发生，那么行为提取和分析模块就能实时拿到行为数据并转化为新的特征，然后经过特征-物品相关模块转换成和新特征最相关的物品，因而推荐列表中就立即反应了用户最新行为的影响。提高推荐结果多样性的第二个方面是要在用户没有新的行为时，也要保证推荐结果每天都有变化。要实现这一点，只能通过如下方式。
(1）记录用户每次登陆推荐系统看到的推荐结果。
(2）将这些结果发回日志系统。这种数据不需要实时存储，只要能保证小于一天的延时就足够了。
(3) 在用户登录时拿到用户昨天及之前看过的推荐结果列表，从当前推荐结果中将用户已经看到的推荐结果降权。
用户反馈
排名模块最重要的部分就是用户反馈模块。用户反馈模块主要通过分析用户之前和推荐结果的交互日志，预测用户会对什么样的推荐结果比较感兴趣。
如果推荐系统的目标是提高用户对推荐结果的点击率，那么可以利用点击模型(click model) 预测用户是否会点击推荐结果。点击模型在很多领域得到了广泛应用，比如搜索结果的点击预测\ 搜索广告的点击预测’上下文广告的点击预测。点击预测的主要问题是预测用户看到某个推荐结果时是否会点击。那么要进行点击率预测，首先需要提取特征。在推荐系统的点击率预测中可以用如下特征预测用户u会不会点击物品i:
(1)用户u相关的特征，比如年龄、性别、活跃程度、之前有没有点击行为；
(2)物品i相关的特征，比如流行度，平均分，内容属性；
(3)物品i在推荐列表中的位置。用户的点击和用户界面的设计有很高的相关性，因此物品i在推荐列表中的位置对预测用户是否点击很重要；
(4)用户之前是否点击过和推荐物品i具有同样推荐解释的其他推荐结果；
(5)用户之前是否点击过和推荐物品i来自同样推荐引擎的其他推荐结果。
点击模型需要离线计算好，在线将模型加载到内存中。为了提高在线预测的效率，一般只可以使用线性模型。