搜索EE场景排序链路升级

京东云开发者
• 阅读 218

作者:京东零售 吕豪

背景

EE(Explore & Exploit)模块是搜索系统中改善生态、探索商品的重要链路,其目标是缓解数据马太效应导致模型对商品排序丰富性、探索性不足,带来的系统非最优解问题。

在JD搜索体系中,EE模块被定义的核心定位是:在给定流量和时间的约束下,探索出更多高效率的商品。EE的优化目标即为,以保障搜索效率为前提,提升广义中长尾商品的探索成功率,提升搜索结果的流动性、丰富性。

EE场景迭代闭环

由于EE场景的特殊性,其从核心定位 → 在线指标 → 离线评估体系 → 模型迭代的优化链路中的每一步,都需结合EE特点进行针对性升级。

搜索EE场景排序链路升级

以下分别从模型迭代、在线实验指标、离线评估体系介绍相应模块的优化。

模型Debias迭代

问题背景

EE的核心定位在于探索更多更高效的潜力中长尾商品,其首要回答的问题便是,在目前搜索体系中,哪些因素阻碍中长尾商品获得更公平合理的展现机会?系统性的各类bias 。

1). Position-bias (展示位置偏置)

当前打分模型基于每天dump的搜索日志进行训练更新。由于搜索结果的position-bias(位置偏置)效应,user的行为动作不仅与商品本身质量有关,而且受position(展示位置)较大影响。position-bias(位置偏置)效应对头部商品的增益,加剧了平台生态的马太效应。使用position-bias的日志数据进行训练,而未对position(展示位置)做去偏,不利于中长尾商品的正确效率预估,不利于平台流动性、丰富性和长期价值。

2). Polularity-bias (流行度偏置)

存在与user偏好匹配程度相当的多个商品时,由于商品间的历史累计销量、累计评论等流行度特征的差异,造成倾向于给用户呈现热门流行商品,已流行商品则更流行。而匹配程度相似的中长尾商品,则难有机会被展现,中长尾更中长尾。

3). Exposure-bias (曝光偏置)

一次搜索请求下,只有有限的商品列表展现给user,绝大多商品无法展示;搜索系统一天内,整体被展现的商品集也只占全部商品集的小部分。 由此带来的问题一方面是模型泛化问题,训练在已展现商品的日志上进行,serving需在所有商品上做推断,如何平衡训练、推断样本分布差异化的矛盾,尤其是头、尾部商品的巨大差距。另一方面是商品label问题,商品未累积获得用户正反馈,是因为与用户不匹配,还是未有展现机会?

针对以上bias问题,EE排序模型从位置偏置建模、反事实推理学习方面进行升级,尝试缓解position-bias和polularity-bias,取得一定收益。而Exposure-bias由于随机dump样本的label问题,还需要做更多探索。

目前EE排序模型整体结构图:

搜索EE场景排序链路升级

  • 针对位置偏置,设计position-bias net于训练时建模位置作用、预测时mask,进行展示位置去偏。
  • 针对流行度偏置,构建 U-I net/ item_net/ user_net 分别建模 用户-商品内容匹配度、流行度因子、用户心智偏好因子的影响,依据因果效应消除偏置因子作用,还原用户对商品本身内容的偏好度。

位置去偏迭代

1. Position-bias 位置偏置建模。

搜索EE场景排序链路升级

EE模型升级至训练、预测两阶段的position-debias方案,通过pos-bias tower建模position-bias影响,并在高语义层级与输出均值融合,拟合训练label,而后在预测阶段摘除,以期去除pos-bias影响。

Pos的建模方式

1.1 pos as feat

训练阶段,pos作为模型特征使用,与其他u/q/i侧特征联合,共同输入模型网络,计算相应logits并梯度回传。预测推理阶段,所有样本强制采用同一个pos值,近乎理解为:同一个user/query下, 所有商品在同样的展示位置上,进行预测分数比较。

搜索EE场景排序链路升级

其潜在风险如下:

  • 强制pos数值如何选择。展示位置一般可限制在[0-30/60]内,然而不同强制位置的设定,会带来排序结果的变化,如何在[0-60]间选择合理的强制位置,以及不同时间和分布下,强制位置的选择是否要重新进行。
  • pos特征的重要性。将pos特征由网络底层输入,其重要性可能难以在最后的logits中得以充分体现,其物理意义(位置因素影响用户商品交互行为的作用大小)不易直观理解。

1.2 multi-pos predict

设计最后一层为多位置通道输出的网络,预测商品在各枚举位置上的logits输出。训练阶段计算商品在所有位置上的输出结果,只激活真实的pos通道计算logit和loss,其他位置通道进行mask。推断时,贪心的从第一个位置开始,无放回的选择当前位置上的最优商品,直至最后一个位置。

搜索EE场景排序链路升级

此方案适配用于排序位置较为固定的场景,如重排N选N,在搜索EE现有架构下并不适配,一方面是SVGP结构对多通道结果输出并不友好,另一方面,EE现有插入范围较大[1-60]、比较插入机制也需做非常复杂化的适配改造,方案过重。

1.3 pos as tower

升级现有DNN + 稀疏变分高斯(svgp) 采样打分模型,采用基于position-bias net(位置偏置)的模型方案,方案具体为训练、预测两阶段的位置去偏。

  • 训练阶段通过引入展示位置表征作为位置偏好网络,与基于user/query/item的主网络共同输入,预估商品在当前位置(位置偏好网络)及自身质量(主网络)下的打分。
  • 预测阶段通过摘除位置偏好网络,预测商品仅基于自身质量的采样打分,去除展示位置影响。通过此方案可以缓解训练数据的position-bias(位置偏执),降低头部商品由于展示位置的打分增益,同时减少中长尾商品由于靠后位置的打分折损,优化搜索结果丰富性和平台生态。

2. 个性化位置偏置建模。

用户对商品的偏好是个性化的,不同用户对商品的偏好不同。用户对位置的偏好也是差异化的,不同用户对位置的敏感度存在差异。

上文的bias-net建模方式,假定所有用户对同一位置偏好相同,忽略了用户间的位置偏好差异。典型例子如下,偏逛用户在系统中对position相对不敏感,position的排名前后对用户的行为决策影响相对更小,而对偏快速够买用户则影响截然相反。

个性化位置偏置建模。升级现有bias-net结构,引入用户个性化特征,包括静态profile和动态行为序列。通过个性化bias-net 计算不同用户对不同position的位置偏好,更准确的还原用户对商品内容的真实偏好。

Pos Tower 与 svgp的结合方式。

2.1 SVGP简介

搜索EE场景排序链路升级

GP(Gaussian process,高斯过程)是用于在样本间存在相关关系的情况下,通过观测值对未知样本label 进行修正预测的算法。简言之,距离观测点越近的未知样本,其均值被修正越多、更接近观测值,方差也越收敛,反之亦然。SVGP(Sparse Variational Gaussian Process, 基于稀疏变分的高斯过程),针对大样本量下协方差矩阵和求逆难以计算的问题,设计一定数量的可学习的引导点,对所有训练样本进行归纳,未知样本通过与引导点的协方差来计算均值和方差。

2.2 表征层融合(Representation Fusion)

Pos-tower与Main-tower融合方式有两种,表征层融合和logit层融合。在SVGP计算前进行融合,即表征层向量进行融合,可以采用 concat/sum/avg 等各种方式。其难点在于,向量间的相加、平均操作,无法直观理解其物理意义和作用,向量叠加是否导致logit正向增大,向量带来多大的logit提升,这些位置偏置作用难以解析。

另外从模型结构来看,svgp依赖样本内容间相似度计算均值和方差,而position-bias的影响应该独立于样本内容的计算。

2.3 logit层融合(Logit Fusion)

在svgp之后的logit层融合,可采用 logits 相乘相加方式,其直接从模型结构上诠释了这样的公式 Label = f(content) + f(position) / Label = f(content) * f(position) ,其中 f(position)的绝对值大小,直观的表示 position 带来的增益大小。

位置偏置建模线上效果

保持大盘效率持平的情况下,EE核心指标提升明显,探索流动性指标(探索更多商品)提升明显 +1.35%,探索成功率指标(探索更高效商品)显著改善 +0.74%。

流行度去偏

3.1 IPS

对每个商品预估 propensity score,然后采用逆向 propensity score 权重的方式,消除倾向分的影响,预估商品真实的内容匹配度得分。

挑战点:

  • 如何准确获得 propensity score,这是对后续纠偏的前提挑战。
  • 整体为两段式训练,链路上有一定复杂度。

3.2 流行度降权

在实际搜推数据中,在user侧、item侧分别依据其流行程度,设计对应降权权重,缓解整体被热门用户、商品所主导的趋势,增强所关注样本的影响力。

面临难点:

  • 合理的设计权重方案。
  • 如何挖掘hard example。

3.3 基于因果关系的反事实推理

如何缓解流行度偏置问题?在训练链路中,增强改善中长尾商品的学习是一类重要方法;对用户交互行为进行解构,拆分出商品流行度等因子的作用,是另一个视角的解决思路。

因果图、因果关系简介

搜索EE场景排序链路升级

因果图是有向无环图,其中节点表示随机变量、有向边表示节点之间的因果作用方向。如上图对于节点Y变量,有两条路径的因果作用,分别是 I → Y 、I → K → Y。

  • I → Y 表示从 I 节点开始的自然直接因果效应 (NDE),作用路径上没有中间节点。
  • I → K → Y 表示从 I 节点开始的间接因果效应 (TIE),K是路径上的中间节点。
  • 直接因果效应和间接因果效应之和,即为Y变量的总因果效应 (TE)。

总因果效应计算,可以由自变量的单位扰动带来的因变量变化进行计算,自然因果和间接因果效应计算亦然:

搜索EE场景排序链路升级

以上公式可得,求出TE和NDE时,可推导计算中间接因果效应 TIE。

搜索中的因果效应

在电商搜索场景下,用户对商品的交互行为,可表示为 U-I 间各种因子的综合作用。常见思路为考虑 U-I 间内容匹配程度作为待预测因子,学习此因子在交互行为中的作用,在未来样本上进行预测排序。

从电商搜索的现实情况出发,对交互行为进一步拆分,影响用户商品交互行为的因子大体包含如下三方面:

  • 1). (U-I) → Y, U-I 内容匹配度因子,用户与item本身内容的匹配程度、喜好程度对交互行为的影响,越喜欢则越点击购买,
  • 2). I → Y, Item流行度特征,内容偏好匹配程度相当的几个商品时,由于历史累计销量等流行度特征,热门商品展现更多、被交互概率更高。
  • 3). U → Y, 用户天然心智,user对流行商品的偏好程度不同,有些用户更倾向于热门商品,部分用户则并不敏感。

搜索EE场景排序链路升级

以上因子的拆解,包括了U/I 内容匹配度的间接因子的效应,也包括了 U、I的直接效应影响。因此在EE模型中设计如下网络,分别建模各个因子的作用:

搜索EE场景排序链路升级

具体分别设计 UI-Match-Net, User-Net, Item-Net 分别预测对应三种因子的作用,其中总效应,U/I 效应分别表示为

搜索EE场景排序链路升级

在训练中Loss的设计如下,分别表示

搜索EE场景排序链路升级

  • U-I与label的loss,优化主模型的准确性
  • U、I侧直接因子的loss,通过这种方式分别预测两种直接因子对交互结果的影响
  • alpha/beta 为训练时超参

预测阶段缓解流行度偏置,主要在于去除流行度因素、用户心智因果(偏置因子)的影响,具体通过总因果效应减去自然直接效应(偏置因子效应),尽量准确还原 U-I 内容匹配程度的影响

TIE = TE - NDE

搜索EE场景排序链路升级

反事实推理后的因果图状态如下,将U/I 的直接效应消除,保留U-I 内容匹配度的效应:

搜索EE场景排序链路升级

反事实推理建模线上效果

保持大盘效率持平的情况下,EE核心指标提升明显,探索流动性指标(探索更多商品)提高 +0.82%探索成功率指标(探索更高效商品) 显著提升 +0.66%。

在线AB指标

探索成功率指标,用于在小流量AB期间指导EE效果分析,其设计思路从EE核心价值出发,推导出长期价值相关联的AB期间核心指标。

具体而言,即论证 探索成功率指标 → EE核心价值。

  • 满足探索成功率的商品,跟踪其一定时间后在搜索中的承接状态,是否被大盘较好承接。
  • 搜索中承接状态,主要为三要素:流量、点击、订单。

通过对 1). 商品概况和承接定义, 2). 商品承接统计, 3). 分层承接分析 等方面进行分析,迭代出搜索EE在AB实验期间所关注的EE核心指标集–探索成功率。

离线评估体系

EE线上指标主要关注

  • 1). 大盘效率,UCVR和UV价值
  • 2). 探索成功率, 其余辅助观测指标包括 流动性指标、丰富性指标。

在线的探索成功率和辅助指标,现阶段难以与模型离线指标(AUC等)关联,无法在离线评测EE模型的探索能力,限制EE模型迭代速度,极大增加迭代时间成本。

针对EE场景特异性的指标,设计了离线指标评测集合,分别从 效率、中长尾探索强度、不确定预估等方面,综合评测EE模型,加速迭代。

总结

搜索EE是提升搜索场景流动性、多样性的关键模块,其面临的问题和以效率排序为主模块的问题有很大差异,对EE同学提出了不一样的挑战。

针对EE场景的特点,排序模型从Debias(打分公平性)入手,拆解存在于各种排序场景的bias问题,对位置偏置和流行度偏置问题升级较通用化的解决方案,取得了EE核心指标的显著提升。同时对于迭代链路中的 在线AB指标、离线评估体系,也进行了论证和迭代,完成对整个EE排序闭环链路的升级。限于篇幅,AB指标和离线评估体系在这里不做全面展开,感兴趣的同学欢迎随时交流,共同探讨。

EE场景面临的挑战很多,后续计划从如下方面继续深入探索:

1). 引入更丰富的用户探索信号的表达,增加explore-net和监督loss,提升EE模型对探索偏好的学习。

2). 思考EE的长期价值,如何在模型结构、Loss设计上结合长期价值。

3). 优化EE探索机制和EE候选集,提升EE全链路探索能力。

点赞
收藏
评论区
推荐文章
blmius blmius
2年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
Wesley13 Wesley13
2年前
PPDB:今晚老齐直播
【今晚老齐直播】今晚(本周三晚)20:0021:00小白开始“用”飞桨(https://www.oschina.net/action/visit/ad?id1185)由PPDE(飞桨(https://www.oschina.net/action/visit/ad?id1185)开发者专家计划)成员老齐,为深度学习小白指点迷津。
Wesley13 Wesley13
2年前
FLV文件格式
1.        FLV文件对齐方式FLV文件以大端对齐方式存放多字节整型。如存放数字无符号16位的数字300(0x012C),那么在FLV文件中存放的顺序是:|0x01|0x2C|。如果是无符号32位数字300(0x0000012C),那么在FLV文件中的存放顺序是:|0x00|0x00|0x00|0x01|0x2C。2.  
Wesley13 Wesley13
2年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Wesley13 Wesley13
2年前
PHP创建多级树型结构
<!lang:php<?php$areaarray(array('id'1,'pid'0,'name''中国'),array('id'5,'pid'0,'name''美国'),array('id'2,'pid'1,'name''吉林'),array('id'4,'pid'2,'n
Easter79 Easter79
2年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Wesley13 Wesley13
2年前
Java日期时间API系列36
  十二时辰,古代劳动人民把一昼夜划分成十二个时段,每一个时段叫一个时辰。二十四小时和十二时辰对照表:时辰时间24时制子时深夜11:00凌晨01:0023:0001:00丑时上午01:00上午03:0001:0003:00寅时上午03:00上午0
Stella981 Stella981
2年前
Jenkins 插件开发之旅:两天内从 idea 到发布(上篇)
本文首发于:Jenkins中文社区(https://www.oschina.net/action/GoToLink?urlhttp%3A%2F%2Fjenkinszh.cn)!huashan(https://oscimg.oschina.net/oscnet/f499d5b4f76f20cf0bce2a00af236d10265.jpg)
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_