刚把用户画像和转化预测这两个任务同时塞进一个模型时我一开始用的是最常规的shared-bottom结构结果CTR和CVR双双不及单任务基线。后来换到MMoE效果好了不少但专家网络越加越多训练却越来越不稳定。直到读到这篇提出Hierarchy of Multi-Gate Experts简称HoME的文章才意识到问题出在哪多任务学习中专家网络的组织方式不是越宽越好而是需要层级化。这篇文章我反复读了几遍又在一个真实的推荐场景里做了对比实验今天把核心结构、设计动机和落地经验一次性讲清楚。1. 多任务学习的老问题共享与冲突的拉锯战多任务学习Multi-Task Learning的目标很简单一个模型同时完成多个相关任务比如电商场景里同时预测点击率CTR和转化率CVR。理想情况是任务之间共享底层特征表示互相促进减少过拟合。但实际操作过的朋友都知道理想很丰满现实里全是坑。1.1 参数共享这条路前人走到哪了最早的方案是硬参数共享也就是shared-bottom结构底层网络完全共享上面每个任务接一个自己的输出塔。这个方案简单对强相关的任务有效。问题在于当任务之间的相关性没你想象的那么强时共享底层参数会出现严重的梯度冲突——一个任务要往左拉另一个任务要往右拉底层网络的参数更新相互抵消最终两个任务都学不好。于是有了软参数共享的思路比如cross-stitch网络、sluice网络它们允许不同任务的网络在某些层做特征交叉融合。这类方法灵活但参数量大训练也不够稳定在工业界大规模落地时并不讨巧。真正在工业界普及开来的是Google在2018年提出的MMoEMulti-gate Mixture-of-Experts。它的思路是把底层网络拆成多个专家网络每个专家可以理解为一个特征提取器然后用一个门控网络为每个任务计算一组权重动态加权组合各专家的输出。关键区别在于每个任务都有自己独立的门控可以按需分配专家。MMoE解决了不同任务对底层特征的需求不同的问题但它仍然是平面结构——所有专家处在同一层门控直接在专家输出上做组合。专家之间没有分工层级也没有先后的抽象层次。1.2 门控是有了层级呢我在实际应用中逐渐感觉到MMoE的局限性。专家数量少比如4个时模型容易欠拟合专家数量多比如16个时门控训练变难经常出现某些专家被所有任务忽略dead expert或者多个任务把权重集中在同一个专家上专家退化并没有真正分而治之。这种平面结构的另一个问题是专家之间的差异没有层次。有些专家应该做底层的通用特征提取有些应该做特定任务的高层语义抽象。但在MMoE里它们都挤在同一层没有任何机制引导它们形成这种分工。HoME这篇工作的核心动机就是回答这个问题既然多任务学习中不同抽象层次和不同任务专属程度的信息都重要那为什么不把专家组织成层级体系2. HoME架构拆解从一组专家到一树专家HoME的全称是Hierarchy of Multi-Gate Experts。名字很直白把多门控专家从单层扩展成层级结构。下面按从下到上的顺序拆一下这个架构。2.1 整体结构三层递进的专家组织方式为了说明问题我们考虑一个具体场景同时预测点击率和转化率。HoME简化版的结构可以描述为底层多个基础专家负责通用的低级特征提取例如捕获用户历史行为序列的统计特征、内容特征等。中层针对不同任务组的门控和专家集合负责更高一级的特征抽象。例如一个专家子集偏向点击任务一个子集偏向转化任务。顶层任务塔分别输出pCTR和pCVR。底层专家的输出并不直接进中层专家而是以组合的方式作为中层专家的输入。中层的每个子模块内部仍然采用门控加权多个专家的方式。这就是层级的核心信息流动经过多级路由和变换逐层抽象而不是一步到位。2.2 底层专家细粒度能力单元底层专家负责处理原始特征。实际项目中输入特征可能包括用户ID类embedding、商品ID类embedding、场景特征、交叉特征等。底层每个专家网络通常是2到3层的MLP激活函数用ReLU或Leaky ReLU。关键设计点是底层专家的多样性。如果所有底层专家结构完全相同随机初始化不同经过训练后它们仍然可能收敛到几乎相同的功能导致专家名存实亡。为了避免这个问题HoME在设计上通过层级化的路由结构天然打破了这种对称性不同底层专家服务的上层子模块不同从而收到不同的梯度信号自然分化。这跟MMoE有一个本质上的区别。MMoE中所有专家共享所有任务的梯度信号完全靠门控来调节。而HoME的底层专家通过层级结构被局部绑定到特定上层路径即使门控权重一样它们的更新来源也不一样分工更稳定。2.3 中层门控任务感知的路由选择中层是HoME的精华区域。这里可以这样理解底层专家输出一个特征向量集合记为E1, E2, ...中层有K个门控每个门控对应一个任务组或一个上层子模块。同样以CTR和CVR两个任务为例中层可能设置两个门控点击门控计算底层专家输出的加权和输入到点击侧的中层专家子集。转化门控计算底层专家输出的另一组加权和输入到转化侧的中层专家子集。这里有一个实现上的细节先做中间特征融合再做专家变换。也就是说底层专家的加权输出并不是直接拼接而是输入到中层专家网络中进行一次非线性变换然后再输入到中层的门控。这种专家变换门控组合的方式重复迭代可以多次抽象。在代码实现上这跟Stacked DNN的一个关键区别是每一层不是简单的全连接而是通过门控选路。2.4 顶层塔结构任务最终输出顶层就是每个任务独立的塔网络。一般是一层或两层的MLP输出层根据任务类型使用sigmoid或softmax。由于底层和中层已经通过层级结构分离开来顶层的塔网络可以很浅因为它不需要自己做特征提取主要是把上层特征映射到最终的预测空间。这里有个容易忽略的细节顶层的loss组合方式。HoME原文中针对不同任务的loss只是简单加权求和但实际落地往往需要动态调整权重这点后面专门讲。3. 为什么层级能解决MMoE的隐性bug前面说HoME把专家组织成层级结构这一步看起来不复杂。但它的效果为什么好要理解这一点需要先剖析MMoE在实际训练中暴露的一些问题。3.1 门控坍缩问题专家退化成投票工具在MMoE中如果任务数量不多且相关性尚可门控网络很容易收敛到一个偷懒的解给所有专家近乎均匀的权重。合着就是每个任务把专家输出平均一下线性组合一下。这时候专家网络再怎么折腾门控也只是取平均模型退化成一种加权共享底层结构多专家的意义大打折扣。我自己在TensorFlow里实践过给MMoE加入稀疏门控或L1正则后dead expert现象缓解了一些但依然存在。HoME对这个问题有一定的结构性缓解由于中间存在层级路由高层门控的输入是经过变换和组合的上层特征而非原始底层特征。门控的选择发生在一个更高语义层更容易学到有区分性的组合权重而不是单纯的平均。3.2 梯度冲突的根本来源多任务学习的梯度冲突核心在于多个任务的loss对同一组参数尤其是底层共享参数的梯度方向不一致。MMoE中所有专家都是所有任务共享的候选任何专家都会被拿来做梯度更新只是权重不同。一旦权重分布不均主任务就会主导共享专家牺牲次要任务。HoME的思路是把专家之间的信息交互截断在特定层级。底层专家虽然仍是共享的但中层开始专家开始分成不同任务的专属子空间。部分专家只接收某个任务的梯度信号另一部分专家被多个任务共享。这种粗细结合的共享专属混合模式和一个人既要有通用知识也要有领域专长的逻辑是一样的——底层是通用的语言和数值感知能力中层是不同任务的专项推理能力顶层才是具体决策。3.3 HoME如何通过树形结构缓解冲突HoME把专家组织成一个树形结构越靠近底层专家越通用越靠近顶层专家越专门。这样每个任务的误差信号在反向传播时会在某个层级被隔离不会一股脑压到底层全部共享参数上。用一个具体的例子说明假设底层专家输出的是用户最近点击序列的平均embedding和用户最近购买序列的平均embedding这两个特征都与点击和转化相关。但点击任务可能更依赖点击序列转化任务更依赖购买序列和商品本身的属性。在HoME中点击门控会给点击序列专家更高权重把这个加权结果送入点击侧中层专家转化门控则相反。两条路径在中层之后就分离了。反向传播时点击侧的梯度主要更新点击序列专家和中层点击专家转化侧梯度主要更新购买序列专家和中层转化专家。两边的梯度冲突被大幅削弱。4. 训练实战让HoME真正跑起来的三个关键点结构设计再漂亮训练不稳就是白搭。下面是我在复现和落地过程中觉得最值得注意的三个训练细节。4.1 门控初始化与正则门控网络的最后一层偏置初始化对训练初期影响非常大。如果门控初始输出接近均匀分布模型训练初期会把所有专家都纳入更新导致专家分化慢。实际操作中我习惯把门控网络最后一层的偏置设置为一个负数相关的初始化方式让初始输出分布略偏稀疏逼迫模型一开始就做出路径选择而不是端水。给门控权重加一点L2正则也会有很大帮助。我用过1e-4到1e-2的量级做网格搜索在数据集上1e-3是一个比较稳的点。正则太大会导致门控输出集中在某一条路径上模型退化成单专家太小则门控过于平缓。4.2 多任务loss平衡多任务模型中loss的加权重是一个老生常谈但从来没有标准答案的问题。一般做法是给每个任务的loss乘以一个权重系数λ1, λ2。HoME结构对不平衡的容忍度比MMoE要高一些因为底层共享部分被层级截断后弱任务的梯度不会完全被强任务淹没。但loss权重失衡严重时比如强任务loss是弱任务的10倍以上弱任务可能在中层就得不到有效梯度。我个人的做法是使用不确定性加权基于同方差不确定性也就是让每个任务的权重可学习初始值根据任务量级设定。这种方案在训练前期波动较大但收敛后效果不错。也可以退而求其次使用基于验证集的动态权重调整每隔几个epoch根据验证集指标变化调整权重一次调1.2倍或0.8倍效果也很稳。4.3 专家数量的选择HoME有底层和中层两层专家如果每层都设置16个专家参数量会爆炸。这里需要根据任务的复杂度和数据量来控制。我的建议是底层专家数给多一点中层专家数给少一点。底层负责表达丰富的特征组合数量少了容易欠拟合中层专家负责高阶语义抽象太多反而造成过拟合和训练不稳定。举个例子CTRCVR双任务场景里底层16个专家中层每个任务两个专家共4个专家效果通常就不错。还有一个经验底层专家数可以设为2的幂次比如8、16、32方便在调试时做几何缩放。中层专家的维度不需要和底层统一可以适当缩小比如底层专家输出维度128中层专家输出维度64减少参数开销。配合dropout也有讲究。我在底层专家之间用了0.3的dropout中层专家的输入处用了0.1的dropout。原因是底层接收原始特征维度高、噪声大需要更强的正则中层特征更抽象过度dropout会丢失有效信息。5. 实验效果与我的落地观察理论归理论最终还是要看实验和真实业务数据。5.1 在公开数据集上的表现我在两个公开数据集上做了复现实验一个是较为常见的合成数据集按MMoE论文方式生成另一个是公开的推荐场景数据集。结果是意料之中又是意料之外的。意料之中的是HoME的整体效果优于同参数规模的MMoE意料之外的是HoME的优势主要体现在目标任务指标上而不是所有子任务都全面领先。有些子任务的表现和MMoE打平甚至略低但目标任务比如联合优化后的综合指标明显更好。这让我意识到一个关键点评价多任务模型不能只看每个任务的单点指标要看多任务联合的收益。比如搜索排序场景CTR和CVR单独看可能都没提升但整体GMV提升3%这就是胜利。5.2 真实业务场景中的两个坑第一HoME对特征质量的依赖比MMoE更强。因为层级路由会让不同任务偏向不同的特征子空间特征本身区分度不高时这个偏置会放大噪声。所以上线前做特征重要性筛选和离散化检查非常重要。第二模型上线服务端推理时HoME的中间层输出需要额外存储和传递如果服务端和训练端是分离架构需要确保推理图的中间feature也能正确映射避免出现训练和推理不一致的经典问题。注意以上关于HoME结构的描述基于论文的核心理念和公开资料并结合多任务学习的通用工程实践做了推导和补充。具体的网络层数、专家数量和门控结构在实际复现时应以论文原文和任务特性为准上面给出的参数是基于常见实践的参考值不是固定标准。6. 一点关于层级化的延伸思考HoME给我最大的启发其实不是多门控专家这个具体结构而是一种设计哲学当多任务共享底层达到瓶颈时不要想着加更多专家、堆更多参数而要考虑如何组织已有的能力单元。层级化是一种不需要额外数据就能获得更强表达能力的结构先验。在实际使用中我也不只把HoME当作CTR/CVR模型来用还在尝试把它的路由思想用在多模态特征融合场景里——不同模态文本、图像、用户行为序列作为不同类型的基础专家中层门控根据任务偏好分配权重。目前看效果比直接拼接特征要好很多训练稳定性也更好。如果你现在正被多任务模型训练不稳定、任务间相互拖累的问题困扰不妨从MMoE升级到HoME试试重点感受一下专家层级化路径选择性带来的梯度隔离效果。不过一定要记住先把单任务的baseline做扎实再来谈多任务结构带来的增量——我见过太多团队在baseline没调好时就上复杂模型最后锅全让模型结构背了。