每日一博 | 深度统一粗排在淘宝主搜索的优化实践
两阶段排序(粗排-精排)一开始是因系统性能问题提出的排序框架,长期以来粗排的定位一直是精排的退化版本,但我们发现通过一些技术手段,粗排可以在较大的集合上超越精排。通过重新审视粗排和精排的关系和提出全域hitrate这一新的评价体系,再结合采样优化、蒸馏等手段,我们提升了搜索大盘约1.0%的成交金额
▐ 概述
淘宝主搜索是一个典型的多阶段检索系统,主要分为召回、粗排、精排等阶段。召回阶段,由文本召回、个性化等多路召回构成,输出商品量级约10^5;粗排阶段,需要从三路召回集合中分别进行筛选,筛选出10^3量级提供给精排;后续经过精排等阶段再进行筛选输出约top10曝光给用户。(注:下文中10、10^3、10^5等均代表数量级,数值只作为示意,只有其相对大小具备参照意义)
去年我们团队采用多目标优化+负样本扩充+listwise蒸馏这“三板斧”成功在主搜粗排阶段取得了显著的成效,也是首次将粗排的训练样本和目标做出了和精排明显的差异,并在每路内召回集合hitrate验证下表明粗排显著超过了精排模型,但是由于时间原因只进行了比较片面的尝试,今年我们继续针对这些问题进行深入的探索和剖析,今年继续新的评价指标和评价体系,我们对所有改进功能都进行了回测,同时进行了进一步改进和提升。
具体到评价指标方面,由于去年我们只有一个片面的衡量与精排一致性的指标(NDCG),无法衡量召回-粗排的损失,进而无法衡量粗排负采样的好坏进行衡量,且本身这个目标就和粗排实际的优化方向存在很大偏差,实验过程也容易发现盲目提高NDCG且不增加负采样只会让粗排效果更差。因此,今年引入了全新的评测指标“全域成交hitrate”作为粗排最重要的评价标准,并且历经一个月时间对从召回->粗排->精排的全域成交漏斗损失结合不同优化对应的线上GMV的影响进行了系统的分析,不仅对此评价指标的有效性进行了检验,还对各个阶段的优化空间、优化目标进行了一定程度的规范与统一。与此同时,具体到对粗排阶段离线优化目标,全域hitrate需要进一步进行拆分,其中粗排前与粗排后、场景内和场景外本身具有天然的不同,且最终我们通过分析和验证提出了两类评价指标分别描述“粗排->精排损失”和“召回->粗排损失”经过分析和细化后的这些粗排评测指标终于能和线上指标具有很强的正相关性。
在“粗排->精排损失”和“召回->粗排损失”的指标都建立完成后,我们会发现用技术手段去缓解最开始提到的两个问题“与精排目标不一致”和“粗排练样本空间与线上打分空间不一致”就可以在这两种指标上分别得到体现,其中长尾商品问题我们去年的做法只是解决了其“打分过高”的问题,但是实际上加重了其“打分过低”的问题,我们今年也进行了一定的尝试,具体的方法将在第4节阐述。
▐ 模型基础结构
的列表,即样本维度为
,其中
分别表示曝光样本、未曝光样本和随机负样本对应的长度。去年只是通过推测和分析进行的这部分样本构造工作,在今年提出和发现全域成交指标后,对此部分工作进行了回测,发现未曝光样本和随机负样本这两部分负样本的扩充共带来约5.5 pt的场景外的hitrate的提升。
在本节中,我们利用新提出的全域成交hitrate指标,对搜索全链路漏斗进行了分析。全域成交可以划分为两类成交样本:场景内成交和场景外成交。场景内成交即用户在搜索场景内产生的所有成交,场景外成交即同一个用户关联到的非搜索场景产生的成交。由于非搜索场景不存在query,我们通过相关性作为关联条件,将用户在场景外的成交item,关联到用户在场景内的query上,且要求场景内query和场景外成交item组成的query-item对满足一定的相关性条件。
我们通过埋点的方式对粗排阶段打分集合归因到对应的场景内和场景外成交。具体的,将多路召回结果统一使用粗排模型打分进行排序,并截断Top K计算搜索引导成交和符合相关性要求的非搜索关联成交对应的hitrate@K,具体见下图:
粗排离线衡量指标分析与修正
▐ 启下:衡量粗排->精排损失
-
粗排hitrate@10等粗排头部场景内成交 精排优化目标本身就是从精排打分集合中选出最优质且符合搜索场景bias(能在搜索场景成交)的 Top 10,乃至 Top 1,所以如果粗排预测的hitrate@10 能提高并接近场景内成交,自然一定程度和精排更加一致 -
曝光商品粗排总分与精排效率分数的NDCG/逆序对 这个是我们最近几年一致在用的指标,更看重和精排的一致性,主要是从模型/特征/目标等方面和精排深度模型对比。 -
AUC 因为部分情况下上面两个指标计算过困难,或有时为了和精排AUC指标之间能进行对比,我们会计算每次请求粒度下的AUC,因为粗排模型的损失函数是基于listwise的排序损失函数,最终输出的分数绝对值没有实际的物理含义,不同请求下的打分无法直接对比,因此没办法计算Total AUC。
▐ 承上:衡量召回->粗排损失
场景内 hitrate@10^3
场景内粗排输出集合的hitrate评测起来肯定是100%,只能通过比粗排打分小不到一个量级的集合近似表征,具体可根据不同场景的打分情况进行具体定义
场景外 hitrate@10^3
由于场景外成交基本不存在bias,需要以场景外指标为基准,判断粗排模型的能力。
▐ 离线hitrate提升幅度与线上A/B test中hitrate提升幅度的一致性分析
-
场景内 提升幅度离在线必定不同:
因为粗排模型上线后,精排的候选集发生明显的 distribution shift ,进而最终指标绝对值必然不同,因此对于场景内分析几乎只能看场景内最终的成交笔数,至于粗排hitrate@ 10^3在上线之后再观察的意义本身也不大,因为这部分结果本身线上也是由精排决定。
-
场景外 离在线提升幅度 不同 :
场景外转化到场景内:如果离线场景外成交的提升转化为了场景内成交,那场景内的成交笔数、场景内与场景内成交的比值都会有明显提升。因为场景外转化为场景内后,剩下的场景外成交对于当前模型变得更 “难” 了,所以本身就符合预期。所以这种情况下其实已经是达到了我们的最终目的——提高了场景内成交。
在线生效出问题:如果场景内笔数没涨,并且场景外提升还变少了,大概率是出现在线生效问题,需要针对具体问题来排查。常见的问题是在离线特征、模型不一致等。
-
场景外 提升幅度 相同( 即场景外没有转化到场景内):
粗排后续阶段(精排等)场景外hitrate是否提升:如果后续阶段本身没有hitrate提升,则说明在粗排后续阶段对于粗排新召回的商品不认可,这种可能需要从特征/样本/loss等指标角度去找差异, 需要根据具体情况决定是对粗排进行调整还是对精排等阶段进行调整。
优化方法
▐ 减少粗排-精排损失
蒸馏样本的进一步扩充
蒸馏作为例子,pctr = pctr * 1 =P(海选->点击) 即可以表征其从海选到点击的概率,但是对于未曝光商品其后验P(海选->曝光)=0,从数学角度来说 pctr 没办法乘0或者直接表征海选到点击的概率。对于以上两个问题,我们发现由于曝光集合是在top10,未曝光采样集合在10-5000随机,通常显著小于曝光商品打分,(i)中存在的问题可以忽略。对于问题(ii)其中一种解决方式是使用label smoothing方法使用 pctr * scale代替 pctr *0的表征使其保留梯度,其中scale << 1。
进一步对齐粗排精排特征
交叉特征的引入
从内积到MLP的尝试
▐ 减少召回-粗排损失
全域样本
在第三节中,我们提到了粗排今年引入的新衡量指标:全域成交hitrate。全域成交hitrate能够降低评价指标中的偏置,更客观地评价模型的能力。为了直接优化这个指标,我们从样本角度出发,将场景外(即除搜索场景以外的淘宝成交)样本引入训练样本中,借此提高模型在hitrate上的表现。
我们通过修正正样本来引入场景外样本。在原始的样本中,场景外的样本有两种可能:一是被作为成交任务的负样本;二是不存在样本集合中(因为场景外样本可能没有被曝光,甚至有可能没有被召回)。为了不破坏训练样本的原始分布,我们首先尝试不引入新样本的方式。在这种方法下,若某个样本存在于原始样本中,则将其成交标签设为1。实验表明,这样的样本修正方式对粗排阶段的hitrate几乎没有任何影响。通过进一步分析,我们发现,若场景外成交样本出现在原始样本中,则几乎只有可能出现在曝光样本中,而极少出现在未曝光样本或随机负样本中。这样一来,这样的样本修正方式实际上是对曝光样本的修正,即将已曝光但在场景外成交的样本,从负样本修正为正样本。需要指出的是,曝光样本实际上是通过粗排模型排出来的样本,即这部分样本即便是成交负样本,对于粗排模型来说打分已经相对较高(因为是曝光任务的正样本),对这部分样本在曝光阶段的成交/点击label修正并不能在粗排阶段带来收益。因此若希望提高粗排阶段的场景外成交hitrate,则必须引入更多粗排阶段没有排出来的场景外样本。
基于上述分析,我们进一步引入场景外成交样本。在对原始样本进行修正的基础上,对于不存在于原始样本中的场景外成交样本,我们将其添加进曝光样本中,将其同时设为曝光、点击和成交任务的正例。通过这种方式,我们将成交样本的样本量扩大了约80%。在对样本做扩增后,粗排模型的场景外hitrate提升了0.6pt。
采样方式的优化
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
,其中
表示对应商品历史的曝光次数。调整采样方式后,长尾商品的占比有了明显变化:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
▐ 其他优化工作
损失函数的形式优化
表示item侧和user侧向量的内积,即similarity;
表示list的长度。不同于其他场景下的任务,粗排模型的三个任务,尤其是曝光任务,在每个list中, 正样 本的数量都可能不为1(尤其是曝光任务,正样本的数量通常为10)。我们发现,在粗排的场景下,直接套用softmax在多正样本的情况下的优化目标具有不合理之处,并据此对该损失函数进行了改进,使之更加适合粗排模型的优化目标。
表示负样本集合,
表示除第
个样本以外的正样本集合
(也称为SmoothReLU函数)近似为ReLU:
,上述损失函数都在试图拉大正样本
与当前list中所有其他样本上界之间的距离,这里的“其他样本”既包括全部的负样本, 也包括除样本
以外的其他正样本 。在绝大多数情况下,正样本的内积相似度大于负样本内积相似度,即
,因此式(5)可以进一步写成:
与除
以外的全部正样本的上界 之间的距离,最终达到的效果是拉大正样本之间的距离,而忽视了真正重要的正样本和负样本之间的差异。
一旦理解了目前softmax函数的问题所在,只要将上述公式稍加改动,就可以避免上文中发现的问题。具体地,在公式(5)中,我们只需要将除



将式(7)平滑展开回softmax。对应地,只需要在softmax计算过程中,将分母中的当前样本
基于全域分析的精排打分量调整
相对于以前只用精排样本的业内常见的粗排版本,主搜从去年到现在提出的针对业务场景的采样方式、多目标loss融合、蒸馏方式等优化,共带来了搜索大盘约1.0%的成交金额提升。需要指出的是,我们对粗排->精排的损失和召回->粗排的损失是同等看待的。但从近期的离线实验可以看出,绝大多数实验都会出现两种情况:一是离线hitrate提升不明显,即优化点无效果;二是召回->粗排的损失缩小,粗排->精排损失增大,即粗排输出集合确实变得更加优质,但是增量部分不能被精排认可(或者只认可一少部分)。这一点其实也一定程度符合认知,比如粗排的很多改动,如正样本中引入关联到的未进精排的全域样本,负样本的随机采样样本分布改动,目前精排目前的实验都没有加入类似的正负样本,很难能对粗排增量的优质集合进行正确打分。因此后续粗排的优化不仅仅要遵循承上+启下两部分损失的优化,对于经过分析验证中发现的精排未通过的优质商品,针对具体问题将粗排和精排的样本进行一定程度的对齐,协同粗排的腰部排序能力和精排的头部排序能力的同时一定程度增加一致性,最终实现双赢。
本文分享自微信公众号 - 大淘宝技术(AlibabaMTT)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
关注公众号
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
Pandoc 3.1 已发布,标记格式转换工具
Pandoc 3.1 发布了,Pandoc 是一个通用标记转换 Haskell 库,用于从一种标记格式转换为另一种,同时也是一个使用该库的命令行工具,它可以转换 28 种标记格式。 修复自定义阅读器扩展的使用 (#8571)。 Text.Pandoc.Writers.Shared:导出setupTranslations[API 更改]。 LaTeX 阅读器:修复环境宏分辨率的回归(#8573)。 Chunked HTML writer:修复带有绝对 URL 的图像处理 (#8567)。 HTML 编写器: 不省略任务列表中的换行符。 不禁用任务列表中的复选框 (#8562)。 确保自动设置的变量pandoc-version,outputfile,title-prefix,epub-cover-image,curdir,dzslides-core可以被--variable命令行覆盖。 修复linux/make_artifacts.sh的手册页复制问题(#8566)。 pandoc.cabal:从额外源文件中删除 pandoc.cabal、stack.cabal (#8560) 需要 ...
-
下一篇
aixinge —— 智能消息推送平台
Ai(爱)Xin(信)Ge(鸽) - 智能消息推送平台致力于解决大家在集成消息推送时的各种难题,力求将消息通知简单化、统一化,实现推送"All in One"的效果。 目标特性 易使用:一个 SDK/API 即可实现不同类型的消息推送,再也不用对接各种消息推送 SDK 了 易管理:集成市面上绝大部分推送渠道,实现统一管理,如需更改渠道,只需要进行相应配置并绑定到对应的消息模板即可。 易部署:可通过二进制文件或者 Docker 镜像实现一键启动,同时有可视化的引导式配置简化大家的配置难度。 高性能:依托于 Go 语言的特性,全程通过 Pipeline + Async 为推送平台提供强劲性能。 功能规划 V1 版本功能规划:
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 面试大杂烩
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- 2048小游戏-低调大师作品
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- MySQL数据库中FOR UPDATE的使用
- Docker快速安装Oracle11G,搭建oracle11g学习环境








微信收款码
支付宝收款码