作者 | MECH 整理 | NewBeeNLP https://zhuanlan.zhihu.com/p/616880233
大家好,这里是 NewBeeNLP。
Que2Search是Facebook的经典论文,之前我们详细解读了Que2Search的技术方案和一些个人的思考,感兴趣的同学可以移步观看:
笔者在OPPO搬砖的时候,在我司搜索广告场景上线了改进版的Que2Search模型,取得了不错的效果。
本文主要分享笔者将Que2Search应用在特定场景的改进措施和绿厂搜索广告中query召回路的设计,看看笔者如何用Facebook这篇“老汤”来煮我司的这盘“新菜”。
笔者负责的OPPO搜索广告场景是OPPO手机中的浏览器和应用商店的搜索广告业务,其商业模式为,用户输入query,下拉栏联想页、搜索落地页都会有相应的广告位来推荐app。在该场景下,app就是广告,因此我们的核心业务就是输入一个query,召回一批app。其中联想页场景的产品形态示例如下:
oppo应用商店联想页示例
和业界大多数召回架构一样,oppo搜索广告为多路召回的模式,分别由以下几路召回组成:
多路召回的优点就是多目标分开建模,每一路都有自己的目标和特点,召回也更多需要考虑多目标间的权衡:
今天要分享的Que2Search模型落地主要是负责在query-app这一路上的优化,目标就是优化query和app间的相关性。
我们先复习下Que2Search特征和样本的设计。忘记的同学请自觉回上篇观看并且三联,靴靴~
Query塔侧有query的3-gram list哈希然后sum pooling、query的XLM embedding、还有国家的emedding。
对于笔者来说,该场景仅面向国内,国家的embedding自然不需要了,XLM也自然被替换成了中文Bert。根据经验,英文等字母类语言3-gram特征比较有效,而中文则是2-gram效果比较好。所以Query塔的特征改动为:
原论文使用了商品title的3-gram、商品描述3-gram、商品title XLM embedding、商品描述XLM embedding、商品图片的GrokNet embedding,doc塔还有一个特殊的多标签多分类label。
在笔者的场景下,笔者做出了如下改动:
主要目标既然是相关性,那最好的样本设置方式其实就是让人工来标注相关性语料,但这种操作放在哪家公司都是不可能让你这么干的,除非你掏钱(就我那点工资标注人员看了都直摇头T^T,贷款上班的活咱不干)。
因此笔者需要像Que2Search一样设置一种弱监督正样本策略,能让训练集尽可能满足相关性目标。目前笔者使用的方法是在点击数据的基础上卡一个ctr阈值,使大于该阈值的query-app对成为正样本,负样本就用batch内负采样的方式来获取。
初版的Que2Search离线评估效果recall指标比baseline低5个百分点。笔者在上线Que2Search前曾经上线过一个base版本模型,该base模型正样本策略和本文一样,负样本在app库中随机采样的,但模型使用的是一个非常浅层的sentence-bert,并且特征也只有query和app名称。
Que2Search在引入了如此多特征的情况下居然还比不过base模型,有点让人惊讶,于是乎笔者通过分析数据和模型部分结构的表现,发现了如下几个问题:
针对上面分析出的问题现象,笔者做出了对应的优化和改进。
上面我们提到了,doc侧多分类label由于热门效应导致很多app只有缺省类别。而热门app却有非常多的类别,并且由于label处的数值=
,因此虽然label多,但是每个label的值却低,形成了一个非常困难的样本分布不均衡、label太小难预估的尴尬场景。
所以,笔者在这里分析后删除了这个多分类任务,将这些app的历史点击query作为特征加入到app侧,辅助理解app内容,这样就减弱了缺省类别过多带来的直接影响。
上面的问题中提到了,query输入混乱难以理解,但观察数据就不难发现其实大部分query是完全可以归一在一起的,只不过由于输入方式和输入习惯的不同,导致其衍生除了千奇百怪的query,从而影响模型理解该query。针对这个问题,笔者在query塔侧加入了一个新特征:改写后的rewrite query,和原始query共享一个Bert。
具体的改写方式和算法选型,请移步笔者的这篇文章观看:
Batch内负彩阳热门打压在业界其实很少有人做,因为batch内负采样热门app更有可能成为负样本,因此其具备天然打压热门item的属性,而且通常会造成过度打压。但是本文中广告场景的某些app热门效应非常显著,自带的热门打压效果似乎难以hold住。笔者清楚 这是正样本策略带来的负面影响 ,但是我们又不能用人力去标注,也暂时没有更好的正样本策略改进方式 。因此这里只能考虑从模型侧入手进一步打压热门app。
笔者采取的方案是针对性挑选如下的app,将其当做少量额外负样本加入到训练的正样本中:
额外负样本加入训练集后,loss虽然还是batch softmax, 但训练集并不只是正样本了,有0有1 ,那么计算batch softmax的叉乘矩阵过程如下:
灰色的部分即为额外加入的负样本,这样对于原来每一行样本来说,绿色的正样本多增加了两条灰色的负样本 ,相当于变相的给其他query增加了更多的item作为负样本,这时候热门的额外负样本的加入,相当于在进一步打压热门,而冷门样本的加入,缓解了SSB问题,一箭双雕。
当然有同学会问,这样不就让冷门app更难展现了吗?其实没关系,本文开头就有说过,一般召回系统都有专门的冷门扶持召回。冷门之所以是冷门就是很少有准确的query来搜索并且点击它,因此我们更需要避免模型在面临一个没见过的query时将一个不相关的冷门app排在前面(因为SSB问题,模型没见过该app,embedding表达很差)。
这里要注意的是,上图中额外负样本所在这一行的loss是不能使用的,因为这一行根本没有正样本,也就失去了物理意义,会对模型产生干扰,因此我们需要将粉色样本所在行的loss抹掉。
算法的详细细节原理、以及其代码实现笔者这里就不展开了,之前的文章里都有。感兴趣的同学请移步笔者的这篇文章:
笔者曾在《推荐系统召回模型batch内负采样训练时出现false negative问题的一些解决方案》一文中详细阐述过针对false negative问题解决方案的探索,里面提到了两种优化的方法,二者的大致思想分别为:
这里只讲下核心思想,如想详细了解,请移步:
除了第二阶段的batch内挖掘困难负样本之外,我们又增加了一个第三阶段的辅助loss,一个目的是我们有很多hard negative数据不用很可惜,第二个问题还是觉得batch内挖掘困难负样本的方式受数据分布影响太大。
第三阶段样本为正负样本对的形式,正样本仍然是一样的策略,负样本为专门用pipline挖掘的困难负样本,依旧是用课程学习的方式,用cosent loss来训练,尝试过bce,效果也还行,这里的挖掘困难负样本的策略可以非常灵活:
到此为止,我们针对query-app这一路的初始目标的优化已经做完了,这其中每一步优化措施都对最终的线上目标指标有一定幅度的提升,完成了这一路应有的使命。
我们前面所有的优化措施,都是在让模型推荐的更准。但我们发现当模型推荐准以后,query-app这一路的线上ctr确实是比其他路高很多的,但是随之而来的是ecpm/arpu这种收入指标并没有上涨,反而有所下降。
观察这一路的线上报表数据发现,该路实际扣费单价低。那么这个问题其实很好理解了,搜索广告虽然名为搜索,但始终是广告场景,而非内容搜索那样需要精准推荐,对于收入这个指标来说,ctr * bid 就是实际扣费,然而不同app之间的出价bid有可能差百倍,纯广告收益场景如果始终精准的推荐用户的需求,精准推荐出的app的bid或许就不那么高,那么ecpm大概率就没办法很高了。
基于对这一点的认识,我们开始重新规划这一路的目标,并不能让其只满足于高ctr或者相关性, 而是在原有基础上损失较小相关性的前提下,尽可能推荐出高价值(高bid)的app 。对于这个优化点,其实笔者已经记录在了之前的一篇文章里,本文仅做思考点分享,详细细节大家可以移步下面这篇文章:Query改写模块的设计和上线部署优化[7]
熟悉笔者的朋友知道,笔者一直强调看搜广推的论文不要只看模型、trick、策略,更重要是看论文作者需要拿它来解决什么问题(以及你是否存在这个问题),如果同样的trick没用在合适的地方上会适得其反。
前面进行热门打压的目的是为了准确,为了相关性。当这一路目标夹杂进收入指标时,我们不期望对热门的app进行过度的打压,这时候放松热门打压程度能进一步提升线上ecpm,相当于要制造和第二目标相近的bias。可以认为这两个目标在优化到一定程度后有一定的冲突,此消彼长。
对于这个现象,百度凤巢的这篇文章:《Sample Optimization For Display Advertising》中详细论证了各种负样本热门打压策略的实验,我们实验的结论和百度凤巢结论基本一致。因为作者是做的在线实验,写的很详细,很有说服力,所以这里就分享下百度的实验结果。首先介绍其实验的样本采样策略,方便等会和图片中的策略对应:
百度的实验结论如下,本文这里只关注实验a、b、c的效果,逐步增加a、b、c后发现线上ecpm逐步提升,但离线auc逐步下降:
实验结果说明了,放松热门打压可以进一步提升线上收入指标。这也应证了笔者所强调的,看论文的时候需要将论文中作者要解决的问题弄明白,思考清楚那些问题是不是你要解决的?如果设计一个搜广推系统时上来就无脑的进行热门打压,结果说不定和目标背道而驰,落得个南辕北辙的下场,结合目标需求和业务理解对症下药才是上策。
可以看到,这篇文章中分享的优化措施,正好可以串联起笔者之前写的几篇文章:
[1]
Que2Search:FaceBook新一代query搜索召回模型分享: https://zhuanlan.zhihu.com/p/615284379
[2]
Query改写模块的设计和上线部署优化: https://zhuanlan.zhihu.com/p/615244161
[3]
推荐系统召回模型batch内负采样训练时出现false negative问题的一些解决方案: https://zhuanlan.zhihu.com/p/613206891
[4]
Query改写模块的设计和上线部署优化: https://zhuanlan.zhihu.com/p/615244161
[5]
双塔模型Batch内负采样如何解决热度降权和SSB的问题: https://zhuanlan.zhihu.com/p/574752588
[6]
推荐系统召回模型batch内负采样训练时出现false negative问题的一些解决方案: https://zhuanlan.zhihu.com/p/613206891
[7]
MECH:Query改写模块的设计和上线部署优化: https://zhuanlan.zhihu.com/p/615244161
[8]
MECH:双塔模型Batch内负采样如何解决热度降权和SSB的问题: https://zhuanlan.zhihu.com/p/574752588
[9]
MECH:推荐系统召回模型batch内负采样训练时出现false negative问题的一些解决方案: https://zhuanlan.zhihu.com/p/613206891
[10]
MECH:推荐模型如何在不影响排序指标的前提下,让高价值的item排序前移?: https://zhuanlan.zhihu.com/p/600369259