优秀的定制网站建设服务商,北京小程序开发推荐,做网站可以先做再给钱吗,小型企业网站开发公司看到一个din的源码#xff0c;将userid也构建了emb table。
于是调研了一下。即推荐算法需要建模userid吗#xff1f;
深度学习推荐算法中user-id和item-id是否需要放入模型中作为特征进行训练呢#xff1f;
深度学习推荐算法中user-id和item-id是否需要放入模型中作为特…看到一个din的源码将userid也构建了emb table。
于是调研了一下。即推荐算法需要建模userid吗
深度学习推荐算法中user-id和item-id是否需要放入模型中作为特征进行训练呢
深度学习推荐算法中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时应该怎么用 - 知乎
深度学习推荐算法中user-id和item-id是否需要放入模型中作为特征进行训练呢 - 知乎
电商推荐算法中用户id和商品id是否需要作为模型特征 - 知乎
