【推荐算法】推荐算法的实时性

从机器学习的角度讲，推荐系统的实时性的重要之处体现在以下两个方面：

1. 推荐系统更新的越快，说明最近用户兴趣更新的越快，越能为用户进行有效推荐；
2. 推荐系统更新的越快，模型越容易捕捉最新流行的数据模式，进行流行推荐。

这两方面的原因直接对应着推荐系统实时性的两大要素：特征 的实时性和 模型 的实时性。

一、推荐系统“特征”的实时性

1. 客户端实时特征

客户端是最接近用户的环节，也是能够实时收集用户会话内行为及所有上下文特征的地方，在经典的推荐系统中，利用客户端收集时间、地点、推荐场景等上下文特征，然后让这些特征随http请求一起到达服务器端是常用的请求推荐结果的方式。但容易被忽视的一点是客户端还是能够实时收集session内用户行为的地方。

如果采用传统的流计算平台，如Flink，甚至批处理计算平台，如Spark，由于延迟问题，系统可能无法在3min之内把一个session内的历史行为存储到特征数据库中，如Redis。这就导致用户的推荐结果不会马上收到session内部行为的影响，无法做到推荐系统的实时更新。

如果客户端能够缓存session内部的行为，将其作为与上下文特征同样的实时特征传给推荐服务器，那么推荐模型就能实时得到session内部的行为特征，进行实时推荐，这就是利用客户端实时特征进行实时推荐的优势所在。

2. 流计算平台的准实时特征处理

流计算平台（比如storm、spark streaming、flink）将收到的日志以流的形式进行批量微处理，然后立刻缓存到特征数据库，供推荐模型使用。由于每次需要等待并处理一小批日志，流计算平台并非完全实时的平台，但他的优势在于能够进行一些简单的统计类特征的计算，比如一个物品在该时间窗口内的曝光次数、点击次数、一个用户在该时间窗口内的点击话题分布等等。

流计算平台计算出的特征可以立刻存入特征数据库供推荐模型使用，虽然无法实时根据用户行为改变用户结果，但分钟级别的延迟基本可以保证推荐系统能够准实时地引入用户的近期行为。

3. 分布式批处理平台的全量特征处理

随着数据最终到达以hdfs为主的分布式存储系统，spark等分布式批处理计算平台可以进行全量特征的计算和抽取。在这个阶段着重进行的还有多个数据源的join以及延迟信号的合并等操作。

有时候用户的各种数据，比如曝光、点击、转化是互相相关，但是会在不同的时间段到达服务器（有的间隔甚至小时级别，HDFS hadoop分布式文件系统）。因此使用分布式批处理平台，在全量数据特征准备好以后，再进行后续操作，无法保证推荐实时更新，但是兼顾了推荐系统特征的全面性，为了用户下次登陆更准确的推荐。

二、推荐系统“模型”的实时性

与“特征”的实时性相比，推荐系统“模型”的实时性往往是从更全局的角度考虑问题，特征的实时性力图用更准确的特征描述用户、物品和相关场景，从而让推荐系统给出更符合当时场景的推荐结果。而模型的实时性则是希望更快的抓住全局层面的新数据模型，发现新的趋势和相关性。

特征的实时性会根据用户最近的行为更快的发现用户可能感兴趣的商品，但绝不会发现一个刚刚流行起来的爆款商品、一个刚刚开始的促销活动，以及与该用户相似的人群的最新的偏好。要发现这类全局性的数据变化，需要实时的更新推荐模型。

模型的实时性由弱到强的训练方式分别是全量更新、增量更新和在线学习。

1. 全量更新

部分时期的数据对模型进行更新；实时性较差；

2. 增量更新

增量更新仅将新加入的样本“喂”给模型进行增量训练。从技术上讲，深度学习模型往往采用随机梯度下降法及其变种进行学习，模型对增量样本的学习相当于在原有样本的基础上继续输入增量样本进行梯度下降。增量更新的缺点是：增量更新的模型网网无法找到全局最优点。因此在实际的推荐系统中，经常采用增量更新与全局更新结合的方式，在进行了几轮增量更新后，在业务量较小的时间窗口进行全局更新，纠正模型在增量更新过程中积累的误差。

3. 在线学习

在线学习是进行模型实时更新的主要方法，也就是在获得一个新的样本即更新模型。与增量更新一样，在线学习在技术上也通过SGD的训练方式实现，但由于需要在线上环境进行模型的训练和大量模型相关参数的更新和存储，工程化要求比较高。

在线学习的另一个附带问题是容易导致模型的稀疏性不好。例如， 在一个输入特征向量达到几百万维的模型中，如果模型的稀疏性好，就可以在模型效果不受影响的前提下，尽让极小一部分特征对应的权重非零，（从而让上线的模型体积很小(因为可以摒弃所有权重为0的特征)，这有利于加快整个模型服务的过程。但如果使用SGD的方式进行模型更新，相比batch的方式，容易产生大量小权重的特征，增大模型体积，增大部署难度。

在在线学习的过程中兼顾在线学习模型效果&稀疏性的研究（FOBOS、FTBL）。还有方法：强化学习的竞争梯度下降用于在线学习。

4. 局部更新

降低训练效率低的部分的更新频率，提高训练效率高的部分的更新频率。

例如GBDT+LR的模型结构，模型利用GBDT进行自动化的特征工程，利用LR拟合优化目标。GBDT是串行的，需要依次训练每一棵树，因此训练效率低，更新的周期长，如果每次都同时训练GBDT+LR整个模型，那么GBDT的低效问题将拖慢LR的更新速度。为了兼顾GBDT的特征处理能力和LR快速拟合优化目标的能力，Facebook采取的部署方法是每天训练一个GBDT模型固定GBDT模型后，实时训练LR模型以快速捕捉数据整体的变化。通过模型的局部更新，做到GBDT和LR能力的权衡。

模型局部更新的做法较多应用在embedding层+神经网络的深度学习模型中，embedding层参数由于占据了深度学习模型参数的大部分，其训练过程会拖慢模型整体的收敛速度，因此业界往往采用embedding层单独预训练和embedding层以上的模型部分高频更新的混合策略。

5. 客户端模型实时更新

客户端往往可以保存和更新模型一部分的参数和特征，比如当前用户的embedding向量。

在深度学习推荐系统中，模型往往要接受用户embedding和物品embedding两个关键的特征向量，对于物品embedding的更新，一般需要全局的数据，因此智能在服务器端进行更新；而对用户embedding来说，则更多依赖用户自身的数据，那么把用户embedding的更新过程移植到客户端来做，能实时把用户最近的行为数据反映到用户的embedding中，从而可以在客户端通过实时改变用户embedding的方式完成推荐结果的实时更新。

举一个最简单的例子，如果用户embedding是由用户点击过的物品embedding进行平均得到的，那么最先得到用户最新点击物品信息的客户端，就可以根据用户点击物品的embedding实时更新用户embedding，并保存该embedding。在下次推荐时，将更新后的用户embedding传给服务器，服务器端可根据最新的用户embedding返回实时推荐内容。

参考资料

1. 深度学习推荐系统 王喆编著 中国工信出版集团
2. 《深度学习推荐系统》读书笔记