推荐系统-CTR答疑

Posted 2021-10-14 我家大宝最可爱

question2

ctr预估算法对于序列特征embedding可否做拼接，输入MLP?与pooling相比，优劣在哪？
ctr预估算法或者推荐系统中的排序算法，目前的主流做法是embedding＋MLP，对于序列特征，比如浏览或者点击过的物品序列，除了采用pooling，比如求和，平均或者DIN的加权求和，可否对物品序列按照时间顺序对embedding向量做拼接，作为MLP的输入？

可以直接concat

深度ctr预估中id到embedding目前工业界主流是端到端直接学习还是预训练?

深度ctr预估中id到embedding目前工业界主流是端到端直接学习还是预训练?
item id的embedding是直接在模型中端到端学习, 还是通过类似item2vec预训练得到?
user id 是否要添加作为特征,端到端还是预训练?
类似Deep Interest Network这种, 已经用历史行为表达用户特征的模型中,再添加user_id端到端学习usr embedding是否有必要?
id是否要过滤掉样本中低频出现的id? 是否需要过滤掉高频?
如果是端到端,id如果本身是string, 需要先映射到整数获得onehot. 是维护一套映射表, 还是直接hash到整数?

统计用户历史1天，2天，3天，。。。。N天内的完单量，本质是一种直方图的思想。

对实体one-hot时候到底要不要用hash trickhash trick有两种常见的策略：

1. hash后的维度跟之前接近，主要是省掉一个映射表同步的工程成本，加速计算。
2. hash后的维度显著小于原始维度，相当于把大量实体当作同一类看待，作为一种降维方式。

一般来说，
1基本上没有太多负面作用，如果工程成本下降很多那么就应该用，冲突率要自己控制一下。
2的话就又回到之前的玄学问题上，我们也不知道这种方式到底破坏了多少信息，又能降低多少给模型增加的容量。
虽然这个方法不是很对搞物理的人的胃口，但确实在一些场景下它会有正向收益。它可以看成是一种随机投影方式，随机投影也确实是有效的，高维数据并不符合我们低维的直觉。如果希望更有可解释性，并且工程开销能够接受，可以进一步考虑把相似的实体算作一类来one-hot，
常见有几类实现：聚类，对簇进行one-hot设计hash函数的时候考虑其业务意义使用GBDT的叶子节点做one-hot，同样叶子节点上的样本可以看做具有某种相似性。

孔某

CTR预估：(标签-权重)列表类特征怎么输入到模型？

这个问题抽象出来就是给定一个由若干个(item_id,weight)组成的列表，如何将这个信息用在模型里面。通常来说这种列表的含义可以是用户历史偏好的item_id以及偏好权重，或者历史收藏加购过的商品或者对应店铺的次数等等。对于问题中的数据 [(‘标签1’, 0.8), (‘标签2’, 0.65), (‘标签3’, 0.32), (‘标签4’, 0.05)]一般情况有一下两种做法来使用这个信息：不考虑上下文因素，直接将这个列表输入。回归到最简单的情况，给定一个无权序列，我们一般可以通过sum/mean pooling 的方式将一个变长序列压缩到一个定长的向量，输入给我们的模型。那么对于带权序列，其实可以看作是一个weighted sum/mean pooling的过程，其实有点类似引入一个attention机制，只不过attention score是预先计算好的。这种方法完整保留了用户所有的偏好信息，更多的是作为一种用户侧表征。对于上述数据，我们得到的表示向量为(不考虑score的归一化)0.8emb(标签1)+0.65emb(标签2)+0.32emb(标签3)+0.05emb(标签4)2. 考虑上下文因素，根据当前预估item进行一个查表操作。比如我们当前打分item属于标签1，那么直接查表得到(‘标签1’, 0.8)，这个时候我们可以选择直接使用权重0.8作为输入，或者选择用0.8*emb(标签1)作为输入。这种方法表达的是用户对于当前item的偏好。