在推荐系统这块摸爬滚打这么多年我很少见到一个技术架构能在发布后短时间内引起这么大范围讨论HSTU算一个。HSTU全称是Hierarchical Sparse Transformer Unit中文可以理解为“层次化稀疏Transformer单元”它来自一篇关于生成式推荐系统的公开论文核心思路是把用户行为序列直接当作“语言”来建模用下一代内容预测的方式统一处理推荐、广告、搜索里的排序问题。这个方向确实戳中了很多从业者的痛点。我们过去做推荐模型通常要拼特征工程、拼模型结构、拼多目标loss最后线上还得靠一堆规则和粗排精排的复杂链路兜底。HSTU的出现相当于把一整条链路重新捋了一遍如果用户行为本身就能自监督训练能不能用一个统一的序列模型替换掉大部分人工设计的环节这篇文章不谈虚的直接聊聊HSTU到底改了什么、为什么这么改以及如果你想落地这套思路有哪些值得注意的细节。1. 推荐系统里的“老毛病”与HSTU的解题视角1.1 传统推荐模型为什么越做越重如果你做过几年推荐或者广告排序模型一定对这套组合拳很熟用户侧特征搞一个embedding物品侧特征搞一个embedding两侧交叉以后接MLP或者Attention最后用logloss训练一个打分模型。看起来没什么问题但实际工程里你会遇到几个绕不开的坎。第一个坎是特征体系越来越庞大。一个典型的信息流推荐场景用户侧的特征可能有几百个年龄、性别、城市、历史点击类目、活跃时段、长期兴趣embedding等等。物品侧就更夸张图文、视频、商品、短内容都有不同的属性字段你想统一建模只能疯狂做特征对齐和字段映射。第二个坎是用户行为序列的长度。一个活跃用户一天能产生上千次曝光点击行为把这些行为全部塞进模型序列长度动辄几千甚至上万。Transformer虽然能处理序列但标准注意力是二次复杂度序列一长训练和推理都扛不住。第三个坎是多目标与多场景的割裂。点赞、完播、转发、关注、下单每个目标可能都要单独建模信息流、搜索、详情页推荐又各搞一套模型最后系统变成了一个堆满“补丁”的大泥球。1.2 HSTU为什么选择生成式范式HSTU最核心的转变是把推荐问题重新定义成一个“序列转导”问题。通俗点说过去我们是让模型学会“判断用户喜不喜欢这个物品”现在我们是让模型学会“预测用户下一个会交互什么物品”。这个思路借鉴了语言模型的建模方式语言模型会预测下一个token是什么推荐模型则预测用户的下一个行为item是什么。这个转变听起来只是loss函数换了一下但实际影响非常大。因为“预测下一个行为”可以做到完全自监督训练数据不再需要大量人工标注用户真实的行为序列本身就是监督信号。同时生成式框架天然支持多任务你可以在预测下一个item的同时额外预测这个item的点击率、完播率、是否点赞所有任务共享同一个骨干网络不再需要为每个目标单独搭一套模型。最后生成式框架还能天然处理多模态内容物品的文本描述、封面图、视频帧都可以作为输入的一部分和用户行为序列一起联合建模。1.3 这个方案在一线业务里的价值我从工程落地角度来说HSTU真正的价值不在于某一个模型的指标涨了多少而在于它提供了“一套架构吃下所有场景”的可能性。论文里提出了支持十亿参数以上、序列长度达到上万级别的训练方案并且通过专门的算子和优化策略把训练吞吐压到非常可观的水平。对业务团队来说这意味着你不用再维护十几个模型、几十张特征表而是一个大规模的序列模型喂进去不同场景的数据就能适配不同业务。当然这不是说HSTU直接就能部署到线上它还有工程改造的门槛。但方向是对的尤其对于用户行为稠密的业务场景这种“行为即语言”的思路确实比堆特征有效得多。2. HSTU的核心技术设计拆解2.1 从标准Transformer到序列转导器HSTU不是一个普通的Transformer变体它更像是一个专门为推荐场景重新设计的序列转导器。标准的Transformer Encoder接收的输入是一个token序列每个token是一个向量然后通过多头注意力建模token之间的关系。HSTU的输入则是一段用户行为序列每个位置对应一个用户交互过的物品同时这个位置还携带了额外的特征信息比如行为类型点击、点赞、购买、行为发生的时间、物品本身的属性embedding。这里有个关键设计HSTU把所有信息都融合到了序列的token表示里而不是像传统推荐模型那样把特征分成用户侧、物品侧、交叉特征侧。论文里用了一个“特征指纹化”的思路把离散特征、连续特征、甚至文本向量都映射到同一个向量空间再拼接到token上。这样一来模型不再区分什么是用户特征、什么是物品特征它只关心序列中不同位置的token如何相互影响。你可以理解为语言模型里的token是词HSTU里的token是“用户在某个时间点做了某个行为”整个序列就是一份“用户行为的语言文本”。模型要学的就是这份文本的语法和语义。2.2 层次化稀疏注意力解决长序列的效率问题推荐场景的行为序列真的太长了动辄上千甚至上万。标准Transformer的注意力机制是O(n^2)的复杂度n是一万的时候单层就要上亿次交互计算这谁也扛不住。HSTU的解法是“层次化稀疏注意力”也就是把长序列切成多个局部窗口窗口内部做完整的密集注意力窗口之间只保留少量稀疏连接。这个设计有个很容易理解的生活类比你读一本书的时候对相邻几页的内容记得最清楚对前面的章节只会偶尔回忆一下而不会每读一页都把整本书重新想一遍。HSTU的注意力也是这样在局部窗口内模型充分建模相邻行为之间的关联比如用户连续看了几个科技视频这个局部信号非常强在窗口之间模型只保留少量用来传递长期信息的连接保证用户一个月前的兴趣偏好还能影响到现在的推荐但不需要对所有历史行为都做一次完全匹配。这样做的好处是复杂度从O(n^2)降到了接近O(n)序列长度可以支持到上万甚至更高。实际落地的时候窗口大小、稀疏连接的比例都是需要调的超参论文里给了一些经验值但具体业务还得自己测。我个人的体会是窗口大小和内容类型有很强的关系短视频场景的用户行为连续性比较强窗口可以适当大一些电商场景用户的行为跳跃性大窗口小一点反而更稳。2.3 相对位置编码与行为顺序建模序列建模必须处理顺序信息。HSTU在位置编码上用了相对位置编码而且和稀疏注意力做了深度结合。每个token只和窗口内的其他token计算相对位置偏移这样模型能够感知行为之间的间隔用户刚看完一个视频就点赞和看完十分钟后点赞这个时间差对行为意图的判断是完全不同的。这个设计还有一层用意相对位置编码对序列长度天然友好。如果使用绝对位置编码训练时见过的最大长度就锁死了线上推理的长度一旦线上序列比训练时长效果会断崖式下跌。相对位置编码没有这个问题因为模型学的不是“第100个位置是什么”而是“两个行为之间隔了多远”。有朋友可能问行为发生的时间间隔怎么处理HSTU的做法是把时间间隔也做离散化变成一个特征拼进token里。比如一个行为发生在当前行为前1分钟、10分钟、1小时、1天分别编码成不同的embedding。这个细节很实用因为用户的长短期兴趣确实存在完全不同的时间尺度。2.4 训练稳定性与多任务建模生成式推荐框架的另一个难点是训练稳定性。语言模型预测下一个词相对简单因为词表是固定的推荐场景预测下一个itemitem的规模可能是几十亿直接做成分类任务参数规模爆炸。HSTU采用的方式是负采样加多任务联合从全量item池子里随机采样一部分负样本同时用点击、点赞、完播等多个行为作为辅助loss帮助模型在早期更快收敛。多任务这块我多说几句。很多团队自己做多目标模型时经常会遇到“跷跷板”问题优化点击率的时候完播率掉下去反之亦然。HSTU的做法是让多个任务共享同一个序列编码器只在最后一层分出不同的预测头。序列编码器学到的是“用户对内容的理解”这部分是所有任务共用的理论上不会出现某个任务带偏编码器核心表示的问题。当然实际调loss权重还是需要花时间的权重比设得不好照样会出现偏科。3. 如果我想落地HSTU应该从哪里开始3.1 确认场景是否适合HSTU不是什么场景都能无脑上的。我的判断标准很简单用户行为是不是足够稠密行为是不是有强序列相关性。信息流推荐、短视频推荐、电商的“猜你喜欢”这类场景非常合适但如果你是做新用户冷启动、或者用户行为极其稀疏的B端推荐HSTU的优势发挥不出来反而不如传统模型。另外还有一个容易被忽略的点你的业务是否真的需要那么长的序列。如果内部实验显示用户最近的10次行为就能决定90%的推荐效果那强行上HSTU纯属浪费算力。我见过有人把序列从200拉到2000效果涨了0.1%训练成本翻了好几倍完全得不偿失。先用数据分析用户行为序列的有效长度区间再决定要不要上长序列模型。3.2 数据层面的改造落地HSTU第一个要改的是数据处理流程。传统推荐样本是一行一个“(用户, 物品, 标签)”HSTU要变成一段一个“用户行为序列”把同一个用户的行为按时间排序切成定长的segment每个segment作为一个训练样本。这里面有一些细节需要处理行为类型要不要区分我建议保留点击、点赞、购买、转发是不同类型的行为它们的语义权重不一样。给每种行为类型分配一个类型embedding拼到行为token里。序列中的正样本怎么定义HSTU是预测下一个行为item所以序列里每个位置的“标签”其实是下一个位置的item。训练时用掩码遮住当前位置之后的token让模型根据历史预测下一个item。稀疏特征和稠密特征怎么融合论文的做法是全部映射成embedding再拼接但实际业务中有些特征特别多比如item ID有些特征特别少比如用户等级。建议把高基数特征单独做一个embedding lookup低基数特征直接拼接不要让所有特征都堆在一个token里否则embedding矩阵会大到吓人。3.3 一个简化版训练配置参考如果你打算用HSTU的思路跑一个最小可行版本我基于公开信息和个人实践经验给你一个参考配置。这个配置不保证效果最优但足够让你把流程跑通观察模型行为和线上效果变化。配置项推荐值备注最大序列长度1024~2048根据显存和线上推理耗时调整局部窗口大小64~128行为稠密场景取大值稀疏场景取小值Transformer层数4~6层先小后大优先保证训练稳定注意力头数8~16头数太多小模型容易过拟合隐藏层维度256~512和特征规模强相关训练batch size64~256序列长的时候batch减小优化器AdamW权重衰减建议1e-4起步学习率1e-4~3e-4配合warmup前1000步线性上升负样本数64~256从全量item里均匀采样多任务权重主任务1.0辅助各0.1~0.3先以点击为主再逐步加目标这个配置跑起来之后我建议先盯着两个指标训练loss的收敛曲线以及验证集上的next-item预测准确率。如果loss掉不下来先检查数据是否有问题如果准确率上去了但线上效果不行大概率是序列构建方式和线上serving不一致后面会专门讲这个问题。3.4 线上serving的工程改造训练和线上推理不一致是这类模型最容易翻车的地方。离线阶段你很容易取到用户完整的历史行为但线上serving的时候用户发生一个新行为你需要以极低延迟拿到更新后的行为序列然后喂给模型推理。如果serving链路里用户行为更新有延迟线下线上效果就会对不上。实操层面我建议为HSTU单独做一个“序列实时拼接服务”用户每次行为事件通过消息队列实时写入一个高速存储serving时按用户ID取最近N条行为再和候选物品一起组装成模型输入。这个链路听起来简单但细节很多行为去重怎么做、过期行为怎么淘汰、序列长度超出上限怎么截断、截断时是保头部还是保尾部。我的经验是行为的截断策略对效果影响很大通常保尾部效果更好因为最近的兴趣信号最能反映用户当前状态但头部少量长稳兴趣也可以保留这就要靠你的层次化稀疏注意力来覆盖跨窗口连接了。4. 常见问题与排查心得4.1 稀疏注意力之后效果反而下降了我遇到过几次这种情况把标准注意力替换成层次化稀疏注意力之后离线AUC轻微下降这是正常的因为模型容量被压缩了。但如果下降特别明显比如掉了三五个点那大概率是稀疏连接的设计不合理。检查两个地方一是窗口大小是不是太小导致模型完全无法建模跨窗口的长期依赖二是窗口之间保留的稀疏连接是不是过于随机建议优先保留“行为时间相邻但属不同窗口”的连接而不是随机挑几个连接。4.2 长序列训练时内存爆炸序列长度上万的时候即使用了稀疏注意力激活值仍然会占用非常大的显存。这时候不要硬扛可以用序列切分加梯度累积把一个长样本切成多段分段计算梯度累加后再统一更新参数。另一种做法是降低batch size但要注意梯度噪声会变大必要时同步增大学习率来补偿。还有一个容易被忽略的点位置编码矩阵会随序列长度平方级增长如果用的是相对位置编码可以考虑提前截断位置差的最大范围比如最多只建模±128的行为间隔超过的部分统一编码成“很远”。4.3 离线指标涨了线上A/B效果平平这个问题很多人会碰到。HSTU离线指标涨说明模型确实学到了用户行为序列中的有效模式但线上效果没跟上问题往往出在serving一致性上。最常见的有三点一是线上没有拿到用户的实时行为导致序列停留在几分钟甚至几小时前二是线上的候选集和离线训练时的采样分布不一致三是离线训练时用了未来信息比如用整个session的目标来计算loss但线上推理时未来的行为还没发生。我的排查顺序是先核对线上拼接的序列和离线样本的序列分布是否一致再检查负采样的分布最后确认时间戳对齐。4.4 多任务loss互相拉扯辅助loss太多有时候会出现主任务效果被拖垮的情况。这不是HSTU特有的问题而是多任务学习的通病。我的处理方式分三步第一步先只训主任务把序列编码器训到一个合理的基准线第二步逐个加上辅助任务每次只加一个观察主任务指标的变化第三步如果某个辅助任务始终让主任务掉点就把它从loss里去掉不要执着于一定要多任务。记住一点多任务是手段不是目的。5. HSTU对整个推荐技术体系的影响5.1 从“特征工程为中心”转向“序列建模为中心”HSTU最深远的影响我认为是改变了推荐系统从业者的思考方式。过去大家默认推荐模型的好坏取决于特征工程做得好不好谁的特征细、谁的特征全谁的效果就好。HSTU给出了一条不同的路特征不需要太多人工设计用户行为序列本身就是一个极富信息的“文本”关键是怎么把它读透。这个转向的好处是能大幅降低人工成本。你不再需要花费大量人力去分析和构造交叉特征而是把精力花在怎么构建干净、完整、实时的用户行为序列上。对于中小团队来说这可能是一个翻身的机会你不需要拥有最多的特征只需要把序列数据整理得足够好。5.2 对广告和搜索领域的潜在影响推荐场景里HSTU验证有效广告和搜索领域大概率也能借鉴但需要做适配。广告场景最大的不同是存在广告主预算、出价等因素用户的兴趣和广告内容之间的匹配只是排序的一部分你还需要考虑商业化目标。HSTU可以在创意理解的部分发挥作用也就是用序列模型理解“用户最近对什么类型的广告创意更感兴趣”但最终排序还是得结合预算和竞价。搜索场景用户行为序列的特点是带有明确的意图信号用户搜了一个query然后点击了某个结果这个序列比纯推荐的兴趣序列更稀疏但也更强烈。用HSTU建模搜索session内外的行为有可能提升对搜索意图的理解特别是在长尾query上效果可能更明显。5.3 什么场景不建议跟风上HSTU我也要给朋友们泼点冷水。如果你的业务符合下面任一情况现阶段我建议再等等第一用户行为极度稀疏平均每人每天只有几次交互序列建模完全喂不饱第二业务实时性要求极高且基础设施薄弱连实时行为收集的管道都没有谈何序列建模第三团队对Transformer的训练和serving经验不足贸然上HSTU只会变成一场灾难。技术选型的核心永远是匹配自身阶段和资源不要因为一个大模型架构火了就强行套到自己头上。我个人在实际操作中的体会是HSTU这种生成式推荐架构最大的门槛不在模型本身而在于工程体系的整体升级。你需要保证行为数据的实时性、序列存储的稳定性、线上推理的低延迟以及一套能支撑长序列训练的算力底座。这些都不是看几篇论文就能解决的需要一步一个脚印地踩坑、调参、验证。但如果这条路走通了你得到的不仅是一个效果更好的模型更是一个能持续自适应业务演进的推荐系统底座。这个方向后续的空间还很大值得持续跟进。