【推荐算法】userid是否需要建模

sdbhewfoqi

已于 2024-02-07 16:17:10 修改

阅读量799

点赞数 8

分类专栏：推荐系统文章标签：推荐算法

于 2024-02-05 01:05:43 首次发布

本文链接：https://blog.csdn.net/weixin_31866177/article/details/136034812

版权

推荐系统专栏收录该内容

72 篇文章 19 订阅

订阅专栏

看到一个din的源码，将userid也构建了emb table。

于是调研了一下。即推荐算法需要建模userid吗？

深度学习推荐算法中user-id和item-id是否需要放入模型中作为特征进行训练呢？

回答1：

大厂会将user id / item id作为特征加入推荐模型，因为他们的数据足够多，算力足够强。
大厂的APP的资深用户的行为足够将他们的user id embedding训练出来。
大厂APP的热门物料会曝光十几万、甚至几十万次，这么多日志足够将这些item id embedding充分训练出来。
如果小厂的推荐模型就不建议使用这些id当embedding了，数据不够，你加进去也学习不出来。

另外这些特征加入模型的位置也非常重要，否则也会被淹没在其他特征中，泯然众人矣。

回答2：

user_id和item_id作为强记忆型特征，是否要放入模型中作为特征进行训练是不能一概而论的。至少需要考虑业务场景的特点、如何放到模型中两个因素。

一般情况下在真实的业务场景中，无论是用户行为还是物品受欢迎程度都呈现长尾分布，少数头部的user和item占据了样本中的绝大多数，他们的id embedding能够得到充分的学习；另一方面，大量的尾部user和item的在样本中出现的频率很低，因而他们的id embedding在模型训练结束后也没有经过几次参数更新，基本上比随机初始化的状态好不了多少。默认情况下，推荐算法都是对中长尾的user和item（比如冷启动用户、新加入的物品）不友好的。

user_id和item_id作为特征直接加入到模型中，基于长尾分布的用户行为日志训练的推荐模型会越来越偏好头部物品，在导致“富者越富”的同时伤害中长尾物品的曝光机会和用户满意度。

通过分析精排模型的特征重要度，我们发现重要度较高的特征主要集中在少量的“记忆性”特征上，而大量的中长尾特征的重要度都很低。“记忆性”特征指的是没有泛化能力的特征，如用户ID、物品ID、用户对物品ID在过去一段时间上的行为统计，在这些特征上无法学到能够迁移到其他物品的知识。常规的模型结构会产生特征重要度的长尾分布，最终带来了模型偏好物品的长尾分布。

总的来说长尾分布越严重的场景越不建议直接加入user_id和item_id作为特征（也不是绝对的，可以加到特殊的模型结构中，参考下文）。当然这里的长尾分布是按照user和item分开看的，确实存在一些业务场景在user这个维度长尾分布很严重，但在item这个维度长尾分布并不突出，这种情况下是可以把item_id作为特征直接丢给模型学习的。

具体来说：

物品池大小适中且基本保持稳定的场景建议加item_id特征；
物品池频繁汰换的场景不建议加item_id特征；
新用户占比很高的场景不建议加user_id特征；
小流量场景不建议加user_id特征；
其他场景大家根据user和item的分布情况自己评估；
搞不清楚的时候可以考虑加item_id，不加user_id。

如何添加user_id、item_id特征？添加在模型结构的什么位置也是有讲究的。

物品池大小适中且基本保持稳定的场景item_id可以和其他特征放在一起训练
user_id等强区分性特征可以放在单独的塔中学习user bias；不和其他常规特征放在一起。
- user bias是有些用户天然喜欢给物品打高分，浏览很广泛，有些用户天然很挑剔
在长尾分布较严重的场景，user_id、item_id等强区分性特征embedding可以做特征粒度的dropout后再与其他特征embedding拼接。注意这里说的是“特征粒度的dropout”，不是常规的神经元粒度的dropout，也就是说特征embedding整体有一定的概率被丢弃（mask）或保留。
也可以考虑使用@石塔西提到的“补水塔”结构。
记忆型特征放在一个单独的塔中，泛化性特征放在另外的独立塔中；引入一个基于物品分布的门控机制，让头部的物品主要拟合“记忆特征”，中长尾物品主要拟合“泛化特征”。通过加权求和的方式在各个特征上学习到的表征特征，再去拟合最终的业务目标。参考谷歌的Cross Decoupling Network (CDN) 。

推荐算法user_id在train和serving时应该怎么用？

推荐算法user_id在train和serving时应该怎么用？ - 知乎

第一次做推荐，看了几篇论文发现都会用到id类特征，比如在电商推荐领域，可能会用到user_id和item_id，随机初始化该类特征的向量表进行模型训练，那么在线服务时怎么对未出现的user_id进行预测呢？

回答1：

1、比较简单的做法，直接将那些新userid的embedding全部设置0，同样对那些出现次数少的userid也设置0，次数少说明该用户训练不够充分，可以直接设置0。

2、训练的时候对样本中的userid随机采样，将他们的userid都设置成同一个id，让其在模型中训练，serving的时候新用户以及出现次数少的用户的embedding就可以用该id的embedding。

回答2：

对于新id（新用户或新物料的id），一般作法是：

训练时，随机初始化
预测时，以全零向量代替。

多说一句，以上作法不是new user id或new item id的专利，而是Parameter Server的通常作法。比如遇到一个new tag, parameter server也是这样处理这个new tag在train & predict时的embedding的。

这样做是出于简单易行，但并非没有缺点。

为了解决这一问题，业界提出使用meta-learning的方式学习出new user/item id的最优初值。在《互联网大厂推荐算法实战》的8.2.3节对meta-learning在推荐冷启动中的应用有专门的论述。书中提出将meta-learning应用于推荐算法，不能简单照搬，而需要在应用范围、优化目标、生成方式三个方面进行改造。

回答3：

1.把这个user id丢掉，或者0向量填充

2.训练的时候对所有长尾的id共享一个向量作训练，预测出现新的id用这个表示

另外，既然是第一次出现的user id，必然是新用户了，可以对新用户单独做个冷启动模型。

参考：

推荐算法user_id在train和serving时应该怎么用？ - 知乎

电商推荐算法中，用户id和商品id是否需要作为模型特征？ - 知乎