HELIX: Purified and Unified - Rethinking Feature Interaction and Sequence Modeling for Large-Scale Recommendation
Yuntao Zheng, Miao Zhang, Yadong Ding, Yanchuan Tang, Lixiyu Chen, Hao Wang, Quan Li, Shiying Cai, Yue Lin, Jiayu Li, Yu Feng, Wentao Yang, Rongkun Xing, Jiekai Wang, Mingge Zhang, Feiling Gong, Xiang Gao, Jinyu Dong, Yajing Zhang, Pengfei Ren, Yinzhou Wang
cs.IR
2026-09-29
HELIX交错序列检索与特征交互，用户侧K/V可摊销。TikTok电商人均GMV约+6%，离线CTR AUC相对基线+0.21%。
工业推荐精排同时要做两件事：在用户、商品、上下文和交叉特征里找高阶组合，并从长行为序列里捞出跟当前候选有关的证据。FM、DeepFM、DCN在中等规模好用，加宽加深很快饱和。DIN、DIEN、DSIN把「看候选再聚合行为」做成了标配，但聚合层浅，序列容量加不上去。
后来两条轴各自长出了能缩放的骨干。特征交互有Wukong、RankMixer、TokenMixer-Large，把异构embedding切成token再走残差块。序列有HSTU、Ultra HSTU、STCA。单独加任何一条，另一条都会先顶住。InterFormer、Kunlun、OneTrans把两条轴塞进共享骨干，但又踩了三个坑：self-attention并不适合异构特征token；检索和交互挤在同一步，mix-token的注意力会被非序列输入打散；双向更新会让用户侧状态跟着候选变，M-FALCON和user-level training都摊销不了。
序列越做越深，如果每个候选都重算一遍用户历史，算力会先爆。
HELIX自称purified and unified。unified指序列检索和特征交互沿深度交错，不是两段拼接。purified指砍掉LHUC、DCN-M、FM模块、跨层残差和辅助损失，只留检索和交互。
输入拆成三路。MixTokenizer把非序列特征和各序列的mean pooling摘要切成M个mix-token，每组独立LayerNorm和FFN。全模型只有这里用LayerNorm，其余全是RMSNorm。SeqTokenizer把U-only序列（与候选无关的用户历史）和U×C序列（用了候选信息的相似序列、item-to-item等）分别投影，位置加在各序列内部再拼接，避免给不同类型序列强加全局顺序。流开头垫可学习[SINK] token。
计算按单向信息流走：
信息只从用户序列流向mix-token。同一请求的所有候选共享cache；训练时同一用户的多样本也只跑一次encoder。注意力统一加QK-Norm、grouped-query attention和gated attention。
内部TikTok电商视频数据，相对生产基线RankMixer + Transformer（210M参数、每样本5.75G FLOPs）。文中写明相对AUC提升0.03%即有业务意义。
| 方法 | CTR ΔAUC | CTR ΔUAUC | CVR ΔAUC | CVR ΔUAUC | 参数 | FLOPs |
| RankMixer + Transformer | 0 | 0 | 0 | 0 | 210M | 5.75G |
| RankMixer Large | +0.04% | +0.15% | +0.03% | +0.19% | 1069M | 27.50G |
| OneTrans | +0.15% | +0.61% | +0.10% | +0.66% | 361M | 39.27G |
| HELIX-L | +0.21% | +0.82% | +0.17% | +1.38% | 358M | 35.28G |
RankMixer把非embedding参数加到约1.07B，CTR AUC只多0.04%。HELIX-L和OneTrans几乎同档参数，四个质量指标都更高，训练FLOPs还略低（35.28G vs 39.27G）。OneTrans对照用的是发表后优化过的生产实现。
S/M/L/XL/XXL联合加宽、加深、加序列token预算。相对HELIX-S：
| 规格 | CTR ΔAUC | CVR ΔAUC | 参数 | FLOPs |
| S | 0 | 0 | 46M | 2.31G |
| M | +0.24% | +0.07% | 99M | 7.90G |
| L | +0.34% | +0.18% | 358M | 35.28G |
| XL | +0.39% | +0.20% | 740M | 72.41G |
| XXL | +0.45% | +0.27% | 1050M | 130.24G |
log(ΔAUC)对log FLOPs近似幂律：CTR斜率0.085、R²=0.925；CVR斜率0.132、R²=0.994。XXL仍未饱和。低算力下RankMixer还能打，加大就落后；OneTrans算力高于HELIX-L，点仍在拟合线下方。
Decoder里用MPTF替换self-attention，同等预算下CTR/CVR AUC分别+0.05%和+0.02%。mix-token只attend cache、不attend自己，两项各+0.02%。只存最后一层cache相对逐层cache，CTR+0.01%、CVR持平，两条轴深度可以不绑死。Non-parametric Gate-Up-Norm给SwiGLU两路做无参归一化再相乘，CTR+0.02%、CVR+0.01%，激活落在FP16范围内，不再靠SoftCap。value侧gated attention（+0.03%/+0.02%）优于SDPA之后再门控（+0.02%/+0.01%）。QK-Norm再加+0.03%/+0.01%。GQA与多头AUC持平，只省cache。Encoder残差加LayerScale，CTR+0.01%、CVR持平。
HELIX-L在TikTok电商视频推荐全流量A/B，对照仍是RankMixer + Transformer：人均点击+2.0591%，人均GMV+5.9932%，人均成交订单+6.0964%，GPM+5.4624%。
用户侧encoder占比p=0.95、一次请求n=100个候选时，Amdahl公式给出约16.8×理论加速。这是公式值，论文没有给实测serving latency。
场景很具体：超大规模电商视频精排，候选多、行为序列长、用户侧计算必须摊销。已经在跑RankMixer、OneTrans或HSTU家族的团队，可以按这个拆法改：注意力只负责从序列里检索，异构特征交互交给MPTF；用户历史做成单向cache，容量往encoder偏，因为encoder能被M-FALCON和user-level training摊掉。
结论提到同一份cache可以给生成式检索、粗排、精排共用。正文没有跨阶段复用的实验数字。
没有这个流量和这套推理栈的团队，0.2%量级的相对AUC很难外推。这是工业缩放上的渐进改进，不是新任务。
没有独立Limitations节。数字全来自TikTok电商视频内部日志，绝对AUC不披露，无公开数据或代码。Related Work点过InterFormer、Kunlun、HSTU、Ultra HSTU和STCA，实验只打RankMixer和OneTrans，OneTrans还是「发表后优化过的生产实现」，外部无法核对这条对照。
消融单项多在0.01%0.05%。按他们自己的0.03%门槛，一半改动刚好擦线或没过线。缩放律只在HELIX五个点上拟合，RankMixer只有两档，不能当成「联合缩放必然斜率更好」的跨架构证明。16.8×依赖p=0.95；MixFormer因U×C序列依赖候选，这部分摊不掉，真实可摊销比例未必到这个数。
purified说砍了辅助模块，骨干上仍堆了gated attention、QK-Norm、LayerScale、Gate-Up-Norm和GQA。这些是能稳住训练的工程件，和口号里的「只留两件事」并不完全同一回事。HELIX-XXL离线还在涨，上线的是L，更大规格的延迟和稳定性没有报。