Fork me on GitHub

腾讯技术 | 超强指南!推荐算法架构——重排

导语 | 重排技术细节非常多,一定要清楚技术架构大图,从而将细节串联起来。实际上主要是为了解决三大方面的问题:用户体验、算法效率、流量调控。

在上篇*《图文解读:推荐算法架构——精排!》* 中我们结合算法架构精排进行解读分析,本篇将深入重排这部分进行阐述。

一、总体架构

精排打分完成后,就到了重排阶段,之后可能还会有混排。召回、精排、重排三个模块中,重排离最终的用户展现最近,所以也十分关键。重排的技术点也十分多,总结下来,个人认为重排主要是为了解决三大方面的问题:用户体验、算法效率、流量调控。下图是重排总体架构:

图片

二、用户体验

重排模块是推荐系统最后一个模块(可能还会有混排),离用户最近。作为最后一层兜底,用户体验十分重要。主要包括打散、多样性等内容。曝光过滤有时候也会放在重排中,但本质上完全可以在召回链路,对已充分曝光的短视频,或者刚刚已经购买过的商品,进行过滤,从而防止用户抵触。

(一)打散

对同类目、同作者、相似封面图的item进行打散,可以有效防止用户疲劳和系统过度个性化,同时有利于探索和捕捉用户的潜在兴趣,对用户体验和长期目标都很关键。

打散问题一般可以定义为,输入一个item有序序列,每个item有几个需要隔离开的属性,输出一个相似属性分离开的item序列。打散可以基于规则,也可以基于embedding。基于规则比较简单可控,但由于item属性枚举值较多,可能需要频繁更新,扩展性不强。基于embedding的打散,泛化能力强,但容易出现bad case。目前主流方法仍然是基于规则的打散。

基于规则的打散主要有如下几种:

  • 分桶打散法:将不同属性的item放入不同的桶中,依次从各桶中取出item即可。这种方法实现简单,打散效果好。但末尾容易扎堆。对原始序列改变较大,可能带来指标的下降。多属性叠加困难,扩展性也较差。
  • 权重分配法:对每个item定义一个分数,计算公式如下:

图片

其中W为每个属性的权重,代表属性打散需求的优先级。Count为同属性item已经出现的次数。f(x)即为打散加权分数,按照它从低到高对item进行排序,即可完成打散。这种方法实现也比较容易,而且可以充分考虑多种属性的叠加,扩展性也很强。但仍然容易出现末尾扎堆。

  1. 滑动窗口法:在一个长度可控的滑动窗口(session)内,同属性item超过一定次数后,就交换出session。这种方法只用考虑局部,不需要全局计算,因此计算量较低。同时对原序的破坏也比较低,最大限度保留相关性。但也会出现末尾扎堆的现象。

(二)多样性

多样性是一个很大的话题,后面我们会作为专项来梳理。多样性会对用户体验、长期目标有比较关键的影响。召回、精排、重排全链路都要考虑多样性问题,但确实一般重排中考虑比较多一些,我们这儿也一起分析下。

  • 评价指标

多样性评价可以使用两种方法:

  • 数据指标分析:可以从user和item两个角度评估,比如平均每个用户的曝光一二级类目数,曝光item同属一个类目的概率等。可以从类目、作者、标签等多个维度进行数据分析和评价。
  • 人工评估:抽样进行人工体验,评估多样性。

两种方法各有所长,一般还是需要结合一起使用。特别是人工体验评估,千万不可忽略。算法工程师也要经常去体验和对比自己的实际业务场景。

  • 发展进程

个人认为多样性算法经历了三个阶段:

  • 规则约束:基本都是基于规则,没有结合相关性来考虑多样性问题。主要有三种:
  • 硬规则约束:比如类目打散、作者打散、同图打散等。一般业务初期都会采用这种方法,开发简单快速,没有实现配置化,所以扩展性不高。新的打散需求一般要重新开发和部署。
  • 规则引擎:规则抽象化和配置化,上线速度快,新增需求只需要新增一个规则即可。
  • 个性化约束:不同类目、不同时段、不同活跃度用户配置不同。比如手机和抽纸,他们的打散窗口可能会不同。不同活跃度人群,其耐受度也会不一样。
  • 启发式方法:多样性和相关性相结合的方法,充分保留相关性。主要有:
  • MMR:最大边缘相关模型。1998年发表,比较老。参见The Use of MMR, Diversity-Based Reranking for Reordering Documents and Producing Summaries
  • DPP:点行列式矩阵。NIPS2018。参见Fast Greedy MAP Inference for Determinantal Point Process to Improve Recommendation Diversity
  • Deep-DPP:结合深度神经网络的DPP,CIKM2018,youtube。参见Practical Diversified Recommendations on YouTube with Determinantal Point Processes
  • 深度模型:主要是加入了上下文感知,从而可以结合规则引擎实现多样性。这部分在与下一章节的上下文感知模块比较类似,放在那边统一梳理。

三、算法效率

重排对于提升算法准确率和效率,从而提升业务指标也十分关键。重排提升算法效率,主要分为三个方向:

  • 多任务融合。精排输出的多个任务的分数,在重排阶段进行融合。可以基于人工调权、grid search、LTR或者强化学习。
  • 上下文感知。精排由于计算性能因素,目前是基于point-wise的单点打分,没有考虑上下文因素。但其实序列中item的前后其他item,都对最终是否点击和转化有很大影响。context-aware的实现方式有pairwise、listwise、generative等多种方式。
  • 实时性提升。重排比精排模型轻量化很多,也可以只对精排的topK重排,因此较容易实现在线学习(目前有一些团队甚至实现了精排在线学习)。实时性提升对于快速捕捉用户实时兴趣十分重要,能大大提升模型准确率和用户体验。通过ODL在线学习,实现重排模型实时更新,可以提升整体链路实时性。另外在端上部署模型,实现端上重排,也可以实现推荐的实时响应和特征的实时捕获。

(一)多任务融合

当前大多数业务场景需要优化多个任务,算法模型也已经实现了多任务学习,比如MMOE和PLE等。那模型输出的多个任务分数怎么融合呢?我们可以在精排阶段融合,也可以在重排阶段融合。由于重排模型相对精排要轻量级一些,容易实现在线学习,所以有不少场景放在重排阶段进行多任务融合。

图片

目前多任务融合主要有以下几种方式:

  • 人工调权:通过专家先验知识,设置多任务融合的超参数。这种方式比较简单,业务发展初期通常采用。缺点也比较明显:
  • 超参组合的选择依赖专家经验,准确率有限,有一定的效率浪费。
  • 固定的超参不能快速自动适应业务和模型迭代,对整体链路算法效率有比较大的影响,甚至负向。
  • Grid search:将各参数可能的取值进行排列组合,穷举搜索所有的可能,再逐步输入系统中进行评估,选择效果最好的参数组合。相比人工调权,grid search显然更有可能找到最优的参数组合。但它缺点同样明显:
  • 超参排列组合多,搜索空间大,十分耗时。超过4个超参后,计算量就要爆炸了。
  • 难以进行在线AB,不能准确拿到用户反馈。这也是超参搜索空间大导致的。
  • 同样不能自动适应业务和模型迭代,会成为整个链路的优化瓶颈。
  • 模型法:将精排各任务的打分结果,采用线性模型或者比较轻量级的深度模型,构建监督学习。一般也可以将其他比较重要的特征,比如商品价格、销量、近期CTR、近期CVR,一起融合在重排模型中。由于精排的打分结果已经相当置信了,重排模型可以尽量轻量级一些,所以比较容易实现在线学习,实时更新特征和模型,提高重排模型的实时能力。模型法优点很多,在目前各业务场景中广泛使用。其缺点主要有:
  • 仍然是基于point-wise的,没有上下文感知能力。
  • 业务场景最终指标必须单一。重排模型做多任务融合,其监督目标必须是一个单一的任务,否则谁来融合重排呢?比如电商场景下订单量指标,一般会在精排构建CTR(曝光到点击)和CVR(点击到转化)两个任务,重排则统一成CTCVR(曝光到转化)即可。但如果还想把用户互动指标(比如收藏、分享、评论)也加入进来,则较难建模了。
  • 强化学习:根据用户在不同状态下的行为,利用强化学习建模状态转移过程,从而提升业务核心目标。state为用户特征,比如用户静态特征、统计特征等。Action为当前各任务的融合参数。reward可以根据业务场景定义,比如内容推荐场景中,一般为用户打开APP到退出的总时长。可以采用DQN、DDPG、A3C等方法。

图片

(二)上下文感知

由于精排模型一般比较复杂,基于系统时延考虑,一般采用point-wise方式,并行对每个item进行打分。这就使得打分时缺少了上下文感知能力。用户最终是否会点击购买一个商品,除了和它自身有关外,和它周围其他的item也息息相关。重排一般比较轻量,可以加入上下文感知能力,提升推荐整体算法效率。

图片

context-wise建模的方法主要有:pairwise和listwise两大类。

  • Pairwise

通过对比两个商品之间相对关系来构建,有一定的上下文感知能力,但仍然忽略了全局信息,而且造成了极大的计算和性能开销。这种方法有RankSVM、GBRank、RankNet、LambdaRank等经典的pairwise LTR方法。

  • Listwise

建模item序列整体信息,通过listwise损失函数来对比商品之间序列关系。可以通过DNN、RNN、self-attention等多种方式建模和提取item序列信息,再通过beam-search等贪婪搜索方法得到最终的序列。主要有五种建模方法:

  • 树模型:LambdaMart等。
  • RNN:DLCM、seq2slate等,分别利用RNN+attention,和pointer-network来构建seq2seq模型。
  • 两段式:PRS等,构建PMatch和PRank两个链路,通过两段式结构得到最终输出。
  • self-attention:PRM、SetRank等,和RNN模型比较像,将RNN替换成了self-attention,客服长程建模梯度弥散问题,以及串行计算耗时过大等。
  • 强化学习:LIRD、GRN等。

这儿简单介绍下PRM,它构建了input layer、encoding layer、output layer三层,通过self-attention使得序列内item充分交互,提取序列信息,通过贪婪搜索得到最终序列:

  • input layer输入层:得到排序阶段输出的有序序列,输入包括三部分:
  1. 每个item对应一个特征向量E。
  2. user和item之间计算一个个性化向量PV,通过预训练模型得到。
  3. item的位置编码PE。
  • encoding layer编码层:通过self-attention建模,每个位置输出一个编码后的向量
  • output layer输出层:编码层输出的每个位置的向量,通过一层线性层和softmax后,得到每个item的概率。通过beam-search等贪婪搜索方法,得到最终的序列。

图片

整个过程和机器翻译等NLP场景任务很像,同样可以结合pointer-network来优化。paper地址:(https://arxiv.org/pdf/1904.06813.pdf

(三)实时性提升

推荐系统的实时性也是一个比较大的话题。实时性对于提升用户体验,优化算法效率,都十分重要。实时性主要包括3方面:

  • 系统响应实时性:考虑到推荐系统QPS压力,用户一次请求会下发多个item,浏览完后重新请求才会触发系统新的响应。系统响应实时性,对于用户实时行为捕捉十分关键。基于端上重排的系统,可以实现响应的实时性。
  • 特征实时性:用户行为特征实时性、item统计特征实时性等。相对来说特征实时性是最容易做到的,也是对推荐效果影响最大的。特征实时性要考虑系统链路数据回收延迟,和用户本身行为延迟反馈问题。
  • 模型实时性:在线学习,实时更新模型等。重排模型比较轻量,容易做到实时更新。精排相对来说困难一些,但也有一些团队实现了精排的在线深度学习ODL。

重排阶段提升实时性主要方法有,在线学习ODL和端上重排,下面详细讲解。

  • 在线学习ODL

深度模型由于需要的训练数据和时间都比较大,资源消耗也比较多,故一般以离线训练为主。小时级或者天级更新。对于用户的实时行为pattern,或者冷启item都不是特别友好。特别在大促期间和秒杀场景,用户兴趣和需求转瞬即逝,商品也随时可能会被售空。我们这儿就不谈数据链路和推荐工程方面的工作了,算法方面主要的问题有:

  • 延迟反馈:用户点击完商品后,可能大数据系统中需要几分钟甚至数小时后才收集到他的购买行为。延迟反馈显然对于label置信度是个很大的挑战。主要原因有数据链路延迟和用户行为延迟。flink收集数据有一定的链路delay,用户也可能犹豫几小时后才真正购买。延迟反馈需要平衡样本置信度和模型新鲜度。优化方法有:

    负例校正法:先标记为负样本,等真正转化后再重新插入正样本。这种方法可以保证模型新鲜度,但假负例会对模型有一定的副作用。(https://dl.acm.org/doi/abs/10.1145/3298689.3347002

    等待法:一定时间内等待真实的成交转化,如果没等到,不管后续有没有,都不校正了。这种方法label置信度有一定提升,但模型新鲜度会有折损。
    https://arxiv.org/pdf/2002.02068.pdf

    纠偏法,例如ES-DFM,对观测转化分布和真实转化分布之间的关系建模,降低假负例的权重和增加真正例的权重,来纠正样本不置信问题。
    https://arxiv.org/pdf/2012.03245.pdf

  • 数据稳定性:数据随时间波动大,比如电商CVR。很多用户习惯白天浏览点击,晚上真正下单。所以CVR在晚上明显比白天高。这时候需要做一定的修正。也可以在线学习和离线增量学习相结合。每天固定一个时间点,对模型做一次天级离线增量更新。从而修正在线学习中积累的误差。

  • 边缘计算与端上重排

边缘计算和端上重排这两年一直都很火,它可以有效降低云端负载,保证数据安全隐私性。同时也可以提升算法效率,算法侧的优点主要有:

  • 推荐响应实时性:不用请求下一页,实现即时更新。
  • 行为特征实时性:端上即时计算,不用回传云端。
  • 行为特征丰富度:负反馈、滚动速度、曝光时长等多种用户行为都可以在模型中使用,基于云端的方式受限于数据传输和存储,一般只会选择点击等关键的用户行为。

端上重排需要将一个轻量级的模型,部署在端侧,实现端上推理。

四、流量调控

流量调控在推荐系统中也十分重要,重排在最后一环,责无旁贷。流量调控要兼顾实时性和准确性,二者之间需要达到平衡。流量调控的作用和方式主要有:

  • 保量类:通过流量扶持,刺激生态建设。比如对冷启item,新热item,大V的新发布item,均可以给予一定的保量流量,让他们能够顺利透出和正循环。保量的实时性也十分重要,作者能第一时间看到自己item得到的点赞、评论等,有利于刺激他们持续创作。保量常见的方法有:

    规则引擎:制订一定的策略规则,实现保量。这种方法简单易行,item也肯定能获得一定流量。但准确度较低,也较难实现个性化。流量容易不够或者超发。

    探索和利用:通过e-greedy、Thompson sampling、UCB等EE类的方法,可以有效探索冷启item,同时利用已有item,保障效率折损最低。

  • 调权类:一般是业务运营需求,需要快速实时干预。比如三八妇女节需要临时对美妆类item做加权,增加其流量。过了这一天可能效果就会大打折扣了。常见方法有:

    规则引擎:直接在重排结果上,对于命中属性规则的item,加入一定的分数,使得最后可以透出,增加其流量。这种方法简单易行,实时性好。但调权准确率低,也较难个性化,可能造成较大的流量浪费和效率折损。适合某些时效要求高的场景。比如大促期间加权等。

    样本加权:对于命中调权规则的样本,增加其在loss中的权重,迫使模型偏向于对它们精准预估。这种方法可以实现个性化,对效率折损较低。但由于需要训练模型并重新上线,故实时性不高。适合某些长期性的调权场景。比如对大店、大V的加权等。

    图片

谢杨易

腾讯应用算法研究员

腾讯应用算法研究员,毕业于中国科学院,目前在腾讯负责视频推荐算法工作,有丰富的自然语言处理和搜索推荐算法经验。


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