多任务学习Multi-Task Learning, MTL在推荐、广告、搜索这些场景里早就不是什么新鲜概念了。但真正在工业级模型里把多任务做好的团队都知道难点从来不在要不要共享底层而在于共享多少、怎么共享、不同任务之间如何不互相拖后腿。HoMEHierarchy 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**给每个任务一套独立参数通过正则项约束参数相似度。参数效率低而且约束强度很难调调大了退化成硬共享调小了等于没共享。**MMoEMulti-gate Mixture-of-Experts**是目前工业界用得最多的方案。它设置若干个专家网络Expert每个任务有自己的门控Gate来决定从各专家那里取多少信息。这个设计确实缓解了任务冲突但 MMoE 有个隐患所有任务共享同一层专家池当任务数量增多、任务之间差异变大时专家池会被拉扯得很难同时满足所有任务门控的区分能力也会下降。**PLEProgressive 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 结构差异对照维度MMoEPLEHoME专家组织单层平铺分层含共享/专属专家多层层次化专家树门控数量每任务一个每任务每层一个每任务每层多个共享粒度单一层共享共享专家专属专家多层级渐进共享任务隔离弱中强参数量低中高调参难度低中高从表里能看出来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 带来的增量反而没那么显著了。所以如果你现在正卡在多任务效果上先别急着换结构回去看看你的数据和标签往往能省下大量时间。 HoME层次化多门控专家：多任务学习共享与隔离的平衡之道
多任务学习Multi-Task Learning, MTL在推荐、广告、搜索这些场景里早就不是什么新鲜概念了。但真正在工业级模型里把多任务做好的团队都知道难点从来不在要不要共享底层而在于共享多少、怎么共享、不同任务之间如何不互相拖后腿。HoMEHierarchy 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**给每个任务一套独立参数通过正则项约束参数相似度。参数效率低而且约束强度很难调调大了退化成硬共享调小了等于没共享。**MMoEMulti-gate Mixture-of-Experts**是目前工业界用得最多的方案。它设置若干个专家网络Expert每个任务有自己的门控Gate来决定从各专家那里取多少信息。这个设计确实缓解了任务冲突但 MMoE 有个隐患所有任务共享同一层专家池当任务数量增多、任务之间差异变大时专家池会被拉扯得很难同时满足所有任务门控的区分能力也会下降。**PLEProgressive 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 结构差异对照维度MMoEPLEHoME专家组织单层平铺分层含共享/专属专家多层层次化专家树门控数量每任务一个每任务每层一个每任务每层多个共享粒度单一层共享共享专家专属专家多层级渐进共享任务隔离弱中强参数量低中高调参难度低中高从表里能看出来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 带来的增量反而没那么显著了。所以如果你现在正卡在多任务效果上先别急着换结构回去看看你的数据和标签往往能省下大量时间。