IAT: 实例即 Token 重塑工业推荐系统的序列特征工程
论文: IAT: Instance-As-Token Compression for Historical User Sequence Modeling in Industrial Recommender Systems
链接: https://arxiv.org/abs/2604.08933
机构: 字节跳动 (ByteDance)
时间: 2026 年 4 月
1. 问题背景
近年来，推荐系统社区在序列建模上投入了大量精力——从更复杂的 paradigm（DIN/DIEN/SIM/TWIN/LONGER 系列），到超长序列的高效架构（稀疏注意力、聚类、压缩），再到生成式范式（HSTU、OneRec）以及 Scaling Laws 的探索。然而，这些工作几乎全部聚焦于 “上层模型如何更聪明地消费序列”，而对一个更基础的问题视而不见：底层的序列特征本身能承载多少信息？
在工业推荐系统中，传统的行为序列特征（图中称为 hand-crafted sequence features）通常由若干稀疏特征拼接而成，包括：
- 物品固有特征（item_id、category、price 等）；
- 用户-物品交互特征（action_type、duration、frequency 等）；
- 上下文特征（timestamp、scenario 等）。
这些特征构成了序列中的每个 token，但都有几个先天约束。
- 资源瓶颈。一个用户的行为序列可能上千个 item，每个 item 上挂大量特征会带来存储、传输、计算三方面的成本爆炸。工业实践中往往只能保留十几到几十维的”核心 ID 类特征”，大量细粒度信号被迫丢弃。
- 工程瓶颈。新增一个序列特征意味着完整的”特征设计 → 离线开发 → 离线验证 → 在线灰度 → 全量”链路，周期以月计。
- 信息密度瓶颈。一条训练样本（instance）天然包含上千维特征对历史行为的完整刻画（包括各种交叉特征、抽样统计特征、模型预估值等），而 hand-crafted 序列只保留了其中很小的一个子集，信息密度严重不足。
论文作者 Xinchun Li 等人来自字节跳动广告团队，他们在落地 RankMixer (Zhu et al., 2025)、TokenMixer-Large (Jiang et al., 2026)、LONGER (Chai et al., 2025) 等先进 ranking 架构时发现：这些模型的 scaling 增益在某个临界点之后开始衰减——而衰减的根源不在 model side，而在 feature side。底层序列输入的信息容量已经成为 ranking 模型 scaling 的上限。
基于这一洞察，IAT 提出一个看似简单但很重要的想法：
既然一条完整的训练 instance（数千维特征）已经无损刻画了一次用户交互，那么是否可以用 instance 本身的压缩表示作为序列的 token？
这就是 Instance-As-Token（IAT，实例即 Token）的核心思想。技术上它对应一个两阶段框架：
- Stage I（IAT Compression）：训练 source model，把每条历史 instance 压成一个紧凑而有信息量的 InsEmb（Instance Embedding）；
- Stage II（IAT Sequence Modeling）：下游 ranking 模型把同一用户的历史 InsEmb 序列拉出来作为新的序列特征做序列建模。
四点主要贡献：(a) 用 instance 压缩替代手工序列特征，开辟了一条新的”序列特征工程”路线；(b) 同时提出 temporal-order 与 user-order 两种压缩方案，后者特别契合下游序列建模；(c) 完整给出包括 batch/streaming 训练与存储部署的工业级实现细节；(d) 大规模离线与在线实验均取得显著收益，已在字节多个广告与电商场景全量上线。
2. 整体框架
IAT 的整体结构如下图（论文 Fig. 2）所示：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌──────────────────────────────────────────────────────────────────┐
│ Stage I: IAT Compression（生成并存储 InsEmb） │
│ │
│ 训练样本 ──► Source Model ──► InsEmb (compressed) ──► PS 存储 │
│ ├─ Temporal-Order: 单实例压缩 │
│ └─ User-Order : 按用户聚合 + SIT 序列建模 │
└──────────────────────────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ Stage II: IAT Sequence Modeling（下游消费 InsEmb） │
│ │
│ request ──► 按 UID 取 InsID 列表（按 ts 截断） │
│ ──► 按 InsID 列表取 InsEmb │
│ ──► InsEmb ⊕ Side Info = InsToken │
│ ──► Transformer/LONGER 序列建模 → RankMixer 等特征交互 │
└──────────────────────────────────────────────────────────────────┘
下面分两个阶段展开细节。
3. Stage I：IAT 压缩
3.1 形式化设定
记一条训练样本的输入特征拆分为序列特征 $x_{\text{seq}}$ 和非序列特征 $x_{\text{non-seq}}$，序列特征是长度为 $T$ 的历史行为列表 $x_{\text{seq}} = \{s_1, s_2, \dots, s_T\}$。Base 模型的前向流程为：
\[h = \mathcal{F}_{\text{interaction}}\big(x_{\text{non-seq}},\, \mathcal{F}_{\text{seq}}(x_{\text{seq}})\big)\]其中 $h \in \mathbb{R}^{D_{\text{raw}}}$ 是经过特征交叉之后的最终隐状态（即 RankMixer / TokenMixer-Large 等 backbone 的输出），随后做 CTR/CVR 预估：
\[\hat{y} = P(y=1 \mid u, v, h)\]并用 BCE loss 优化。
注意 $h$ 的维度 $D_{\text{raw}}$ 不是模型 hidden size，而是 backbone 输出的拼接维度（论文配置中约 6000 维）——它本身已经融合了 instance 全部特征的非线性交互结果，是天然的”压缩候选”。
3.2 Temporal-Order Source Model：朴素压缩
最直接的想法：把 $h$ 投影到一个低维空间作为 InsEmb 存下来。论文在 base 模型上加一对 compress/decompress 层（图 2(a)）：
\[h_{\text{compress}} = \sigma\big(\mathcal{W}_1 h + b_1\big),\quad \mathcal{W}_1 \in \mathbb{R}^{D \times D_{\text{raw}}}\] \[h_{\text{decompress}} = \sigma\big(\mathcal{W}_2 h_{\text{compress}} + b_2\big),\quad \mathcal{W}_2 \in \mathbb{R}^{D_{\text{raw}}\times D}\]其中 $\sigma$ 为激活函数（ReLU/GELU），论文取 $D=64$，$D_{\text{raw}}\approx 6000$，压缩比接近 100 倍。$h_{\text{decompress}}$ 替代原始 $h$ 进入后续预估和 loss 优化，目的是迫使 $h_{\text{compress}}$ 承担”保留所有判别性信息”的功能——这相当于一个监督式自编码器。
为什么使用 compress/decompress 这种间接结构？ 一个看似更简单的方案是直接把 $h$ 投影到低维并接 softmax：但那样 $h_{\text{compress}}$ 会强烈过拟合当前任务的输出分布，丢掉除 label 之外的判别信息（即 task-specific 坍塌）。Compress + decompress 让低维表示重新回到原始高维空间再做预估，本质上是个 information bottleneck（信息瓶颈），鼓励 $h_{\text{compress}}$ 保留足够丰富的中间特征，从而具备跨任务、跨场景的可迁移性。这点对后文 cross-domain 实验（Tab. 6）的成功至关重要。
局限性：温度太低——$h_{\text{compress}}$ 是从单条样本中压出来的，本身不包含同一用户其它历史 instance 的信息。它顶多是个”高保真的 instance 表示”，而不是”具备序列建模能力的 token”。这是接下来 User-Order Source Model 要解决的问题。
3.3 User-Order Source Model：用户视角下的序列化压缩
3.3.1 训练样本的重组织
工业系统中训练样本通常按 action timestamp 全局有序流出——某用户的两条 instance 之间可能夹杂着海量其它用户的样本。在这种排序下，做”同一用户跨 instance 的信息流动”代价极高。
近期工作（HSTU/Zhai et al. 2024、Guan et al. 2025）提出 user-order training：在一段时间窗口内先按 UID 聚合样本，再按各自时间戳排序。论文沿用这个组织方式，但目的并不是常规意义上的训练加速——而是为了能在一个 batch 内构造同用户的”行为流”。
为了表达简洁，论文假设一个 batch 就是一个用户的所有历史 instance，并把 batch size 等同于序列长度 $T$（实际工程上会按固定长度切片并 pad dummy instance）。
3.3.2 Source Instance Transformer（SIT）
对一个 user batch 的所有 instance，先按 Eq. (4) 得到 $H_{\text{com\_batch}} \in \mathbb{R}^{T \times D}$（$D=64$，$T$ 为 batch 内 instance 数），再喂给 SIT：
\[H_{\text{SIT\_batch}} = \mathcal{F}_{\text{transformer}}\big(\text{Reshape}(H_{\text{com\_batch}}, [1, T, D]),\, \mathcal{M}\big)\]这里有几个关键点：
- Reshape 为 $[1, T, D]$：原本作为”batch 维度”的 $T$ 在 SIT 内被重新解释为”序列维度”，等于把一整个 user batch 看成单条长序列；
- Causal Mask $\mathcal{M}$：保证每个位置只能看到自己之前的 instance，防止未来信息泄漏。论文 Fig. 2(b) 中 “instance 1” 是最近的一条 instance，能看到 $\{1,2,\dots,T\}$；
- SIT 极轻量：2 层 transformer，hidden=64，FFN 中间维度=128。即便 $T=1024$ 也只新增几百万参数，FLOPs 几乎可以忽略。
SIT 之后接 decompress 层并继续预估：
\[H_{\text{SIT\_batch}} \xrightarrow{\text{reshape}\,[T,D]} \xrightarrow{\text{Eq. 5}} h_{\text{decompress}} \to \hat{y} \to \mathcal{L}_{\text{BCE}}\]注意一个反直觉的设计：论文最终存储的 InsEmb 是 SIT 之前的 $H_{\text{com\_batch}}$，而非 SIT 之后的 $H_{\text{SIT\_batch}}$。这点在消融实验（Tab. 4 “w/ InsEmb Stored after SIT”）中得到验证：存 SIT 之后的版本会让下游 AUC 下降 0.09%。
为什么 SIT 之后的版本反而更差？我的解读基于论文 Sect. 4.4 的两个 hint：
- 同质化（homogenization）：SIT 内部是 causal attention，位置越靠后聚合的历史信息越多，导致输出向量之间相似度上升——存下来作为下游 token 会损失区分度；
- 信息泄漏的反向问题：SIT 之前的 InsEmb 仅来自单条 instance 自身的压缩，相当于干净的”原子表示”；SIT 之后的 InsEmb 则混入了”截至该时刻的历史摘要”，会与下游的序列建模过程产生重复——下游 transformer 再做一次 sequence aggregation 时反而是冗余的。
换言之，SIT 在 source model 阶段的角色是辅助监督训练（让压缩层学到对序列建模有用的表示），但 SIT 本身不是要”为下游做好序列摘要”。这是非常聪明的设计——把 SIT 当作 representation-shaping 的 inductive bias，而非 representation 本身。
3.3.3 User-Order vs Temporal-Order 的本质区别
论文明确指出 user-order 相比 temporal-order 有两点优势：
- Source model 自身性能更好。SIT 在 source model 内引入了同用户历史信息流，把 source model 的 AUC 拉高 0.6%（vs. 单实例 compress/decompress 的 -0.05%）；
- 生成的 InsEmb 自带”序列建模友好性”。在 SIT 训练目标的牵引下，压缩层会偏向学到那些与同用户历史 instance 易于聚合的特征——这种 inductive bias 让 InsEmb 在下游 transformer 中能产生更强的协同效应。
这是个非常微妙但很重要的差异。Temporal-order 训练时每条 instance 都是孤立的，压缩层只需要学到”判别当前样本”的足够信息；user-order 训练时压缩层被迫学到”既能判别当前样本、又能与历史 instance 形成有意义的 attention 模式”的表示——后者天然更适合做下游序列 token。
3.4 Source Model 的训练范式
工业推荐系统的训练范式是 batch（历史数据预训练） + streaming（实时数据增量训练） 的组合。这两个阶段对 user-order source model 提出了不同的工程挑战。
3.4.1 Temporal-Order：两阶段一致
temporal-order source model 完全单实例处理，不依赖样本组织方式，batch 训练和 streaming 训练共用同一份代码与图结构。无需特殊设计。
3.4.2 User-Order：流式阶段的工程改造
Streaming 阶段，新样本来自全网各种用户，batch 内通常每个用户只有 1 条 instance——直接套用 batch 阶段的”一个 batch 一个用户”假设会崩溃。论文的解决方案（Eq. 7, 8）：
\[H_{\text{com\_concat}} = \text{Concat}\big(H_{\text{com\_stream}},\, \text{sg}(H_{\text{com\_stream}}')\big)\] \[H_{\text{SIT\_stream}} = \mathcal{F}_{\text{transformer}}\big(H_{\text{com\_concat}},\, \mathcal{M}\big)\]其中：
- $H_{\text{com\_stream}} \in \mathbb{R}^{B \times D}$：streaming batch 中 $B$ 条新 instance 自己计算出的 InsEmb；
- $H_{\text{com\_stream}}’\in \mathbb{R}^{B \times (T-1) \times D}$：对 batch 中每条 instance，从 PS 直接捞出该用户最近 $T-1$ 条历史 InsEmb；
- $\text{sg}(\cdot)$：stop gradient，避免梯度回流到历史 InsEmb（它们是过去版本模型产出的，反传梯度会让训练不稳）；
- 最终只取 $H_{\text{SIT\_stream}}[:, 0, :]$（即当前 instance 对应的输出位置）做后续 decompress 和预估，新生成的 InsEmb 也只更新 batch 内这 $B$ 条。
论文配置 $B=1024,\, T=256$，所以每次 streaming forward 实际处理 $1024 \times 256 = 262{,}144$ 个 token，但只反传 1024 条新 instance 的梯度——这是个不错的”看得多、写得少”的工程权衡。
附录 A.2 中给出的另一种方案——Recomputation——是把这 $T-1$ 条历史 instance 用最新模型重新前向算一遍 InsEmb。优点是消除了 stale embedding 的不一致性，缺点是计算量 $T$ 倍膨胀（$T=256$ 时就是 256× FLOPs），论文最终因成本考虑没有采用。这是 “Embedding 时效性 vs 训练成本” 的经典 trade-off，对延迟敏感的工业场景而言，Method 1（store retrieval）是合理选择。
3.4.3 进一步优化：两段反向训练（Appendix A.3）
User-order batch 训练有个潜在不公平性：早训练到的用户产生的 InsEmb 来自未收敛的 source model，质量低于晚训练用户的 InsEmb。论文提出的解法是训两个 job：
- Job 1：正常时序顺序训练，只保留后半段用户的 InsEmb；
- Job 2：完全反向时序训练，只保留后半段用户（在反向序中实际是原始的前半段）的 InsEmb。
两个 job 合在一起，保证每条 InsEmb 都来自”训练靠后阶段、模型较为收敛”时的版本。实验显示这个 two-pass 技巧能在 one-pass 基础上再涨 0.2% AUC（0.6% → 0.8%）。
这个设计反映了对工业大规模训练里 “model staleness” 现象的深刻理解——常见但常被忽视。
4. Stage II：IAT 序列建模
Stage I 产出的 InsEmb 已经存到 PS 中。Stage II 的任务是在下游 ranking 模型里把它们组织成可消费的序列特征。
4.1 Core Side Information
虽然 InsEmb 已经压缩了数千维特征，但仍有一些任务相关、且不该被混入 InsEmb 的信息需要显式拼出来：
- Label Side Info：历史 instance 的 multi-task label（用户是否点击、是否下单、是否复购等）。这些 label 在生成 InsEmb 时不能被泄漏到压缩层（否则下游会产生 train-serve 不一致），但下游消费时可作为重要 side feature；
- Other Task-Related Side Info：典型如归因相关的时间戳（论文中是广告归因链中的关键时间戳），共有 5 类其他 side info。
这些 side info 走传统的 ID + embedding table 路线处理，输出 $E_{\text{side}} \in \mathbb{R}^{B \times T \times d_{\text{side}}}$，论文取 $d_{\text{side}} = 64$。
消融实验（Tab. 4）显示：去掉 label side info 对 U-IAT 造成 -0.10% AUC 的明显下降，说明 InsEmb 确实没有充分编码 label 信息（这其实是 by design——避免泄漏），需要在下游显式补回。而去掉 other side info 对 U-IAT 几乎无影响（-0.01%），但对 T-IAT 有 -0.05% 影响——这暗示 user-order InsEmb 的信息丰富度已经覆盖了大部分上下文信息，而 temporal-order InsEmb 还需要 side info 补足。
4.2 InsEmb Adaptation：低维到高维的投影
下游 transformer 的 hidden size 通常远大于 64。论文在下游引入 adaptation MLP：
\[E_{\text{InsEmb\_adapt}} = \sigma\big(E_{\text{InsEmb}} \mathcal{W}_{\text{adapt}}^{\top} + b_{\text{adapt}}\big),\quad \mathcal{W}_{\text{adapt}} \in \mathbb{R}^{d_{\text{adapt}} \times d}\]论文取 $d = d_{\text{adapt}} = 64$（一致），实际工业部署中可视下游 hidden 维度调整。这个 adaptation 层是下游模型独有的、可训练的，等价于让下游模型自适应地学习如何使用 source model 产出的固定 embedding——类似 BERT fine-tuning 时在表示之上加 task-specific head 的设计。
4.3 InsToken 构造
把 adapt 后的 InsEmb 和 side info 拼起来即得到 InsToken：
\[E_{\text{InsToken}} = \text{Concat}(E_{\text{InsEmb\_adapt}},\, E_{\text{side}})\]最终的 InsToken 维度为 $d_{\text{adapt}} + d_{\text{side}} = 128$，序列长度 $T = 256$。对比传统 hand-crafted sequence 通常 sequence length=512 但每个 token 维度仅几十维（且这几十维往往只覆盖 ID 类特征）的设定，IAT 序列以一半长度承载了数倍的信息密度。
4.4 Query Token 的构造
序列建模需要一个 query token（对应当前候选 item）才能做 attention。论文有意设计了一个”对齐 InsEmb 风格”的 query：
\[Q = \mathcal{F}_{\text{compress}}\big(\text{Concat}(X_{\text{seq}}, X_{\text{non-seq}})\big),\quad Q \in \mathbb{R}^{B \times d_{\text{query}}}\]也就是把下游模型的所有序列与非序列特征拼起来再压一遍，得到一个 $d_{\text{query}}=512$ 维的 query。
为什么不直接用 candidate item embedding 作为 query？ 消融实验（Tab. 4 “w/ ID-based query”）显示：用 ID-based query 会导致 U-IAT AUC 下降 0.09%。论文的解释是：InsToken 是 informationally rich 的，需要一个同样 informationally rich 的 query 才能”对得上”——简单 ID query 信息量不足，attention 难以聚焦到真正相关的历史 instance 上。
这点在我看来其实有更深一层含义：传统的 DIN-style 序列建模本质是 “用 candidate item 检索历史相似 item”，query 的语义维度低也能 work；而 IAT 序列每个 token 是 “上千维特征的压缩态”，更像是一种”丰富语义的 user state 流”——此时 query 必须是同样语义层级的”user-candidate 联合表示”，才能正确地做 attention。
4.5 序列建模架构选择
IAT 序列本身可以用任何主流的 sequence modeling network。论文做了对比实验（Tab. 2）：
| 下游 IAT 序列建模架构 | ΔAUC vs Base |
|---|---|
| DIN | +0.03% |
| LONGER | +0.31% |
| Transformer | +0.29% |
有趣的发现是 DIN 几乎无效——只有 +0.03%（vs. Transformer/LONGER 的 +0.3%）。论文给出的解释是 SIT 在 source model 阶段就是 transformer 结构，下游用同族架构能更好地继承上游建立的表示规律。我补充一种解读：DIN 的 target attention 假设序列 token 是”被检索的离散历史 item”，与 IAT 序列”信息密度高的 user state 流”语义不太匹配；而 transformer 的 self-attention 能在序列内部建模 instance 之间的长程依赖，更适合 IAT 这种富信息序列。
4.6 IAT 在下游整体架构中的位置
论文还研究了 IAT 序列建模结果放在下游网络哪个位置最好（Tab. 4 “w/ IAT after Feat. Int.”）。结论是 把 IAT 序列建模结果作为输入 token 喂给上层的特征交互模块（如 RankMixer）效果最好——比放在特征交互之后再融合要好 0.06%。
这个设计的直觉是：把 IAT 建模结果与其他底层 token（用户画像、上下文、候选 item 等）一起喂给 RankMixer，让特征交互模块自主地决定如何利用这一信息——而不是把它当成一个”已经处理完的高级特征”在最后简单融合。这印证了一个通用原则：让模型自主学习如何融合信号，通常优于人工预先规定融合方式。
5. 存储架构设计
IAT 之所以能在工业环境落地，关键在于一套精心设计的存储与服务架构（图 4）：
1
2
3
4
5
6
7
8
9
10
11
┌────────────────────────┐ ┌──────────────────────┐
│ Source Model 训练侧 │ │ 下游 Ranking 服务侧 │
│ │ │ │
│ feature ─► InsEmb │ ┌────────►│ request │
│ │ │ │ │ │ │
│ ├──► [InsID, Emb] ├────► PS (Emb) │ ├─► 按 UID 取 │
│ │ │ │ │ InsID list │
│ └──► [UID, InsID, ├────► KV Store ─┘ ├─► 按 InsID 取 │
│ Side Info] │ (按 ts 排序) │ InsEmb │
│ │ │ └─► InsToken │
└────────────────────────┘ └──────────────────────┘
四个关键步骤：
- Source model 处理 instance，产出 InsEmb，以 InsID 为 key 写入 PS（Parameter Server）；
- 与此同时，特征抽取模块异步输出
(UID, InsID, SideInfo)三元组到消息队列，再持久化到高性能 KV 存储。系统按时间戳排序、截断到 $T$，形成每个用户的历史 instance 序列； - 在线请求到来时，下游模型先按 UID 从 KV store 拉取 InsID 序列（按 request timestamp 严格截断，防止泄漏）；
- 按 InsID 列表从 PS 拉取 InsEmb，构造 InsToken 喂给下游 ranking model。
5.1 InsID 的设计
InsID 是 instance 的唯一标识，论文建议用”时间戳 + 任务相关 ID”（如广告场景的 request ID + creative ID）的 hash 来构造。这种设计保证：
- 全局唯一，避免冲突；
- 天然带时序信息，可按时间戳排序与截断；
- 跨业务复用，比如 advertising 训练出的 InsEmb 可以被 mall、feed、live-streaming 等下游服务直接复用——这是 cross-domain 实验（Tab. 6）取得成功的工程基础。
5.2 PS 存储成本估算
\[\text{PS Storage Bytes} = N_{\text{daily}} \times T \times d \times 4\]其中 $N_{\text{daily}}$ 是日均训练 instance 量，$T$ 是历史保留天数，$d$ 是 InsEmb 维度，FP32 占 4 bytes。论文给出的典型规模估算：2 年保留期、日均数亿样本、64 维 InsEmb，约几十 TB 的 PS 存储——对字节这种量级的公司完全可承受，而其带来的 AUC 收益与跨场景复用价值远高于这个存储成本。
值得注意的是论文给出的对比基线：新增一条长度 256 的 hand-crafted 序列，按经验需要在 ranking 模型里投入大量特征工程工作，AUC 增益往往不到 0.1%；而 IAT 同样的序列长度能稳定带来 0.3% 的 AUC 增益。从单位 AUC 收益的特征工程 ROI 看，IAT 是巨大的进步。
6. 实验分析
6.1 实验设置
- 数据集：字节内部 CVR 预估数据集，4 个月连续训练数据，规模约百亿条 instance；
- Base Model：3 种序列建模架构 DIN、LONGER、Transformer，统一接 RankMixer 做特征交互；
- 训练：分布式 GPU 集群，几百节点，batch size = 1024；
- 指标：AUC、LogLoss、Params、FLOPs/Batch。
6.2 整体性能（Tab. 1）
整理为更易读的格式（取 LONGER 行为代表，其他类似）：
| 模型 | AUC | ΔAUC | LogLoss | ΔLogLoss | Params | FLOPs |
|---|---|---|---|---|---|---|
| LONGER (Base) | 0.83705 | - | 0.45113 | - | 55M | 89G |
| + Temporal IAT | 0.83830 | +0.15% | 0.44969 | -0.32% | 60M | 97G |
| + User IAT | 0.83967 | +0.31% | 0.44812 | -0.67% | 60M | 97G |
几个观察：
- 温度排序符合预期：User-Order > Temporal-Order > Base。User-IAT 在所有 3 种 base 架构上稳定带来 +0.24% ~ +0.31% AUC 提升，在工业 CVR 预估中”0.1% 即显著”的标准下属于强势收益；
- FLOPs 增加适度：相比 base 仅多 ~9% FLOPs（97G vs 89G），主要来自下游对 IAT 序列的 transformer 处理；
- Params 几乎不变：增加的参数只在 InsEmb adaptation + 下游 IAT transformer 上，参数效率高。
6.3 Source Model 的性能（Sect. 4.2.1）
| Source Model | ΔAUC vs Base |
|---|---|
| Temporal-Order | -0.05% |
| User-Order | +0.6% |
Temporal-order source model 由于 compress/decompress 引入的信息瓶颈，自身性能略降；user-order 因 SIT 引入了用户内部信息流，反而比 base 模型涨 0.6%。
为什么 source model 自身的 -0.05% 不影响下游性能？ 因为 source model 是为了 generate InsEmb，而不是 serving。Temporal-order InsEmb 哪怕在 source 上略损失 AUC，仍然比传统 sparse 序列特征蕴含的信息密度高得多——下游受益于”输入信息量的提升”而非”上游模型 AUC”。
6.4 序列长度敏感性分析（Fig. 5）
论文提供了两个非常有说服力的统计：
- 约 80% 用户的历史 instance 数 < 256，这也是为什么 IAT 序列长度上限选 256；
- 按 IAT 序列长度分组的 AUC 增益：序列越长，AUC 增益越大，最高可达 0.4%。
这说明 IAT 的价值不仅在”用更短序列做相同效果”，更在”长尾用户的精细化建模”——历史行为越丰富的用户，能从 IAT 的高信息密度中受益越多。
6.5 Scaling Studies
Scaling Base Model（Tab. 3）：
| Scaling 方式 | Params | Source Δ | Downstream Δ |
|---|---|---|---|
| Dense Scaling | 150M | +0.54% | +0.5% |
| Seq. Len. Scaling | 350M | +0.51% | +0.30% |
| Feat. Int. Scaling | 1B | +0.41% | +0.33% |
即使 base model scaling 到 1B 参数（特征交互维度的 scaling），IAT 仍能在其之上叠加 +0.33% AUC——这说明 IAT 提供的是与 model-side scaling 正交的特征侧收益，不会被上层 scaling 吸收抵消。这一点在论文核心论点中至关重要：信息密度瓶颈与模型容量瓶颈是两个独立维度。
Scaling Source Model（Fig. 6）：增大 InsEmb 维度 $d$ 或 SIT 层数 $L$，source model AUC 从 +0.52% 提升到 +0.80%，下游模型也同步受益。这表明 source model 本身具备清晰的 scaling 收益曲线。
Scaling Downstream Model（Fig. 7）：固定 IAT 序列长度，下游 transformer 层数 1→2→4，呈现标准 scaling law 形态，且层数越多 scaling 越显著——意味着 IAT 序列具备承载更复杂下游模型的潜力。
6.6 消融实验（Tab. 4）
| 设定 | T-IAT | U-IAT |
|---|---|---|
| Larger B=2048 | +0.0% | +0.02% |
| w/ InsEmb Stored after SIT | - | -0.09% |
| w/o label sideinfo | -0.06% | -0.10% |
| w/o other sideinfo | -0.05% | -0.01% |
| w/ ID-based query | -0.06% | -0.09% |
| w/ IAT after Feat. Int. | -0.04% | -0.06% |
每个消融的解读已在前文方法部分穿插展开。综合看，user-order IAT 对各项设计选择更敏感、但每项选择也带来更大收益——这反映了 user-order 的更高上限。
6.7 在线 A/B 实验
In-Domain（Tab. 5）：在原始训练数据来源的广告主场景：
| 模型 | ADSS | ADVV |
|---|---|---|
| Temporal-Order IAT | +0.685% | +0.653% |
| User-Order IAT | +1.557% | +1.340% |
User-IAT 带来 1.5% 量级的核心广告收入指标增长，对一个成熟的强 baseline 而言是相当显著的提升。
Cross-Domain（Tab. 6）：把 advertising 训练的 IAT 直接复用到其他场景：
| 场景 | 任务 | 指标 | Uplift |
|---|---|---|---|
| 商城广告 | CVR | ADVV | +1.482% |
| Feed 广告 | CVR | ADSS | +0.5% |
| Feed 广告 | CTR | ADSS | +3.015% |
| NOC 广告 | CVR | ADSS | +1.19% |
| 直播电商 | CT-CVR | GMV | +0.151% |
这里有几个值得深挖的观察：
- Feed 广告 CTR 收益最大（+3.015%）：可能是因为 Feed 场景用户单次曝光时间短、决策快，hand-crafted 序列特征对 CTR 预估的信息量本就不足——IAT 引入的高信息密度对 CTR 这种”快决策”任务收益最大；
- 直播电商 GMV +0.151% 看似偏小但实际很可观：直播电商的 GMV 是最终交易额，链路最长、噪声最大，能稳定 lift 0.1% 已经属于强 signal；
- 跨场景全面正向：证明 InsEmb 学到的是”通用用户兴趣表示”而非过拟合于源场景的 task-specific 表示——这正是 compress/decompress 信息瓶颈设计带来的好处。
7. 关键结论与争议点讨论
7.1 核心结论
- 重新定义了序列特征工程：从手工设计离散特征转向”用 instance 自身的压缩表示作为序列 token”，这是推荐系统特征工程范式的一次根本性转变；
- 两种压缩方案对照清晰：Temporal-order 简单但信息有限，User-order 引入 SIT 让 InsEmb 具备序列建模友好性，二者各有适用场景；
- 跨域迁移能力强：advertising 训练的 InsEmb 能直接迁移到 mall、feed、live-streaming 等场景，工业 ROI 极高；
- scaling 正交性：IAT 的收益与 base model scaling 正交，不会被上层模型容量增长抵消。
7.2 可讨论的几个问题
(1) Stale Embedding 的真实影响有多大？
论文为了工程成本选择了 Method 1（store retrieval），这意味着 SIT 在 streaming 阶段消费的历史 InsEmb 是”过去版本模型”产出的。在数据分布快速漂移的场景（如热点事件、新创意上线），stale embedding 的影响可能被低估。论文未给出”InsEmb 的更新延迟分布”或”按 embedding age 分组的 AUC”的实验——这是一个潜在的优化点。
实际部署时可考虑的折中：对”最近 N 条” instance 采用 recomputation（高时效性，成本可控），对”更远的历史” 用 store retrieval——既保住核心时段的精度，又控制总体计算开销。论文未明确做这个对比，是个明显的延伸方向。
(2) “InsEmb 不含 label 信息” 的设计是否最优？
论文为避免泄漏，刻意不让 label 进入 InsEmb；但消融实验显示去掉 label side info 会让 AUC 降 0.1%——说明 label 信息至关重要。这种”刻意排除再显式补回”的设计虽然 safe，但增加了 side info 的工程复杂度。
是否存在更优雅的方案？例如让 source model 在不同任务上用多个 head 联合训练（multi-task），InsEmb 自然编码多任务标签的统计模式而不直接泄漏单条样本 label——这在 Universal Encoder 思路下是值得探索的方向。
(3) 与生成式推荐范式（HSTU、OneRec）的关系
近期生成式推荐范式（HSTU 用 trillion-parameter sequential transducer 直接输出 next item、OneRec 一统检索与排序）的发展方向是端到端、单模型。IAT 的两阶段架构在这个 trend 下显得”传统”。但反过来看：
- IAT 的 source/downstream 解耦让 InsEmb 能成为通用基础设施，多个下游场景共享同一份 source model——这种”特征中台”思路在多业务公司比生成式端到端更具工程价值；
- 生成式模型对 hand-crafted 特征的依赖在 industrial 落地中并未真正消失（论文中 HSTU 的”actions speak louder than words”实际上仍依赖大量 action token 设计）——IAT 提供的 instance-level 压缩是对生成式架构本身的”输入层升级”，二者可以协同。
我倾向于把 IAT 看作”判别式范式中的最后一次大优化”——它把判别式 ranking 模型的输入信息密度推到极限。下一步真正的范式跃迁可能要等到生成式模型完全消化”用户行为流”这个原始信号。
(4) 与 LLaTTE / HLLM / external foundation model 等 two-stage 工作的差异
论文在 Related Works 中提到 HLLM、LLaTTE 这类 two-stage ranking 工作。差异在于：
- HLLM/LLaTTE 的两段是 user-tier 与 item-tier（先抽 item 内容特征再做 user-side 序列建模）；
- IAT 的两段是 instance-tier 与 sequence-tier（先把整条 instance 压缩，再把同用户的压缩序列做建模）。
IAT 的粒度更细——它不只压缩 item 内容，而是把整条 instance（item + 用户当时上下文 + 当时各种交叉信号）一并压缩。这是论文”信息密度极致化”的核心创新点。
7.3 未来工作
论文自己提到了两条延伸方向：
- 一阶段框架：能否避免两阶段训练的复杂性，让 source 和 downstream 联合训练？挑战在于 InsEmb 的存储与查询如何在统一图中表达；
- 更先进的压缩技术：FP32 → INT8 量化、PQ（Product Quantization）等可大幅压缩存储成本，但对 AUC 的影响需要细致评估。
我会补充第三条延伸方向：Instance-Level Pretraining。当前 source model 仍是有监督训练（依赖 CTR/CVR label），可以探索自监督的 instance-level pretraining 范式（如 contrastive learning over instances）——这样 InsEmb 能更广泛地编码通用用户行为模式，跨域迁移效果可能进一步提升。
8. 总结
IAT 在工业推荐系统的序列建模演化中是一次”基础设施级”的工作——它没有发明新的注意力机制，没有提出新的 scaling law 函数形式，但通过一个看似简单的观察 “为什么我们要在每个 token 上手工设计特征？整条 instance 本身就是最丰富的 token“，从根本上重塑了序列特征工程的范式。
技术上最值得借鉴的几个 design choice：
- Compress/decompress 信息瓶颈 避免压缩表示坍塌到 task-specific 信号；
- 存 SIT 之前而非之后的 InsEmb 既享受 SIT 的训练牵引，又保留下游序列建模的自由度；
- streaming 阶段 stop-gradient + store retrieval 实现了时效性与训练成本的实用平衡；
- two-pass 反向训练 解决了 model staleness 带来的样本不公平问题；
- InsID 全局唯一标识 + PS 存储 + KV store 元数据 是一套优雅的工业级特征存储方案。
从字节角度看，这个工作的真正威力在于其作为特征中台的可复用性——一份在 advertising 主场景训练的 InsEmb，可以无成本地输出到广告生态的所有子场景（商城、Feed、NOC、直播电商），每个子场景都能直接获得 0.5%~3% 的核心指标增长。这种”乘法效应”是单纯的模型优化做不到的。
对推荐社区而言，IAT 提供了一个新的研究坐标系：在追求 model-side scaling 的同时，不要忘记 feature-side 仍有数量级的优化空间。