HoME层次化多门控专家：多任务学习共享与隔离的平衡之道

多任务学习（Multi-Task Learning, MTL）在推荐、广告、搜索这些场景里早就不是什么新鲜概念了。但真正在工业级模型里把多任务做好的团队都知道，难点从来不在"要不要共享底层"，而在于共享多少、怎么共享、不同任务之间如何不互相拖后腿。HoME（Hierarchy of Multi-Gate Experts）这个工作，正是冲着这个核心矛盾去的——它试图用"多门控专家"的层次化结构，在参数共享与任务隔离之间找到一个更优雅的平衡点。如果你正在做多目标预估、多场景排序，或者被"跷跷板效应"折磨过，这篇内容值得你花时间看完。我会从它要解决的问题、核心结构设计、门控机制的原理、实操中的调参经验，以及它和MMoE、PLE这些经典结构的差异几个角度，把HoME拆透。

1. 多任务学习到底卡在哪：从跷跷板效应说起

1.1 共享底层带来的负迁移问题

多任务学习最朴素的动机是：多个任务共享一部分网络参数，让数据量大的任务帮数据量小的任务"带一带"，同时降低整体参数量和过拟合风险。这个逻辑在理论上很漂亮，但落到实际业务里，问题马上就来了。

最典型的就是负迁移（Negative Transfer）。假设你在做一个电商推荐模型，同时预估点击率（CTR）和转化率（CVR）。CTR 更依赖"标题吸不吸引人""主图够不够抓眼"这类浅层特征，而 CVR 更依赖"价格是否合理""评价好不好""详情页信息是否充分"这类深层特征。如果强行让它们共享同一套底层参数，CTR 的梯度会不断把底层往"抓眼球"的方向拉，而 CVR 的梯度又想把底层往"看质量"的方向拉，两边互相打架，最终两个任务都学不好。

这就是所谓的跷跷板效应（Seesaw Phenomenon）：一个任务涨了，另一个任务就掉。很多团队在初期做多任务时都踩过这个坑——上线后发现主目标涨了 0.5%，但辅助目标掉了 2%，算总账反而是亏的。

1.2 现有方案的妥协与局限

为了解决这个问题，业界演化出了几条技术路线，但每条都有自己的妥协。

**硬共享（Hard Sharing）**是最早的做法，所有任务共用底层，只在最后分几个塔。它的优点是参数效率最高，缺点是任务冲突完全无法缓解，跷跷板效应最严重。

**软共享（Soft Sharing）**给每个任务一套独立参数，通过正则项约束参数相似度。参数效率低，而且约束强度很难调，调大了退化成硬共享，调小了等于没共享。

**MMoE（Multi-gate Mixture-of-Experts）**是目前工业界用得最多的方案。它设置若干个专家网络（Expert），每个任务有自己的门控（Gate）来决定从各专家那里取多少信息。这个设计确实缓解了任务冲突，但 MMoE 有个隐患：所有任务共享同一层专家池，当任务数量增多、任务之间差异变大时，专家池会被"拉扯"得很难同时满足所有任务，门控的区分能力也会下降。

**PLE（Progressive Layered Extraction）**在 MMoE 基础上做了改进，把专家分成"任务专属专家"和"共享专家"，并做了多层堆叠，进一步隔离了任务间的干扰。但 PLE 的结构相对固定，共享专家和专属专家的比例需要人工设定，而且层与层之间的信息流动方式比较刚性。

HoME 的出发点，就是在这些方案的基础上，把"专家"和"门控"都做成层次化的，让模型能够自适应地在不同粒度上决定共享与隔离的程度。

2. HoME 的核心结构：层次化多门控专家是怎么搭起来的

2.1 从单层专家池到层次化专家树

理解 HoME 的关键，是先理解它对"专家"这个概念的重新组织。

在 MMoE 里，专家是平铺的——比如 8 个专家排成一层，所有任务的门控都从这 8 个里选。HoME 则把专家组织成层次结构：底层专家负责捕捉更通用、更跨任务的模式，上层专家负责捕捉更细分、更任务相关的模式。这有点像卷积网络里浅层学边缘、深层学语义的思路，只不过这里学的是"任务共性"和"任务特性"。

具体来说，HoME 的专家被分成多个层级（Hierarchy Level）。每一层的专家接收上一层的输出作为输入，并在本层内做进一步的特征变换。底层专家数量多、感受野广，负责提取通用表征；越往上，专家越倾向于服务特定任务或特定任务组合。

这种设计的好处是：任务之间的共享发生在多个抽象层级上，而不是只在最底层共享一次。CTR 和 CVR 可能在底层共享"用户兴趣表征"，在中层分化出"点击偏好"和"转化偏好"，在高层再各自细化。这种渐进式的分化，比一刀切的共享或隔离要自然得多。

2.2 多门控机制：每个任务如何选择专家

HoME 的第二个核心是多门控（Multi-Gate）。每个任务在每一层都有自己的门控网络，用来计算该任务对本层各专家的权重分布。

门控本质上是一个 softmax 层，输入是任务的表征（通常是原始特征经过变换后的向量），输出是长度为"本层专家数"的权重向量。然后该任务的输出就是本层各专家输出的加权和。

这里有个细节值得注意：HoME 的门控不是只在最后一层做一次，而是在每一层都做。这意味着每个任务在每一层都会重新"审视"当前层的专家，决定这一层要吸收哪些信息。这种逐层门控的设计，让任务能够在不同抽象层级上动态调整自己的信息摄取策略。

举个例子，假设有三个任务：CTR、CVR、完播率。在底层，三个任务的门控可能都给出比较均匀的权重，因为底层特征通用性强；到了中层，CTR 的门控可能更偏向"吸引力专家"，CVR 更偏向"信任度专家"，完播率更偏向"内容质量专家"；到了高层，各任务的门控进一步聚焦到自己的专属专家上。整个过程是自适应的，不需要人工指定哪个任务该用哪些专家。

2.3 层次间的信息流动与残差连接

HoME 在层次之间还引入了信息流动机制。每一层的输出不仅传给下一层，还可能通过残差连接直接跳到更后面的层，或者与原始输入做融合。这样做有两个目的：一是缓解深层网络的梯度消失问题，二是保留低层学到的通用信息，避免在逐层抽象中丢失。

从工程实现角度看，残差连接在这里还有一个隐性好处：当某一层的门控学得不好时，残差路径可以作为一个"兜底"，保证信息不会完全断掉。这在训练初期特别重要，因为门控权重刚开始是接近均匀分布的，如果没有残差，深层的信息传递会很不稳定。

3. 门控网络的设计细节与梯度行为

3.1 门控的输入到底该用什么

门控网络的输入选择，是实操中最容易被忽视但影响很大的一个点。常见的选择有三种：

• 用原始特征：门控直接看用户、物品、上下文的原始特征，决定怎么选专家。优点是信息最全，缺点是门控本身要学的映射比较复杂。
• 用共享底层输出：门控看的是底层网络的输出，相当于在已经抽象过的表征上做选择。优点是门控输入维度低、好学，缺点是如果底层被某个任务主导，门控会受偏。
• 用任务专属塔的中间输出：门控看的是任务自己塔的中间层，相当于"任务自己决定要什么"。优点是任务区分度最高，缺点是门控和塔耦合太紧，训练时容易震荡。

HoME 在实践中通常采用混合输入：门控的输入是原始特征经过一个轻量变换后的向量，再拼接上任务 ID 的 embedding。这样既保留了原始信息，又让门控知道"我现在是在为哪个任务做选择"。

3.2 门控权重的温度系数与稀疏化

门控的 softmax 通常会带一个温度系数（Temperature）。温度高，权重分布更均匀，各专家都被激活；温度低，权重分布更尖锐，门控更倾向于"选少数几个专家"。

这个温度系数在训练中怎么设，直接决定了模型的共享程度。温度太高，等于所有专家都被平均使用，退化成硬共享；温度太低，每个任务只用自己的几个专家，退化成独立模型。经验做法是训练初期用较高温度，让专家充分竞争，后期逐步降低温度，让门控收敛到明确的选择。

另外，有些实现会对门控权重做稀疏化约束（比如加 L1 正则，或者用 Top-K 门控），强制每个任务只激活少数专家。这样做的好处是推理时计算量可控，坏处是可能损失一些跨任务共享的机会。是否稀疏化，取决于你的算力预算和任务相关性。

3.3 门控梯度与专家梯度的平衡

多门控结构里，梯度有两条路径：一条通过门控权重回传，一条通过专家输出回传。这两条路径的梯度尺度如果不平衡，会导致训练不稳定。

具体来说，如果门控梯度太大，门控会频繁大幅调整，专家学不到稳定表征；如果专家梯度太大，门控来不及适应，专家会被某些任务"霸占"。HoME 通过梯度裁剪和分层学习率来缓解这个问题——门控网络通常用比专家网络更小的学习率，让门控的变化更平滑。

提示：如果你在复现 HoME 时发现 loss 震荡严重，优先检查门控的学习率是不是设得和专家一样大。把门控学习率降到专家的 0.1~0.3 倍，往往能立刻稳住。

4. HoME 与 MMoE、PLE 的对比：什么时候该选哪个

4.1 结构差异对照

从表里能看出来，HoME 在任务隔离和共享灵活性上最强，但代价是参数量和调参复杂度都上去了。这不是"越复杂越好"的问题，而是要看你的任务差异有多大。

4.2 任务相关性决定选型

我的经验是：任务相关性高、任务数少（2~3 个）时，MMoE 足够用，没必要上 HoME，徒增调参负担。比如 CTR 和 CVR 这种天然相关的任务，MMoE 的门控已经能学到不错的区分。

任务数多（4 个以上）、任务之间差异大时，HoME 的优势才明显。比如一个内容平台同时预估点击、点赞、评论、分享、完播，这几个任务的行为逻辑差异很大，MMoE 的单一专家池很容易被拉扯，这时候层次化专家的价值就体现出来了。

PLE 介于两者之间，适合任务数中等、有一定差异但不想引入太多参数的场景。它的共享/专属专家划分比 MMoE 清晰，又比 HoME 轻量。

4.3 实测中的性能与成本权衡

从公开的实验结果和我的实际复现来看，HoME 在任务差异大的场景下，相比 MMoE 通常能带来主目标 0.3%~0.8% 的相对提升，辅助目标的提升更明显（因为辅助目标往往是之前被主目标压制的那部分）。但这个提升不是白来的——参数量可能增加 50%~100%，训练时间增加 30%~60%，推理延迟也会上升。

所以选型时要算清楚账：如果主目标提升带来的业务收益能覆盖算力成本，就上 HoME；如果算力紧张或者任务差异不大，MMoE 或 PLE 是更务实的选择。

5. 复现 HoME 时的实操要点与踩坑记录

5.1 专家数量和层数怎么定

这是复现时第一个要面对的问题。我的建议是从少到多试：先设 2 层、每层 4 个专家，跑通流程看效果；如果效果不如 MMoE，先别急着加专家，而是检查门控和残差是不是有问题；如果效果略好于 MMoE，再逐步加到 3 层、每层 6~8 个专家。

专家数量不是越多越好。专家太多，每个专家分到的梯度就少，学不充分，反而会引入噪声。而且门控要在更多专家上做 softmax，区分难度也上升。经验值是每层专家数控制在 4~8 个，层数控制在 2~3 层，超过这个范围收益递减明显。

5.2 训练不稳定的常见原因

HoME 训练不稳定，通常有这几个原因：

• 门控学习率过大：前面说过，门控学习率应该是专家的 0.1~0.3 倍。
• 缺少 warm-up：训练初期专家还没学好，门控就开始做选择，容易选错。建议前几个 epoch 固定门控为均匀分布，让专家先充分学习。
• 残差路径被门控覆盖：如果残差权重也是可学的，初期可能被学成接近 0，导致信息断流。建议残差权重初始化为 1，或者干脆用固定权重的残差。
• batch size 太小：多门控结构对 batch 内的梯度估计比较敏感，batch 太小会让门控权重抖动。建议 batch size 不低于 1024。

5.3 线上推理的性能优化

HoME 的推理成本主要来自专家计算和门控计算。优化思路有几个：

• 专家剪枝：训练完后，把门控权重长期接近 0 的专家剪掉，减少推理计算。
• 门控缓存：如果门控输入中用户特征变化不频繁，可以缓存门控权重，避免每次推理都重算。
• 专家共享计算：同一层内，如果多个任务的门控都激活了同一个专家，这个专家只需要算一次，输出给多个任务复用。这个优化在实现时要注意，别写成每个任务各算一遍。

注意：专家共享计算虽然省算力，但会改变梯度回传的路径（一个专家收到多个任务的梯度），训练和推理的行为要一致，否则会出现训练推理不一致的问题。

6. 从 HoME 延伸出去：多任务结构的演进思路

HoME 代表了一种思路：用层次化结构来管理任务间的共享与隔离。这个思路其实可以往几个方向延伸。

一是动态层次。HoME 的层次是预先定好的，能不能让模型自己决定要几层、每层几个专家？这涉及到网络结构搜索（NAS）和多任务学习的结合，目前有一些探索，但工程落地还比较难。

二是任务关系的显式建模。HoME 的门控是隐式学习任务关系的，能不能显式地建模"任务 A 和任务 B 更相关，应该多共享"？这可以用任务 embedding 之间的注意力来实现，让门控不仅看自己的任务，还看其他任务的状态。

三是与序列建模的结合。现在的多任务模型大多处理的是静态特征，如果任务本身有时序依赖（比如用户行为序列上的多任务），HoME 的层次化专家能不能和 Transformer 之类的序列结构结合？这是一个比较有前景的方向。

从工程角度看，我的建议是：别一上来就追求最新最复杂的结构。先把 MMoE 跑稳，理解清楚你的任务之间到底是怎么互相影响的，再决定要不要上 HoME。很多时候，问题不在结构不够复杂，而在于特征工程没做好、样本权重没调对、任务定义本身就有问题。结构只是最后那 10% 的优化，前面 90% 的功夫在数据和特征上。

我在实际项目里踩过的最大的坑，就是过早引入了复杂结构，结果调了两周发现效果还不如老老实实调特征。后来复盘才明白，当时任务之间的冲突其实主要来自样本空间的重叠和标签定义的不一致，跟网络结构关系不大。把样本和标签理顺之后，再用 MMoE 就已经拿到了大部分收益，HoME 带来的增量反而没那么显著了。所以如果你现在正卡在多任务效果上，先别急着换结构，回去看看你的数据和标签，往往能省下大量时间。