Fork me on GitHub

闲鱼搜索相关性——体验与效率平衡的背后

作者: 涤生、远悠 闲鱼技术

背景

闲鱼搜索是闲鱼APP最大的成交场景入口, 成交归因中搜索占一半以上,所以提高成交效率是工程和算法迭代优化的主要目标,然而只以效率为最终的衡量标准不但会影响搜索的质量阻碍成交,还会恶化整个平台的长期生态建设无法成长,所以搜索相关性和平台生态对搜索平台至关重要,其中平台生态治理(例如恶意引流、欺诈、黑产等治理)涉及运营,算法和架构等诸多因素,并不是这里讨论的重点。本文主要讨论搜索相关性,它是整个产品的基石,也是搜索技术中的核心。下文则将依次介绍闲鱼搜索相关性遇到的问题现状,优化升级方案以及后续进一步的优化方向。

问题

当前闲鱼搜索存在多种扩召回策略,典型的如query改写、i2i、商品图像文本抽取、同款商品文本信息扩充等。扩召回策略是必要的,但不可避免地在下游引入相关性差的case。与此同时下游的相关性控制却十分有限,在精排阶段的相关性主要存在以下问题:

图片

经过多轮top和中长尾相关性case分析,整理了top的问题类型(同一个case可归到多个类型),并给出了典型例子:

图片

图1.badcase分析

总结来看,当前系统的问题主要在于相关性策略覆盖不足,语义表达不准,基础数据更新迭代慢等问题。

技术方案

针对上述基础相关性因子弱、覆盖不足的问题,闲鱼搜索相关性规划第一阶段的优化目标为建立相对完善、高覆盖的基础相关性匹配链路,第二步是在基础策略基础上探索精细化的语义匹配策略提升相关性。本文主要介绍第一阶段方案。

工程链路设计

闲鱼搜索目前的工程链路为比较经典的搜索架构:SPL做数据中转和中间参数构造;QP负责query相关理解、特征抽取;检索引擎(Ha3)中做召回、粗排、精排算分、打散;RankService通过在线模型服务实现深度模型重排序。

而相关性匹配链路有两种选择,一个是在检索引擎(Ha3)精排算分插件中完成,另一个则是在RankService中实现。虽然二者各有优势,选择在检索引擎(Ha3)精排算分插件中实现可以灵活的配置召回和精排阶段的不同数量方便实验。出于效率考虑,特征则优先采用离线抽取方式:

•Query特征通过离线抽取,增量方式导入到线上KV存储中,在线QP中请求KV存储获取相应特征,最后通过SPL传给检索引擎(Ha3)精排算分插件。

•Item特征的离线抽取同样包括全量和增量两部分:天级别全量、15min级别增量回流到检索引擎(Ha3)。

•检索引擎(Ha3)精排算分插件获取query和item特征,在线计算相关性分。

图片

图2.搜索架构图

算法模型实现

搜索算法最终的doc排序往往是考虑多因子,而在闲鱼搜索中比较重要的因子包括成交效率因子、相关性因子和其他业务规则。简化来说可以先只讨论相关性和成交效率因子,而二者的融合方式大致有三种:

•相关性做档位分,下游根据相关性分层排序。

•相关性连续值score和效率score加权得到最终排序分。

•相关性和效率目标联合优化。

为做到对相关性的绝对控制,同时尽可能少的影响效率模型排序分,算法侧的链路选择第一种方式:在对Query、商品理解的基础上,构造各种相关性匹配特征,进而进行特征融合得到相关性档位(这里分为三档)。最后根据规则进行分档,输出给检索引擎(Ha3)精排算分插件和RankService重排做相关性的档位控制。

整体的相关性层次链路如下图,其中算法侧最为关键的部分包括基础理解、特征抽取以及特征融合。而特征抽取往往又依赖或包括了基础理解,因此下文将重点介绍特征构造和特征融合,并在特征构造的讨论中穿插基础理解的工作。

图片

图3.相关性链路

特征构造

搜索相关性的特征这里分为三个维度:基础特征、文本匹配特征以及语义匹配特征。基础特征主要包括query和item的统计特征,以及结构化相关的匹配特征,如类目是否匹配、关键属性(品类、品牌、型号等)是否匹配。文本匹配特征主要是字面上的匹配特征,如term匹配数、匹配率、带同义词策略的匹配、带term weight的匹配以及最基础的BM25分等。语义匹配特征则主要包括基于点击行为的表示匹配、文本和多模态语义匹配。

图片

图4.搜索相关性的特征

其中基础特征和文本匹配特征相对常规,不再详细展开。下面重点对语义匹配特征做进一步的介绍:

文本语义匹配

处于性能考虑,文本的语义匹配采用双塔向量匹配模型结构:基础模型使用开源的BERT,Query和Item共享相同的参数权重。同时为了适应下游的相关性分档,模型采用Pointwise的训练方式。篇幅原因,这里对模型细节不作展开。而相比模型结构的设计,其实闲鱼搜索中更重要的工作在于训练样本的构造。由于现阶段缺少人工标注数据的积累,所以当前该部分工作主要解决以下两个问题:

  • 高置信样本挖掘,缓解搜索点击日志“点击但不相关”的问题。
  • 定制化的负样本构造,避免模型收敛过快,只能判断简单语义相关性,而对上文提到的闲鱼场景"勉强相关"的难case无法区分。

针对以上问题,参考集团相关经验并结合对闲鱼搜索数据的观察分析,做了如下采样方案:

  • 正样本:
  • 充足曝光下高点击ctr样本(ctr大于同query下商品点击率平均值)

•负样本:

  • 同父类目的邻居叶子类目负采样。

  • 高曝光低点击类目样本:同一个query搜索下,根据点击过商品的类目分布,取相对超低频类目样本作为负样本(如类目分布占比 < 0.05的商品视为负样本)。

  • 充足曝光情况下,低于相应query平均曝光点击率10%以下的样本做负样本。

  • 基于query核心term替换构造负样本:如对于“品牌A+品类”结构的Query,使用“品牌B+品类”结构的query做其负样本。

    •随机构造负样本:为增加随机性,该部分实现在训练时使用同batch中其他样本做负样本,同时引入batch hard sample机制。

上述方式采样得到的训练数据,随机抽测准确率在90%+,进一步采样后量级在4kw+。在此基础上训练双塔模型,上线方式为离线抽取Embedding,线上查表并计算向量相似度。

图片

图5.文本语义模型

该部分工作独立全量上线,抽测top300 query + 随机200query搜索满意度+6.6%;同样文本语义向量用于i2i向量召回,复用到闲鱼求购场景,核心指标点击互动人次相对提升20.45%。

定义搜索query top10商品完全相关/基本相关占比>80%为满意,一组query评测结果为满意的占比为query满意度。

多模态语义匹配

除了文本语义向量匹配,本次工作也尝试了多模态语义向量。模型侧使用预训练的多模态BERT,类似工作集团已经有大量的尝试,本文主要参考过([1],[2]),并对模型和策略作了一些调整:

  • 替换多图特征抽取为首图region特征抽取做图像特征序列(resnet pooling前的特征序列),提升链路效率;
  • 替换Bert-base为Electra-small,减小模型参数(经测试47M的模型,下游分类任务精度损失2个点以内),方便与Resnet联合E2E训练。

下游的匹配任务仍使用双塔模型策略,和文本语义模型不同的是,这里直接使用Triple Loss的方式,主要考虑加大模型之间的差异性,使后面的模型融合有更大的空间。

图片

图6.多模态语义模型

PS: 该部分工作离线AUC为0.75相对较高,在下游特征融合AUC提升1个点以上。但在上线过程中,由于需要图像处理,增量商品特征更新回流相对其他链路延迟较大,容易造成新商品特征缺失,因此还需要进一步链路优化。

点击图表示匹配

除了上文提到的通过语义向量引入语义信息,还可以借助搜索日志中的点击行为表示query或item构造图结构引入新的语义表示。其中基于图结构的match算法SWING算法,在阿里内部应用广泛,相关的文章也有很多,这里不在阐述。针对闲鱼场景首先将<user, item>点击pair对改造为<item, query>点击pair对,这样直接沿用现有的swing工具,可以得到query2query的列表。聚合key query的所有相似query,并进行分词,对所有的term进行加权求和,归一化后得到key query的表示。

其中的权重为swing算法输出的score,key query的term权重默认为1。而对于行为稀疏的长尾query则使用上文语义向量召回最相近的头部query,补充其语义表示。最终得到的query表示实例:

图片

得到query表示后,item同样做类似的归一化表示。上线时使用稀疏存储的方式,在线计算匹配term的加权和作为点击图表示匹配分。

特征融合

准备好必要的相关性特征后,下一步则是对众多特征的有效融合,本文则采用经典的GBDT模型完成该步骤。选择GBDT模型的好处一方面在于检索引擎(Ha3)精排算分插件中有现成的组件可以直接复用,另一方面也在于相比于更加简单的LR模型可以省去很多特征预处理步骤,使得线上策略更加简单。

模型的训练使用人工标注的训练数据,标注目标为四档(完全相关、基本相关、勉强相关以及完全不相关)。在训练阶段,四个档位被映射到1、0.75、0.25和0四个分位,GBDT模型则通过回归的方式对分位进行拟合。由于该部分策略是对子特征的ensemble,因此并不需要非常多的训练数据(这里的量级在万级别)。

图片

图7.特征融合模型

最终,经过常规的调参,GBDT特征融合模型离线AUC可以达到0.86,基本符合预期(最优单特征AUC为0.76)。该策略全量上线,在文本语义向量的基础之上,不影响成交效率的前提下:随机query抽测(top 800w)DCG@10相对提升6.51%,query搜索满意度+24%;头部query同样也有相应的提升,相应地搜索体感也得到有效提升。

小结与思考

闲鱼搜索相关性优化第一阶段重点在于搭建相对完整的链路作为Baseline,为后续的进一步优化奠定基础。通过本季度的优化,基础相关性的问题得到一定的缓解,但仍存在比较大的优化空间。

而从进一步的case分析可以看出当前策略在细粒度属性/意图的匹配上表现不够优秀,同时也存在goodcase的误打压情况。因此后续的优化方向也比较明确:优化现有特征细节;增加更精细的相关性特征如query tagging、商品结构化特征、核心词匹配等;积累更多的人工标注数据,同时探索更加细粒度的匹配模型。

最后抛出策略优化过程中的两个思考:

1、相关性与成交效率的“冲突”:工作中被挑战最多的问题,为什么相关性提升没有带来交易效率的提升?对于这个问题的几点考虑:

  • 技术方案不完美是客观存在的,如上所提到的因为策略问题导致goodcase误打压的情况,会损失一部分交易效率。
  • 相关性或者商品治理优化会将一些勉强相关但可能成交的周边产品打压,如相关性优化后搜“手机”类型的query不再出成交频次更高的“手机壳”、“屏幕”、“总成”等配件、零件,搜“xx车”不再出“轮胎”、“轮毂”等配件;治理优化后“低价引流”或“欺诈”商品减少明显,但有意思的是欺诈的商品成交效率往往高于正常商品。
  • 完全不相关的query优化后确实会提升交易效率,但和上述交易效率的损失中和后,整体的交易效率提升会变弱。
  • 最后个人认为电商搜索优化的路径,应该是开始就在相对严格相关性条件下进行成交效率的优化,进而逐步放宽召回限制并同时优化相关性策略,达到相关性和成交效率同步提升。如果在一开始就在弱相关性的条件下只关注成交效率,让系统处于一个放飞的状态,突然关注体感的时候一脚刹车,难免会带来想吐的感觉。

2、体感会不会骗人:二手交易市场,本身就是“杂”的特质。而很多时候技术同学并不是闲鱼的目标用户,“我”认为的相关和体感并不一定是用户的真实需求,一刀切的治理和相关性优化是否会损失掉一部分闲鱼产品特色需求的满足(当然不是说欺诈和色情之类),真正说清楚这个问题还是需要更多的数据支持以及对产品更深层次的理解。

[1] Hao Tan and Mohit Bansal. Lxmert: Learning cross-modality encoder representations from transformers. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing, 2019.

[2] Jiasen Lu, Dhruv Batra, Devi Parikh, and Stefan Lee. Vilbert: Pretraining task-agnostic visiolinguistic representations for vision-and-language tasks. arXiv preprint arXiv:1908.02265, 201


本文地址:https://www.6aiq.com/article/1626310476669
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出