数据与广告系列三十二：重排ReRank，广告推荐算法链路上的背叛者，生态系统格局的重塑者...

作者·黄崇远

『数据虫巢』

全文23138字

题图ssyer.com

“ 在推荐系统又或者计算广告中，重排ReRank明目张胆的把召回、粗排、精排几个链路逻辑辛苦生成的序给打乱，但却敢号称是为了大局着想。这是一个非常有意思的算法阶段，细思下去充满乐趣，当然也充满挑战。”

在整个系统推荐或者计算广告中，重排ReRank并没有如排序Rank这般知名度高，甚至再往前追溯的召回阶段都比他更被为人所熟知，更不用说精排进一步拆分的粗排、精排细分阶段。

这种陌生，一方面体现在于模型论文的持续沉淀，另一方面在于业务逻辑中其起到的核心作用。前者看各个期刊的收录的论文中，重排领域的内容占比即可，对比于排序、召回，其受“冷落”的程度是一目了然的。后者在于哪怕是推荐广告领域的从业者，重排对于整个系统真正的意义在哪，可能都无法说出个很明确的之所以然来，大部分可能只会止步于用户体验和多样性，这是远远不够的。

但他理应受到如此“待遇”吗？理论上不应该的，特别是在流量红利触顶，同质化严重，纷纷挖掘流量存量价值的时代，它将变得越来越重要。而其产生的价值，以及其在整个链路中所带来的作用，愈发值得我们深思下去，其技术逻辑以及业务逻辑，也比我们想象中更有乐趣，以及更有挑战。

所以，我们这篇的主题是重排，一个看似简单但实际上非常有趣且重要的算法应用阶段。

所以，这篇会包含整个推荐广告算法链路的定位拆解，排序与重排的深入讨论，重排底层技术逻辑的拆解，以及广告领域中独有的重排序的现状，以及突破其格局的求解思路。每个章节都是相互关联的，层层递进，业务与技术点所结合，让读者朋友们不但能理解重排的业务场景，也能充分理解到为什么要这样做，以及如何做，最终希望延申到自己的业务场景中该怎么做。

而聊重排，自然就绕不开重排所处的整个算法链路的位置，对于前置阶段的依赖，以及不同算法阶段的定位。

01

排排不休，繁复的算法链路

关于推荐系统或者计算广告的整个算法链路，我们直接上图。

图1 推荐广告算法链路图

如图，这里我们不做推荐系统还是计算广告的具体区分，我们按用户推荐或者广告触发，在推送或者播放请求的场景里，以item候选缩减的视角来观测整个算法链路的构建。

起点是数十万，甚至是百万级的候选item，例如商品SKU，而终点是若干最终推荐出来的Item，例如推荐系统中通常会有若干陈列的item，而广告播放场景中可能最终只会取Top1的最终广告为用户进行广告播放。

Item的数目从数十万到十的量级，中间经历了一些硬性的条件过滤，以直接刨除不符合条件的候选，然后进入到候选召回环节，将候选缩减到万的级别，在进入粗排阶段，将候选量级缩减到千的级别，最终过精排输出了数百的序，经过ReRank进行序的重新排列，最终根据应用场景做截断，截断成TopN还是Top1。

而整个过程，以信息流为例，包含在了从用户滑屏触发到Item推荐或者广告播放出来的底层逻辑中，用时可能仅仅是100个毫秒。

所以，为什么看着整个链路逻辑图如此繁复，最核心的诉求在于，如何在短短的100ms内在数十万的候选中，快速筛选出合适的Item推送出去，以达到业务目标最大化，例如广告的流量效率最大化，推荐的转化最大化等目标的实现。

基于候选的量级缩减以及时效的要求，这就对应于不同阶段的定义，模型实现逻辑，工程逻辑有不同的要求，各司其职，最终才能使得整体业务收益的增长或者说最大化。

抛开基于条件硬性过滤的Filter逻辑不说，我们从真正能缩减量级的召回说起。关于推荐的召回，对于熟悉经典的同学来说，第一反应应该就是所谓的多路召回。

图2 传统多路召回逻辑图

热点召回基本上就是基于历史统计的信息做非个性化的热点Top召回；纯粹照顾新item的冷启动召回；i2i的话基本是直接计算item与item的相关度，但是实现手法上又有不同的选择，比如直接计算item之间的表面语义相关，又或者基于itemCF协同的逻辑融入user与item的交互行为计算i2i的相关性，甚至同类别，同个聚类下的item集合都可以作为召回逻辑；u2i的话，传统逻辑就是基于userCF的协同，拿到user与item的关系；除此之外，还有给item打标签的，然后同时给user也打标签，通过检索逻辑做标签匹配的召回等等。

如上这种多路召回的逻辑，典型特色就是种类繁多，逻辑各异，也不知道是谁想出来的，理解起来太费劲了。这些召回逻辑的有一个共同特点就是快，能够在短短10ms左右时间把符合召回逻辑的候选给筛选出来，那么要么是直接内存查找数据，要么是通过倒排索引提前构建好索引，然后进行检索召回。

而如上的逻辑不管是查表还是规则，大部分都依赖于离线的计算，哪怕是诸如上了一些聚类，协同过滤的模型，都是离线建模，离线预测，在线数据加载，然后内存检索的路子。

这是候选多、响应时长短导致的工程限制。

而为什么会出现这么多不同逻辑的召回，本质上离不开召回阶段的能力定义--为后续排序阶段提供更多潜在的候选，更多的可能性。所以多路召回中才有忽略了个性化的优质候选，与推荐标的物相关的item候选召回逻辑，以及有用户行为个性化的协同推荐逻辑，或者兴趣标签相关的召回逻辑等。

从不同维度为排序阶段提供输入候选，本义上还是为后续排序阶段提供更多潜在的有用Item候选，如何定义有用，则涉及到精排的建模目标，以最常见的pCTR为例，即预测当前user对于候选item的点击率如何，以广告为例，同样是pCTR预估（先不讨论更为复杂的转化等问题），只是最终排序是叠加了bid之后的eCPM。

除此之外，多路召回的另一层产品逻辑的意义在于，提供多种逻辑的召回，从而增加了候选item的多样性，从而提升了用户体验。

但为了满足多样性带来的多路逻辑召回，首先需要解决的是融合问题，因为下游粗排对于能够接受处理的候选item数量是有限的，以透传下游一千候选为例，众多的召回逻辑，其计算逻辑是不同，有基于静态统计，有基于简单的标签匹配，有基于简单的协同模型离线计算，所以很难放在一个维度上进行截断。

目前仍然采用传统多路召回的系统中大部分采用的是配比融合，即每一路按比例进行Top融合，最终取够既定的数量item透传给下游。

但这种逻辑有很大的硬伤。

其一，这种比例搭配很多时候只能靠拍脑袋来决定，无法量化衡量其合理性。

其二，抛开不一定叠加的重排不论，召回之后至少尚有粗排精排，而粗排精排的建模目标非常明确，就以常规的点击率场景为例，优化的就是单次user与item的pCTR最大化，简单点说就是哪个pCTR大就排在前头。会不会存在比如热点召回的item都被粗排干掉了？又或者基于i2i的召回大部分排序靠后？这是完全有可能的，所以最终很有可能哪怕你在比例逻辑中设置了较大的比例，但最终经过了粗排精排之后大概率被丢弃了，多路了个寂寞。

因此，近些年才有两个核心主流的方向在引导召回往向量召回方向发展，以及一直强调召回粗排与精排的整体目标一致性。

关于向量召回，可以参考前面系列的文章《数据与广告系列二十五：Embedding的起源与演化，以及序列构建与目标拟合派的流派之争》《数据与广告系列十九：推荐召回与广告LookAlike，万物皆可Embedding》以及《数据与广告系列二十二：智能化投放中扩量场景的技术实现策略》中的实现向量召回的双塔模型结构图。

图3 广告召回中的双塔模型向量召回

趋于主流的向量召回解决方案，一方面是顺应了深度模型逐步走向前言的大趋势，另一方面数据暴涨的堆叠可以对网络进行充分的训练，最后就是双塔的结构最终可以很好的进行离线预测，在线部署，工程维度上进行高效的向量检索，从而在目标一致性上，以及工程效率上都能满足。

且由于建模目标上与排序阶段保持了一致，因此item-vec与user-vec的内积计算，是可以表征user*item关系的，因此，想要向下游透传多少量级，只需要按Top截断即可。

至此，召回逻辑就不再细述，我们进入排序阶段。

如图1所示，本质上不管是pre-rank还是rank其实都是排序，在早期时，甚至很多推荐系统并未拆分pre-rank，而拆分的原因也非常明确，那就是在有限的响应时效内，精排无法在追求高精准的预估前提下，对于过多的候选进行逐一判定。

为什么是逐一判定，因为大部分精排所采用的建模方式都是pointwise，这是对于当个item*user最细颗粒度的建模预估，因此其响应效率完全与其输入的待排序候选有直接的关系，不说是线性关系，最起码是正相关关系。

而pre-rank在大模块上与rank保持一致，与match区分开，同样是阶段定位问题，pre-rank与rank的建模目标可以认为是完全一样的，包括样本构造方式，如果不受限于pre-rank的输入候选更多，响应时长的要求，甚至可以认为特征输入也是差不多的。

因此，pre-rank为了保持与rank的目标一致，在建模目标、建模方式、样本完全一致的情况下，只能对模型网络进行简化、对复杂特征进行缩减，可以看作是一个轻量级的rank模型，这是过去非常主流的做法，特别是在深度网络时代，rank阶段的网络结构是非常复杂的，这就为通过简化网络从而牺牲部分预测精度来换取对更多候选的轻量预测提供了更大的空间。

除此之外，当前比较流行的模型蒸馏也同样为简化模型提供了一个非常好的落地思路。以及，既然粗排是完全作为rank的预选动作，并且只为预估的准确和精度负责，那么直接去学习拟合精排的序是否可行？这又是当下另一条粗排建模的路径，LTR（Learning to rank）。因为本质上哪怕是广告，最终靠eCPM（pCTR*pCVR*CPAbid）来排序，其实在精排前理论上只需要序的截断，不需要精确的知道每个item的pCTR或者pCVR，只需要确保截断列表中的item的相对位置是对的即可。

关于排序，系列文章中几乎没有涉及到，这也是笔者慎之又慎不敢轻易下笔的领域阶段，因此，这里不过多阐述，等输出排序相关的篇章的时候我们再来展开。

最后，我们来看rerank。

聊之前需要明确的一个点是，在图1的算法链路逻辑中，只有match和rank是必选项，pre-rank和rerank本质上是可选项，最起码在很多推荐广告场景中是这样的。至于说大厂，卷不完的人力物力下，海量候选下，复杂的业务诉求下，就没有所谓的可选项了，豪的剩下都是必选项，并且怎么复杂怎么来了。

从目前已有的大部分资料中，我们可以查询到的重排是这样定义的保证推荐item的多样性，更为关注用户的体验，又或者是插入一些商业规则逻辑的考量。

抛开硬性的策略调整不说，从建模思路角度上，重排的目标不再局限于单次user*item的匹配关系，而是user*N-items的关系，这就意味着需要考虑到前后推送item之间的相互影响，这一点在推荐场景尤其重要，在广告场景稍微感知不那么强，因为广告场景会有严格的频控存在，前后曝光的items之间的感知会弱化很多。

对于重排，更为直观的定位是提升推荐结果的多样性，从而提升用户的感知体验，而不管是深一层的体验角度，还是直接的多样性考量，都已经脱离了单个item的判断，而是以一个推送list的好坏作为评估标准，而非单个item*user的转化率为评判标准。

因此，从整个链路逻辑来看，按当前主流的模型解决方案来评估，不管是召回，还是粗排，其目标对齐的是精排，这就是我们所说的目标一致性。更多时候精排的前置阶段，不管是召回还是粗排，本质上都是为精排缩小候选规模，以达到在规定时效内，快速精准进行单个item价值预估而服务的。

而重排不同，他位于整个算法链路逻辑中的最后一环，掌握了将精排序重新打乱的权力，但其目标又迥异于排序，更多关注于List结果的多样性，以及用户整体感知体验的提升，从这个角度上看，ReRank都像是整个链路的背叛者。

但是，他绝不是单纯的“背叛”了召回、排序，也不是单纯的为了用户体验“强行”插入的多样性目标，而是肩负了更大的责任，那就是重塑系统生态的格局，理应站的更高看的更远。