网页跳转到别的网站,甜品店网页模板html,电子商务网站设计的认识,做设计必看十大网站文 | 水哥源 | 知乎Saying1. 工业特征处理和学术特征处理存在巨大差异#xff0c;这里建议同学们一定认真阅读。这个差异可能引发未来各种方法落地的矛盾。2. full embedding在概念上和one-hot的操作等价#xff0c;但在操作上省略了这个过程。3. hash是最省事的#xff0c;… 文 | 水哥源 | 知乎Saying1. 工业特征处理和学术特征处理存在巨大差异这里建议同学们一定认真阅读。这个差异可能引发未来各种方法落地的矛盾。2. full embedding在概念上和one-hot的操作等价但在操作上省略了这个过程。3. hash是最省事的一切特征转string一切string转hash。4. 在embedding分解这里没有融入一些语义信息是比较遗憾的如果有万能的知友看完后搞出来了请给我一个致谢。这是 【从零单排推荐系统】 系列的第17讲承载上一讲这里要详细聊聊特征生成和取embedding的过程是怎么样的。需要注意的是这一讲的东西可能会构成学术界和工业界最大差异的两个地方。在阅读论文的时候判断其中所讲的东西有多大概率能在实践中work有两个参考问题1该论文的特征机制如何处理源源不断的新的特征或者新的ID2该论文的训练机制是否与online learning的习惯冲突 根据我个人的经验和上面两个点有冲突的方案难以在工业实践中带来提升即使费了劲把这两个问题解决了最后效果可能也是平的。具体来讲特征处理就是一个典型的学界/工业界有裂痕的例子本讲会回到embeddingDNN这个范式的上面部分聊一聊特征的生成方式和业界对于embedding的一些重新思考。特征生成在学术研究中有很多特征本身就是类别categorical特征比如城市枚举国内的所有城市你一定在其中之一。我们往往把各类ID也看做类别特征比如总共有1000个用户这次遇到的用户是哪一类。与类别特征直接相关的处理方式就是先变成one-hot的向量只有属于的那一个bin是1其他的都是0在经过一个矩阵 转化到浮点向量参与后面的处理。举个例子我们在用户侧有性别User ID城市三种特征。在科研情景中我们就有三个one-hot的特征每一个都通过乘以矩阵 转化为embedding如下图所示或者也可以把他们组合成multi-hot的向量然后用一个统一的大 来映射。这是典型的科研场景下的问题描述形式。工业界的处理方式大致符合上面的操作但和常见学术论文有一个区别是并不存在一个真正的one-hot特征更不存在从one-hot特征乘以 再映射到向量的过程。这是大部分同学或是初学者最容易不理解的地方。首先在大型工业场景下会源源不断出现新的item新的用户新的ID原先的one-hot和 必须得不断扩充。但是这个过程并没有什么必要性在one-hot乘以权重这个操作中实际上就是取出了 1对应的 的那一列而已等于0的那些列根本就没用。那我们干脆新出现哪个1给它分配一个列向量就好了。这也就是embedding look-up table的操作。所以说工业实现概念上和one-hot一样操作上不一样。第二个区别是特征高度ID化一切特征都可以是ID原来不是ID的特征也转向ID。由于没有one-hot这个过程还需要一个东西记录非0出现的位置这个位置就可以看作是所有特征的ID。比如城市这个特征我们可以把第一个出现的特征记为cityID1第二个出现的记为cityID2等等。但是这样又会遇到一个问题目前增长到哪了是需要记录的而且需要在各个机器中互相传递否则A机器上新出现了一个你定义为第11但是在B机器中出现可能是第13个这就出问题了。如果要针对这个同步的问题做处理那么又得在机器之间做通信比较麻烦。防止这个问题的做法就是对特征本身做hash将得到的数字作为它的ID。只要每台机器用的hash算法一样出来的值就是一样的。用hash还有第二个动机就是其实我们也不希望ID是无限增长的。使用hash之后可以保证所有特征一定都在某个空间中不会出现意外。所以有一种做法是我们给一种特征分配一个编号称为Slot ID每一个特征的取值我们hash后得到一个ID称为FIDfeature ID在一个n位的二进制数字中前k位用slot ID的二进制表示填充后面n-k位用FID填充组成一个整体数字作为这个feature的最终表示。经过这个操作可以保证每一个特征的取值都有唯一的取值如果不考虑碰撞的话。hash表示的最大好处是它可以处理至少是处理处理的好不好是另一回事所有类型的特征只要你是能写出来的就可以用string表示只要你能用string表示你就能hash。实际中完全可以先全部hash跑起来然后再细分有些特征需不需要特别处理。既然是使用hash那么不可避免的会遇到碰撞的问题。原则上我们不希望有任何两个不一样的特征被hash到同一个ID上所以会尽量选择好的算法比如cityhash。但是问题也没有那么严重很多特征都有生命周期。像广告中的item ID预算没了不投放了可以认为那个ID没啥用了。可以设计遗忘机制。当我算出一个ID之后看到记录上一次算出这个ID是很早之前了就可以再次初始化embedding让一切重新开始。Embedding压缩与分解embeddingDNN是一个“头重脚轻”的方案几乎所有的内存消耗都压在embedding的存储上面。如果是按照one-hot那样内存会随着时间线性增加这是一个很大的消耗。如果按照上面说的hash的方法可以避免内存线性增大总的内存消耗和我们开的空间大小有关。但问题是既然是hash就一定有碰撞。如果空间设的很大碰撞概率低效果好但内存大反之若空间开的很小那么碰撞概率就会增大对效果有不好的影响。有没有方法可以做巧妙的权衡这种动机在近两年引领了一波新的风潮一种直接的思路是把一个大的ID拆解成数个小的ID的组合[1]。然后最终的embedding也是在这两个小ID的embedding上做某种操作得到的。我们会想到可能有两个大ID在某一个小ID中出现了碰撞但是只要最终的表示中另一个小ID不同我们就认为最终的表示是不同的。首先介绍的是一个Facebook发表在KDD2020上的方案把一个大的ID拆解成商余数的组合。比如一种特征的ID取值介于1-1000000之间。完全保存这种特征的embedding需要 的空间这里 代表平均的特征维度。我可以找一个除数 然后把特征ID唯一的表示为原始ID除以 后得到的商和余数。 这里就选1000商会有大约1000种取值而余数也是有大约1000种。然后原始特征的embedding现在表示为商和余数的两个embedding的组合可以是拼接也可以是加起来或者element-wise乘。由于商和余数各自只有1000种选择现在整个空间压缩到了2000相比于1000000有500倍的压缩这个压缩是一个平方级的减小。当然我们会有疑问2001和2002这两个ID算下来商是一样的那不就意味着有一半的embedding都是一样的吗是的所以这个方法一定会带来性能折损实验部分也能体现的出来。但是这个方法在实验中比直接hash到2000要好。沿着上面的思路还可以有更加通用的方案分成固定的若干个互补分区。比如上面的商和余数的方案还可以对余数再取 的商和余数一直往下。也可以拿出这个ID范围内的所有质数把能整除某个质数的放一起等等。综合下来对原始复杂度是指数级的衰减。类似的方法也有今年CIKM的一个方法[2]通过控制二进制表示来压缩空间但这些方法有一个没有解决的问题是分配到多个分区的过程没有什么逻辑依据缺乏“语义”。2001和2002因为商一样所以前半段embedding都是一样的但是它们也有可能是两个完全没有联系的特征那有一半embedding都一样就不太合理了。根据我们在FM那几讲中提到的观点embedding还是要承载一些语义信息的。期望中应该是类型上更接近的特征共享的概率越大反之亦然。现在还没有看到有工作涉及这方面看到这里的读者可以赶紧动手攒paper了其实embedding压缩还涉及一个方向是Network Architecture SearchNAS后面在热点篇里面专门做介绍这里简单提一下也是可以给各个不同的特征分配不同的权重。总结一下无论什么样的压缩方案肯定都会对效果有影响毕竟天下没有免费的午餐。但是选用什么样的方案就是根据环境的。在业务还没完全起来的时候用一些embedding压缩的方案是性价比较高的选择。Deep Hash EmbeddingDHE[3]回到最开始的问题我们说embedding占用的空间那么大其本质原因在什么地方呢在于我们把原始特征表示为one-hot的不是0就是1的表示方式当然是需要很大维度才能表示的。如果我们有一个非学习性的方法一上来就把特征ID表示成浮点数会怎么样如果能表示成一段浮点数的向量会怎么样如果找到了这样的方法后面的事情是水到渠成的可以就地接一个MLP把前面的特征表示变换到一般要用的embedding再接下面的DNN这样空间的占用一下就下来了如下图所示在第一步图上也强调了是non-learnable的对应左边的look-up table需要占 的空间而右边的MLP就少非常多了这样就大大减小了存储消耗。那么怎么把一个原始的ID变成浮点向量呢首先可以考虑变成整型的向量我们可以联想到不同的hash方式可以得到不同的int同一种hash加不同的种子也可以做到这一点。当使用各种hash方法/种子拼出一个高维的整数向量后再做归一化高斯化就可以得到所需要的浮点数向量把这个向量送入下面的“decode” MLP即可。这个方案的另外一个考虑是基于冲突上面讲的hash方法其实都是存在冲突可能性的。即使是上面商余数的方案表面上看最终的embedding不一样但是局部的冲突可能很大。而使用了许许多多hash方法的结果后再经过网络变换最终到了embedding表示这里冲突的概率就很小了。有一个缺点是由于embedding也是网络生成的了一点参数的变化会引起全局特征漂移这样对记忆性的原则有影响因此论文中的实验还是没有打过完全不冲突的look-up table。这个文章很有意思它是完全根据实际应用场景遇到的问题提出的方案。如果这条路真的能走得深而且work的话可能会是一个很有前途的方向还有不少可以做的事情。下期预告推荐系统精排之锋12DINDIEN机器学习唯一指定涨点技Attention往期回顾召回 粗排 精排如何各司其职拍不完的脑袋推荐系统打压保送重排策略简单复读机LR如何成为推荐系统精排之锋召回粗排精排-级联漏斗上召回粗排精排-级联漏斗下推荐系统精排看阿里妈妈再试线性模型推荐精排之锋FM的一小步泛化的一大步推荐中使用FNN/PNN/ONN/NFM优化特征交叉聊聊推荐系统的高阶特征交叉问题真正的高阶特征交叉xDeepFM与DCN-V2GBDT是如何成为推荐系统顶级工具人的DNN与推荐两大门派一念神魔功不唐捐后台回复关键词【入群】加入卖萌屋NLP/IR/Rec与求职讨论群后台回复关键词【顶会】获取ACL、CIKM等各大顶会论文集 [1]Compositional Embeddings Using Complementary Partitions for Memory-Efficient Recommendation SystemsKDD2020 https://arxiv.org/pdf/1909.02107.pdf[2]Binary Code based Hash Embedding for Web-scale ApplicationsCIKM2021 https://dl.acm.org/doi/pdf/10.1145/3459637.3482065[3]Learning to Embed Categorical Features without Embedding Tables for RecommendationKDD2021 https://arxiv.org/pdf/2010.10784.pdf
