推荐系统RM介绍根据响应用户行为的速度不同，系统可以大致分为基于离线训练和在线训练。离线训练的推荐系统架构是最常见的一

总体架构

业界典型的三层架构：召回+排序+后处理，流程如下：

根据响应用户行为的速度不同，系统可以大致分为基于离线训练和在线训练。

离线推荐

离线训练的推荐系统架构是最常见的一种推荐系统架构。使用历史一段时间（比如周或者几周）的数据进行训练，模型迭代的周期较长（一般以小时为单位）。模型拟合的是用户的中长期兴趣。

如下图所示，一个典型的基于离线训练的推荐系统架构由数据上报、离线训练、在线存储、实时计算和 A/B 测试这几个模块组成。其中，数据上报和离线训练组成了监督学习中的学习系统，而实时计算和 A/B 测试组成了预测系统。另外，除了模型之外，还有一个在线存储模块，用于存储模型和模型需要的特征信息供实时计算模块调用。图中的各个模块组成了训练和预测两条数据流，训练的数据流搜集业务的数据最后生成模型存储于在线存储模块；预测的数据流接受业务的预测请求，通过 A/B 测试模块访问实时计算模块获取预测结果。

数据上报： 据上报模块的作用是搜集业务数据组成训练样本。一般分为收集、验证、清洗和转换几个步骤。将收集的数据转化为训练所需要的样本格式，保存到离线存储模块。

离线训练： 线训练模块又细分为离线存储和离线计算。实际业务中使用的推荐系统一般都需要处理海量的用户行为数据，所以离线存储模块需要有一个分布式的文件系统或者存储平台来存储这些数据。离线计算常见的操作有：样本抽样、特征工程、模型训练、相似度计算等。
在线存储： 因为线上的服务对于时延都有严格的要求。比如，某个用户打开手机 APP ，他肯定希望APP 能够快速响应，如果耗时过长，就会影响用户的体验。一般来说，这就要求推荐系统在几十毫秒以内处理完用户请求返回推荐结果，所以，针对线上的服务，需要有一个专门的在线存储模块，负责存储用于线上的模型和特征数据。
实时推荐： 实时推荐模块的功能是对来自业务的新请求进行预测。1.获取用户特征；2.调用推荐模型；3.结果排序。

在实际应用中，因为业务的物品列表太大，如果实时计算对每个物品使用复杂的模型进行打分，就有可能耗时过长而影响用户满意度。所以，一种常见的做法是将推荐列表生成分为召回和排序两步。召回的作用是从大量的候选物品中（例如上百万）筛选出一批用户较可能喜欢的候选集（一般是几百）。排序的作用是对召回得到的相对较小的候选集使用排序模型进行打分。更进一步，在排序得到推荐列表后，为了多样性和运营的一些考虑，还会加上第三步重排过滤（后处理），用于对精排后的推荐列表进行处理。

A/B测试： 对于互联网产品来说， A/B 测试基本上是一个必备的模块，对于推荐系统来说也不例外，它可以帮助开发人员评估新算法对客户行为的影响。除了离线的指标外，一个新的推荐算法上线之前般都会经过 A/B 测试来测试新算法的有效性。

下图是与之对应的实际系统中各个组件的流转过程。需要注意的是生成推荐列表就已经做完了召回和排序的操作，业务层直接调用API就可以得到这个推荐列表。

召回算法

UserCF
ItemCF
传统矩阵分解（MF）& SVD & SVD++
BPR
item2vec/word2vec/embedding

排序算法

Logistic Regression
GBDT
GBDT+LR
GBDT+FM
LightGBM
DNN+GBDT+FM

DNN

PNN
Wide & Deep
DIN
DIEN

后处理

至此我们已经可以推荐给用户最有可能购买的商品了，但是考虑到推荐的周期性（不可能只运行一次对吧），因此可以结合我们的业务需求去设计一些业务规则，如：用户购买过同样商品后需要多久后才继续推荐这个商品（即使模型算出来的概率很高）；或者同样商品在连续几个推荐周期内重复推荐，用户仍没有购买，我们就不能强人所难了，诸如此类的规则。业务过滤实现方法很多，可以SQL定期构建重复商品表，排序后的推荐结果与此表关联过滤再进行推荐，等等。
另外还有一些冷启动和新用户等问题的处理方案，不同场景处理方法不同，可以做一些处理并加入到算法里面，也可以单独走另一套流程，如创建热榜规则，对新用户只推热榜商品，或对活跃用户推送新商品，好处是对于活跃用户或热门商品来说，将新商品/新用户与之联系能快速产生交互数据，方便后续的推荐使用。