推荐系统
参考书本： 项亮, 推荐系统实践. 2012
本文系阅读笔记
推荐系统架构
可以看做推荐系统需要为用户生成特征，然后对每个特征找到和特征相关的物品，从而最终生成用户的推荐列表。因而，推荐系统的核心任务被拆解为两部分，一个是如何为给定用户生成特征，另一个是如何根据特征找到物品。
主要是建立《用户-特征-物品》一个映射
（其实用户和物品的关系类似于QA）
如果把所有的特征都考了，系统会非常复杂。因此，推荐系统需要由多个推荐引擎组成，每个推荐引擎文件方便地配置不同特征和任务的权重。每个推荐引擎负责一类特征和一种任务；而推荐系统的任务只是将推荐引擎的结果按照一定权重或优先级合并、排序然后返回。
【此处书上有一个比较容易理解的图】
这样做还有两个好处：
1.可以方便地增加/删除引擎，控制不同引擎对推荐结果的影响。对于绝大多数需求，只需要通过不同的引擎组合实现。
2.可以实现推荐引擎级别的用户反馈。每一个推荐引擎其实代表了一种推荐策略。而不同的用户可能喜欢不同的推荐策略。
推荐引擎架构
推荐引擎架构主要包括3部分。【具体看书，有图】
该部分负责从数据库或者缓存中拿到用户行为数据，通过分析不同行为，生成当前用户的特征向量。不过如果是使用非行为特征，就不需要使用行为提取和分析模块了。该模块的输出是用户特征向量。
该部分负责将用户的特征向量通过特征-物品相关矩阵转化为初始推荐物品列表。【大部分推荐算法关心的地方，填物品用户表得到推荐物品】（很多个相关表，得到特征-物品相关推荐）
该部分负责对初始的推荐列表进行过滤、排名等处理，从而生成最终的推荐结果。
生成用户特征向量
用户行为种类，用户行为产生时间，用户行为次数，物品热门程度（对热门物品的喜爱不能很好地展示用户的个性，因为用户可能是在跟风）
特征-物品相关推荐
即使是协同过滤，也可以根据不同的用户行为数据得到不同的相关表。比如可以根据用户的打分行为计算论文之间的相关性，也可以根据用户的浏览行为计算论文之间的相关性。总之，对于一个推荐引擎可以在配置文件中配置很多相关表以及它们的权重，而在线服务在启动时会将这些相关表按照配置的权重相加，然后将最终的相关表保存在内存中，而在给用户进行推荐时，用的已经是加权后的相关表了。
过滤模块
一般来说，过滤模块会过滤掉以下物品。
用户已经产生过行为物品 因为推荐系统的目的是帮助用户发现物品，因此没必要给用户推荐他已经知道的物品，这样可以保证推荐结果的新颖性。
候选物品以外的物品 候选物品集合一般有两个来源，一个是产品需求。比如在首页可要求将新加入的物品推荐给用户，因此需要在过滤模块中过滤掉不满足这一条件的物品。另一个来源是用户自己的选择，比如用户选择了某一个价格区间，只希望看到这个价格区间内的物品，那么过滤模块需要过滤掉不满足用户需求的物品。
某些质量很差的物品 为了提高用户的体验，推荐系统需要给用户推荐质量好的物品，那么对于一些绝大多数用户评论都很差的物品，推荐系统需要过滤掉。这种过滤一般以用户的历史评分为依据，比如过滤掉平均分在2分以下的物品。
排名模块
经过过滤后的推荐结果直接展示给用户一般也没有问题，但如果对它们进行一些排名，则可以
