多任务学习实战中，MMoE已经不够用了？聊聊HoME这套层级多门专家架构
做推荐、做广告、做搜索的朋友，这几年对MMoE（Multi-gate Mixture-of-Experts）应该都不陌生。它通过多个专家网络和门控网络，把多个任务放在一个模型里联合训练，省资源、提效果，业内落地案例很多。但用久了你会发现一个问题：任务一多，门控和专家之间容易互相“抢生意”，尤其当任务之间相关性不高时，负迁移现象防不胜防，模型收敛越来越难调。这时候，就需要换个思路重新设计专家结构了。
最近我仔细研究了一个叫HoME（Hierarchy 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×256=2048维参数空间；HoME如果底层8个专家、中层8个、顶层按5个任务各2个专家，那就是(8+8+10)×256=6656维参数空间，看起来参数量增加了，但因为不同层承担不同职能，实际上每层参数的学习压力反而比单层专家池更小。更重要的是，任务之间在低层是“有共享路径”的，模型有机会利用共性样本信息。
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稳定，推荐默认用Adam，beta1取0.9，beta2取0.999。学习率初始值按Batch大小调整——Batch 1024时初始学习率3e-4比较安全，Batch 4096时1e-3也能跑。如果训练过程中出现Loss突刺，第一时间不是改学习率，而是检查训练数据里是否有异常样本。
一个容易忽略的地方是专家网络内部做的Batch Normalization。在MMoE里，专家内部加BN有时反而不稳定；但在HoME里，层间既是层级传递，就意味着前一层输出的分布会直接影响后一层门控的学习。我建议至少在通用层和任务组层之间加一层BN或者LayerNorm。实测下来，加与不加，在5个任务场景里收敛速度差20%左右，后期效果也更稳定。
专家网络的深度方面，通用层专家建议用2层MLP（hidden 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的表现，你就能明显感觉到结构化带来的收益了。
