多任务学习实战中MMoE已经不够用了聊聊HoME这套层级多门专家架构做推荐、做广告、做搜索的朋友这几年对MMoEMulti-gate Mixture-of-Experts应该都不陌生。它通过多个专家网络和门控网络把多个任务放在一个模型里联合训练省资源、提效果业内落地案例很多。但用久了你会发现一个问题任务一多门控和专家之间容易互相“抢生意”尤其当任务之间相关性不高时负迁移现象防不胜防模型收敛越来越难调。这时候就需要换个思路重新设计专家结构了。最近我仔细研究了一个叫HoMEHierarchy of Multi-Gate Experts for Multi-Task Learning的多任务学习框架。核心思路很直接把单层的专家池改造成层级结构让不同任务先在低层共享通用特征再到高层获取专属信息每一层都配上门控去动态组合。这个设计实测下来在任务数量较多、任务复杂程度差异大的场景里比标准MMoE稳定不少效果提升也比较明显。这篇文章我想把HoME的结构原理、工程实现要点、训练技巧和常见坑位聊一遍内容偏实操向适合已经跑过MMoE、PLE这类模型正想优化多任务效果的团队参考。1. 多任务模型为什么要“加层”从MMoE到HoME的思路演进先说一个我在业务里经常遇到的场景一个信息流推荐系统同时要预测点击率、停留时长、完播率、点赞率、关注率。按业界常规做法这五个目标可以拆成两类——一类是消费行为目标一类是互动行为目标。用MMoE搭这个模型通常的做法是设置8个或16个专家每个任务配一个门控网络门控输出权重对专家做加权求和得到每个任务专属的“专家组合”。这套机制在任务数量少、任务之间比较“和谐”的时候没问题。但任务一多就麻烦了门控对所有专家都有权重两个弱相关的任务可能会抢同一个高容量专家导致某个专家被“拉向”完全不兼容的方向训练时Loss波动很大最终效果甚至不如单任务模型。HoME解决这个问题的思路说白了就是“分层治理”。它不把专家池拍平成一个level而是把整个模型按语义层级拆成若干层。低层专家偏向通用特征比如用户历史行为序列、物品基础属性所有任务共享中高层专家开始分化一部分偏重消费行为建模一部分偏重互动行为建模最顶层则让每个具体任务拥有一组高度特化的专家。每一层之间用门控连接层与层的输出会逐级融合传递。这套设计的内在逻辑跟现实业务是一致的。比如用户对一个视频是否点赞既取决于他是否有消费该视频的意愿低层通用信息也取决于他本身的互动习惯高层专属信息。如果这两类信息在同一个专家池里“混着学”模型很难把“为什么看”和“为什么赞”这两件事同时解释清楚。分层之后每层解决一部分问题压力分摊收敛路径也清晰得多。一个很容易被忽略的点是HoME的层级结构本质上是在模仿人脑的“先共性后特性”处理流程。底层先回答“这个用户是谁、他喜欢什么”高层再回答“在当前场景下他会不会做某个动作”。这种结构对梯度的传播也有好处底层专家的梯度来自所有任务的“合力”相对平滑高层专家的梯度则聚焦在当前任务本身噪声更小。2. HoME结构拆解层级专家、门控机制与信息通路看任何多任务模型第一件事是理解专家、门控和输出信息怎么组织。HoME也不例外但它的组织方式比MMoE多了一个维度。2.1 层级专家和分组逻辑HoME的专家网络不仅在宽度上有每组多少个专家在深度上也有——层数。实际工程里最常见的配置是三层通用层、任务组层、任务层。每一层都由若干组专家构成每组里再放若干个专家网络。通用层Shared Layer通常放4~8个专家输入是原始特征embedding输出作为后续层的“原材料”。这一层的专家容量要大因为所有信息通路都要经过它。任务组层Group Layer按业务语义把任务分簇。比如前文说的消费类目标放一组互动类目标放一组每组配2~4个专家。这一层的专家会在通用特征的基础上继续抽取“组内共性”的信息。任务层Task Layer每个任务独立享有一组专家数量不用多2个左右就够。这一层负责提取“任务专属”信息相当于最后一个特征精炼步骤。这里有个设计细节值得留意前一层输出送进后一层时通常不是“全部拼接”而是带路径权重的。比如通用层的输出对任务组层来说不是平均使用而是由“层间门控”决定哪些任务组对通用信息更依赖。这种设计的好处是模型可以学习出“停留时长预测”比“点赞率预测”更依赖通用消费特征让信息通路的分配更灵活。为什么分组而不是让每个任务都在所有层独立建专家直接分析一下参数量就懂了。假设专家统一用256维隐藏层MMoE里8个专家就是8×2562048维参数空间HoME如果底层8个专家、中层8个、顶层按5个任务各2个专家那就是(8810)×2566656维参数空间看起来参数量增加了但因为不同层承担不同职能实际上每层参数的学习压力反而比单层专家池更小。更重要的是任务之间在低层是“有共享路径”的模型有机会利用共性样本信息。2.2 门控网络的进阶使用不是简单的Softmax加权在MMoE里门控网络就是一个输入特征映射到专家权重的Softmax层。HoME里的门控最关键的变更是多了“层级上下文”作为门控输入。具体来说在任务组层门控的输入至少包含三部分原始特征、通用层的输出、任务组标识的embedding。这个任务组标识embedding是训练中学出来的它告诉门控“当前这个任务组更关注什么”。在任务层门控输入又会加上任务组层的输出。这意味着每一层门控都能感知到上一层已经提炼出的信息而不是完全从原始特征独立计算权重。从梯度角度看这个设计还顺带缓解了门控与专家之间的“死锁”问题——所谓死锁就是某个专家激活度低门控给它更小权重导致它的梯度更新更少权重进一步降低最终这个专家“死掉”的现象。HoME因为层级之间有纵向信息传递就算某个专家在某一层失活上一层的信息还是能通过其他通路到达下一层不至于整条链路失效。门控网络结构的实现上我推荐用两层MLP而不是单层Softmax激活函数在中间层用ReLU输出层用Softmax归一化效果相对稳定。单层Softmax在特征维度高时容易过拟合表现在训练初期门控输出几乎均匀、后期突然“跳变”到某种极端分布很不稳定。2.3 信息融合的几种连接方案层级结构里层与层之间的信息怎么融合直接决定了模型的表达上限。我梳理过三种主流连接方案逐一说说对比。串联式每层输出拼接到下一层的输入信息保留最完整但特征维度会随着层数膨胀训练显存开销大。跳跃式除了逐层传递每层的输出还直接送到最终任务层类似ResNet的skip connection梯度传导更友好但门控的“分层意义”会被稀释。门控融合式HoME通常采用层间输出先过一层门控再与下一层输出加权求和。虽然参数量最多但对不同任务的适用性最好因为它允许模型动态决定“低層通用信息该占多大比重”。我实际测试下来门控融合式在5个任务以上的模型里比串联式稳定在小规模任务场景里串联式性价比更高。所以如果项目初期任务数不多可以先用串联式快速跑通再逐步升级。3. 工程落地与训练实操参数设置、Loss平衡和稳定性结构再好看跑不起来、训不稳定就是在纸上谈兵。这一节我把HoME的工程落地过程拆成几部分从特征输入、模型搭建到训练配置尽量给出可以直接抄作业的参数经验。3.1 多任务模型的数据与特征准备先说数据。多任务模型对样本的要求比单任务模型高得多。如果某些任务的正样本比例太低比如点赞率只有1%对应的任务层专家很容易学不到有效信息。我的建议是进入HoME模型前先对所有任务做一次样本量评估。对于占比低于阈值的任务考虑用“采样降权”的方式来平衡不建议直接调整loss权重因为容易导致其他任务效果大幅回退。特征方面所有任务共用一份底层特征。这里要特别提醒特征交叉的时机非常重要。HoME里特征交叉应该主要发生在通用层内部而不是在任务层再做高维交叉。因为每个任务层专家是任务独立的如果每个任务都做自己的特征交叉不仅计算量线性增长而且违背了“共享底层信息”的初衷。具体操作上输入层通常分成三类特征用户侧特征历史点击序列、兴趣embedding等、物品侧特征ID类、内容属性类、上下文特征时间、场景、设备等。这些特征先做embedding拼接再送入通用层。我自己实验时embedding维度统一取32~64类别特征超过百万的用hash分桶处理低频特征合并到UNK桶里这样通用层的输入维度能控制在一个合理的范围。3.2 损失函数与多任务平衡策略HoME模型的最终损失是各个任务损失的加权和。但“加权”这两个字在工程里有很多学问。常用的做法有固定权重预先按业务重要性给定权重简单直接但调参过程比较痛苦因为5个任务就要调5个权重。不确定性加权用任务的同方差不确定性homoscedastic uncertainty自适应调节loss权重业界用得多在HoME里也可用。动态权重观察各个任务的验证指标按“提升幅度”调整权重。比如某个任务连续几个epoch负向说明可能要降低它的loss权重或者检查是否有任务冲突。我个人经验是HoME模型因为层级结构分化了专家任务之间的冲突比MMoE小所以Loss权重反而不需要太精细地调。先设成均等权重跑起来观察效果再微调。相比权重更重要的是单个任务的loss是否稳定。我建议给每个任务单独记录训练曲线不要只盯总loss——总loss被掩盖掉的任务问题往往就是负迁移开始的地方。3.3 优化器、学习率和Batch配置实测HoME模型参数量比MMoE多对优化器的要求也会稍微敏感一些。我多次测试下来AdaGrad在这个结构里表现不如Adam稳定推荐默认用Adambeta1取0.9beta2取0.999。学习率初始值按Batch大小调整——Batch 1024时初始学习率3e-4比较安全Batch 4096时1e-3也能跑。如果训练过程中出现Loss突刺第一时间不是改学习率而是检查训练数据里是否有异常样本。一个容易忽略的地方是专家网络内部做的Batch Normalization。在MMoE里专家内部加BN有时反而不稳定但在HoME里层间既是层级传递就意味着前一层输出的分布会直接影响后一层门控的学习。我建议至少在通用层和任务组层之间加一层BN或者LayerNorm。实测下来加与不加在5个任务场景里收敛速度差20%左右后期效果也更稳定。专家网络的深度方面通用层专家建议用2层MLPhidden size 128~256任务组层专家1~2层任务层专家1层就够。各专家层最后一层不要接激活函数直接输出向量方便后续门控加权求和。如果加了偏置记得初始化偏置为0。3.4 训练策略分阶段训练与热启动HoME因为底层通用专家承担了大部分信息压缩任务训练初期如果所有层一起随机初始化、同时更新很容易出现底层专家“什么都想学、什么都没学好”的被动局面。我的处理方式很简单分阶段训练。第一阶段只训练通用层和任务组层固定任务层参数让它先把用户基础表征学好。第二阶段放开所有层参数用一个较小的学习率第一阶段学习率的1/5~1/3联合训练。这样做的好处是底层信息表征先稳定下来高层任务层训练时梯度扰动小收敛稳定很多。如果你有历史单任务模型或者MMoE模型可以采用热启动把低层专家、甚至门控的参数直接初始化到HoME里高层任务层从零训练。这种做法的收敛速度很快训练时长可以缩减到冷启动的一半左右效果也不会差。前提是旧模型的特征工程和新模型保持一致否则初始化反而成了负担。4. 坑位与排查多任务模型训练时最常遇到的几类问题不管结构设计得多好训练过程中该踩的坑一个都不会少。这里我把实操中遇到的高频问题整理成速查表并附上我习惯用的排查手段。4.1 某一路任务效果明显变差模型却还能收敛这是多任务模型最磨人的问题。现象是总loss持续下降但某一个任务的AUC或GAUC却在下降。排查步骤我建议这样走先看这个任务的训练loss和验证指标是否同向。如果训练loss还在降验证指标在降优先怀疑过拟合或数据分布不一致。再查它的任务层专家激活值分布查看是否有很多专家输出接近0。如果出现了说明信息通路断了。最后看它对应门控的输出权重分布是否出现大量Softmax权重集中在某一个专家上。如果是就需要检查该专家是否被其他更强任务垄断了。针对这种情况我的调整优先级依次是增大该任务的样本权重、在该任务门控输入里加入更丰富的上层特征、强化该任务层专家的容量增多专家数量或隐藏层维度。三个手段里最有效的通常是第二个因为门控信息不足往往是“任务间通信”失败的根源。4.2 门控坍缩导致专家无效化门控坍缩是指门控网络输出接近one-hot分布几乎所有权重都给了某一个专家其他专家相当于“死了”。在MMoE里就常出现HoME里也不能完全避免尤其在任务组层。原因主要有两类一是某专家初始效果稍好梯度更新更多逐渐形成赢者通吃二是训练样本中某部分特征占主导导致门控“偷懒”。解法有两个方向一个是给门控网络的Softmax加温度参数开始训练时温度大一点让分布更均匀后期再慢慢降低温度另一个最有效就是直接给专家的输出加随机dropout强迫模型不能过度依赖某一个专家。在HoME场景下我个人建议重点在任务层加Dropout因为任务层专家数量本来就少一旦坍缩任务基本就废了。Dropout比例从0.1起步看情况最多加到0.4再高会导致收敛困难。4.3 层级之间出现信号短路HoME结构里低层输出会经过门控融合进入高层。有时候模型会发现一条“捷径”高层直接忽略低层门控完全依赖自己那一层的信息。这会导致底层专家的价值被架空模型退化成多个独立的小模型多任务联合训练的意义就没了。排查方法是可视化低层输出的梯度模长如果训练中后期底层梯度模长远小于高层梯度模长说明低层参数更新幅度很小信号确实被“短路”了。处理方式在门控融合时不给低层输出设置过高初始权重甚至可以让底层输出先经过一个线性变换再接进门控这样模型不能零成本跳过底层信息。以我测试的经验这个“短路”问题在任务间数据分布差异较大时更容易触发。如果事先知道多个任务的数据来源差异很大我会在通用层后增加一个域分离loss约束底层专家的表征在任务间尽量一致避免高层任务走捷径。4.4 训练显存与推理时延的稳定性优化HoME层级专家叠加后参数量和计算量都上去了。训练阶段的显存压力还好主要靠梯度累积和混合精度来解决。推理阶段要特别注意多个专家网络在线性打分链路里是串行的如果不优化时延线上性能会直接崩。我的优化经验是这三个专家剪枝训练完成后统计各层专家的平均激活权重。权重长期低于阈值比如均值的一半以下的专家直接裁剪掉再拟合一个轻量版模型。分组动态路由在线推理时先根据门控输入快速判断需要激活哪几个专家其余专家跳过计算。这个需要把门控网络单独部署一次提前算好专家子集。特征压缩通用层专家输入的原始特征embedding维度如果很大先做一次低维投影再进专家。代价是损失少量底信息但推理时延能减少30%左右。HoME的定位是精度优先的模型如果线上算力很紧张我建议不要全量部署HoME。可以用HoME训练出一个“教师”模型再蒸馏到单层的小模型上精度损失可控。这也算是高精度模型的实际落地思路。5. 效果评估与长期维护除了离线和在线指标还要关注什么做推荐或广告模型的同行都清楚离线指标涨不等于线上收益涨。HoME也不例外它的层级结构让离线AUC提升比较快但线上测试可能会出现“指标翻转”。5.1 多任务模型的评估体系评估多任务模型不能只盯着每个任务的AUC分别看。三个我在生产环境里验证有效的评估维度任务收益矩阵不只看每个任务的指标变化还要看任务间的相关指标。比如点击率涨了但停留时长降了这可能说明模型被“点击任务带偏了”。分组稳定性按用户活跃度、内容类型、时段等维度切分数据看各个分组的指标是否一致地涨。HoME的分层机制在细分组上的表现特别重要如果某个分组指标异常下跌要优先怀疑对应任务组层的门控是否在异常分布上失效了。解释性检查多任务模型不是黑盒。定期抽5~10个样本把门控权重和专家激活值导出做可视化确认模型在“用低层通用信息”还是“套用高层模板”能帮你提前发现结构性问题。5.2 长期迭代中的数据偏差问题多任务模型上线后用户行为和内容生态都在变模型会慢慢衰减。HoME层级结构因为把不同任务的职责拆分得很清楚在遇到数据分布变化时往往表现出“部分老化”的现象——比如通用层信息跟不上新内容形态。应对策略是给每层设置独立的数据保鲜机制。通用层的训练数据可以按时间滑窗采集保证基础表征反映最新用户行为任务组层和任务层的训练数据可以适当延长窗口因为它们的“任务规律”变化相对缓慢。如果发现线上某任务效果突然下跌可以先检查是不是对应任务层的数据分布和周遭环境不匹配。5.3 后续可以怎么扩展HoME的层级结构本身是个开放框架不限于固定的三层。如果你的任务语义层级更丰富比如内容理解、意图识别、行为预估三层结构可以对应增加层级。另一个扩展方向是把HoME的路由机制和AutoML结合让门控网络学习出专家分组结构而不是预设分组关系。如果团队资源充足可以试试把HoME和LLM做融合用大模型产出任务相关性先验结合HoME的轻量级门控路由实现更智能的特征共享与任务协同。这块我们也在探索中初步看来方向是通的但工程复杂度不低适合有算法团队的中大型项目尝试。最后分享一点个人的感受多任务模型这条路很多人一开始都以为“多个任务一起训练总归是省事的”真正上手做之后才发现任务之间的对抗、样本分布的差异、收敛的稳定性每一项都比单任务模型难处理得多。HoME的价值不在于它把MMoE里的专家分层了这么简单而在于它提供了一套“通过结构化解耦多个任务、让模型学会在什么层级共享什么信息”的思路。模型能不能调好关键还是看你对业务任务关系的理解深度。结构给了一个好骨架但让骨架真正学会“先共性后特性”地处理信息还是得靠细致的数据分析和训练调参。这套经验我在多个业务场景里反复验证过照着搭一遍HoME再对比一下MMoE的表现你就能明显感觉到结构化带来的收益了。