OneTrans如何实现统一序列建模与特征交互？

OneTrans解读：统一序列建模与特征交互 一、问题背景：为什么要打破两段式 Pipeline 工业推荐系统的排序模型，长期以来沿用一种固定范式：先用序列模块（如 DIN、Transformer）对用户行为历史进行编码，得到压缩的用户兴趣表示；再将其与用户画像、物品特征、上下文特征拼接，送入特征交互模块（如 DCNv2、Wukong、RankMixer）完成高阶交叉。这一设计被称为 encode-then-interaction pipeline。 这种两段式范式存在两个根本性缺陷。其一是信息流的单向性：行为序列被压缩为固定向量之后，才与物品和上下文特征交互，这意味着物品特征无法在序列编码阶段对用户历史产生影响——candidate-aware 的信息无法逆向流入序列表示。其二是执行碎片化：两个模块独立计算，无法共享 KV Cache、FlashAttention 等 LLM 工程优化，导致在线延迟偏高、扩展困难。 OneTrans 提出了一个根本性的解决思路：将序列特征与非序列特征统一表示为 Token 序列，用同一个 Transformer Backbone 完成序列建模与特征交互的全部计算，从而打通双向信息流，并使整个模型能够直接复用 LLM 的训练与推理优化栈。 二、统一 Tokenization：将异构特征映射为 Token 序列 OneTrans 的第一步是通过 Tokenizer 将所有输入特征映射为统一维度 \(d\) 的 Token 序列。特征被分为两类：来自用户行为历史的序列特征（S-tokens），以及来自用户画像、物品属性、上下文信息的非序列特征（NS-tokens）。 序列特征的 Token 化 对于点击序列、购买序列等多路行为序列，每一个交互事件（event）由 item ID 与其 side information（如类目、价格）拼接后，通过共享 MLP 投影到统一维度 \(d\)，得到对应的 S-token。多路行为序列的融合方式有两种：若时间戳可用，则按时间交织排列；若不可用，则按行为意图强度（purchase → add-to-cart → click）有序拼接，并在序列边界处插入可学习的 [SEP] token 以区分边界。消融实验表明，时间戳感知的融合方式优于意图排序方式，因此在特征可用时应优先选择。 最终得到的 S-tokens 表示为 \(\mathbf{X}_S \in \mathbb{R}^{L_S \times d}\)，其中 \(L_S\) 为全部行为事件数量与 SEP token 数量之和。 非序列特征的 Token 化：两种方案的对比 非序列特征的 Token 化是 OneTrans 与前序工作（如 RankMixer）的重要区别之一。论文提出了两种方案： Group-wise Tokenizer 按语义人工预先分组，例如将所有用户画像特征划为一组 \(g_1\)，物品特征划为 \(g_2\)，上下文特征划为 \(g_3\)，统计特征划为 \(g_4\)。每组特征在组内拼接后通过各自独立的 MLP 投影为一个 \(d\) 维 Token： \[\text{NS-tokens} = \left[\text{MLP}_1(\text{concat}(g_1)),\ \ldots,\ \text{MLP}_{L_{NS}}(\text{concat}(g_{L_{NS}}))\right] \] 这种方式语义清晰，但需要人工维护分组规则，且多个独立 MLP 会带来多次 GPU kernel 启动开销。 Auto-Split Tokenizer 则更加自动化：将所有非序列特征统一拼接为一个向量，通过一次 MLP 投影到 \(L_{NS} \times d\) 维空间，再按维度切分为 \(L_{NS}\) 个 Token： \[\text{NS-tokens} = \text{split}\left(\text{MLP}(\text{concat}(\mathcal{NS})),\ L_{NS}\right) \] 以一个具体例子说明：假设所有非序列特征拼接后维度为 1000，预设 \(L_{NS} = 12\)，每个 Token 维度 \(d = 80\)，则 MLP 的输出维度为 \(12 \times 80 = 960\)，随后按每 80 维切分为 12 个 Token。值得注意的是，\(L_{NS}\) 是一个人工设定的超参数，工业系统中通常取 8 至 32 之间。