81 lines
4.1 KiB
Markdown
81 lines
4.1 KiB
Markdown
# 推荐系统的外围架构
|
||
|
||
|
||
|
||
<center>推荐系统外围架构图</center>
|
||
|
||
在外围结构中，我们有以下部分：
|
||
|
||
- **UI界面**：负责与用户进行交互，并收集用户的各种行为数据记录至日志系统。
|
||
|
||
- **日志系统**：通过日志系统，将用户的行为数据存储至用户日志存储系统。
|
||
|
||
- **用户日志存储系统**：可能存储在内存缓存中，数据库中或者文件系统中。
|
||
|
||
- **推荐系统**：分析行为数据，生成推荐列表，展示至UI界面供用户选择。
|
||
|
||
# 推荐系统的架构
|
||
推荐系统的任务集中于：根据提供的数据，生成用户的推荐列表。这个任务可以抽象为一个从用户通过各种各样的特征最终走到不同物品的过程。而这个过程又可以拆解成两个部分：一是如何生成用户的特征，二是如何根据特征找到物品。
|
||
|
||
而基于之前学习的各种知识，我们可以对于这两个部分找到对应的方法。生成特征可以看成是在庞大的数据集中找到一个适合的分类规则，例如：通过基于上下文信息分类，通过标签信息，利用行为信息等，而根据特征找到物品可以看成是基于不同特征下的计算用户对于物品的兴趣度。（待斟酌）
|
||
|
||
若是将推荐系统的任务细分，可以结合现实实际情况：将最新加入的物品推荐给用户；商业上需要宣传的物品推荐给用户；为用户推荐不同种类的物品。
|
||
**复杂的特征和情况不同的任务**会让推荐系统变得非常复杂，所以推荐系统的架构为了方便考虑，采用多个不同的推荐引擎组成，每个推荐引擎专门负责某一类特征和一种任务，而推荐系统再将推荐引擎的结果按照一定的优先级合并，排序并返回给UI系统。
|
||
|
||
|
||
|
||
<center>推荐系统的架构</center>
|
||
如上图所示。
|
||
|
||
这样做能够灵活的更换推荐引擎，以适应不同用户或不同场景下的推荐需求。
|
||
|
||
# 推荐引擎的架构
|
||
推荐引擎的架构主要包括三个部分：
|
||
|
||
- 特征向量生成部分（特征向量输出部分）
|
||
|
||
- 初始推荐物品列表生成部分
|
||
|
||
- 推荐列表筛选、过滤、重排列部分
|
||
|
||
|
||
|
||
以上为推荐引擎的架构图。
|
||
|
||
## 特征向量生成部分
|
||
特征向量生成时，若用户的人口统计学特征等信息直接缓存在内存中，则推荐是直接拿到用户的特征数据进行特征向量生成。
|
||
|
||
而另一种情况中，系统缺少人口统计学特征或是无法直接调用，则需要从用户的行为信息中生成特征向量。此时，就需要将用户行为的一些特征素纳入考虑，并将这些特征赋予适合的权重进行计算。
|
||
|
||
## 初始推荐物品列表生成
|
||
由得到的特征向量，进行特征-物品迁移，从而生成初始的推荐物品列表
|
||
|
||
## 推荐列表筛选、过滤、重排列
|
||
|
||
**筛选过滤模块**
|
||
|
||
得到了初始化的推荐列表之后，此时是不能直接将其展示给用户的，因为在这个列表中仍然存在包括：**用户已产生过行为**、**候选物品外的物品**、**某些质量很差的物品**，等不符合推荐原则的物品，所以需要进行第一步筛选过滤。
|
||
|
||
**排名模块**
|
||
|
||
再经历了筛选过滤之后的推荐列表，已经具有只是给用户的能力了，但若是能将排名进一步更新则会提高用户的满意度。对于排名进行更新有以下几种思路：
|
||
|
||
**新颖性排名**
|
||
|
||
为了提高列表的新颖性，可以对列表中的热门物品进行适当的降权处理
|
||
|
||
**多样性排名**
|
||
|
||
思路有：按照物品的内容分类后，从分类中选择排名最高的物品组合推荐；控制不同推荐理由出现的次数。
|
||
|
||
**时间多样性**
|
||
|
||
为了避免用户每次使用系统时得到的推荐列表没有任何变化
|
||
|
||
**用户反馈**
|
||
|
||
对于用户反馈的信息在排名加权计算中进行反馈，从而生成对应的推荐列表
|
||
|
||
|
||
|