再评Airbnb的经典Embedding论文

作者:石塔西
来源:https://zhuanlan.zhihu.com/

p/162163054

编辑:深度传送门

前言

Airbnb的《Real-time Personalization using Embeddings for Search Ranking at Airbnb》是一篇经典的论文,类似Google的Youtube论文和A view from the trenches那篇论文。而对待经典的态度就是应该多读几遍。论文没有变,但是希望你自己有所长进,能带着自己的感悟重新阅读,加深对推荐系统的理解。

这篇论文我去年就读过了,把自己的心得发表在知乎上,还收获了不少赞。其实说来惭愧,那时的我,尽管有着好几年的排序算法经验,空有召回模型的理论,但是没有亲自上手实现过召回模型。用我根深蒂固的排序思维,来理解召回算法,其实范下不少的低级错误。比如,我在回答中说认为这种非监督的学习方式是"非主流",就被同行在评论中diss了,着实让人汗颜。

最近一段时间,我开始负责召回算法。有了亲自实现、调试召回模型的经验后,才发现当初我对召回模型的理解是非常浅薄的,很多时候用排序的思维来理解召回,往往会适得其反。所以,一年后的今天,我再评Airbnb的这篇论文,炒炒冷饭,把我最新的感悟记录下来。上次评论的时候,我主要说了这篇论文的优点,这一回,我主要是想说说这篇论文的不足。论文仍然是好文章,只不过是我自己进步了。

缺点一:强套word2vec算法,强套序列、滑窗的概念

缺点

word2vec是NLP算法,它的某些概念,比如上下文、窗口,其实并不适用于推荐系统。论文强把召回问题,抽象成一个center word找context word的问题,好套用word2vec算法,反而模糊了问题的本质,加上论文中的那几幅示意图的误导,让人难以理解。

其实在一年前我的上篇评论中,就已经感受到这种理解上的困难,比如:

  • 为什么final booked listing要成为点击序列中的每个listing的邻居?

  • word2vec中的center word与context word隐含了一种顺序上的正确性。比如“我今天回家吃饭”就是一句人话,而倒过来"吃饭回家今天我"就不是人说的。而一个点击序列中两次clicked listing的顺序那么重要吗?交互了点击顺序,就是一条异常的点击序列吗?

  • 同理,word2vec中的窗口在这里适用吗?难道一条点击序列中的两个listing相隔较远,超过了窗口的限制,二者就没关系了吗?就不相似了吗?

  • 学习user-type/list-type embedding时,为什么要将user-type/listing-type画在一序列里? 代表了什么?代表了user与listing是相似的?

Airbnb算法与word2vec不是父子关系

造成这种困惑的原因是Airbnb在论文中把自己的算法描述成“衍生自word2vec”,从而不得不把所有话术都往往“父亲”word2vec那里套,把简单问题复杂化了。

其实Airbnb算法,与word2vec是兄弟关系,但是怎么命名它们共同的父亲,我尚没有很好的思路,只好以“xx2vec”算法代称。可以从如下三个方面来理解xx2vec算法的共性:

  • 相关性:看word2vec的公式,最基础的模块就是两个向量的点积。众所周知,向量点积就代表两个向量是相似的。而这里,我把这种关系定义成更广义的“相关性”。毕竟,你不能说word2vec中center word与context word是相似的,只能说它们是“相关”的。

  • Pairwise思想

    • 排序中常用的CTR预估思想,代表了一种Pointwise思想,每个样本由<user,doc,label>组成,正负例分属不同的样本

    • 而经典的召回算法,比如youtube, dssm, word2vec的公式,都采用了Pairwise的思想。以u2i召回为例,一个样本由<$u,d_+,d_{-1},d_{-2},...,d_{-N}$>组成,loss要求user与$d_+$的匹配程度尽可能高,而与$d_-$的匹配度尽可能低

      • 没错,word2vec也可以看成一种召回算法,由center word在整个词典中召回context word

      • Youtube/Word2Vec论文里面用的都是softmax,而最后都(可以)转化为pairwise模式,即一个正例配若干负例

      • 至于为什么召回用的是Pairwise思想,而不是排序常用的Pointwise思想,我以为主要是召回面对的候选集巨大(几十、上百万),目标不要求十分精确(还有排序把关),缺少显式负反馈(召回的,用户不点击,未必代表用户不喜欢,有可能是因为没有曝光)

  • 选择负样本: Pairwise中,一个正样本搭配的负样本从哪里来?

    • 一来,我不可能拿u与库中所有物料都比较一遍;二来,如果真的都比较一遍,就发现u与$d_+$未必是最匹配的

    • 因此,最常见的做法就是拿随机采样出来的做负样本。如果库足够大,随机抽样出来的,很大程度是与user"八杆子打不着的",我们有充足信心要求user与这些负样本的匹配度足够低。

    • 但是同样因为负样本是随机采样出来的,信号没那么强,使模型可能只学习到一些粗粒度的差异,False Positive可能性较大。

重新理解word2vec

按照"相关性+Pairwise+负样本"三个方向来重新理解word2vec:

  • 相关性

    • word2vec中的"相关“描述了词语的共现性,即center word与context word出现的可能性,要比center word与随机词共现的可能性高

  • Pairwise思想

    • 因为要衡量共现,所以才引入“窗口”的概念。只有在一个窗口中共现的两个词,才能构成一个正样本对儿。

    • 所以“窗口”是word2vec所独有的,并非所有类似算法不可缺少的标配。

  • 选择负样本

    • 缺乏人工显式负反馈(没有”一个词绝对不能出现在另一个词周围“的知识)

    • 只能在词库里随机抽词。如果库大,抽样数目较少,大概率抽到的都是不可能出现在center word周围的词。

重新理解Airbnb Listing Embedding算法

按照“相关性+Pairwise+负样本”三个方向来重新理解Airbnb通过点击序列学习listing embedding的算法

  • 相关性

    • 与word2vec不同,这里的”相关“就是”相似性“,而不是共现性。同属一个点击序列中的listing应该是相似的

  • Pairwise

    • 与word2vec不同,其实这里没有窗口的概念,一个序列里所有的listing可以cross join,它们彼此都是相似的

    • 但是如果全部做cross join,样本量太大,只好还考虑窗口。但是保留信号最强的那个listing,即让final booked listing与点击序列中的所有listing都相似

    • 如果还按照word2vec窗口的方式来理解,增加final booked listing作为global context,好似突然冒出来的"神来之笔"

    • 而如果参考了本来就没有什么窗口的限制,增加final booked listing,不过是水到渠成,而且还是基于工程代价考虑的保守、替代方案。

  • 负样本

    • 随机抽样,大概率是与listing不相关的,是合格的负样本

    • 但是,这种信号太弱,可能让模型学习到粗粒度的特征差异,比如“是否同城”,导致大量的false positive

    • 因此,要增加一批“同城”做负样本,缓解正样本在"地域"上的bias

重新理解Airbnb User-type/Listing-type Embedding算法

  • 相关性

    • 这里的相关性,即user-type embedding与listing-type embedding的点积,表达是二者之间的匹配性。不是word2vec中的共现性,也不是item2vec中的相似性

    • “预订成功”代表了一种正的匹配性

    • “被拒绝”代表了一种负的匹配性。从这个角度来看,加入“被拒绝”做负样本,显而易见,水到渠成

  • Pairwise

    • 与item2vec类似,这里也没有序列、窗口的限制,论文中将user-type, listing-type画在一个序列里,只能误导读者,让人徒生迷惑

    • 从公式(8)(9)中可以看到,$D_{book}, D_{neg}, D_{reject}$都是<user, listing>对,那么当中心是user时,其context只能是listing,而不能是其他user。这就更突现出图5给读者造成的误导

  • 负样本

    • 如上所述,“被拒绝”代表了一种明确的负匹配性,加入公式(8),理所应当

    • 这种人工反馈,比随机采样得到的负样本信号更强,能够让模型学习到细粒度的差异

    • 这种方式对我们有什么借鉴意义?我是做内容推荐的,内容推荐中也不乏显式负反馈,比如“曝光未点击”

      • 将“曝光未点击”与“随机抽样”,合起来做负样本,我做过尝试,效果上也没有明显提升

      • 我猜测的原因,一是“曝光未点击”本身的噪声很多,用户未点击,并不能代表用户不喜欢。可能时机不对,或者同屏的有用户更喜欢的而已。

      • 二来,从召回的角度来看,“曝光未点击”毕竟经过了上一版召回+排序的双重筛选,可能应该做权重较小的“正样本”,而不是负样本。


缺点二:人工聚类是败笔

缺点

首先我要声明,我强烈同意,“没有最好的算法,只有最合适的算法”。Airbnb通过人工聚类的方式,解决了user/listing booking太稀疏的问题,取得了好效果,为公司带来收益,那就是好算法。但是,这也不能否认,Airbnb这种人工聚类方法的缺点

  • 依赖于产品经理对业务的理解,主观性太强

  • 维护困难。比如价格变化了,那么原来价格划分方式,是否还适用?

  • 表达能力比较弱。比如房间1/2/.../5间都是独立的类别,但是,是否1间/2间的特征更相近,表示是“小房子”;而4/5间的特征更相似,表示是“大房子”。

如何在word2vec中引入画像

说白了,Airbnb所面临的问题不是其独有的,其本质是在id之外引入画像的问题,从而能够解决稀疏、冷启动的问题。

在这方面,我更加认同阿里在《Billion-scale Commodity Embedding for E-commerce Recommendation in Alibaba》一文中提出的GES/EGES算法。做起来也很容易,

  • 先把画像特征离散成id型特征

  • 每个离散化的画像,embedding成一个向量

  • 画像的embedding与用户id或物料id的embedding,pooling成一个向量,代表这个用户或物料的向量

  • 拿这个整合了id和画像的用户或物料的向量,参与Skip-Gram或CBOW的算法迭代

这样一来,如何拿各种画像相互交互,形成用户或物料的向量,是由模型自动学习到的,而不是靠人工规则。

重申一下,模型学习到的,未必就一定比人工聚类的效果更好。但是,模型自动学习到的,更顺应潮流趋势。就好比,早期的火枪故障率高,精度差,阴天下雨还打不响。有很多战例,弓箭手打败了火枪兵。但是现在,步枪已经是军队的基本装备,而弓箭大多数已经变成了体育器械。为什么?其中一个原因,就是培养一个弓箭手既费时又费钱,而火枪大幅降低了使用者的门槛。这里,模型自动学习和人工规则,也是同样的道理。


亮点:离线评估

离线评估的重要性

相比于一年前我吹捧的评论,这一次的评论主要集中于Airbnb算法中的不足。但文中还是有一点值得做召回算法的同行借鉴,就是Airbnb的离线评估方法。

离线评估在推荐、搜索场景下的重要性,再怎么强调也不过分。线上开AB实验,是评价算法有效性的终极目标。但是,AB实验的缺点也很突出:

  • 为了得到稳定结果,AB实验往往要进行一段时间,时间成本太高

  • AB实验,受外界因素的影响很大。大盘、特殊时间或事件、其他模块,都可能对AB实验造成影响,短时间内观察到的收益起伏不定,让我们难以下结论。

因此,我们做算法的,要重视离线评估。只有离线评估上有明显收益,才放到线上实验,以节省线上实验的时间成本。

离线评估召回算法的难点

但是相对排序,我感觉召回的离线离线更加难做

  • 召回缺乏显式负反馈。如果召回的,用户没有点击,可能并不代表用户不喜欢,而可能是压根没有曝光给用户。而没有曝光的原因有很多,比如排序偏向老召回,没有将你的召回结果排上去;或者你本路召回,在多路召回融合时的配比太低。

  • 召回,受后面的粗排、精排的影响较大。配合不好,可能排序会大大减弱你这一路召回的影响。

  • 召回之间存在重叠、竞争的关系。没准你单路召回的指标非常好看,但是对大盘没什么影响,原因这一路召回的东西和其他线上的召回返回的结果,重合度太高了。

所以,相比于排序,召回的离线评测与线上效果之前存在更大的gap。但是仍然要做,最起码,离线评估不能告诉你这一路召回有多好,但是这一路召回有多差,倒是能够清楚显示出来。

Airbnb对召回的离线评估

论文的第4.2节描述对召回结果的定量分析。简单来讲,就是用户正反馈的listing在召回列表中的平均位置。这个平均位置越低,说明模型的效果越好。

除了定量分析,文中还介绍Airbnb开发了一个工具,帮助人工评测“源listing”与“召回listing”是否相似。尽管是人工评测,无法自动化,也无法量化,不能告诉你召回结果有多好,但是如果效果结果太差,却能让人印象深刻。


小结

相比于一年前的吹捧,这一回的评论,我主要关注这篇论文的不足之处

  • 从算法技巧上来看,这篇论文描述的算法,不如阿里的EGES

    • 在“在word2vec中引入画像”方面,EGES的“embedding+pooling”的方法,要比这里“人工规则聚类”的方法,更加是大势所趋,更加有模仿的价值。

    • EGES根据图上的随机游走产生序列,产生的序列突破了单个用户序列的限制,能够描述user/doc之间更深层次的关系。

  • 而从结合业务实际,选择样本上来看,Airbnb的这篇论文仍然是我们学习的榜样

    • 增加final booked embedding突破了word2vec对窗口的限制

    • 增加“同城负例”与“显式拒绝”,增加了更强的负信号,能够让模型学习到正负例之间细粒度的差异,减少False Positive

    • 如果不强套word2vec,不在“序列+窗口+上下文”的语境下阐述算法,就更清晰了

最后,还是要强调,尽管本次的评论指出它的很多不足,但是Airbnb的这篇论文仍然是一篇值得多读几篇的经典。论文依旧,而我两次评价迥异,无它,是因为我自己进步了:)

你点的每个“在看”,我都认真当成了喜欢

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页