如何增强推荐系统模型更新的实时性？

全量更新

模型训练最常用的方式就是全量更新。模型会利用某时间段内的所有训练样本进行重新训练，再用训练好的新模型替代“过时”的模型。

但全量更新需要训练的样本量大，因此所需训练时间较长；而且全量更新往往在离线的大数据平台上进行，如 spark+tensorflow，因此数据的延迟也较长，这都导致了全量更新是“实时性”最差的模型更新方式。

事实上，对于已经训练好的模型，可以仅对新加入的增量样本进行学习就可以了，这就是所谓的增量更新。

增量更新 (Incremental Learning)

增量更新仅将新加入的样本喂入模型进行增量学习。 从技术上来说，深度学习模型往往采用随机梯度下降（SGD）以及其变种进行学习，模型对增量样本的学习相当于在原有样本的基础上继续输入增量样本进行梯度下降。因此在深度学习模型的基础上，由全量更新改为增量更新的难度并不大。

但工程上的任何事情都是 tradeoff，永远不存在完美的解决方案，增量更新也不例外。由于仅利用增量样本进行学习，因此模型在多个 epoch 之后也是收敛到新样本的最优点，而很难收敛到原所有样本 + 增量样本的全局最优点。

因此在实际的推荐系统中，往往采用增量更新与全局更新相结合的方式，在进行几轮增量更新后，在业务量较小的时间窗口进行全局更新，纠正模型在增量更新过程后中积累的误差。在“实时性”和“全局最优”中间进行取舍和权衡。

在线学习（online learning）

“在线学习“是“增量更新”的进一步改进，“增量更新”是在获得一批新样本时进行增量更新，而在线学习是在每次获得一个新样本的时候就实时更新模型。在线学习在技术上也可以通过 SGD 类的方式实现。但如果使用 general 的 SGD 方法，在线学习会导致一个很严重的问题，就是模型的稀疏性很差，打开过多“碎片化”的不重要特征。

我们关注模型的“稀疏性”某种意义上也是工程上的考虑，比如在一个输入向量达到几百万维的模型中，如果模型的稀疏性好的话，可以在模型效果不受影响的前提下，仅让极小一部分维度的输入向量的对应权重非零，也就是说在模型上线的时候，模型的体积是很小的，这无疑有利于整个模型 serving 的过程。无论是存储模型所需的内存空间，以及线上 inference 的速度都会因为模型的稀疏性收益。

本文地址：http://www.6aiq.com/article/1579758694609
本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出
知乎专栏点击关注

如果使用 SGD 的方式进行模型更新，相比 batch 的方式，容易产生大量小权重的特征，这就增大了模型部署和更新的难度。那么为了在在线学习过程中兼顾训练效果和模型稀疏性，有大量相关的研究，最著名的包括微软的 RDA，google 的 FOBOS 和最著名的 FTRL 等，篇幅原因这里不展开讲在线学习的具体方法，对细节感兴趣的同学推荐参考冯扬的文章在线最优化求解 (Online Optimization) 。

模型局部更新

提高模型实时性的另外一个改进方向是进行模型的局部更新，大致的思路是降低训练效率低的部分的更新频率，提高训练效率高的部分的更新频率。这种方式比较有代表性的是 facebook 的 GBDT+LR 模型。

图 2 GBDT+LR 的模型结构

我们在之前的文章王喆：回顾 Facebook 经典 CTR 预估模型中已经介绍过 GBDT+LR 的模型结构，模型利用 GBDT 进行自动化的特征工程，利用 LR 拟合优化目标。由于 GBDT 是串行的依次训练每一颗树，因此训练效率不高，更新的周期较长，如果每次都同时训练 GBDT+LR 整个模型，那么 GBDT 的低效问题将拖慢 LR 的更新速度。因此为了兼顾 GBDT 的特征处理能力和 LR 快速拟合优化目标的能力，Facebook 采取的部署方法时每天训练一次 GBDT 模型，固定 GBDT 模型后，准实时的训练 LR 模型以快速捕捉数据整体的变化。那么通过模型的局部更新，做到了 GBDT 和 LR 能力的权衡。

模型局部更新的做法也较多采用在 Embedding 层 + 神经网络的深度学习模型（例如图 3 的 W&D 模型）中，因为 Embedding 层负责将高维稀疏输入向量转换为稠密 embedding 向量，因此 Embedding 层一层的参数往往占深度学习模型 90% 以上。因此 Embedding 层的更新会拖累模型整体的更新速度，因此业界也往往采用 embedding 层单独训练甚至预训练，embedding 层以上的模型部分高频更新的策略。

图 3 Wide&Deep 模型是经典的 embedding+NN 的结构

客户端模型实时更新

在上篇文章中介绍“特征”实时性的部分，提到了客户端“实时特征”的方法。既然客户端是最接近用户的部分，实时性最强，那么能否在客户端就根据当前用户的行为历史更新模型呢？

客户端模型实时更新在业界也是仍处于探索阶段的方法。难点在于分布在每个客户端模型的更新与服务器端模型的更新的协同问题。也许可以采用类似 parameter server 架构的模型更新策略，但本质上，模型的更新不会对用户的推荐产生十分显著的影响，采用客户端模型实时更新的必要性也不是非常大。这里想介绍的其实是一种简化的客户端模型更新策略，用户 embedding 的实时更新。

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

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

当然，用户 embedding 的生成过程可以使用更复杂的网络和 embedding 方法进行生成，如果能与整个网络解耦合，并单独部署到客户端，同样可以进行实时更新。

按惯例提出两个讨论题，欢迎大家积极分享自己的见解：

1、模型实时性到底是否重要？在模型更新时，你是否能通过自己的工作经验来直观解释模型到底新学到了什么知识？

2、你觉得影响模型实时更新的工程制约因素有哪些？即使在理论层面解决了 online learning 的问题，有那么容易上线吗？