AMBER：An Event is Worth One Token —— 面向工业级 LLM 推荐的事件 Tokenization¶

AI at Meta，2026-08-24（arXiv 2608.25546v1，cs.IR）。核心贡献者 Fan Xia、Zhaoheng Zheng、Iman Setayesh、Ruogu Lin、Yiqin Pan、Samarth Mittal。

一、研究动机与背景¶

1.1 从 LLM 到 LEM：什么是 snapshot resolution¶

论文先给出一个更大的框架：大型自回归模型正被越来越多地用于真实世界事件序列的预测任务——推荐系统建模用户交互事件序列，世界模型从「观测-动作」序列预测未来状态，金融模型从金融事件序列预测行情。这些领域共享同一种结构：序列的每个位置编码的是一个 temporal snapshot（时间快照），即系统在事件发生时刻的一份结构化观测记录，由一组异构信号共同刻画。作者把这一类从结构化事件序列预测未来状态的基础模型称为 Large Event Models (LEMs)：LLM 在一个固定词表上操作，而 LEM 在真实世界事件的时间快照上操作。

LEM 与 LLM 的关键区别，作者命名为 snapshot resolution（快照分辨率）：

在任一时刻，系统的真实状态包含的信息远多于任何系统能记录的量；snapshot resolution 就是模型实际捕获了其中多少——形式化地说，每个事件编码的不同信号的数量。

推荐事件包含 user / item / context / outcome 四类信号，机器人控制事件包含视觉观测、关节状态、活跃子目标。在自回归训练下，更高的 snapshot resolution 同时改善注意力机制的两侧：query 侧表达更细粒度的意图，key-value 侧为所有后续位置保留更多上下文细节。

1.2 工业推荐的结构性两难¶

工业推荐是 LEM 的一个典型大规模实例，它当前面临序列长度与 snapshot resolution 之间的严格权衡，根源是 serving 算力约束：在大规模推荐系统里，特征相关操作（存储、反序列化、网络传输）的开销可以与 GPU 算力相当甚至超过它。这个瓶颈把架构逼进了二选一：

• Pointwise 模型（BST [6]、DIN [28] 谱系）：为当前 query 保留完整的异构特征，但历史只能用稀疏表示；
• 自回归模型（SASRec [15]、HSTU [26] 谱系）：擅长序列建模，但被迫把详细的历史事件退化为简单的 item-semantic 表示（Semantic ID [4,5,7,24]）或人工挑选的特征子集 [12,26]。

两种情况都造成强制性的信息损失，而且由于每个位置都是下一个位置的上下文，这种退化会沿序列逐级复合放大（compounds progressively across the sequence）。这是本文反复强调的 root cause：不是模型容量不够，而是输入表征里根本没有那些信息，模型 scaling 无法恢复输入表征中缺失的信息。

Related Work 一节把这个不对称量化了：受严格 serving 算力约束，per-impression query 的 snapshot resolution 通常比一个历史事件高数十到数百倍。

1.3 本文的赌注¶

既有工作证明 LLM 可以在对齐嵌入空间后处理压缩的隐表征（如 BLIP-2 [21]、LLaVA [22] 的 visual token）。据此论文提出 AMBER（Autoregressive Modeling via Bottlenecked Event Representation）：不把原始特征直接喂给序列模型，而是用一个统一的 Event Tokenizer 把每个时间快照的海量异构信号封装成一个紧凑的 Event Token，再由下游序列模型自回归地消费。整条流水线端到端训练。serving 时，由于 tokenization 是逐事件、与历史无关的，可以在事件发生时异步触发，结果 Event Token 缓存进用户的历史序列——从而把 snapshot resolution 与 serving 算力解耦。

Figure 1 是全文的纲领性结果：在总（训练 + 服务）FLOPs横轴下（含 CPU 特征物化开销），从「Semantic IDs + 内容理解嵌入」→「item features」→「全量事件特征」逐级推进 Pareto 前沿；而只有通过异步计算 + 缓存 Event Token（AMBER），全特征 scaling 才在工程上可行，并使 Event Tokenizer 方向的 scaling 拥有比 User LLM scaling 更好的算力-质量趋势。

论文进一步声称 event token 范式有两条使其适合工业规模的性质：

1. Event Tokenizer 容量可以独立 scaling，几乎不影响实时 serving 算力——因为 tokenization 每次曝光只触发一次并被缓存；
2. 下游 LLM 性能随容量可预测地 scaling——说明 Event Token 没有被过度压缩，仍保留足够的细粒度语义来解锁下游 scaling law。

此外还分享了运营中的两条工程教训：recurrent representation drift（周期重训导致的表征漂移） 与 Event Token 存储。

二、相关工作定位¶

推荐中的序列建模。工业推荐主要依赖两套特征：per-impression 异构特征与历史行为特征。Pointwise 模型用高分辨率的 per-impression 特征去 attend 低分辨率历史，性能强但训练效率差（每次曝光都要冗余地重编码历史）；自回归模型用一次因果前传高效处理历史，但每个位置的 query 分辨率天生弱，最终封顶整体性能。AMBER 的定位是同时拿到自回归的单次前传训练效率和 pointwise 的高 per-event 分辨率。

LLM 推荐。多数 LLM 推荐器把事件序列化成文本 [9] 或 Semantic ID [4,7,12,24]：Semantic ID 高效地编码 item 但丢弃事件上下文，文本能描述完整事件但信息密度太低。与多模态 LLM [1,21,22] 类似，HLLM [5] 端到端把 item 文本压成嵌入，但丢弃了事件级信号。并发工作 LoopFM [14]（arXiv 2605.29280）用基础模型（FM）的中间表征构成序列，但这种解耦式蒸馏阻断了下游梯度，当下游模型容量追平 FM 时增益缩水。AMBER 的区分点是：端到端训练一个事件中心的 tokenizer，把完整异构事件压成直接为下游序列建模优化的高密度 Event Token。

表征漂移与系统效率。缓存学习到的表征引入两个系统性挑战：周期重训中的表征漂移、规模化后的存储开销。前者借鉴 Domain Adaptation [8,10,25]，把对抗原理 [8] 从跨域迁移改用于跨时间检查点的表征稳定；后者建立在 Matryoshka Representation Learning [17,18] 与 quantization-aware training [2] 之上。

三、核心方法：AMBER 架构¶

3.1 利用训练/服务的算力不对称¶

论文的架构哲学是一句非常明确的工程主张：当前工业推荐系统在训练与服务之间存在巨大的算力不对称——离线训练没有严格延迟约束、只处理真实记录的行为加合成负样本，其算力开销只是在线服务的一个零头；而在线服务要实时对大候选池打分。AMBER 刻意用额外的离线训练算力去换取在线服务算力的降低。

AMBER 有两个组件：

• Event Tokenizer $g_\theta$：把每个事件的原始信号压缩为 $d_z$ 维的 Event Token $\mathbf{z}_i$；
• User LLM $f_\psi$：消费 Event Token 并自回归地做预测。

实验中 $f_\psi$ 由一个预训练 1B 参数的 Llama 初始化。RoPE 用的是相对于固定参考日期的事件时间戳，而不是序列下标——这是一个重要细节，它让位置编码携带真实时间语义。训练时两者 $(g_\theta, f_\psi)$ 联合优化；服务时两者解耦：Event Tokenizer 异步运行，下游模型只从缓存的 Event Token 序列做预测。

3.2 Tokenizer 架构¶

Event Tokenizer 分三步把原始信号映射为一个 Event Token：

1. 特征编码（Feature encoding）。稀疏类别特征（embedding 查表）、嵌入类特征（线性投影）、稠密数值特征（归一化后拼接再投影）各自被映射为独立的 $d_{\text{model}}$ 维 token $\mathbf{h}_1,\dots,\mathbf{h}_m$。
2. 交互与汇总（Interaction & summarizing）。在特征 token 后追加 $c$ 个可学习的 [CLS] token $\mathbf{h}^{(1)}_{\text{CLS}},\dots,\mathbf{h}^{(c)}_{\text{CLS}}$，整个序列过一个 $L$ 层双向 Transformer 编码器，使特征互相交互并被汇总进 $c$ 个 [CLS] 输出。
3. LLM 空间投影。一个 MLP 把上下文化后的 [CLS] 输出映射为最终的 $d_z$ 维 Event Token。

$$\mathbf{z}_i = \mathrm{MLP}\Big(\mathrm{BiTransformer}\big(\mathbf{h}_1,\dots,\mathbf{h}_m,\mathbf{h}^{(1:c)}_{\text{CLS}}\big)[\text{CLS}]\Big) \tag{1}$$

三点容易读错的地方：

1. 稠密数值特征不是「一个标量一个 token」。原文写的是 "Sparse categorical features (via embedding lookup), embedding features (via linear projection), and dense numerical features (normalized, concatenated, and projected) are each mapped to independent $d_{\text{model}}$-dimensional tokens"——三类并列在 "each mapped to independent tokens" 之下，但稠密那一路先做了 concatenate，说明整组稠密特征是被拼成一个（或少数几个）token 的。原文在此处措辞自相矛盾，且没有给出 $m$ 的值，无法判断确切数量。
2. 输入 $m$ 个特征 token，输出只有 1 个 Event Token。[CLS] 是唯一出口，标题「An Event is Worth One Token」指的就是这一步的压缩比。这与序列层面的 token 预算是两件事（见 §3.5：检索 1 token/事件，排序 2 token/事件）。
3. 这里的双向注意力跑在「同一事件的特征之间」，不是「事件之间」。见下。

Tokenizer 不吃序列——原文明确定性为 history-independent：

"At serving time, because tokenization is per-event and history-independent, it is triggered asynchronously as events occur, and the resulting Event Tokens are cached into the user's history sequence."

这条性质是承重的，不是顺手的设计：整篇论文的算力论证都挂在它上面。因为 token 只依赖当前事件，事件发生时算一次、缓存、永久复用；若 tokenizer 看得见历史，用户每新增一个事件就会让此前所有 token 失效而需要重算，异步缓存这条路直接塌掉，「用离线算力换在线算力」的核心主张随之失效。双向注意力在这里也才合法——单个事件的快照内部没有时序，不需要因果掩码。

由此 AMBER 的分工是干净的两层：

序列建模完全发生在 User LLM 一侧，粒度就是 event：每个位置对应一个事件（检索），或两个位置对应一个事件（排序的 context/label 交错）；RoPE 用的是事件时间戳相对固定参考日期而非序列下标，因此两个事件相隔 1 分钟还是 30 天对模型可见。论文对瓶颈的表述也正是序列层面的复合效应：每个位置快照分辨率低 → query 表达弱 → 而每个位置又是下一个位置的 context → 退化沿序列累积。

关键超参一律未披露：$m$（特征 token 数）、$c$（[CLS] 数）、$d_{\text{model}}$、$d_z$ 全文都没有给值（$L$ 默认为 4，见 Table 7）。§3.1 写明 "detailed in Appendix B"，但 Appendix B 的实际标题是 "Baseline Encoder Architectures"，内容是 Concat+FFN / DHEN / PMA 的编码器对照，不含 tokenizer 的任何实现细节——这是一处断掉的交叉引用。唯一的量级线索是 §5.6 的 3.84M dense 参数 + ~200GB 稀疏嵌入表。

3.3 统一 Event Tokenizer 与角色掩码¶

AMBER 不为不同任务/实体各配一个编码器，而是用单个共享的 $g_\theta$，通过动态特征掩码生成不同角色的 token：

$$\mathbf{z}_i = g_\theta(\mathbf{f}_i, \mathbf{m}),\qquad \mathbf{z}_i \in \mathbb{R}^{d_z} \tag{2}$$

其中 $\mathbf{f}_i$ 是事件 $e_i$ 的异构特征，$\mathbf{m}$ 是基于角色的二值掩码，规定该角色能看见哪些特征。除了简化服务，这个共享设计还通过跨实体的正迁移优于专用的 per-entity 编码器（§5.3.2）。

Table 1：逐角色特征掩码（单一共享 Event Tokenizer，只有输入掩码不同；✓ 保留，✗ 掩掉；metadata = position, weight）

注（本文推断，原文未定义）：metadata 里的 "position" 不是序列位置。论文没有解释这两个字段，但从掩码表可以反推：metadata（position, weight）与 outcome 同列，排序的 context token (A) 把它掩掉、只有 label token (B) 保留。序列下标不构成标签泄漏，没有理由从 context 侧掩掉；会被这样对待的只能是曝光展位位置 + 样本权重这类与标签强相关的信号（展位位置即 position bias 的常规处理）。真正的时序位置信息走的是 User LLM 的 RoPE（事件时间戳），不经过 tokenizer。

3.4 三阶段训练¶

直接把随机初始化的 Event Tokenizer 与预训练 LLM 一起训练会破坏 LLM 的世界知识。因此借鉴视觉-语言模型的两阶段对齐 [21,22]，再加一个周期重训阶段：

• Stage 1（Pre-alignment，预对齐）：冻结 User LLM，只训 Event Tokenizer，把事件特征对齐到 LLM 的预训练嵌入空间；
• Stage 2（Joint training，联合训练）：解冻 User LLM，两者端到端共同适配；
• Stage 3（Recurrent training，周期重训）：周期性重训以追踪分布漂移。由此产生的缓存 token 漂移问题由 §4 处理。

3.5 序列设计：每个事件几个 token？¶

上下文长度是序列推荐的瓶颈：在固定上下文窗口下，每事件多花一个 token 就要驱逐一个历史事件。实验（§5.3.2）表明优先保证历史覆盖度比提高每事件 token 数更划算。因此论文寻找每个任务所需的最小 token 预算：检索 1 token/事件，排序 2 token/事件。

排序目标（自回归 BCE）。对每个事件交错放置一个 context token $\mathbf{z}^{(A)}_i$ 和一个 label token $\mathbf{z}^{(B)}_i$（互补掩码，见 Table 1），构成序列：

$$\big(\mathbf{z}^{(A)}_1, \mathbf{z}^{(B)}_1, \mathbf{z}^{(A)}_2, \mathbf{z}^{(B)}_2, \dots, \mathbf{z}^{(A)}_n, \mathbf{z}^{(B)}_n\big) \tag{3}$$

每个 context 位置 $\mathbf{z}^{(A)}_i$ 通过一个 MLP head 预测事件 $i$ 的 label。因为 label token $\mathbf{z}^{(B)}_i$ 排在 $\mathbf{z}^{(A)}_i$ 之后，它永远不会被 $\mathbf{z}^{(A)}_i$ attend 到，所以预测天然无泄漏。整个序列一次前传完成训练：

$$\mathcal{L}_{\text{rank}} = -\frac{1}{n}\sum_{i=1}^{n}\big[y_i \log \hat{y}_i + (1-y_i)\log(1-\hat{y}_i)\big] \tag{4}$$

其中 $y_i \in \{0,1\}$ 是行为标签。推理时候选被作为一个不带 label 的 context token 追加到序列末尾。

检索目标（InfoNCE）。每个事件融合成单个未掩码 token，最大化 LLM 能 attend 的历史长度：

$$(\mathbf{z}_1, \mathbf{z}_2, \dots, \mathbf{z}_n) \tag{5}$$

LLM 在每个位置输出用户嵌入 $\mathbf{u}_i$；目标 item 由同一个 tokenizer 从 item-only 特征预编码，与用户独立地缓存。用噪声对比估计损失训练：

$$\mathcal{L}_{\text{ret}} = -\frac{1}{n}\sum_{i=1}^{n}\log\frac{\exp(\mathbf{u}_i^\top \mathbf{v}^{+}_i/\tau)}{\exp(\mathbf{u}_i^\top \mathbf{v}^{+}_i/\tau) + \sum_{j \in \mathcal{N}_i}\exp(\mathbf{u}_i^\top \mathbf{v}^{-}_j/\tau)} \tag{6}$$

其中 $\mathbf{v}^{+}_i$ 是用户近未来中有正向互动的 item，$\tau$ 是温度，$\mathcal{N}_i$ 混合了难负样本（曝光未互动）与易负样本（随机采样 item）。

排序与检索并非联合训练——这是容易误读的一处。 论文里两者是两个独立的配置/训练运行，不是一个多任务模型：

1. 序列布局互斥：排序是 $(\mathbf{z}^{(A)}_1, \mathbf{z}^{(B)}_1,\dots)$ 交错、2 token/事件；检索是 $(\mathbf{z}_1,\dots,\mathbf{z}_n)$ 融合、1 token/事件。同一次前传不可能同时是这两种布局。
2. 两个损失从未被组合：$\mathcal{L}_{\text{rank}}$（式 4）与 $\mathcal{L}_{\text{ret}}$（式 6）全文没有出现加权求和形式的多任务目标。唯一出现的组合损失是 §4.2 漂移缓解的 $\mathcal{L}_{\text{task}} + \lambda\mathcal{L}_{\text{adv}}$，其中 $\mathcal{L}_{\text{task}}$ 是占位符，指当前任务的损失。
3. 结果分两节报、指标与 baseline 都不同：§5.2.1 排序用 NE，§5.2.2 检索用 Soft Recall。
4. 原文措辞是 "We seek the minimum token budget each task requires"——按任务分别定预算。

真正被「联合」的是另外两件事，别混淆：

• (a) Event Tokenizer 与 User LLM 端到端联合优化（"During training, the two models $(g_\theta, f_\psi)$ are jointly optimized"）。这才是论文所说的 joint training，走 §3.4 的三阶段。消融量化了每一步：解冻 vs 冻结 −1.04%、预训练 vs 随机初始化 −0.20%、预对齐 vs 直接联合 −0.10%。
• (b) 单个 Event Tokenizer 通过角色掩码服务四种 token 角色（Table 1）。这是参数共享，不是多任务训练。而且 §5.3.2 那个 +0.02% 的 "unified vs per-entity" 消融是在排序任务内部跨 entity type（user / item / other / label）测的、指标为 NE；原文表述也正是 "positive transfer across entity"，不是 across task。

因此严格地说：Event Tokenizer 的架构与掩码方案在两个任务间是复用的，但论文没有给出任何证据表明两个任务的 tokenizer 权重是同一份 checkpoint。Figure 3 的图注 "All Event Tokenizer instances share weights and differ only in their feature masks" 横跨 (a)(b) 两个子图，字面上可读成跨任务共享；但既然两个任务的目标函数与序列布局互不兼容、不可能被同时训练，最站得住的解读是「在每个任务各自的训练运行内部，各 tokenizer 实例共享权重」。跨任务这一层是论文留下的空白。

四、大规模服务（Serving at Scale）¶

4.1 异步上游架构¶

AMBER 是一个把特征计算与实时服务解耦的两级系统。

离线 tokenization 与缓存：Event Tokenizer 异步运行——曝光事件发生时触发，通过既有的训练数据管线查询该事件的完整异构特征集，压缩成一个 Event Token，追加到 feature store 里该用户的 Event Token 序列。

两种下游模式：

• 排序：为实时排序在线服务端到端 LLM 会带来严重的基础设施瓶颈，尤其是长用户历史的 KV cache 维护。论文明确把这部分留作未来工作，转而证明表征的普适可迁移性：把缓存的 Event Token 作为即插即用的序列特征喂给既有的非 LLM 排序模型（§5.6 验证）。
• 检索：User LLM 直接消费缓存 token 序列产出实时用户嵌入，供 ANN 检索。

4.2 缓解表征漂移¶

周期重训把编码器从 $g_{\theta_{\text{old}}}$ 更新到 $g_{\theta_{\text{new}}}$ 会改变其输出空间，造成表征漂移：漂移跨重训累积，使新生成的 token 与此前缓存的 token 不兼容，从而扰动下游 LLM 的预测。

Figure 4 的度量方式很值得借鉴：用检查点可分性（k-NN 准确率）衡量漂移——越高说明两个检查点产出的表征越容易被区分（漂移越大），0.5 表示完全不可区分（无漂移）。无正则的基线单调上升，说明持续重训中嵌入空间存在严重的渐进漂移。

对抗正则。重训期间训练一个轻量判别器 $D_\phi$ 去区分某 token 由旧编码器还是新编码器产出：

$$\mathcal{L}_{\text{adv}} = -\frac{1}{n}\sum_{i=1}^{n}\big[s_i \log D_\phi(\mathbf{z}_i) + (1-s_i)\log(1-D_\phi(\mathbf{z}_i))\big] \tag{7}$$

其中 $s_i \in \{0,1\}$ 指示编码器版本。一个梯度反转层推动 $g_{\theta_{\text{new}}}$ 产出与 $g_{\theta_{\text{old}}}$ 不可区分的表征，最小化联合目标 $\mathcal{L}_{\text{task}} + \lambda \mathcal{L}_{\text{adv}}$。$\lambda$ 取小值（约 $5\times10^{-3}$）——更大的 $\lambda$ 会产生「骗过判别器却没有真正减少漂移」的退化表征，这是一条很实的调参教训。

EMA 权重更新。跨每日周期维护一个 EMA 编码器作为稳定参照系，让 DANN 对齐到它，而不是只锚定前一天的检查点。

分片周期重训（Sharded recurrent training）。每天在全量用户上重训是浪费的：每个用户序列里只有很小一部分是新的，大部分数据被重复看到。因此把用户随机划分成 $N$ 个分片，每天只重训一个分片，$N$ 天轮一遍全部用户，最大化每次训练的新鲜信号量。模型收敛后，这样已足以追上最新趋势。

4.3 嵌入压缩¶

每个用户存数百个预计算 Event Token 需要压缩。论文用了两个互补技术。

Matryoshka Dropout。为支持灵活的 token 维度而无需反复重训，论文引入 Matryoshka Dropout。标准 Matryoshka Learning [17] 每步需要多次下游前传，对 LLM 而言算力上不可接受。AMBER 改为在单次前传内通过结构化后缀 dropout 实现连续的维度重要性排序：以概率 $\rho$ 把 $\mathbf{z}$ 截断到前 $d_r \sim \mathrm{Uniform}(d_{\min}, d_z)$ 维，并施加 $d_z/d_r$ 的缩放：

$$\tilde{\mathbf{z}}(j) = \begin{cases} \dfrac{d_z}{d_r}\mathbf{z}(j) & j \le d_r \\[4pt] 0 & j > d_r \end{cases} \tag{8}$$

这样模型学会把最重要的信息保留在每个前缀里。

量化感知训练（QAT）。训练时通过 STE [2] 让编码器暴露于模拟 INT8 噪声，服务时按 INT4 下发，相对 FP32 实现 8× 存储缩减，同时保留全精度嵌入约 80% 的效果。

五、实验设置¶

5.1 数据集¶

模型在某大规模工业推荐平台的 PB 级（petabyte-scale）曝光日志上训练，采用按时间的切分：训练与特征选择用过去数据，校准只用紧邻评测期的近期数据，所有指标都在未见过的未来日期上计算。每个事件携带 user / item / context / outcome 四类信号中最重要的数百个特征；消融实验（§5.3-§5.3.2）用 10% 子采样，主结果（§5.2）用全量。

论文对「为什么不用公开数据集」给了明确辩护：AMBER 针对的是特征物化、周期重训、非平稳性带来的真实系统约束，评估这些约束需要每事件数百个异构特征加十亿级时序数据，而常见公开推荐基准无法同时提供这两个性质。

5.2 评估指标¶

NE（Normalized Entropy）[13]，工业排序的标准离线指标，定义为平均对数损失除以经验正例率 $p$ 的熵：

$$\mathrm{NE} = \frac{-\frac{1}{N}\sum_{i=1}^{N}\big[y_i\log \hat{y}_i + (1-y_i)\log(1-\hat{y}_i)\big]}{-\big[p\log p + (1-p)\log(1-p)\big]} \tag{9}$$

所有 NE 改进都以相对变化量（NE Δ）报告。由于 NE 由对数损失计算，它同时反映排序质量和概率校准：过度自信或不足自信都会抬高 NE，即使排序不变。因此每个模型都在近期无泄漏数据上做校准（使聚合预测互动率匹配观测互动率，校准比接近 1），再在未见未来数据上算 NE。

Ensemble NE。纯粹的跨范式对比不足以评估互补预测收益。Ensemble NE 度量的是 AMBER 相对于高度优化的 Incumbent 的互补性：在未见未来数据上线性融合两者预测后计算 NE，混合权重在前置的 held-out 切片上调优。为了考虑特征物化延迟，会掩掉 10 分钟或 1 分钟延迟窗口内的前序事件。Ensemble NE 越低说明 AMBER 捕获了 Incumbent 之外的额外信号。

Soft Recall（检索）：本模型召回的候选与 Incumbent 召回的候选合并、经下游排序器重打分之后，top-item 价值被保留的价值加权比例，捕获端到端效用而非孤立的召回精度。

显著性：0.02% 以内的 NE 差异取两次运行平均；观察到的 run-to-run 波动至多 0.02%。

5.3 Baseline¶

• Incumbent：高度优化的线上排序模型，在万亿级样本上训练，用来报告 Ensemble NE；
• Incumbent (fair)：在特征、FLOP 预算与训练目标上与 AMBER 对齐的受控基线，用于报告 NE；
• HSTU-style input：沿用 HSTU 的输入 schema（每事件只保留 item 类别特征，用户特征只在序列最前面出现一次），但保留 AMBER 的 LLM 主干以隔离输入 schema 的影响；论文引用 [16] 指出 Transformer 与 HSTU 主干在规模化后表现相当。为了不让它吃亏，用户侧输入给得很慷慨（包含全部 user float / embedding / ID-list 特征，而参考实现只在序列前放少量 user 类别特征）。
• Semantic IDs + CU embeddings：由于消融显示固定上下文长度下历史覆盖度比每事件多加 token 更重要，这个基线把多个 Semantic ID 与内容理解（CU）嵌入融合进一个 token。CU 嵌入被包含进来作为「Semantic ID 解压缩的无损上界」。为控制 tokenizer 架构与容量，该基线使用与 AMBER 完全相同的 Event Tokenizer 架构与规模。
• Pointwise：在 AMBER 的主干内复现 pointwise 输入模式——当前 query 用完整事件，历史只保留 item 特征（且给的是完整 item 特征全集作为强上界，尽管在线物化这么多历史特征代价高昂）。

六、主要实验结果¶

6.1 排序¶

Table 2：排序性能。NE Δ 相对 Incumbent (fair)；Ensemble NE Δ 度量与 Incumbent 线性融合后的互补预测信号，在模拟 10 分钟 / 1 分钟特征延迟下评测。（↓ 越低越好）

† Pointwise 的设置见附录 D。

结论分析（why，而不只是 what）：

1. AMBER 取得最低 NE，分别优于 Incumbent (fair)、Pointwise、HSTU-style、SID + CU emb 0.40%、0.30%、1.00%、1.60%。
2. 对 SID + CU emb 的 1.60% 优势直指 item 中心表征的信息瓶颈——即使给了 CU 嵌入这个「无损上界」，只描述 item 语义仍然远不够。
3. 对 Pointwise 的 0.30% 优势证明：把高 snapshot resolution 贯穿整个历史（而不只在当前 query 上保有）是有益的。这是全文最关键的受控证据。
4. Pointwise 相对 Incumbent (fair) 的 0.10% 优势则隔离出自回归建模在同等算力下的效率收益（单次前传 vs 反复重编码历史）。
5. HSTU-style 相对 SID + CU emb 降低 0.60% NE（靠静态用户侧特征与 item 类别特征），但它的 Ensemble NE 与 SID + CU emb 相近（−0.03% / −0.06%），说明这些信号与 Incumbent 高度冗余——单模型指标提升不等于系统级增量。
6. 互补性：AMBER 与 Incumbent 融合后，10 分钟延迟下 Ensemble NE 降 0.10%，1 分钟窗口下降 0.16%；SID + CU emb 只有 0.03% / 0.05%，不到 AMBER 的三分之一，去掉 CU 嵌入后还会进一步退化（§5.3.1）。不过 item-semantic 基线仍有非零的 ensemble 增益，作者认为部分可能来自 LLM 容量本身。

6.2 检索¶

Table 3：检索 Soft Recall Δ 随距上次重训的天数变化，相对 Incumbent。（↑ 越高越好）

分析：AMBER 在所有检查点年龄上都维持 0.31%–0.51% 的提升，比 CU 嵌入高 0.28–0.32 个百分点。更关键的是衰减特性：CU 嵌入到第 8 天已经归零（−0.01%），而 AMBER 仍保有 0.31%。这说明高分辨率事件信息不仅提升检索，还对检查点陈旧（staleness）更鲁棒——因为事件级信号里包含大量随时间稳定的用户状态，而纯内容嵌入更依赖新鲜的物料分布。

七、消融与分析¶

7.1 特征组消融（§5.3.1）¶

两组互补分析：(1) 从完整 AMBER 中一次去掉一组特征；(2) 从最小的 Semantic ID 表征出发逐步加特征。全部使用同一编码器与预对齐设置。

Table 4：特征组消融（预对齐阶段）。SID 表示 Semantic ID；Ensemble NE 在 10 分钟延迟下相对 Incumbent 度量。（↓ 越低越好）

逐项分析：

1. Item 信息最重要，但 Semantic ID 远远不够。去掉全部 item 特征让 NE 恶化 6.65%，确认 item 表征仍是序列推荐的首要信号。但只保留 Semantic ID + outcome 信号仍与完整 AMBER 相差 2.40%；加上 CU 嵌入与非 CU 的 item 类别特征把差距收窄到 1.52%——说明大量 item 信息根本没有被 Semantic ID 捕获。这是对 SID 范式一次直接的实证审判。
2. 学到的 item 表征之间信号高度重叠。在 CU 嵌入 + item 类别特征之上再加一个行为型 item 嵌入，NE 只改善 0.02%（1.52% → 1.50%）。同样，从完整 AMBER 中单独去掉 SID 是中性的，但把 SID 与 item 嵌入一起去掉损失 0.15%，而单独去掉 item 嵌入只损失 0.06%——说明 SID 提供的信息几乎全部已被学到的 item 嵌入编码。另一方面，SID 与 content hashes 同时去掉损失 0.07%，说明不同标识符类型之间仍有互补。
3. 用户特征携带行为序列之外的信号。加入用户特征改善 NE 1.10%（1.50% → 0.40%），是累积加法中最大的一跳。Ensemble NE 也印证：最大的两处提升来自用户信号与 CU 嵌入——而这两者恰恰是在线物化成本最高的，正好是 AMBER 异步缓存范式的最大价值所在；相反，行为型 item 嵌入在事件历史里被复用时几乎不带来额外信息。

7.2 Tokenizer 与架构设计（§5.3.2）¶

Table 5：AMBER 的设计消融。（NE Δ ↓ 越低越好）

(a) 训练阶段贡献

(b) 统一 vs. per-entity tokenizer

口径注记：这两行都用 NE 度量，即在排序任务内部测的；"unified" 指的是跨 entity type（user / item / other / label）共享一份 tokenizer，而不是跨排序/检索两个任务共享。原文用词为 "positive transfer across entity"。跨任务的权重共享全文未做实验，也未声明（详见 §3.5 末与 §10.2 第 9 条）。

(c) 每事件 token 数（2 vs. 1 token/事件）

(d) 事件编码器对比（= 附录 Table 7）

逐条分析：

• 统一 tokenization 带来正迁移：共享 tokenizer 在 4-token 与 2-token 两种 schema 下都改善 NE 0.02%，说明结构上截然不同的实体类型之间存在正迁移——这是一个反直觉但对工程简化极有价值的结论（服务端只需维护一份 tokenizer）。
• 历史覆盖度决定 token 预算：2 token/事件在无限上下文下有帮助（−0.10%），但在受限窗口下反而有害（+0.16%）。因此 AMBER 选择优先保证历史覆盖度。这条结论直接决定了检索用 1 token、排序用 2 token 的设计。
• Transformer 提供最佳实际权衡：4 层双向 Transformer 在相近 FLOPs 下与 DHEN (×12) 打平（0.00%），但更灵活且能吃 FlashAttention 的效率；PMA (Set Transformer) [20] 与 Concat+FFN 分别落后 0.20% 与 0.22%——Concat+FFN 省掉了自注意力、把特征间交互限制在前馈网络里，落后说明事件内的显式特征交互是必要的。层数缩到 ×2 / ×1 分别恶化 0.09% / 0.19%。
• 预训练知识可迁移到事件建模：即使冻结 LLM，也比只用 Event Tokenizer 好 0.83%——这是「Event Token 可以直接作为 LLM 输入模态」这一主张最直接的证据。解冻 LLM 再多拿 1.04%。预训练初始化相对随机初始化的优势会随数据增多而收窄，但稳定在 0.20%（附录 H）。预对齐相对直接联合训练也有 0.10% 的收益。

附录 H 的这张图很诚实：预训练初始化的优势在训练早期高达约 2.2%，20K 步之后衰减并稳定在约 0.2%。也就是说预训练权重的价值主要体现在收敛速度，长期看只留下一个小而稳定的余量。

7.3 效率与 Scaling 分析（§5.4）¶

Scaling 协议：User LLM 深度 $\{1,2,4,8,16\}$，Event Tokenizer 深度 $\{1,2,4\}$、宽度 $\{64,128,256,512\}$，snapshot resolution $\{100, 200, 400\}$ 个特征。特征按置换重要性排序（打乱某特征后 NE 的上升幅度），在每个分辨率下保持特征类型分布不变，并始终保留 label 与 metadata 特征。

算力成本模型：

$$C_{\text{total}} = m_u C_{\text{user}} + m_e C_{\text{event}} + C_{\text{mat}} \tag{10}$$

其中排序负载的服务/训练比在 30–100×，论文全篇取下界 30×。缓存化的 tokenization 使 $m_e \ll m_u$，$C_{\text{mat}}$ 捕获序列物化开销。NE 是实测的，而服务算力是估算的（附录 A）。附录 A 给出负载分解：

$$m_u = 1 + r_{\text{traffic}}\frac{K_{\text{serve}}}{K_{\text{train}}} r_{\text{eff}} \tag{11}$$

$r_{\text{traffic}}$ 是服务曝光与保留训练曝光之比，$K_{\text{serve}}/K_{\text{train}}$ 刻画全候选打分 vs 采样训练样本，$r_{\text{eff}}$ 反映受延迟约束的推理相对批式训练的低利用率。特征物化算力的一阶 scaling 建模为：

$$C_{\text{mat}} \propto N_{\text{served}} H \sum_{g} n_g c_g \tag{12}$$

$N_{\text{served}}$ 是服务的排序请求数，$H$ 是物化的历史长度，$n_g$ 是特征组 $g$ 每事件的特征数，$c_g$ 是其经验标定的单值物化算力。论文明确说明这些系数依赖服务栈，因此只报告粗略区间而非绝对测量：以「完整异构事件物化」归一为 1，则 Semantic ID + CU 嵌入落在低个位数百分比区间，item features 因为值更多、浮点载荷更大落在高个位数百分比区间，而 AMBER 用一个定长缓存 token 取代两者。

三条核心发现：

1. Snapshot resolution 改善算力-质量前沿。从 Semantic ID + CU 嵌入 → item features → 全量特征，NE 单调改善（Figure 1）。作者据此下了一句很重的判断：模型 scaling 无法恢复输入表征中缺失的信息。AMBER 再通过把全特征物化移出在线服务路径，进一步推进前沿。
2. 训练最优的 scaling 不等于系统最优。只算训练 FLOPs 时，扩 User LLM 容量的 scaling 趋势最强（Figure 5 左）；把服务算力计入后，事件侧 scaling 变得更高效——因为 User LLM 每个请求都要跑，而 Event Token 只算一次并被缓存（Figure 5 右）。只基于训练算力做 scaling 决策，在总算力口径下可能是次优的。这是本文对整个工业 scaling 讨论最有方法论价值的一条。
3. Event Token 质量决定下游 scaling。冻结由 2 层 / 16 层 User LLM 协同训练出的 Event Tokenizer 所产出的 token，再在未来数据上 scaling 一个新的下游 User LLM——与 16 层模型协同训练出的 token 随下游算力改善得更快（Figure 6），说明更强的协同训练产出了更能被大模型利用的表征。

这第 3 条实际上是对「先离线压缩、再在线建模」这一两阶段范式最直接的辩护与修正：压缩器不能与下游解耦地训练，否则它决定了下游的 scaling 天花板。

7.4 漂移缓解评估（§5.5）¶

在 20 天检查点间隔（更严格、对短期波动更不敏感的漂移测试）下比较 DANN 与 MMD、CORAL、$L_2$ 正则。余弦相似度比较同一批事件在两个编码器下的表征；k-NN 准确率独立地衡量一个非线性分类器能多好地分开两者的表征，从而降低对被优化的对齐目标本身的依赖（避免「优化什么就在什么上好看」的自证）。

Table 6：20 天检查点间隔下的漂移缓解。cos_mean 越高越好，knn_acc 越低越好；NE Δ 相对无正则。

分析：DANN 在不牺牲预测质量的前提下给出最好的对齐，其轻微的 NE 改善（−0.02%）作者认为可能反映了对当前分布过拟合的减少。$L_2$ 正则最差（+1.64%）——直接约束权重/输出的 $L_2$ 距离过于粗暴，压制了模型追踪新分布的能力；CORAL 只匹配二阶统计量也不够。需要一个「分布不可区分」而非「逐点接近」的目标，这正是对抗式对齐的价值。

附录 F/G 给出两个佐证：t-SNE 显示 1 天间隔下两个检查点的分布充分混合，20 天间隔下簇内已出现颜色分离；漂移缓解的实际收益体现在下游 NE 轨迹的方差降低（Figure 9），而不只是表征指标好看。

7.5 对特征物化延迟的鲁棒性（附录 E）¶

真实服务里，事件发生到特征物化之间有 1–5 分钟的延迟是常态。论文尝试在训练时通过随机掩掉时间窗内的近期事件来模拟这一延迟。与预期相反：即使评测端也按同样偏移计算，延迟模拟仍使 NE 恶化 0.2%。作者的解释是模型本身就对特征物化延迟鲁棒，而人为掩码反而移除了有用的训练信号。这是一条负面结果，但报告得很诚实，对同类系统有直接参考价值。

八、工业落地：Facebook 全流量部署（§5.6）¶

这是本文工业价值的核心证据，值得逐条摘出：

• 把一个 Event Tokenizer（3.84M dense 参数；约 200 GB 稀疏嵌入表） 集成到 Facebook 的一个全流量（full-traffic）面上；
• 支持每天数十亿事件的在线编码；
• 通过 AMBER 的周期重训框架更新它，每条记录的事件只 tokenize 一次以维护 Event Token 序列；
• Incumbent（线上高度优化的生产排序模型）把这些序列作为额外的历史特征消费；
• 在内部数据集上，NE 降低 0.02% 即被认为具有统计显著性并足以产生可测量的收入影响；
• AMBER 的 Event Token 使 NE 降低 0.06%，即达到内部显著性门槛的 3 倍。

作者对这个结果的解读是双重的：它既证明了跨架构迁移（Event Token 可以脱离 LLM 主干、被一个非 LLM 排序器直接消费），也表明提高历史 snapshot resolution 提供了 Incumbent 之外确实缺失的预测信号。

需要客观指出：§5.6 报告的是离线 NE 口径下的生产收益（在全流量面上、由生产模型消费），论文没有报告线上 A/B 的业务大盘指标（CTR / 时长 / 收入的具体数字），也没有给出延迟或成本的实测数字。但「全流量面 + 每天数十亿事件 + 200GB 稀疏表 + 生产 Incumbent 消费」这一组描述本身已经是真部署而非叙事性的落地声明。

九、核心贡献总结¶

1. 提出 snapshot resolution 这一新的 scaling 维度，并把工业推荐的「序列长度 vs 每事件信息量」二难归因到 serving 侧的特征物化成本，而非模型容量。
2. 提出 AMBER 与 Event Token 这一新的 LLM 输入模态：单个共享的双向 Transformer Event Tokenizer 通过角色掩码把每个事件的数百个异构特征压成 1 个（检索）或 2 个（排序）连续 token，与预训练 1B Llama 端到端联合训练。
3. 异步 tokenization + 缓存把 snapshot resolution 与实时服务算力解耦，从而使「事件侧 scaling」在总算力口径下比「User LLM scaling」更高效——并由此提出训练最优 ≠ 系统最优的 scaling 决策原则。
4. 系统工程贡献：DANN + EMA 的周期重训漂移抑制（附带「$\lambda$ 不能大」的踩坑教训与 k-NN 可分性这一漂移度量）、单次前传的 Matryoshka Dropout、INT8 QAT / INT4 服务的 8× 存储压缩、分片周期重训。
5. 全流量生产验证：Event Token 作为历史特征喂给生产 Incumbent，NE −0.06%（内部显著门槛 0.02%）。

与已归档相关工作的对比¶

IAT IAT: Instance-As-Token Compression for Historical User Sequence Modeling in Industrial Recommender Systems (ByteDance, 2026-04-10)¶

关系：独立并发（本文未引用 IAT，两者殊途同归）· 已加载对方精读

• 共同关注的问题：两篇论文对 root cause 的判断几乎逐字一致——工业排序模型的历史行为序列被迫使用手工挑选的稀疏特征子集（item ID、类目、交互类型、时间戳），而存储与在线服务成本正是这个子集无法扩大的原因；与此同时，每一次历史交互在训练日志里本来就有完整的特征记录（IAT 说约 6000 维原始特征，AMBER 说每事件数百个最重要特征）。瓶颈不在数据可得性，而在表征方式与服务算力预算。
• 相近的技术骨架：都是「离线把每条历史交互的完整特征压成一个低维 token → 存进集中式存储 → 下游模型检索并在 token 序列上做序列建模」。IAT 用 source model 的压缩-解压缩层产出 64 维 InsEmb 写入参数服务器（key 为 InsID），下游按 UID 检索 InsID 列表再取 InsEmb；AMBER 用 Event Tokenizer 产出 $d_z$ 维 Event Token 写入 feature store，下游按用户取缓存序列。两者都额外拼接了 label / 时间戳等 side information（IAT 的 label side info 消融 −0.06%/−0.10%；AMBER 的 outcome signals 留一消融 +0.24%）。
• 本文的差异与推进：IAT 是两阶段解耦的，AMBER 是端到端联合训练的。 IAT 的 source model 与下游模型是两个独立模型，历史 InsEmb 在下游只做 forward、不回传梯度（stop-gradient），并且 IAT 明说 User-Order source model「资源消耗过大，不能直接部署上线」，只作为 InsEmb 的生产模型。AMBER 则用 Stage 1 预对齐 + Stage 2 联合训练把 tokenizer 与 User LLM 一起优化，并且用 Figure 6 直接证明了这件事的必要性：与 16 层 User LLM 协同训练出的冻结 token，比与 2 层协同训练出的 token 有明显更陡的下游 scaling 曲线——即压缩器的训练伙伴决定了下游模型的 scaling 天花板，这正是 IAT 式两阶段范式的长期隐患所在。此外 AMBER 把下游从 DLRM 系（RankMixer）换成预训练 1B Llama，并论证 Event Token 是「一种新的 LLM 输入模态」（冻结 LLM 仍比只用 tokenizer 好 0.83%）。
• 可比的方法 / 实验差异：IAT 报告工业 CVR 数据集上 AUC +0.24%～+0.31%（对比 DIN / LONGER / Transformer 三种基础模型），并给出「传统方案引入长度 256 的手工序列特征几乎拿不到 0.1% AUC」的对照；AMBER 报告 NE −0.40% vs Incumbent (fair)、生产集成 NE −0.06%，两者指标口径不同（AUC vs NE）不可直接换算。IAT 明确给出存储成本公式与「数 TB PS 存储」的量级；AMBER 则用 Matryoshka Dropout + INT4 服务把存储压到 FP32 的 1/8，在存储治理上更进一步。漂移问题是 AMBER 独有的处理：IAT 的精读中没有讨论 source model 周期更新导致历史 InsEmb 与新 InsEmb 不兼容的问题，而 AMBER 用整个 §4.2 处理它——这是把同一范式推到「每天重训 + 缓存长期存活」的生产状态后才会暴露的问题。

SIF SIF: Sample Is Feature —— 从 Item-Level 到 Sample-Level 的统一大规模推荐模型 (Meituan, 2026-04-17)¶

关系：独立并发（本文未引用 SIF，两者殊途同归）· 已加载对方精读

• 共同关注的问题：SIF 的两条结构性瓶颈中的第一条与 AMBER 完全同构——「受限于存储与在线服务成本，现有方法只保留 bare item embedding 或少量手工特征，大量原始样本语境（用户画像、实时上下文、行为结果、预计算交叉）完全被丢弃」。SIF 举的例子（凌晨优惠券激活时的点击 vs 正午吃饭高峰的点击，在 bare item ID 下完全等价）与 AMBER 的 snapshot resolution 论证是同一件事的两种说法。SIF 的第二条瓶颈——历史 token 是单字段 item embedding、当前请求 token 是多字段富表征，二者的「信息密度不对称」——则与 AMBER Related Work 里「per-impression query 的 snapshot resolution 比历史事件高数十到数百倍」的量化判断精确对应。
• 相近的技术骨架：都是「离线把每条历史 raw sample 的完整特征快照压缩 → 存 KV → 在线查表还原 → 在同构的样本级 token 序列上做注意力」，并且都特别处理了当前请求 token 无法预计算这一问题（SIF 用不量化的线性投影 + 对齐损失 $\mathcal{L}_{\text{align}}$ 把 target token 映到码本空间；AMBER 在推理时把候选作为一个不带 label 的 context token 追加）。两者也都对 tokenizer 施加了任务监督而非纯重建：SIF 用 label-supervised codebook（额外 pCTR loss），AMBER 用与下游共享的自回归 BCE / InfoNCE 目标。
• 本文的差异与推进：核心分歧在离散 vs 连续，以及压缩器与下游的耦合程度。 SIF 走离散路线：先按语义组（user / item / ctx / cross，$G=4$）切分，组内按 $B=32$ 个字段一个 sub-token 自适应切分（美团 schema 下 $T=27$），每个 sub-token 上做 $M=3$ 层残差量化（$V=256$），最终每样本 648 bit 的码本索引；在线只存 int 索引，embedding 由 Mixer 内部码本查表。AMBER 走连续路线：一个双向 Transformer 的 [CLS] 输出经 MLP 直接产出 $d_z$ 维稠密向量，量化（INT8 QAT / INT4 服务）只是事后的存储手段，不承担语义组织功能。这带来两组不同的赌注：SIF 的码本一旦固化就限定了下游的表征空间，但存储极致紧凑且天然可解释为语义组；AMBER 的连续 token 保持了与预训练 LLM 嵌入空间对齐的可能（这是它能复用 Llama 权重、并主张「Event Token 是新的 LLM 输入模态」的前提），代价是引入了 SIF 不存在的表征漂移问题——离散码本索引在码本版本内是稳定的，而连续嵌入每次重训都会漂。AMBER 的 §4.2 本质上是为「选择连续路线」付的账。
• 可比的方法 / 实验差异：SIF 相对 HyFormer 最多 +0.88% GAUC，线上 A/B 拿到 +2.03% CTR / +1.21% CVR / +1.35% GMV/session 并已部署到美团外卖排序管线；AMBER 报告 NE −0.40% vs Incumbent (fair) 与生产集成 NE −0.06%，给出了业务量级更大的部署面（Facebook 全流量、日均十亿级事件）但没有报告业务大盘数字。序列建模层面两者也分道：SIF 用 MLP-Mixer 风格的 Token-level / Sample-level 双向混合（复杂度 $O(L^2T + LT^2)$），保留了每个样本内 $T$ 个 sub-token 的显式结构；AMBER 坚持每事件 1–2 个 token 并用消融证明在受限上下文下，历史覆盖度比每事件多留 token 更值钱（2 token/事件在受限上下文下反而 +0.16%）——这一条恰好是对 SIF「$T=27$ 个 sub-token 一个样本」路线的一个反向数据点，但两者上下文预算不同（SIF 的 $L$ 是几十到几百量级、且不共享 LLM 上下文窗口），不能直接判定优劣。

HLLM HLLM: Hierarchical Large Language Models (ByteDance, 2024-09-19)¶

关系：显式引用但原文未展开对比（仅在 Related Work 一句话区分）· 已加载对方精读

• 共同关注的问题与骨架：HLLM 是本文架构上最直接的前置。HLLM 用 Item LLM → item embedding → User LLM 的双层结构，把「每个历史位置放什么」交给一个可训练的编码器，并且丢弃 User LLM 的 word embedding（因为输入输出都是 item embedding 而非文本 token）。AMBER 的 Event Tokenizer → Event Token → User LLM 与之在拓扑上一模一样，连「每个位置一个由编码器产出的连续向量、下游是一个从预训练权重初始化的 decoder-only LLM」这一点都相同。
• 原文的区分方式：本文只在 Related Work 给了一句话——「与多模态 LLM [1,21,22] 类似，HLLM [5] 端到端把 item 文本压成嵌入，但丢弃了相关的事件级信号（discards relevant event-level signals）」。原文没有把 HLLM 作为实验 baseline，也没有任何指标层对比，所以这里的差异只能从两篇论文各自的正文推断。
• 实质差异：分歧点是「一个位置应该编码什么」。HLLM 的 Item LLM 输入是 item 的 title / tag / description 文本，产出的是纯 item 侧的内容表征，位置上不携带 user 状态、请求上下文、交互结果；AMBER 的 Event Token 输入是 user / item / context & cross / metadata & outcome 四类共数百个特征，通过角色掩码（Table 1）决定可见性。AMBER 的 Table 4 恰好可以量化这个差距：只有 item 表征（SID + CU 嵌入 + item 类别 + item 嵌入）距离完整 AMBER 有 1.50% 的 NE 差，其中加入 user 信号一跳就补回 1.10%——这正是 HLLM 那条路线上缺失的部分。另一方面 HLLM 的 Item LLM 携带真正的语言世界知识（Table 3 显示性能随预训练 token 数从 0T 到 3T 单调提升），而 AMBER 的 Event Tokenizer 是从零训练的特征编码器，其预训练红利只来自 User LLM 一侧，且附录 H 显示这份红利长期只剩约 0.2%。
• 一个诚实的补充：AMBER 与 HLLM 的可比性受限于 HLLM 只在 PixelRec / Amazon Books 等公开数据集上评测（Recall@K / NDCG@K），而 AMBER 全部指标来自内部 PB 级日志（NE / Soft Recall），两者没有任何一个共同的数据点。

Step 2.5 被剔除的近似候选（记录以防门槛放水）：

• TransX TransX（LinkedIn, 2026-07-31）：同样把长期行为编码缓存下来以绕开实时服务算力，serving 算力降约 80%。但它缓存的是序列级的行为编码并靠候选特定的稀疏交叉注意力使用，root cause 定位在「长序列的实时算力」而非「每事件的信息密度」，方法流程图无法与 AMBER 抽象重合 → 剔除。
• SITA SITA（USTC, 2026-08-04）：同样离线预计算并按用户存储 token、在线廉价读取。但它把整条行为序列压成 N×K 个由 semantic ID 组织的兴趣 token，服务时用目标 item 的 SID 硬索引——压缩方向（跨事件聚合）与 AMBER（事件内特征聚合、事件数不变）相反，且核心诉求是 target-aware → 剔除。
• TM20K TM20K（ByteDance）/ KSA KSA（Kuaishou）：都是把过长序列通过 token merge / summary token 压短，属于「减少 token 数」而非「提高每 token 信息量」，与 AMBER 明确选择的「宁可 1 token/事件也要保历史覆盖」正交 → 剔除。
• Tlow Tlow（清华+腾讯, 08-25）/ PRQ-KMeans PRQ-KMeans（快手, 08-25）/ Dynamic PV-S2 Dynamic PV-S2（快手, 08-21）：这一组 8 月下旬的 item 语义 ID 量化工作与本文不构成对照。它们的 root cause 都在「层级残差量化本身的病理」——嵌入各向异性使 PQ 网格失配（Tlow）、全码字相减留下残差夹带（PRQ-KMeans）、层间条件稀疏（Dynamic PV-S2）——解法都是重新设计离散码本的构造算子；而 AMBER 的 root cause 在「serving 侧特征物化成本压死了每事件的信息密度」，产出的是连续稠密向量，全文没有码本、没有残差量化，其 INT4 量化纯属事后存储手段。更关键的是，AMBER 对 semantic ID 的态度是把它判为冗余（Table 4：从完整 AMBER 中去掉 SID 是中性的；只有 SID + outcome 时距完整 AMBER 差 2.40%），而那三篇是在假定 SID 范式成立的前提下改进 SID 质量。问题与解法都不同源，硬拉对照会失真 → 剔除。
• Mosaic Mosaic / DUET DUET（均为 Meta）：同样把上游表征离线预训练、冻结后异步供多个下游排序器消费，机构与工程模式同源。但它们压缩的单位是用户（一个用户一组嵌入专家 / 两条用户嵌入流），不是事件，序列结构完全不同 → 剔除。

十、讨论与局限性¶

10.1 值得借鉴的设计¶

1. 「用离线算力换在线算力」这条哲学被贯彻到了指标层。论文没有停留在口号，而是给出 $C_{\text{total}} = m_u C_{\text{user}} + m_e C_{\text{event}} + C_{\text{mat}}$ 这个显式成本模型，并据此得出「训练最优 ≠ 系统最优」的结论。任何做工业模型 scaling 的团队都应该问一遍：我的 scaling 曲线横轴用的是训练 FLOPs 还是总算力？
2. 无泄漏的排序序列设计。把 label token 排在 context token 之后，靠因果掩码天然保证 $\mathbf{z}^{(A)}_i$ 看不到自己的 label——一次前传训练整条序列，既拿到自回归的训练效率，又不需要任何额外的掩码工程。
3. 漂移的度量方式。用检查点可分性（k-NN 准确率，0.5 = 完全不可区分）而非只用余弦相似度，并且明确说明这样做是为了减少对被优化目标本身的依赖——这是很少见的、有方法论自觉的评估设计。
4. 单次前传的 Matryoshka Dropout。标准 MRL 需要多次下游前传，对 LLM 不可行；用结构化后缀 dropout + $d_z/d_r$ 缩放在一次前传内获得连续的维度重要性排序，是一个可以直接搬走的技巧。
5. 统一 tokenizer + 角色掩码：用输入掩码而非专用编码器来区分 ranking context / ranking label / retrieval history / retrieval target 四种 token 角色，既简化服务又拿到 0.02% 的跨实体正迁移收益。但要留意收益口径：那个 +0.02% 是在排序任务内部跨 entity type 测的（指标为 NE），论文并未证明跨排序/检索两个任务共享同一份 tokenizer 权重——详见 §3.5 末与 §10.2 第 9 条。

10.2 局限与争议¶

1. 没有任何公开基准，可复现性为零。全部实验在内部 PB 级日志上完成，绝对指标值一律不披露（只给相对 NE Δ），baseline 是内部的 Incumbent / Incumbent (fair)。论文对此给了辩护（公开基准无法同时提供数百异构特征与十亿级时序数据），辩护本身合理，但结果无法被外部验证或复现，也无法与任何已归档工作对上一个共同数据点。
2. 算力横轴是估算的，不是实测的。§5.4 明确写着「NE 是实测的，而服务算力是估算的」；附录 A 进一步说 $m_u$ 在 30–100× 之间（取下界 30×），$C_{\text{mat}}$ 的系数依赖服务栈、只给粗略区间。Figure 1 和 Figure 5 这两张全文最重要的图，纵轴可信而横轴带有相当的建模自由度——「事件侧 scaling 更高效」这个结论对 $m_u$ 的取值敏感（取 100× 会更有利于本文结论，取更小值则不然）。
3. 端到端 LLM 排序并未上线。§4.1 坦承为长用户历史维护 KV cache 存在严重的基础设施瓶颈，「解决这些服务挑战超出本文范围」。因此 §5.6 的生产部署走的是「Event Token 作为历史特征喂给非 LLM 的 Incumbent」这条降级路径——论文最有野心的部分（自回归 User LLM 实时排序）恰恰是没有部署的那部分。
4. 生产收益的口径偏窄。§5.6 只报 NE −0.06%，虽然内部 0.02% 即显著，但没有线上 A/B 的业务大盘指标、没有延迟/成本实测、没有部署时长与流量比例之外的细节。检索侧（Soft Recall）也只有离线数字。
5. 异步缓存的固有代价没有被完全消化。事件发生到 token 可用之间存在 1–5 分钟延迟；附录 E 的延迟模拟实验得到的是负面结果（模拟延迟反而恶化 NE 0.2%），作者归因于「模型本身鲁棒 + 人工掩码删掉了有用信号」，但这个解释并未被独立验证。论文自己在 Future Work 里承认需要「维护一条极短保留期（如 10 分钟）的高分辨率序列，对尚未缓存的事件做按需 tokenization」——说明这个洞是真实存在的。
6. 表征漂移是选择连续 token 的自缚。DANN + EMA 把 20 天间隔下的 k-NN 可分性压到 0.856（理想值 0.5），离「不可区分」还差得远；漂移只是被抑制，没有被解决。而这个问题在离散码本路线（如 SIF）里结构上要轻得多。
7. Semantic ID 的判决可能被场景限定。Table 4 显示 SID 在完整 AMBER 中是冗余的（去掉中性），这个结论很有冲击力，但成立的前提是同时拥有 CU 嵌入 + item 类别特征 + 行为型 item 嵌入这套已经很富的 item 表征。对于没有这些资产、或者需要用 SID 做生成式解码的系统（TIGER / OneRec 谱系），这一结论未必可迁移——AMBER 的检索是嵌入 + ANN，本来就不需要可解码的离散 ID。
8. 方法论可扩展性上的一个真实优势。相比 IAT / SIF 的「先压缩再建模」，AMBER 的 Stage 2 联合训练让「如何表征历史」与「如何建模序列」两条路径可以同步 scaling，Figure 6 也直接证明了协同训练伙伴的容量决定下游 scaling 斜率。但 serving 阶段仍然是冻结缓存 token + 定期重训，下游模型在两次重训之间面对的是一组固定表征——训练时耦合、服务时解耦这个错位是本范式尚未消除的结构性张力。
9. 「统一 tokenizer」的跨任务维度没有被验证。Table 1 的四种角色掩码与 Figure 3 的图注容易给人「一份权重通吃排序与检索」的印象，但两个任务的序列布局与损失互不兼容、不可能同时训练，论文也从未说明两者用的是不是同一份 checkpoint（详见 §3.5 末）。支撑「统一」的那个 +0.02% 消融是排序任务内部跨 entity type 的结果。「统一」在跨 token 角色这一层有证据，在跨任务这一层只有措辞。
10. Tokenizer 的关键超参一律未披露，且交叉引用是断的。$m$、$c$、$d_{\text{model}}$、$d_z$ 全文无值；§3.1 指向 "Appendix B" 称有详细说明，但 Appendix B 的实际内容是 baseline 编码器对照（Concat+FFN / DHEN / PMA），不含 tokenizer 实现细节。唯一的量级线索是 §5.6 的 3.84M dense 参数 + ~200GB 稀疏表。对一篇把「Event Tokenizer 容量可独立 scaling」当作核心卖点的论文，读者无法知道被 scaling 的究竟是多大的东西，Figure 6 的横轴也因此难以外部解读。
11. 「与历史无关」是结构意义上的，不等于 token 里没有历史信息（本文推断）。Tokenizer 结构上确实只看当前事件，但工业系统的 user 特征通常包含大量历史聚合计数（近 N 天点击、类目偏好分布等），这些是事件时刻物化的用户快照、会随历史变化，因此历史信息可能经由 User 特征组隐式进入 token。值得留意是因为消融里「加入 user 特征」恰是累积加法中最大的一跳（1.50% → 0.40%，改善 1.10%），而论文既未列出 user 特征的具体构成，也未拆分这部分增益中有多少其实来自历史聚合。若占比可观，则「高 snapshot resolution 带来增益」这一叙事中，有一部分实际上是「历史聚合特征带来增益」。