Administrator
Published on 2026-08-07 / 6 Visits
0
0

Meta 多阶段广告排序:在延迟约束下扩展用户序列

推荐系统的 Scaling Law 很容易被理解成继续增加参数、数据和算力。Meta 的多阶段广告排序给出了更具体的工程答案:重计算放到异步上游,候选相关计算保留在在线链路,再测量上游改进有多少真正传到了线上结果。决定系统上限的是计算位置、信息质量、迁移损耗、数据新鲜度和延迟预算的组合。

阅读时间:约 9 分钟

先看约束,再看模型

广告排序同时面对几类约束:系统需要在毫秒级时间内处理大量候选,还要结合用户长期行为、当前意图、广告特征和请求上下文。长序列和深模型能够提供更多信息,也会直接抬高每次请求的计算成本。

Meta 在 LLaTTE 论文中把线上排序描述为万亿请求规模。论文研究的核心问题因此很明确:如何继续利用长序列和大模型,同时守住实时服务的延迟边界。

单点扩容解决不了这个问题。在线模型继续变大,延迟先成为瓶颈;只优化推理速度,用户历史的信息量又会成为瓶颈。有效的系统增益可以写成:

线上有效增益
= 上游模型增益
× 阶段迁移效率
并同时通过新鲜度、延迟、可靠性和成本门槛

这个表达式把研究指标到生产结果之间的损耗显式化了。

两个阶段,两个时间尺度

Meta 的工程文章将系统拆成异步上游用户模型和实时下游排序模型。

这里的多阶段指用户表示流水线,和常见的召回、预排、精排漏斗属于两种结构。LLaTTE 的两个阶段都在服务在线排序:上游准备可复用的用户表示,下游结合当前上下文给候选打分。区分这两类结构很重要。embedding 迁移损耗与早期候选漏召需要不同指标,也需要不同修复方法。

上游模型只处理用户侧特征。它用更深的 Transformer 读取数千条历史事件,把结果压缩成用户 embedding,写入 feature store。公开资料称,生产系统主要在转化等高价值事件发生后触发更新,并在独立的 H100 集群上执行。

下游模型位于请求链路。它读取缓存的用户 embedding,同时处理新鲜用户信号、广告候选和上下文特征。论文披露的在线序列按来源大约限制在 400 个事件。这个阶段保留候选感知能力,可以判断同一段用户历史对不同广告意味着什么。

阶段 主要职责 核心约束 应持续监控的证据
异步上游 将长期行为压缩为可复用的用户表示 计算预算、更新时效、存储成本 上游 NE、embedding 年龄、缺失率、单次更新成本
实时下游 融合当前意图、候选特征和上游表示 P99 延迟、请求成本、可用性 下游 NE、迁移效率、P99、降级比例
端到端系统 将模型改进转化为排序和业务结果 收益、成本和运行风险 A/B 结果、单位增量成本、故障与回滚指标

这套架构真正拆开的是时间尺度。长期理解按事件或批次更新,实时判断按请求执行。模型复杂度由所在链路的约束决定。

Scaling Law 有扩展顺序

LLaTTE 实验同时研究了深度、宽度、序列长度、事件构成和语义特征。结果表明,这些维度会相互设限。

宽度先为深度解除瓶颈

在序列长度 400 的实验中,Meta 将层数从 1 扩到 8,将宽度从 128 扩到 1024。宽度只有 128 时,继续增加深度很快进入收益递减;宽度达到约 256 后,深度扩展才变得有效。另一端,浅层模型单独把宽度推到 1024,消耗了更多 FLOPs,NE 改进仍弱于均衡配置。

这说明模型容量存在配套条件。某个维度没有达到阈值,新增计算就会滞留在非瓶颈环节。

更长历史需要足够的模型容量

在 200 到 1600 个事件的测试范围内,序列变长带来了持续的排序质量改善,深层模型从长历史中获得的收益更大。论文还报告,注意力分布覆盖了中长期位置,信息并未全部收缩到最近事件。

长序列会产生两笔成本:模型需要足够容量来利用新增信息,数据基础设施也要承担更长时间范围的采集、物化和读取。

事件构成同时约束信号强度和新鲜度

Meta 固定 1000 个事件,对广告浏览和转化事件的比例做了实验。均衡组合表现最好。纯转化序列里的单条信号更强,但转化较稀疏,为填满序列需要读取更久以前的历史;纯浏览序列更及时,单条信息量又较弱。

因此,序列长度只是一个表面变量。真正需要分配的是事件多样性、单条信号强度和时间覆盖范围。

语义信息决定新增算力能学到什么

稀疏 ID 可以表达谁与什么发生过交互,对新广告和深层泛化的支持有限。Meta 的实验显示,引入语言模型和多模态模型生成的内容 embedding 后,增加深度和序列长度带来的收益显著扩大;只使用 ID 时,扩展曲线更早趋缓。

输入信息质量本身属于 Scaling Law。算力会放大模型能够看到的信息。语义贫乏时,更大容量容易演化为更昂贵的记忆系统。

两阶段结构会产生新的信息瓶颈

异步上游解除了实时延迟约束,也创建了一个新接口:数千条行为需要压缩进固定维度的用户向量。论文披露的生产向量维度是 2048。向量生成时缺少具体广告候选,上线使用时还会受到异步更新延迟影响。

Meta 用 transfer ratio 衡量阶段迁移效率:

迁移效率 = 下游 NE 改进 / 上游 NE 改进

在一组计算量匹配的对比中,序列更长的上游配置带来 0.14% 的上游 NE 改进,传到下游后是 0.07%;层数更多的配置分别是 0.13% 和 0.07%。对应迁移效率约为 50% 和 53%。

损失掉的部分提供了重要诊断信号。固定维压缩、数据陈旧、上下游容量差和候选上下文缺失都可能参与其中。上游继续变强而迁移效率持续下降时,接口已经成为新的瓶颈。

生产系统应该把 embedding 当作有版本的接口合同:

  • 定义 schema、维度、生产者版本和兼容窗口;
  • 记录更新时间、触发事件和数据来源覆盖;
  • 按流量分组观察 embedding 年龄和缺失率;
  • 为过期、缺失和版本不兼容设计经过演练的降级路径;
  • 每次重要模型升级都同时报告上游增益和下游增益。

这样才能把隐藏表示转化为可观测的系统边界。

正确解读 Meta 公布的生产数字

LLaTTE 论文称,上游模型使用的序列计算预算约为在线排序模型的 45 倍。在线链路新增的主要操作是一次 feature lookup。作者报告,相比没有上游 LLaTTE embedding 的基线,P99 排序延迟没有可测变化。

计算被迁移到了另一条链路,并未凭空消失。低 QPS、高批处理的 H100 服务可能比逐请求执行更有效率,训练、推理、存储和网络资源仍然需要计入完整成本。公开论文没有披露这份总账。

在 Meta 内部多轮大规模 A/B 测试中,论文报告旗舰广告排序模型的 NE 约下降 0.25%,Facebook Feed 和 Reels 的转化率相应提升约 4.3%。

后续 Meta 工程文章还披露了更广范围的累计结果:Instagram 转化提升 6%,Facebook 转化提升 3%,Facebook 广告点击提升 3.5%。原文明确说明,这些数字来自本文架构与更广泛建模创新的共同贡献。它们与论文里的 4.3% 属于不同口径,不能相加,也不能互换。

这些结果证明该架构在 Meta 内部具备生产价值。公开资料仍缺少绝对延迟、完整基础设施成本、流量分组结果、feature store 故障表现和可供外部复现的数据集。Meta 同时是系统运营方和结果报告方。

严谨的结论可以收敛为:在披露条件下,这套架构通过了 Meta 内部的延迟与业务门槛。

独立行业研究支持技术方向,仍无法替 Meta 的具体数字背书。Amazon Ads 的用户广告行为序列预训练研究观察到模型扩展与测试损失之间的幂律关系,也报告了预训练改善向转化预测和机器人流量识别任务的迁移。它使用了另一套架构、数据和评估设计,只能交叉支持机制,不能验证 Meta 的 50% 迁移效率或 4.3% 转化数字。

一套可迁移的上线框架

团队无需拥有 Meta 的规模,也可以复用它的测量方法。

1. 冻结目标和预算

先确定一个排序质量指标、一个线上业务指标、P99 延迟上限和单位请求成本预算。实验开始前写清接受范围。离线损失改善只负责进入下一阶段,不能直接授权发布。

2. 建立单阶段基线

测量现有排序模型的质量、序列覆盖、延迟和成本。先确认长历史计算是否构成当前主要约束。

3. 把上游表示设计成接口合同

明确更新触发条件、最大年龄、缓存策略、版本兼容、降级逻辑和责任归属。测试延迟、缺失、重复和版本不兼容等异常状态。

4. 运行受控扩展矩阵

在固定计算预算下分别改变深度、宽度、序列长度、事件构成和语义特征。模型指标与端到端指标同步报告。极端配置容易把瓶颈推到相邻维度,均衡配置通常更有解释力。

5. 测量阶段迁移效率

把上游改进和下游改进放在同一张表。迁移效率下降时,应优先检查 embedding 接口、在线模型容量和新鲜度策略。

6. 设置发布门槛

门槛 最低检查问题
排序质量 下游模型在留出数据和真实流量上是否持续改善?
迁移效率 上游收益经过压缩和延迟后还剩多少?
新鲜度 更新延迟和 embedding 缺失率是否落在预算内?
延迟 峰值流量下的 P99 是否满足服务目标?
成本 增量业务价值是否覆盖训练、推理、存储和网络成本?
可靠性 上游或 feature store 故障时,降级链路能否维持服务?
治理 事件来源、保留策略、访问权限和模型版本是否可追溯?

7. 每轮改进后重新寻找瓶颈

长序列计算被移到上游后,新鲜度和 feature store 可靠性可能成为主要约束。语义特征增强后,在线模型容量可能成为主要约束。扩容路线应持续跟随瓶颈迁移。

与 GEM 训练效率文章的关系

此前的 Meta GEM 训练效率分析关注 jagged kernel、数值精度、分布式并行、内存和端到端 MFU,回答推荐模型如何被高效训练。

多阶段 LLaTTE 关注另一类问题:计算放在哪个阶段,才能让新增模型能力穿过在线延迟边界。前者是训练吞吐问题,后者是服务拓扑与信息传递问题。生产级 Scaling Law 需要同时解决这两层。

常见问题

什么是多阶段广告排序?

它把推荐计算分配到具有不同成本和延迟预算的多个阶段。Meta 公开的设计中,异步模型生成长期用户表示,在线模型再把该表示与新鲜用户信号、广告候选和上下文结合。

推荐系统也遵循 Scaling Law 吗?

Meta、Amazon 等团队都报告过模型规模、数据、序列长度或计算量与损失之间的规律关系。LLaTTE 进一步表明,语义特征质量和模型形状会改变曲线斜率,生产约束还会决定哪些离线收益能够上线。

为什么不直接部署一个更大的在线模型?

在线模型受到每次请求的延迟和成本限制。两阶段架构将深层长序列计算放到时间预算更宽松的异步路径,把候选感知和新鲜信号留在请求路径。

语义特征如何改善冷启动?

内容 embedding 能表达广告或商品本身的信息,减少对历史交互 ID 的单一依赖。新广告和新广告主历史较少时,这类信息尤其重要。

其他系统也能获得 4.3% 的转化提升吗?

公开证据支持这一结果发生在 Meta 的内部部署和实验中。其他系统的结果取决于数据、基线、目标、流量和架构,最终授权应来自本地 A/B 测试。

什么时候值得增加异步上游模型?

长历史计算已经限制排序质量、用户表示能被足够多的请求或模型复用、在线链路又存在严格延迟上限时,这种拆分才有充分价值。流量较小、历史较短或复用率较低的系统,简单在线模型和更好的特征往往具有更低的综合成本。

参考资料


Comment