推荐系统——推荐引擎的架构
什么是推荐系统
谈推荐系统之前我们先聊一下搜索系统，推荐系统和搜索系统都是为了解决互联网信息过载的问题，互联网信息的数量远超过人类可以逐一浏览的程度，而搜索引擎便是解决这一问题的代表。用户通过描述他们需要的信息，带有目的性地输入一个能够准确描述问题的词条，索引引擎在毫秒级返回最相关的几十条数据。而用户对检索结果的满意程度成为了评估搜索效果的关键。
但搜索引擎只能解决用户拥有明确需求场景的信息过载问题，当用户不明确自己的需求但是又想获取某方向的需求时应该怎么办？如何在海量的信息中找到用户感兴趣的内容并推荐给用户？这便是推荐系统要解决的问题。
举个例子：俄乌战争爆发的几天后，车臣部队发了一段出征誓师的视频，当夜微博b站平台车臣的搜索量上涨，同时在相关视频的推荐下面，相关的俄罗斯与车臣战争的科普视频播放量也暴增，普京个人科普视频播放量也随之上涨。
大部分用户在搜索相关视频的时候，只想关注与“车臣”有关的视频，但是他们并不清楚与车臣有关的视频有哪些，他们不会去搜第一次车臣战争或者第二次车臣战争，因为在这之前他们并不清楚这些东西。所以这就是推荐系统要做的事，感知哪些信息是用户想获取的。
系统架构
在服务层，下面的推荐引擎由于推荐模型的不同，可能会存在多个推荐引擎。服务层对多个推荐引擎进行召回得到初始的推荐结果，并经过过滤排名等操作将最后结果推荐给用户。
推荐引擎的架构
推荐引擎架构主要包括3部分：
- 生成用户特征向量
该部分负责从数据库或者缓存中拿到用户行为数据，通过分析不同行为，生成当前用户的特征向量。 - 特征—物品相关推荐
该部分负责将用户的特征向量通过特征-物品相关矩阵转化为初始推荐物品列表。 - 过滤-排名模块
该部分负责对初始的推荐列表进行过滤、排名等处理，从而生成最终的推荐结果
在线召回
通过对接上游feed服务的流量请求,返回用户会最感兴趣的N条以内的推荐列表(ID列表)。
如何在海量的内容中找到用户最感兴趣的几条数据的呢?这就是在线层所解决的问题。业界通常将这个过程分为四个步骤：召回,粗排,精排,调整。
召回
负责从亿量级的内容中筛选出千条数据返回。这一步骤的目标就是能够在保证低延迟的情况下使用一些召回策略快速的选择出内容的候选集。基于机器学习的模型离线计算好用户的特征与物品之间的映射存储为倒排索引,存储在索引服务中(离线召回的一种方式)等,召回策略决定了一次推荐效果的上限。
精排
这一步将为输入的推荐列表进行预估, 所谓预估,就是对用户浏览这条信息后是否会提升期望的某种指标进行预测。业界常见的方法就是使用点击预估, 精排模型使用预估模型对输入的推荐列表计算预估分并按预估分排序,推荐引擎会最终在上百条的推荐内容中选择预估分排在前几十的内容返回。
粗排
在现实的工程系统中, 精度和时间往往不能兼得，精排性能往往令人堪忧,因此在精排之前都会选择一个折中的步骤过滤掉一个量级的候选内容,保证整体的响应时间是可控的。所以粗排会在保证推荐结果的情况下尽可能地排除掉一些内容。
至此,推荐引擎返回了零到十几条不等的推荐内容给feed服务,feed服务可能会混排信息流广告或者从其他推荐系统返回的不同内容进行混排,最终打包内容与用户信息返回给客户端。
离线服务
离线服务通常用来处理不需要给用户及时响应并且计算量大耗时久的事情，比如
- 离线的召回模型计算物品之间的相似度写入索引服务
- 离线的模型训练
- 离线的同步数据到HDFS
- 用于特征工程生成训练集与画像的构建
- 数据总线中的消息
- 爬虫爬取的内容信息