news 2026/10/22 19:31:47

级联延迟反馈建模:破解展示广告CVR预估的两段式延迟难题

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
级联延迟反馈建模:破解展示广告CVR预估的两段式延迟难题

展示广告的CVR预估,做久了你会发现有两件事最让人头疼:一是样本极度稀疏,二是转化反馈总是迟到。市面上解决延迟反馈的模型已经不少,但多半是把“曝光到转化”当成一个整体延迟来建模。阿里妈妈在WWW 2026上提出的这篇级联延迟反馈建模框架,把问题粒度又往下钻了一层——它明确指出延迟不是一段,而是两段:曝光到点击的延迟,以及点击到转化的延迟,这两段叠在一起才是展示广告的真实反馈链路。这篇内容很适合正在做广告算法、推荐排序,或者被转化延迟和样本拼接折磨的同行参考,看完你至少能厘清三个问题:传统单点延迟模型到底错在哪、级联建模的概率框架怎么搭、以及落到工程上需要处理哪些细节。

1. 为什么“延迟”会变成级联的:展示广告里的两段式时间账

1.1 曝光到点击,再到转化,中间隔着两个时钟

先说一个我在实际业务里反复遇到的场景。一个用户在某App的信息流里看到一条商品广告,当时没点,两天后通过另一个渠道的推送想起来这个商品,点进详情页,又过了几个小时才完成下单。如果只统计“曝光到转化”的总时长,那是“两天零几个小时”,看起来像一个长尾延迟。但这个总时长其实是两个完全不同性质的随机过程拼起来的:曝光到点击的决策过程,和点击到转化的决策过程。

这两个过程的驱动因素差别很大。曝光到点击,更多受创意吸引力、广告位置、用户当下是否在逛等因素影响;点击到转化,则受商品价格、详情页内容、竞品对比、用户购买意愿强度影响。一个用户可能因为“广告图好看”很快点击,但货比三家拖了三天才买;也可能反复看了广告好几遍,最后点进去立刻下单。如果强行把两段合并成一个延迟分布,等于默认这两个阶段的时间特性是同质的,这个假设在展示广告里基本不成立。

这也是为什么标题里要强调“级联”这个词。级联的含义就是:下游事件(转化)的发生,以上游事件(点击)的发生为前置条件,两段延迟在概率上存在天然的先后依赖。忽略这个依赖而直接回归总延迟,相当于把一条生产流水线上的两道工序合并成一道来估算工时,看似简化了问题,实际会带来系统性的偏差。

1.2 传统单点延迟模型在多重延迟场景下的三个翻车点

现在业界常见的延迟反馈建模思路,比如早期FTC那类方法,核心是给曝光样本一个正样本的延迟分布假设,然后用生存分析处理观察窗口内未转化样本。这类方法在“曝光即代表有效触达”的场景里问题不大,但放在展示广告里,会遇到三个非常尴尬的情况。

第一,样本身份定义混乱。展示广告的点击率往往很低,大量曝光根本没有产生点击。传统模型把“曝光后未转化”统一当作删失样本处理,但其中“未点击”和“已点击未转化”其实是两种完全不同的删失状态,前者可能压根没有进入购买意愿阶段,后者已经进入了却被价格或体验劝退。把它们混在一起估计延迟分布,等于把两种性质完全不同的数据混在一个桶里训练。

第二,观察窗口的选择进退两难。如果按曝光时刻起算观察窗口,为了覆盖转化延迟的尾部,窗口往往要拉很长,但点击延迟在窗口内的占比会被稀释;如果按点击时刻起算,又会丢掉大量“始终未点击”的曝光样本,导致模型完全没有机会学习曝光侧的延迟和转化率。

第三,预测校准不自洽。线上推理时,单点模型通常直接输出一个“曝光后多久会转化”的期望。但展示广告的真实链路上,用户要先点击才可能转化,未点击的曝光根本没有资格进入转化概率的计算。单点模型把这个过程折叠了,输出值容易偏高,尤其当点击延迟比较大的时候,校准误差会比较明显。

这三处痛点合在一起,就是阿里妈妈这篇工作想要解决的“多重延迟”问题。而它的破局思路也很直接:既然延迟是两段的,那就把模型也拆成两段。

2. 级联延迟反馈建模:从单一延迟分布到联合生存模型

2.1 核心思想:用概率链把两段延迟解耦

级联延迟反馈建模,通俗讲就是不再直接对“曝光到转化”的总时长做一个回归,而是把转化事件分解成两个子问题:事件A = 曝光后发生点击,事件B = 点击后发生转化。两者的延迟分别记为T_c和T_v,目标概率P(转化|曝光)通过链式法则写成P(点击|曝光) × P(转化|点击),并且每个环节都携带各自的延迟信息。

妙在哪?妙在每个环节现在可以用独立的生存分析模型来刻画,而且可以共享一部分特征,却不必共享延迟分布。点击延迟分布和转化延迟分布可以有各自的参数、各自的形态。你可以假设点击延迟服从一个快速衰减的分布,因为用户在浏览场景下的点击决策通常很快;而转化延迟则拖着一个更长的尾巴,因为下单前要比价、要犹豫。这在单点模型里是做不到的。

从数学形式上看,训练目标会变成一个双重积分:对点击发生的时刻和转化发生的时刻做积分,且积分域满足转化时刻大于点击时刻。这个约束很关键,它把“级联”这个业务直觉直接编码进了概率结构:只有点击先发生,转化才可能出现。模型本质上就是在拟合两个事件在时间轴上的联合分布,而级联约束让这个联合分布退化为一个条件分布和一个边缘分布的乘积,大大简化了参数的估计难度。

2.2 训练样本的三种状态与似然构造

实际训练时,面对的都是带截断和删失的数据。对一个曝光样本,我们通过日志能观测到的状态无外乎三种:曝光后没有任何点击;有点击但在观察窗口内没有转化;点击和转化都发生了,且有对应的时刻。第三种是完整样本,前两种分别是不同层级的删失样本。

级联模型在构造似然函数时,需要为每种状态分别写概率。完整样本贡献的是点击延迟密度和转化延迟密度的乘积;已点击未转化贡献的是点击延迟密度乘以转化延迟的生存函数(也就是点击后到窗口截止都还没转化的概率);未点击贡献的是点击延迟的生存函数。这三个部分的加总,就是整个训练集的对数似然。

这里有个容易被忽略的点:未点击样本的似然不是直接对P(转化|曝光)取对立面,而是只对点击延迟的生存函数做积分。换句话说,模型从“未点击”这个事实里学到的是“点击延迟超过了观察窗口”,而不是“这个用户永远不会转化”。这样处理的好处是,即使观察窗口很短,模型也能从大规模“尚未点击”的曝光里学到点击延迟的分布形状,而不是简单地把它们当负样本丢掉。这对展示广告这种低点击率场景来说是至关重要的。

2.3 推理阶段的期望计算与校准

线上推理时,模型需要输出一个可供排序使用的标量。级联框架天然给出了一个更合理的形式:把点击延迟的密度函数和转化延迟的条件生存函数做积分,算的是“在给定时间范围内预期转化率”,而不是某条固定时间路径下的点估计。实际实现中一般会做数值积分或者离散化求和,将时间轴切成桶,每个桶算一下条件概率再累加。

还有一个很实际的问题:校准。延迟反馈模型最常见的坑就是预测值整体偏高或偏低,因为训练标签的观察窗口和线上请求的环境不一致。我的建议是,在推理层增加一个分桶校准器,用最近一段时间内实际观察到的转化数除以预测期望数,作为校准因子乘上去。分桶维度可以按广告主的行业来分,因为不同行业的延迟特性差异很大,一个统一系数往往不够用。这样调完,线上的预测CTR/CVR漏斗会更加对齐,出价稳定性也会好不少。

3. 工程落地细节:从论文到广告系统的最后一公里

3.1 样本拼接与观察窗口设计

论文里的框架设计再好,落到工程上第一关永远都是样本。级联模型对样本拼接的要求比单点模型更高:一张训练样本需要同时关联曝光日志、点击日志和转化日志,并记录曝光时间、点击时间、转化时间三个时间戳。这一套逻辑在离线数仓里通常会写成多表join,但真正容易出问题的是归因口径。

我的实操经验是,曝光和点击之间按session内去重归因,一个点击只归因到最近一次有效曝光;点击和转化之间继承业界的常规归因方式,比如7天或30天窗口内最后一次点击归因。注意,这里“最近一次”和“最后一次”的口径不能混。如果两个口径混用,会导致同一个曝光出现在多张样本里,标签互相打架,模型学到的概率分布会变得非常不稳定。

观察窗口方面,级联模型打开了一个新选项:可以为点击延迟和转化延迟分别设置窗口。比如点击延迟窗口设为1天,转化延迟窗口设为7天。因为点击决策通常很快,窗口拉太长只会引入大量噪声;而点击后的转化则需要更长的观察期。这里要注意的是,两段窗口的结合处会产生一段“等待区”:用户已经点击,但还在转化延迟观察期内。这个区域的数据在流式训练里要特别小心,不能因为暂时没有转化就立刻当作负样本打标,否则会把高潜用户误伤成负样本。

3.2 特征体系与模型结构怎么搭

特征方面,级联模型最值得投入的是两阶段各自的特征分离。底部共享特征可以包含用户画像、广告素材类目、上下文场景、时间特征;但点击延迟分支要额外加入“曝光位置”“创意尺寸”“是否首刷”这些影响注意力的特征;转化延迟分支则要加入“商品价格带”“店铺评分”“历史复购率”这些影响购买决策的特征。两类特征有交叉,但又各有侧重,硬塞进同一个tower里会让梯度互相干扰。

模型结构上推荐双塔加共享底层的设计:一个共享embedding层,上面分叉成两个小网络,分别输出点击延迟分布的参数和转化延迟分布的参数。分布可以选Weibull或者分段指数,前者参数少、好调,后者表达能力强、更贴数据。我的建议是先用Weibull打底,因为它只需要两个参数,训练稳定;等线上验证效果之后,再考虑换成更精细的分段模型来压尾部误差。

3.3 离线评估与线上AB的配合

延迟反馈模型的离线评估是个容易自欺欺人的环节。常规的AUC和GAUC只能反映排序能力,反映不了延迟分布拟合得好不好。我见过的团队踩过不少坑:离线AUC涨了,线上成本却飘了。原因是模型把延迟预测得过于集中,导致出价频率异常。

所以在离线阶段,除了排序指标,还要加两个维度的度量:一个是延迟分布的拟合度,可以看测试集上完整样本的经验延迟分布与模型预测分布的KL散度或者KS统计量;另一个是校准误差,按预测概率分桶,看每个桶内实际转化率与预测期望的比值。这两个指标过关了,才能把模型推到线上。

线上AB时不要只盯7日CVR的均值,还要看两个辅助指标:转化时间的中位数是否被拉低,以及分行业的成本稳定性。级联模型最大的收益往往不是CVR暴涨,而是整个漏斗的节奏更一致,点击和转化之间的等待时间被更准确地估计,从而让调价系统对“这条流量值多少钱”的判断更稳。

4. 常见问题与避坑实录

4.1 条件独立性假设什么时候会失效

级联框架默认点击延迟和转化延迟在给定特征后是条件独立的,但真实场景里这两个延迟经常会因为同一个隐藏因素一起变化。最常见的就是新用户:新用户既可能因为不了解品牌而延迟点击,也可能因为信任度低而延迟转化,这两个延迟正相关。如果模型完全忽略这种相关性,会把转化概率的方差估计偏大,导致排序结果在冷启动流量上偏激进。

我的一个处理建议是:在共享底层加入一个用户活跃度向量,把“用户和广告主的熟悉程度”作为一个连续的隐变量塞进去。这样模型可以通过这个隐变量间接捕获点击与转化之间的相关性,而不需要强行改变概率结构。实测下来,这种折中方案比单纯硬套条件独立假设要稳。如果数据量足够,也可以进一步扩展成带共享随机效应的层次模型,但工程成本会明显上升,属于后续的锦上添花。

4.2 双重删失带来的数据稀疏问题

级联模型要估计两个延迟分布,对数据量的要求比单点模型高不少。尤其是在点击率很低的广告位上,第一段延迟的完整样本本来就少,第二段再乘以转化率,完整样本就更加稀疏。训练时很容易出现延迟分布的尾部参数拟合得特别差,线上对长尾流量的预测时好时坏。

我的经验是用分阶段训练来缓解:先用全量曝光数据训点击延迟分支,让这一层的参数收敛;再固定住它,用点击后的数据训转化延迟分支;最后解冻全部参数做联合微调。这个流程比端到端一把梭收敛得稳定得多,而且调试起来也方便,哪个分支出了问题可以单独定位。如果还嫌尾部数据不够,还可以在抽样时对长延迟样本做加权,强制模型看到更多“迟到但发生了”的尾部样本。

4.3 一个容易被忽略的分桶细节

训练时做时间分桶,桶的粒度不要定得太细。我见过有人把延迟按时长精确到小时分桶,结果尾部桶里的样本量寥寥无几,噪声很大,模型在那些桶上学到一堆异常尖峰。更合理的做法是前段用小时级、中段用天级、尾部直接合拢成一个“超过N天”的桶,这样既保证了短延迟场景下的精度,又避免了尾部过拟合。

线上推理时还有个性能问题:双重积分如果实时计算,QPS会很难看。建议离线把点击延迟和转化延迟的分布参数在每个特征分桶下预先算好,存成查找表,线上只需要查表做几次数值累加。对生存函数也可以离线生成时间-概率映射表,线上用二分查找取值,可以显著降低单次请求的延迟,这在大规模展示广告流量的场景下是必须做的优化。

5. 我个人在实际操作中的体会与后续扩展

这套级联框架真正打动我的,不是它把延迟拆成了两段,而是它把“延迟是什么”这件事想得更符合业务本质了。做广告算法久了你会有一种感觉:不少模型其实是在用一个统计近似掩盖业务结构,比如把所有“过了很久才发生”的事都塞进一个延迟分布里。而一旦把业务结构显式建模,很多之前模糊的问题就会变得清晰。比如你可以明确地回答运营同学:这个广告位点击来得快不快、转化来得慢不慢,而不是笼统地解释“用户要过很久才买”。

这套框架还有一个很自然的扩展方向:把多触点归因也纳进来。现在的级联是“曝光→点击→转化”,但实际链路里可能存在多次曝光、多次点击。如果未来要把“多次曝光对转化的延迟贡献”也建模进来,这个级联框架的积分形式可以继续往上叠加,变成更一般的多级漏斗模型。还一个方向是跟出价联动——既然能预测每个阶段的期望延迟,就可以在广告主预算有限的情况下,优先去争取那些“点击快、转化也快”的流量,而不是只看最终的预估转化率。

最后分享一个我们在迁移这套框架时反复强调的原则:不要一上来就追求复杂的分布形式。先用最简单的参数化把链路跑通,确认线上收益,再逐步增加复杂度。延迟反馈建模本质上是跟时间赛跑,先把流程建好,后面换模型结构其实是水到渠成的事。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/22 19:31:36

用Python爬虫打造城市图书馆活动采集系统:从页面解析到CSV导出

城市图书馆的活动信息其实很有价值,讲座、展览、读书分享会都是公开资源,就是散落得厉害。我年前想做一份自己的活动日历,发现光靠人工去翻官网,一遍遍登记时间地点,效率实在低得可怕。后来我索性用 Python 爬虫 写了套…

作者头像 李华
网站建设 2026/10/21 22:39:44

阿里 Qwen3.6-35B-A3B 实测:MoE 架构下智能体编程与多模态能力全解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/10/17 13:35:46

LaTeX中优雅输出钩号与叉号:方案对比与实战指南

1. 为什么要在文档里折腾钩和叉写文档这件事,最让人抓狂的往往不是内容本身,而是那些看起来微不足道的符号。你辛辛苦苦排好了一篇技术报告或者一份检查清单,结果到了要标记"通过"和"未通过"的地方,发现键盘上…

作者头像 李华
网站建设 2026/10/14 10:23:35

Spring模块面试题深度拆解:从模块清单到源码本质

说实话,这道题出现在“每日面试题分享”第141期,我一点不意外。它看起来简单,甚至在不少人眼里就是一道送分题——Spring有哪些模块,背一遍不就行了?但恰恰是这种题,最能看出一个人是真懂 Spring&#xff0…

作者头像 李华
网站建设 2026/10/16 14:52:13

Agent-Reach 实战:用 CLI 快速搭建与部署 AI Agent

1. 从零认识 Agent-Reach:它到底解决什么问题 Agent-Reach 这个名字,第一次看到的时候我以为是某个网络探测工具,后来翻了一圈资料才搞明白,它其实是一个面向 AI Agent 的 CLI 工具集,核心定位是让开发者用命令行就能快…

作者头像 李华
网站建设 2026/10/16 5:32:30

C++代码冗余消除实战:从识别到重构的完整路线图

C项目的技术债里,最隐蔽、最拖累后期维护的大概就是代码冗余了。不是那种一眼就能看出来的重复函数,而是散落在各个模块里、看起来不太一样、实际上干着同一件事的片段。我在接手老项目和重构遗产代码时,把大量时间花在了跟这类冗余打交道上面…

作者头像 李华