做展示广告CVR预估的同行,应该都体会过一种无奈:线上模型明明离线指标很漂亮,上了线却总感觉转化率被高估了,尤其是新广告和冷启动商品。我前几年排查这类问题时,最后几乎都会定位到同一个根源——延迟反馈。用户点击广告之后,转化不是瞬间发生的,有人几分钟就买了,有人货比三家两三天才回来下单,偏偏我们训练模型的时候,把“点击后还没转化”的样本统统当成了负样本。这个偏差不解决,模型估的其实不是“会不会转化”,而是“在观察窗口内会不会转化”。阿里妈妈这次在WWW‘26上提出的级联延迟反馈建模框架,把这个问题往前推了一大步,因为它处理的不是单层延迟,而是“展示→点击→转化”这条链路上同时存在的多重延迟。这篇就把这个框架的核心逻辑、训练细节和工程落地的关键点拆开讲清楚。
1. “延迟”到底有几层:从单一延迟到多重延迟的问题演进
很多人一提到延迟反馈,脑子里只有“点击到转化”这一层延迟。这没有错,传统CVR建模确实是围绕这条链路做的。但在展示广告的真实场景里,事情要复杂得多。用户看到广告之后,不一定会马上点击,可能在当前页面停留一阵,翻翻其他内容,然后才点进来;点进来之后也不一定马上转化,可能还要比较评价、咨询客服、跟家人商量。也就是说,从广告曝光到你观测到转化行为,中间其实经过了两次时间间隔:展示到点击的间隔,以及点击到转化的间隔。这两段间隔叠加在一起,才是我们真正观测到的“总延迟”。
为什么要抠这个区别?因为建模方式完全不同。如果把“展示到转化”当作一个整体延迟来拟合,你会丢失中间状态的信息。比如一个用户展示了10分钟才点击,点击后立刻购买了,和另一个用户展示后立即点击,但过了10天才购买,两者从“展示时刻”看过去的最终转化时间可能差不多,但它们的性质完全不同:前者是点击意愿的延迟,后者是转化决策的延迟。流量质量、广告创意吸引力、商品承接力分别作用于哪一段,也被混在了一起。
这样讲可能有点抽象,我举个更生活化的例子。你在商场门口看见一家新店的广告,当时没进去,逛了两小时才进店看看,这是“看到广告到进店”的延迟;进店之后你反复试穿、犹豫,最后结账,这是“进店到购买”的延迟。如果你只统计“看到广告到结账”的时间长度,你会觉得整个过程很慢,但你没法分辨是广告没吸引你,还是商品不够让你立刻下单。对CVR模型来说,这两种情况如果要优化,手段是完全不同的。广告系统需要的是区分开的能力,而不是把两者糊成一个黑盒。
更进一步,这个区分对训练信号的构造有直接影响。传统方法在训练时,对“点击后未转化”的样本统一标记为负样本,用极大似然去训练pCVR。一旦考虑展示到点击的延迟,你就发现一个尴尬的问题:观测到的训练样本本身是有偏的。那些“展示后很久才点击、点击后很快转化”的样本,在观察窗口内可能只被记录成了“未点击”或“未转化”,它们实际是延迟样本,却被当成了负样本。这种有偏监督信号,会在训练中持续给模型传递错误信息。
从问题定义上讲,阿里妈妈这篇工作有意思的地方在于,它把延迟反馈建模从单层扩展到了级联结构。级联的意思是:整个转化过程被建模成“先发生点击、再发生转化”这样两个阶段,每个阶段都有自己的延迟分布,两个阶段联合起来构成最终观测。这个思路并不复杂,但它改变了目标函数的构造方式,也改变了训练样本的权重分配方式。后面我会详细拆这套目标函数是怎么设计出来的。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 现有方案为什么在多重延迟场景下“按下了葫芦浮起了瓢”
要理解新框架的价值,先得知道之前的方法是怎么做的,以及它们卡在了哪里。业界比较基础的做法是DEFER这类延迟反馈建模思路。它的核心是把“在观察窗口内未转化”的样本从绝对负样本改造成带权样本:如果一个样本在观察窗口内未转化,它既可能是真负样本,也可能是“还没转化”的正样本。DEFER用延迟分布的概率密度函数和时间戳信息,去估计“这个样本到底有多大概率是假负样本”,从而修正训练目标。
FNW这类后续工作做了进一步扩展,它不再只预测一个固定的延迟分布,而是让延迟分布的参数也依赖于特征,比如用h(t)和H(t)的条件概率形式去建模“给定特征,转化发生在t时刻的概率密度”和“给定特征,转化发生在t时刻之后的生存概率”。这样每个样本都有自己的延迟曲线,比用一个全局分布要精致得多。
这些方法在实际工程里确实有效,但本质上它们都建立在“单一延迟”的假定上。什么意思?就是它们把“从点击发生的时刻到转化发生的时刻”作为唯一的延迟变量来建模。在一些场景下,例如搜索广告里用户点击行为比较集中、点击和转化间隔相对独立,这个假设勉强够用。但在展示广告里,点击行为本身就是稀疏且延后的,用户的点击可能发生在展示后几秒到几天之间。如果你忽略“展示到点击”这一层延迟,直接用“点击到转化”的延迟分布去补偿观察窗口内的未转化样本,会发生两件事:
第一,假负样本的辨识会失真。一个样本“展示后第3天点击、点击后第1天转化”,观察窗口是7天。从“点击时刻”看,它只用了1天就转化了,延迟很短;但从“展示时刻”看,系统在第4天才观测到转化。如果你只按点击后的延迟来判断,你会低估这类样本的延迟,把它们归入“很快转化”的一类,导致延迟分布估计偏乐观。下游纠正假负样本权重时,就会给这些样本分配过高的负样本概率权重,造成CVR被系统性低估。
第二,点击模型的训练信号被污染。展示广告的CTR模型和CVR模型往往是联合训练或级联训练。如果点击延迟没有被显式建模,CTR模型的训练样本同样会有“展示了但没点击”的假负样本问题。那些晚点才点击的样本,在观察窗口内被当作负样本喂给CTR模型,会导致点击率预估也偏低。CTR低,CVR高,两者乘起来看着可能“运气好”抵消了,但一旦流量结构发生变化,比如某个渠道的延迟特征变了,这个平衡就瞬间崩掉。
用一句话概括,就是“按下葫芦浮起了瓢”。你只处理了转化延迟,点击延迟的偏差累积到上游;你试图用更复杂的延迟分布拟合转化延迟,但训练数据本身又是因为点击延迟而缺失的。要根治,必须把两段延迟放在同一个建模框架里联合处理。
不过这里要说明一点,我上面的批评只针对“把单层延迟模型直接搬到多重延迟场景”的做法。DEFER和FNW这类工作本身的价值是巨大的,它们把“延迟反馈是噪声”重新定义成了“延迟反馈是可建模的信息”。阿里妈妈这个新框架,本质上是在这个范式之内,把延迟的维度扩展了。
3. 级联延迟反馈建模的核心框架:两段条件分布的联合分解
现在进入正题,看这个新框架是怎么设计的。核心思路,是把从展示到转化的全过程,拆成两级条件事件。第一级是展示后发生点击,第二级是点击后发生转化。两级各有各的延迟时间变量,分别记为延迟一和延迟二。整体的观测概率,就是两段条件概率的联合积分。
从数学表达上看,假设一个样本在时间零点被展示,点击发生在时刻t_c,转化发生在时刻t_v。那么联合事件“在t_v时刻发生转化”的概率密度,可以写成一个积分形式:从0到t_v,对“点击发生在s时刻、点击后经过t_v-s时间转化”的所有可能性做积分。这个拆分的好处在于,它把问题转化成了两个相对独立的学习目标:一个是点击延迟分布,一个是转化延迟分布。两个分布都可以用带特征条件的参数化模型来拟合。
这里有一个关键的选择:为什么要用“条件独立”而不是直接建模“展示到转化”的整体分布?直接建模整体分布在数学上更简单,但实际效果往往不如级联。原因有两层。第一层,点击和转化受到的影响因素不同。点击延迟主要跟广告创意、上下文场景、用户当下的注意力状态有关;转化延迟主要跟商品价格、类目、用户原本的购买意图强弱有关。把这两类因素放在一个分布里,模型必须自己去隐式地分解,这在数据量充足时或许做得到,但消耗的学习成本太高。第二层,从贝叶斯角度看,条件分解能让模型在“点击已经发生”和“展示了但尚未点击”这两种状态下,分别给出校准的预估。线上服务的时候,你通常已经观测到了点击事件,此时你真正需要的是给定点击发生后、转化延迟的条件分布;如果用整体分布,还得再做一步条件化计算,容易引入误差。
级联结构带来的另一个好处,是训练目标可以很自然地拆成两部分的组合。假设我们有一个观察窗口W,当窗口结束时,一个样本的状态有几种:未点击、已点击未转化、已转化。三种状态都能提供监督信号。未点击的样本,概率来自“点击延迟大于窗口长度”的生存函数;已点击未转化的样本,概率来自“点击已发生、转化延迟超过剩余窗口时间”的生存函数;已转化的样本,概率来自“点击延迟和转化延迟的联合密度在某个时间点的取值”。把这三类样本的似然写出来,整个目标函数就确定下来了。
逻辑上这样设计很顺,但工程实现上有一个容易忽视的细节:对每一个训练样本,你都要同时保存它的展示时间、点击时间(如果有)、转化时间(如果有)。数据结构上稍微设计不好,训练pipeline会被拖慢不少。后面我单独用一节讲工程落地的坑,这里先把框架逻辑讲透。
另外值得注意的一点是,这个框架在训练时不是简单地把延迟分布当作一个固定的先验,而是让延迟分布的参数也由特征网络输出。也就是说,模型会学习到“不同用户、不同广告、不同场景下的延迟曲线差异”。比如大促期间的转化延迟通常比日常更长,夜间用户浏览到点击的延迟可能比白天更长,这些模式如果只靠一个全局分布,是学不出来的。特征化的延迟分布,是让框架能在复杂场景里持续生效的核心能力之一。
4. 延迟分布的选择与“未转化”样本的监督信号构造
分布选型决定了框架的上限。在常见的延迟反馈建模里,指数分布最省事,因为它形式简单、只有一个参数,生存函数和密度函数都是闭式解,训练稳定。但现实里的转化延迟几乎都是长尾的——大部分转化发生在很短时间内,但尾部能拖到好几天。指数分布对尾部的拟合能力偏弱,用它估计“窗口外还有多少概率转化”时会过于乐观。
对数正态分布和Weibull分布是更常见的选择。对数正态分布对“大部分样本短延迟、少数样本长延迟”的形态拟合得更好,而且参数可以通过神经网络来输出。Weibull分布则有一个优点:它的生存函数和危险函数有清晰的解析表达式,方便在损失函数里代入。但要注意,分布选型本身应该被视为一个超参数,不同业务的数据表现差异很大。我在实际项目里通常的做法是,先在日志数据上离线拟合几类分布的极大似然,对比一下谁的对数似然最高,再把它作为初始分布族嵌入模型,而不是一上来就拍脑袋用某个分布。
再来说监督信号。这是整个框架里最容易出错、也最值得展开的一块。假设观察窗口是W天,一个样本在展示后t_c时刻发生点击,在t_v时刻发生转化。如果t_v > W,那么这个样本在训练的时候被观察到的标签是“未转化”。但它不是负样本,它是“尚未转化的正样本”。框架要做的,是给这类样本一个合理的监督贡献。
具体做法是:对“未转化”的样本,不再把它当作y=0喂给二分类损失,而是把它当作一个“在窗口内未观测到转化”的样本,用“1 - 条件转化概率”来加权。这里的条件转化概率指的是,给定点击已经发生、且已知当前时间离点击已经过去了多久的条件下,转化可能在窗口内发生的概率。这个概率乘上样本原本的pCVR预测,再和真实的转化情况做对比,就构成了一种软标签机制。
我把这种构造类比成天气预报。预报员说“明天下雨的概率是70%”,但到了明天如果没下雨,你不能说这个预报是错的,只能说小概率事件发生了。同样,“在窗口内未转化”不代表“不会转化”,只是你在有限时间内没有观测到。建模的时候,应该让模型学会输出一个“在窗口内转化”的概率,而不是“最终转化”的概率;线上推断时,再通过某种变换把它修正成“最终转化”的概率。这个修正逻辑,就是延迟反馈建模领域常说的unbiasing。
具体到实现里,损失函数会变成对数似然形式,而不是交叉熵。对已转化样本取密度函数值的对数,对未转化样本取生存函数值的对数,对未点击样本也取点击生存函数的对数。这三项加在一起,就是整个级联框架的训练目标。这个目标函数有一个很好的性质:当窗口W趋近无穷大时,生存函数项趋近于0,整个目标退化成普通的全量监督学习;当窗口W很小时,未转化样本的贡献会被生存函数自动拉高,相当于自动做了样本加权。这种一致性让人安心:新框架在窗口极度充裕的场景下不会表现得更差。
5. 从目标函数到线上推断:延迟补偿的工程实现路径
模型训练好了,线上怎么用?这是论文里经常篇幅很少、但工程上最麻烦的部分。对级联延迟反馈框架来说,线上推断要回答的核心问题是:给定一个广告展示,我们已经观察到了点击(或者还没观察到点击),模型应该输出多大的pCVR值来参与排序?这里必须把延迟因素带进推断逻辑,否则训练时做了延迟补偿、推断时又退回朴素模型,等于白做。
具体来说,线上场景分两种。第一种,用户已经点击了广告,实时请求触达模型。这时候模型已知当前时间离点击过去了多久。如果转化已经发生,那一切好办;如果没有,模型需要预测的是“在当前剩余时间窗口内转化”的概率,而这个概率不等于“最终转化”的概率。框架的做法是调用点击后转化延迟的条件分布函数,计算“从点击到现在已过时间t”之后,在剩余时间窗T内转化的概率。这个条件概率会随着t的增大而单调递增——用户点击后过了5分钟还没转化,和过了5天还没转化,后者最终转化的可能性要低得多。模型输出这个条件概率,再结合预估的点击率,才是最终用于排序的得分。
第二种,用户还没点击。这时候问题更复杂。广告系统需要预估“这个展示最终能带来转化的概率”,它等于“最终会点击的概率”乘以“点击后最终会转化的概率”。前者需要用到点击延迟分布的尾部积分,即展示后很长时间内点击发生的累计概率;后者则是转化延迟分布的尾部积分。两部分的乘积,就是这个展示的长期价值估计。这种“长期预估”对广告系统的冷启动和预算分配特别重要,因为它避免了只看短期表现导致的出价波动。
工程实现上,这些分布函数的计算需要注意性能。延迟分布如果用的是对数正态或Weibull,累积分布函数在线上频繁调用时,不能每次都用数值积分硬算。哪怕用TensorFlow或PyTorch Serving,单个CDF的计算也很消耗CPU。我建议的做法是预计算一张CDF查找表,把时间轴从0到最大观察窗口切成长度几百或几千的离散桶,线上推断时用二分查找加线性插值,误差控制在一个很低的范围内,代价几乎可以忽略。阿里妈妈的框架在工业界落地,大概率也走了类似的工程优化,不然这种基于连续分布的建模很难扛住高并发请求。
还有一个细化点:观察窗口W在线下训练时是一个固定常数(比如7天或14天),但线上推断时,广告系统面对的是“从展示时刻开始的滚动时间”。一个广告在1天后被看到,和7天后被看到,剩余可用窗口长度完全不同。如果训练时的窗口和线上评分的窗口不一致,延迟分布的绝对数值会有偏差。严谨的做法是,在线上推理时传入每个请求的实际剩余窗口长度,让模型的条件概率计算动态适配。这一点在做AB实验时尤其重要,否则容易出现实验组离线收益很好、线上效果却不升反降的怪象。
6. 实验设计与效果拆解:什么场景下收益最大
按我的经验,这类延迟反馈模型的效果,高度依赖业务场景里延迟的“严重程度”。如果业务本身转化很快,大部分转化发生在点击后几小时内,那么加不加延迟建模差别都不大,模型复杂度反而可能带来训练不稳定。如果业务转化拖得很长,比如金融、教育、耐用消费品这类高客单低频类目,延迟反馈建模的提升空间就非常大。
从阿里妈妈这个框架的定位看,它瞄准的应该是展示广告里比较“重”的行业,比如汽车、家居、大家电。这类商品有一个共同特点:用户从看到广告到最终下单,中间的信息收集和决策周期很长,点击延迟和转化延迟都不可忽视。在这种场景里,如果依然用单层延迟模型,点击延迟的偏差会直接污染点击延迟分布的估计,进而让转化延迟的补偿出现系统性偏移。
我梳理了一下,适合验证这类框架效果的数据集和实验设置,通常包括几个角度。
第一,对比在同一观察窗口下,级联模型和单层模型在离线AUC、GAUC上的差异。这里要注意,离线指标本身也是有偏的,因为测试集同样存在截断问题。更好的做法是构造一个“足够长的观察窗口”作为近似全量标签,然后用短窗口数据训练、长窗口数据评估,这样才能真实反映模型的延迟补偿能力。
第二,要观察不同延迟长度分组下的误差分布。比如把测试样本按“展示到转化实际间隔”分成0到1小时、1到24小时、24小时以上三组,然后分别计算预测偏差。单层模型往往在短延迟组表现很好,长延迟组严重低估;级联模型因为显式建模了点击延迟,长延迟组的低估问题会明显缓解。这种分组维度的分析,比单一AUC更能说明问题。
第三,要看冷启动和预算消耗曲线。新广告、新商品没有足够的历史转化数据,延迟反馈模型可以借用延迟分布的先验来补偿“假负样本”,从而让新物的pCVR预估不那么保守。这个效果在线上通常表现为:实验组的冷启动期预算消耗更平稳、成本更可控。
需要提醒的是,如果把这类框架套用到所有流量上,可能不会每次都涨。有些场景的转化延迟很短,点击延迟可以忽略,级联结构反而增加了参数量和过拟合风险。对这类场景,更务实的做法是把级联框架当作一个可配置项,通过离线数据上的延迟分布诊断来决定要不要开启。这个判断方法很简单:你在日志里统计一下,在观察窗口内未转化但窗口结束后才转化的样本占比,如果超过10%,就值得上延迟建模;如果只有1%到2%,还是把精力花在特征和模型结构上更划算。
7. 复现和落地中的实操细节与踩坑记录
最后这部分,聊点代码和工程上的实际经验,省得大家看完整篇论文的逻辑觉得很美好、一动手就处处碰壁。我把这套级联延迟反馈建模从零开始复现和落地时遇到的几个关键问题列出来。
第一个坑是时间戳对齐。训练数据必须同时有展示时间、点击时间、转化时间。很多公司的日志链路里,点击日志和转化日志是分开存储的,且转化日志可能只记录到订单时间的“天”级别,没有精确到秒。延迟建模对时间精度很敏感,如果你拿到的转化时间只有日期,那么在同一天内点击且转化的样本会被显示成零延迟,这会严重扭曲延迟分布的形状。我在项目里要求至少保留到秒级,毫秒更好,否则延迟分布拟合出来基本没法用。
第二个坑是窗口漂移。训练时你用的观察窗口是固定W,但数据生产的时间是滚动的。今天训练样本里“最近一天新产生的展示”其实还没有机会积累足够的转化,它们的标签大部分是假负样本。如果不做特殊处理,模型会对流量里的新曝光过度惩罚。解决办法是训练时按“展示时间”分层采样,或者给不同展示时间的样本设置不同的窗口长度,让模型看到更平稳的标签分布。阿里妈妈框架的公开材料里也提到了类似处理,这基本是延迟反馈建模的标配操作。
第三个坑是分布参数初始化。神经网络输出的分布参数如果初始化不合理,训练早期很容易出现损失震荡甚至NaN。比如对数正态分布的尺度参数如果初始值太大,生存函数在早期会坍塌到接近0,所有未转化样本的梯度都变成0,模型直接死掉。我的经验是,先用全量日志离线拟合一个全局分布,把它的参数作为神经网络输出层的偏置初始值,让模型在初始状态就具备一个合理的先验,然后再去学习特征带来的偏移。这一步能显著加快收敛,也让训练更稳定。
第四个坑是实时性要求高的场景,不能把延迟分布当成静态的。大促期间、周末和工作日,用户的转化节奏有明显的周期性变化。如果一个延迟模型在大促前训练,大促期间直接上线,参数基本是错的。我看到比较靠谱的做法是做短期滑动窗口内的分布校准,或者干脆用在线学习的方式持续更新分布参数的偏置项。论文里虽然不常写这些,但在真实业务里,这些细节直接决定了模型能不能在线上存活。
另外,这套框架和已有的校准工具是兼容的。线上如果已经有了一套基于保序回归的分数校准流程,延迟反馈建模后的输出依然可以接在这套校准后面。不过要注意,校准数据的选择要对应同一个观察窗口,否则校准层会把延迟补偿的效果又拧回去,白忙一场。
总的来说,我复现这套级联延迟反馈框架的最大体会是:数学推导只是其中一环,真正决定成败的还是在数据清洗、时间对齐、窗口设计、分布初始化这些“看不见”的地方。如果你正在处理展示广告的CVR预估问题,而且日志里能明显看到“展示到点击”和“点击到转化”两段延迟的分布形态,这套思路非常值得在你的业务里试上一版;如果你的场景转化很快、延迟很短,那么优先诊断一下样本时间和窗口设计,可能收益更高。延迟反馈建模不是银弹,但当你确认了问题的存在之后,它的价值会非常直接。
