想象你经营一家生意火爆的餐厅。客人既要上菜快，又要味道好，还要摆盘精致——这就像推荐系统要同时预测点击率、互动率和观看时长。一开始，你让所有厨师共用一套备菜流程，结果为了快就牺牲了味道；于是你请来炒锅、炖汤、面点三位专精师傅，每类菜品由主厨按需“点将”组合师傅协作，这就是 MMoE 的核心思想；再后来，你把后厨按热菜、凉菜、甜品分层，让师傅们在层内渐进式协作，把“好心帮倒忙”的干扰彻底隔离，这就是 PLE 的进阶之道。这篇文章带你从 Shared Bottom 走到 MMoE 再走到 PLE，把多任务学习这门“后厨管理学”彻底捋清楚。

岗位关联

多任务模型是推荐、广告、搜索系统的标配，掌握 MMoE 与 PLE 的演进逻辑，能帮你直接提升多目标模型的离线指标与线上收益，是算法工程师进阶的必备能力。

目录
  1. 可视化演示
  2. 多任务困境：为什么同一个模型难伺候多种需求
  3. 硬共享基线：所有人共用一套菜谱
  4. MMoE架构：请几位专精师傅分头接单
  5. 门控机制：主厨如何拍板
  6. PLE演进：把后厨分层，渐进隔离干扰
  7. 落地上线：推荐系统里怎么用
  8. 专家调优：后厨请几位师傅最合适
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

交互展示Shared Bottom到MMoE多门控专家再到PLE分层抽取的架构演进，可视化任务冲突消除机制与门控权重分配。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Shared Bottom共享底层 所有任务共享同一底层网络参数 任务间梯度冲突导致负迁移 y\u1d62 = f(x; \u03b8_shared) 共享参数导致任务间互相干扰，难以同时优化

多任务困境：为什么同一个模型难伺候多种需求

开餐厅最怕什么？最怕客人既要上菜快，又要味道好，还要摆盘漂亮。你催着炒锅师傅快点儿颠勺，口味就淡了；你让师傅多花十分钟摆盘，翻台率就掉了。这三条需求互相拖着后腿，就像推荐系统里同时优化点击率、互动率和观看时长——你推高一个指标，另一个往往往下掉，这就是多任务学习里最出名的“跷跷板效应”。

在深度学习里，多任务学习是指用同一个模型同时预测多个目标：比如视频推荐要预测“用户会不会点”和“用户会不会看完”。最朴素的做法是让两个任务拼一个损失函数一起训练。可一旦任务之间相关性不够强，任务 A 学到的规律反而会污染任务 B，这种现象叫“负迁移”。

多任务的目标通常是各任务损失的加权和：

这就像你给三位主厨各定一个“考核 KPI”：速度、口味、颜值，加在一起算总绩效。问题在于：三位主厨用的是同一个备菜间、同一套食材和刀具。为了速度把菜切得粗糙，摆盘再好看也救不回来——任务之间共享的东西越多，互相拖后腿的概率就越大。那该怎么办？要么给不同任务配不同的后厨班子，要么把后厨按需求分层。这正是后面 MMoE 和 PLE 要解决的事。

Ltotal=∑k=1Kwk Lk(θ)\displaystyle \mathcal{L}_{\text{total}} = \sum_{k=1}^{K} w_k \, \mathcal{L}_k(\theta)
这个公式说：总损失 = 每个任务的损失乘以各自的权重再相加。K 是任务个数，w_k 是第 k 个任务的重要程度，θ 是所有共享的参数。权重怎么定、参数怎么被各类任务拉扯，决定了负迁移的严重程度。
  1. 任务总个数 KK 表示模型要同时优化的任务数，比如同时优化点击率和互动率时 K = 2。
    K∈N+,K≥2\displaystyle K \in \mathbb{N}^{+}, \quad K \ge 2
  2. 任务权重 w_kw_k 控制第 k 个任务在总损失中的话语权，权重越大，优化时越偏向该任务。
    wk>0,∑k=1Kwk=1\displaystyle w_k > 0, \quad \sum_{k=1}^{K} w_k = 1
  3. 各任务损失 L_kL_k(θ) 是第 k 个任务在共享参数 θ 下的损失，分类任务通常用交叉熵。
    Lk(θ)=−1N∑i=1N[yilog⁡pi+(1−yi)log⁡(1−pi)]\displaystyle \mathcal{L}_k(\theta) = -\frac{1}{N} \sum_{i=1}^{N} \big[ y_i \log p_i + (1 - y_i) \log(1 - p_i) \big]
  4. 加权求和把所有任务的损失按权重加起来，得到一个标量，反向传播时就靠它更新所有共享参数。
    Ltotal=w1L1+w2L2+⋯+wKLK\displaystyle \mathcal{L}_{\text{total}} = w_1 \mathcal{L}_1 + w_2 \mathcal{L}_2 + \cdots + w_K \mathcal{L}_K

硬共享基线：所有人共用一套菜谱

最简单的多任务做法，就像一家餐厅所有厨师共用一张基础菜谱：洗切、焯水、调底味全在一个“共享底层”里完成，每个任务再配上自己专属的“出锅窗口”。这就是许多公司起步时用的 Shared Bottom 结构。

技术上，Shared Bottom 是所有任务共用一个底层网络 f，输入 x 先经过它得到通用表征，然后每个任务接一个自己的“塔”（小网络）输出预测。因为底层参数被所有任务强制共享，所以任务越多、差异越大，底层的梯度越容易被不同任务“拔河”。

回到餐厅：Shared Bottom 就像所有菜都在一个备菜间里切配，优点是省人省地，缺点是川菜师傅嫌备菜切太粗，粤菜师傅又嫌焯水过了头。一旦两类客人口味差得远，这套“中央厨房”就成了互相掣肘的地方。于是，我们要引入专家分工。

y^k=gk(f(x;θs);θk),k=1,2,…,K\displaystyle \hat{y}_k = g_k\left( f(x; \theta_s) ; \theta_k \right), \quad k = 1, 2, \dots, K
f 是共享底层，θ_s 是它的参数；g_k 是第 k 个任务的塔，θ_k 是塔自己的参数。输入 x 先进共享底层，再由各自的塔输出预测 ŷ_k。
  1. 共享底层 ff(x; θ_s) 把原始特征 x 映射成通用表征，对所有任务可见，所有任务共用这一套参数。
    h=f(x;θs),h∈Rdh\displaystyle h = f(x; \theta_s), \quad h \in \mathbb{R}^{d_h}
  2. 任务塔 g_kg_k 把共享表征 h 进一步加工成第 k 个任务的预测，塔的参数只属于自己。
    y^k=gk(h;θk)\displaystyle \hat{y}_k = g_k(h; \theta_k)
  3. 参数划分整个模型的参数被分成共享部分 θ_s 和各任务私有部分 θ_k，共享部分越大，任务之间的相互影响越大。
    θ={θs,θ1,θ2,…,θK}\displaystyle \theta = \{ \theta_s, \theta_1, \theta_2, \dots, \theta_K \}

MMoE架构：请几位专精师傅分头接单

既然共用一套菜谱不行，那就请几位专精师傅：炒锅师傅、炖汤师傅、面点师傅。每道菜出锅前，主厨按这道菜的需求决定“炒锅七分、炖汤三分、面点不叫”，让几位师傅按比例配合。这就是 MMoE（Multi-gate Mixture-of-Experts）的核心思想。

MMoE 用 n 个专家网络 f₁, f₂, ……, fₙ 取代单一共享底层。这些专家各有各的参数，相当于各有所长的师傅。每个任务 k 都有一个自己的“门控” g_k，负责把几个专家的输出按权重混合起来，再送进任务塔。

餐厅里，这一步是从“中央厨房”升级成“专家排班”：炒锅、炖汤、面点师傅随时待命，每类菜的主厨（门控）根据客人的点单动态调配师傅组合。川菜主厨多叫炒锅师傅，粤菜主厨多叫炖汤师傅——任务各取所需，专家共享但不再被强行捆绑。这正是 MMoE 化解“拔河”的秘密。

y^k=hk(∑i=1ngk(x)i⋅fi(x))\displaystyle \hat{y}_k = h_k\left( \sum_{i=1}^{n} g_k(x)_i \cdot f_i(x) \right)
第 k 个任务的输入先被每个专家 f_i 各加工一遍，门控 g_k(x) 给出一个权重向量，把专家输出加权求和，最后过任务塔 h_k 得到预测。权重越大，说明这个任务越依赖那位“师傅”。
  1. n 个专家n 表示专家数量，每个专家 f_i 都是一个独立的小网络，参数互不相同。
    {f1,f2,…,fn},fi:Rdin→Rdmid\displaystyle \{ f_1, f_2, \dots, f_n \}, \quad f_i : \mathbb{R}^{d_{\text{in}}} \to \mathbb{R}^{d_{\text{mid}}}
  2. 门控权重 g_k(x)_i第 k 个任务分配给第 i 个专家的权重，由输入 x 动态决定，相当于主厨看单点将。
    0≤gk(x)i≤1,∑i=1ngk(x)i=1\displaystyle 0 \le g_k(x)_i \le 1, \quad \sum_{i=1}^{n} g_k(x)_i = 1
  3. 加权求和先对专家输出加权相加，生成任务专属的融合表征 e_k。
    ek=∑i=1ngk(x)i⋅fi(x)\displaystyle e_k = \sum_{i=1}^{n} g_k(x)_i \cdot f_i(x)
  4. 任务塔 h_k融合后的表征经 h_k 输出该任务的预测，塔的参数按任务独立训练。
    y^k=hk(ek)\displaystyle \hat{y}_k = h_k(e_k)

门控机制：主厨如何拍板

门控在 MMoE 里就像每类菜的主厨：他看一眼点单（输入 x），心里立刻有数——这道菜该请哪几位师傅、各占多少比例。门控不是写死的规则，而是个能学习的网络，训练时会自动调出最适合任务的一组配方。

最常见的门控是一个线性层接 softmax：把输入 x 映射成 n 个专家得分，再归一化成概率。这样输出非负且和为 1，天然适合做“权重分配”。

这道“拍板”动作让每个任务都拥有自己的组合配方，而不需要把所有任务拉到同一张桌前吵架。主厨（门控）只看点单（输入）就能动态调配，这就是门控机制既温柔又强大的地方。

gk(x)i=exp⁡(wgk,i⊤x)∑j=1nexp⁡(wgk,j⊤x)\displaystyle g_k(x)_i = \frac{\exp(w_{gk,i}^{\top} x)}{\sum_{j=1}^{n} \exp(w_{gk,j}^{\top} x)}
门控先给每个专家打一个分（w_{gk,i} 与 x 的点积），再用 softmax 把得分变成和为 1 的权重。哪个专家对当前输入最有利，它的权重就越大。
  1. 打分用第 k 个任务门控矩阵 W_{gk} 的第 i 行 w_{gk,i} 与输入 x 做点积，得到第 i 个专家的原始得分。
    si=wgk,i⊤x\displaystyle s_i = w_{gk,i}^{\top} x
  2. 指数化用 exp 把所有得分变成正数，避免出现负权重，同时放大得分差距。
    ei=exp⁡(si)\displaystyle e_i = \exp(s_i)
  3. 归一化除以所有指数得分之和，使所有权重加总等于 1，形成概率分布。
    gk(x)i=ei∑j=1nej\displaystyle g_k(x)_i = \frac{e_i}{\sum_{j=1}^{n} e_j}

PLE演进：把后厨分层，渐进隔离干扰

MMoE 已经能按需点将，但仔细观察会发现：所有任务都在抢同一批专家，口味相近的任务还好，口味完全相反的任务（比如“出餐快”和“摆盘精致”）还是会互相拉扯。于是工程师们想：不如把后厨按菜系分层，让任务在“层”之间渐进式地分开——这就是 PLE（Progressive Layered Extraction）的由来。

PLE 的前身是 CGC（Customized Gate Control）：每一层里既有“任务专属专家”，也有“共享专家”。任务专属专家只服务自己的任务，共享专家负责吸收任务之间的共同规律。门控在层内把两类专家加权组合，做到“既共享、又隔离”。

PLE 更进一步，把这种 CGC 结构堆叠成多层：上一层输出作为下一层输入，任务专属信号逐层“提纯”，共享信号逐层沉淀。这就像后厨先把热菜、凉菜、甜品分成三个大区，再在每个区里安排共享备料台和专区灶台——矛盾被结构性地隔开，负迁移自然被一步步挤出去。

Ek=∑i∈Ωkgki(⋅) fitask(⋅)+∑j∈Ωsgkj(⋅) fjshared(⋅)\displaystyle E_k = \sum_{i \in \Omega_k} g_k^i(\cdot) \, f_i^{\text{task}}(\cdot) + \sum_{j \in \Omega_s} g_k^j(\cdot) \, f_j^{\text{shared}}(\cdot)
Ω_k 是第 k 个任务专属的专家集合，Ω_s 是所有任务共享的专家集合。任务 k 的输出 = 专属专家加权和 + 共享专家加权和，两类专家各司其职。
  1. 任务专属专家Ω_k 里的专家只被任务 k 使用，它们的梯度不会被其他任务干扰。
    Ωk={fitask:i=1,…,mk}\displaystyle \Omega_k = \{ f_i^{\text{task}} : i = 1, \dots, m_k \}
  2. 共享专家Ω_s 里的专家吸收所有任务的公共信息，供所有任务按权重取用。
    Ωs={fjshared:j=1,…,ms}\displaystyle \Omega_s = \{ f_j^{\text{shared}} : j = 1, \dots, m_s \}
  3. 两类门控分别加权任务专属和共享专家各有一组门控权重，加权求和后拼接或相加，得到该层输出。
    Ek=∑i∈Ωkgkifi+∑j∈Ωsgkjfj\displaystyle E_k = \sum_{i \in \Omega_k} g_k^i f_i + \sum_{j \in \Omega_s} g_k^j f_j

落地上线：推荐系统里怎么用

讲完结构，回到真实后厨。在抖音、淘宝这类推荐系统里，一个模型要同时预测“用户会不会点”（CTR）、“会不会点赞评论”（互动率）、“会不会看完”（完播率）。这几个目标口味差异极大：吸引点击的可能靠夸张标题，而完播率靠内容质量。用 Shared Bottom 会出现“标题党内容被疯狂推荐”的负迁移，用 MMoE/PLE 就能让各目标选择不同的专家组合。

落地时，输入特征是用户、物品、上下文三大类稀疏特征，经过 embedding 后进入专家层。工程师通常选择 4~8 个专家，每个专家两三层 MLP，再配上任务专属塔。上线的第一步往往不是全量，而是做 AB 实验：实验组跑新模型，对照组跑线上老模型，比一比各指标相对提升。

行业共识是：MMoE 相对 Shared Bottom 通常能在次要任务上拿到几个百分点的提升，主要任务基本持平或略涨；PLE 则更适合任务冲突明显的场景，比如“点击率 × 完播率”。这就像后厨升级的账本——不是每道菜都变好吃，但整体翻台率和口碑都会更稳。

Lift=yˉexp−yˉbaseyˉbase×100%\displaystyle \text{Lift} = \frac{\bar{y}_{\text{exp}} - \bar{y}_{\text{base}}}{\bar{y}_{\text{base}}} \times 100\%
Lift（相对提升）=（实验组均值 − 对照组均值）/ 对照组均值。算完每个任务的 Lift 后，还要做显著性检验，确认不是随机波动。
  1. 实验组均值\bar{y}_{exp} 是上 MMoE/PLE 新模型的流量桶里，某指标的平均值（如人均播放时长）。
    yˉexp=1nexp∑i=1nexpyi\displaystyle \bar{y}_{\text{exp}} = \frac{1}{n_{\text{exp}}} \sum_{i=1}^{n_{\text{exp}}} y_i
  2. 对照组均值\bar{y}_{base} 是继续跑老模型的流量桶里，同一指标的平均值。
    yˉbase=1nbase∑i=1nbaseyi\displaystyle \bar{y}_{\text{base}} = \frac{1}{n_{\text{base}}} \sum_{i=1}^{n_{\text{base}}} y_i
  3. 相对提升两者之差除以对照组，得到百分比化的收益，配合 p 值判断是否显著。
    Lift=yˉexp−yˉbaseyˉbase×100%\displaystyle \text{Lift} = \frac{\bar{y}_{\text{exp}} - \bar{y}_{\text{base}}}{\bar{y}_{\text{base}}} \times 100\%

专家调优：后厨请几位师傅最合适

走到这一步，一个现实问题摆在面前：专家数量设多少？请少了，师傅们忙不过来，表达能力不足；请多了，后厨人浮于事，训练又慢又容易过拟合。专家数量是多任务模型里最敏感的超参数之一。

从容量角度看，专家数 n 直接决定模型容量：

后厨请师傅也一样：炒锅、炖汤、面点三位师傅是起步配置；到了满座高峰，可以考虑加一位凉菜师傅分担；但请十位师傅却只服务四桌客人，纯属浪费。专家数量不是越多越好，而是看任务冲突程度和训练数据规模，用实验说话。这也是多任务模型从“能用”走向“好用”的关键一步。

Ctotal=n⋅Cexpert+∑k=1KCtask(k)\displaystyle C_{\text{total}} = n \cdot C_{\text{expert}} + \sum_{k=1}^{K} C_{\text{task}}^{(k)}
总容量 = 专家数量 × 单个专家容量 + 各任务塔容量之和。n 越大，模型越发散、越容易记住噪声；n 越小，专家越难分工。实践中常用小网格搜索（如 2、4、6、8）在验证集上选 n。
  1. 单个专家容量C_expert 表示一个专家的参数量或表达维度，多个专家的总容量随 n 线性增长。
    Cexpert=din×dmid+dmid\displaystyle C_{\text{expert}} = d_{\text{in}} \times d_{\text{mid}} + d_{\text{mid}}
  2. 任务塔容量每个任务塔独立贡献容量，任务数量多时这部分也不可忽视。
    Ctask(k)=dmid×dout(k)\displaystyle C_{\text{task}}^{(k)} = d_{\text{mid}} \times d_{\text{out}}^{(k)}
  3. 容量与效果权衡n 太小欠拟合，n 太大过拟合，验证集损失随 n 呈 U 形，取验证损失最小的 n。
    n∗=arg⁡min⁡n  Lval(n)\displaystyle n^{*} = \arg\min_{n} \; \mathcal{L}_{\text{val}}(n)

AI 应用场景

推荐系统的多目标排序

阶段：模型结构设计与在线服务阶段

解决的问题：短视频、电商推荐要同时预测点击率、互动率、完播率或转化率。传统 Shared Bottom 模型把三个目标强绑在同一套底层特征上，容易出现“标题党点击涨、完播率暴跌”的负迁移；MMoE/PLE 让每个目标拥有独立门控与专属专家，按内容类型动态调配特征组合。

具体案例：某短视频 App 将 PLE 用于主 Feed 排序，实验组相对线上 Shared Bottom 基线，互动率提升 4.2%、完播率提升 3.1%，点击率基本持平，经 AB 实验显著性检验后全量上线。

内容理解与用户画像联合建模

阶段：特征学习阶段

解决的问题：一条内容要同时打标签、判质量分、识别人物关系，多个任务共享底层视觉或文本特征。MMoE 门控能按内容模态（图文、视频、音频）选择不同专家，避免低质量内容的噪声污染高质量分类任务。

具体案例：内容平台用 MMoE 统一做文本分类、情感分析和质量分预测，多任务联合训练后各任务离线 AUC 均有提升，线上运营筛选效率明显提高。

广告转化与反作弊联合预估

阶段：预估模型阶段

解决的问题：广告系统要同时预估点击率、转化率与作弊概率。转化事件稀疏、作弊标签噪声大，两者共享底层会导致梯度冲突；用 PLE 把“转化预估”与“作弊识别”放在分层结构中，共享专家吸收通用规律，专属专家隔离噪声。

具体案例：某广告平台用 PLE 联合建模 pCVR 与反作弊分，作弊召回率提升 18%，转化预估 AUC 稳定上涨，异常流量过滤耗时明显下降。

Python 演示

python61 行
# 数值梯度演示：MMoE 中每个任务的门控如何学会挑专家import numpy as np def sigmoid(z):    return 1.0 / (1.0 + np.exp(-np.clip(z, -30, 30))) def softmax(z):    ez = np.exp(z - z.max(axis=1, keepdims=True))    return ez / ez.sum(axis=1, keepdims=True) def bce(p, y):    eps = 1e-9    return -(y * np.log(p + eps) + (1 - y) * np.log(1 - p + eps)).mean() np.random.seed(1)N = 128X = np.random.randn(N, 8)# 任务A依赖前4维特征，任务B依赖后4维特征，模拟口味不同的两个需求yA = (X[:, 0] + 0.8 * X[:, 1] + 0.05 * np.random.randn(N) > 0).astype(float)yB = (X[:, 6] + 0.8 * X[:, 7] + 0.05 * np.random.randn(N) > 0).astype(float) # 两个专家：专家1偏向任务A的特征，专家2偏向任务B的特征e1 = np.tanh(X[:, :4] @ np.random.randn(4, 16))e2 = np.tanh(X[:, 4:] @ np.random.randn(4, 16))wA = np.random.randn(16, 1) * 0.5wB = np.random.randn(16, 1) * 0.5  def tower_loss(Wg, y, w):    s = softmax(X @ Wg)    mix = s[:, 0:1] * e1 + s[:, 1:2] * e2    p = sigmoid(mix @ w).ravel()    return bce(p, y)  def gate_grad(Wg, y, w):    g = np.zeros_like(Wg)    eps = 1e-5    for idx in range(Wg.size):        r, c = np.unravel_index(idx, Wg.shape)        Wp = Wg.copy()        Wm = Wg.copy()        Wp[r, c] += eps        Wm[r, c] -= eps        g[r, c] = (tower_loss(Wp, y, w) - tower_loss(Wm, y, w)) / (2 * eps)    return g  ga = np.random.randn(8, 2) * 0.1gb = np.random.randn(8, 2) * 0.1lr = 0.1for step in range(30):    ga -= lr * gate_grad(ga, yA, wA)    gb -= lr * gate_grad(gb, yB, wB) sA = softmax(X @ ga).mean(axis=0)sB = softmax(X @ gb).mean(axis=0)print("任务A门控对[专家1, 专家2]的平均权重:", np.round(sA, 3))print("任务B门控对[专家1, 专家2]的平均权重:", np.round(sB, 3))print("结论: 每个任务的门控学会了按自己的需求挑选专家,")print("任务A更依赖专家1, 任务B更依赖专家2, 冲突被门控调度化解")
目的：用 128 条合成样本演示 MMoE 的核心机制——每个任务的门控通过数值梯度学会“挑专家”，从而化解任务间的更新冲突。
  1. e1 = np.tanh(X[:, :4] @ np.random.randn(4, 16))专家1只看前4维特征，相当于只熟悉任务A口味的师傅；专家2对应后4维特征
  2. mix = s[:, 0:1] * e1 + s[:, 1:2] * e2门控把两个专家的输出按权重混合，权重由 softmax 得分决定
  3. s = softmax(X @ Wg)门控网络给每个专家打分并归一化，保证权重非负且和为 1
  4. ga -= lr * gate_grad(ga, yA, wA)任务A只更新自己的门控参数，任务B更新自己的，互不抢占
  5. sA = softmax(X @ ga).mean(axis=0)统计训练后任务A对两个专家的平均偏好，观察门控是否学会分工

常见误区

误区我把专家从 4 个加到 16 个，容量变大了，离线指标应该跟着涨吧？反正专家就是几路并行的网络，多加几路又不亏。

正解专家数量要与数据规模、任务冲突程度匹配。专家太少表达不足，专家太多会过拟合、拖慢训练，并在门控上引入更多噪声。验证集指标随专家数呈 U 形，业界常用 2、4、6、8 做小网格搜索。就像后厨请太多师傅，灶台不够分，反而互相碍事。

为何常见：参数越多能力越强的直觉很普遍，且小数据集上多几个专家的过拟合一开始看不出来，等大流量上线才暴露。

误区MMoE 不就是 Shared Bottom 中间多开几个并行分支嘛，感觉结构差不多，效果应该也差不多。

正解关键差异在于每个任务都有自己的门控。门控按输入动态加权专家输出，改变了梯度的路由方式：任务A 可以压低对它有干扰的专家权重，从而在共享参数上减少任务间的拔河。只加并行分支不加门控，梯度依然在所有分支上平均拉扯，负迁移并不会消失。

为何常见：只看结构图画面上多了一排方块，没注意到门控对梯度流和优化方向的调节才是本质。

误区只要上了 PLE，任务之间就完全隔离了，负迁移为零，可以放心大胆随便拼任务。

正解PLE 通过分层抽取和任务专属专家大大压缩了任务间的梯度冲突，但共享专家层仍会传递公共信息，损失权重、样本量差异和任务本身的相关度依然在起作用。负迁移是被显著缓解而不是被完全消除，上线前依然要做任务相关性分析和 AB 实验。

为何常见：把论文里的缓解负迁移记成了消除负迁移，而且看到部分指标大涨后容易夸大结论。

误区多任务能共享表征、还能互相补充数据，随便把两个任务拼在一起，肯定比各训练一个模型强。

正解当两个任务相关度很低（比如预测点击率和预测退货率）、数据分布冲突明显时，硬拼只会带来负迁移，主任务指标可能低于单任务模型。正确做法是先用相关性分析判断任务亲疏，再决定用 Shared Bottom、MMoE 还是 PLE；必要时放弃多任务，各跑各的。

为何常见：只看到多任务共享的好处，忽略了负迁移的前提——任务之间确实存在可共享的规律。

面试题

Q1. MMoE 中门控的核心作用是什么？

单选题 · easy

  • A.把输入特征原样复制给所有专家
  • B.按任务对专家输出做加权组合← 正确答案
  • C.把高维特征压缩成低维向量
  • D.直接计算任务的最终预测结果

答案：B。门控根据输入给每个专家分配一个权重，再把专家输出加权组合，正是按需点将。A 是复制输入，C 是降维，D 是任务塔的职责，都不是门控做的事。

Q2. Shared Bottom 结构的主要缺点是什么？

单选题 · easy

  • A.模型参数量过于庞大
  • B.训练速度明显变慢
  • C.任务强制共享底层易负迁移← 正确答案
  • D.无法支持线上实时推理

答案：C。Shared Bottom 的所有任务共用一套底层参数，任务差异大时优化方向互相拉扯，这是负迁移的来源。它参数量不大、训练不慢，也完全支持线上推理。

Q3. 下列哪一项最能描述负迁移？

单选题 · easy

  • A.模型在训练集上过拟合
  • B.一个任务的学习损害另一个任务← 正确答案
  • C.网络训练时梯度发生爆炸
  • D.样本标签出现大量噪声

答案：B。负迁移指任务A的学习规律干扰了任务B的效果提升。过拟合是单任务问题，梯度爆炸是优化问题，标签噪声是数据问题，都不是负迁移。

Q4. MMoE 的门控网络输出通常用什么归一化？

单选题 · mid

  • A.ReLU 激活函数
  • B.Sigmoid 激活函数
  • C.Softmax 激活函数← 正确答案
  • D.Tanh 激活函数

答案：C。门控输出要满足权重非负且和为 1，softmax 天然满足这一归一化需求。ReLU 和 tanh 输出不为概率分布，sigmoid 只能对单个标量归一化，无法对一组专家权重求和为 1。

Q5. 相比 Shared Bottom，MMoE 的主要优点有哪些？

多选题 · mid

  • A.各任务可差异化使用专家← 正确答案
  • B.门控引入任务特定参数← 正确答案
  • C.模型总参数量一定变小
  • D.降低任务间的梯度冲突← 正确答案

答案：ABD。MMoE 每个任务有独立门控，可以差异化使用专家，并通过门控路由降低梯度冲突。但它额外引入多个专家和门控，参数量通常变大而非变小，C 错。

Q6. PLE 比 MMoE 在结构上的关键改进是什么？

单选题 · mid

  • A.完全去掉门控网络
  • B.分层抽取同时保留任务专属专家← 正确答案
  • C.使用卷积层替换全连接层
  • D.大幅加宽共享底层网络

答案：B。PLE 引入分层抽取的结构，并同时保留任务专属专家与共享专家，让信号逐层提纯。它没有去掉门控，也没有改用卷积层或单纯加宽底层。

Q7. 关于专家数量选择，下列说法正确的是？

多选题 · mid

  • A.专家太少会导致表达能力不足← 正确答案
  • B.专家数量越多效果一定越好
  • C.专家过多会增加训练与过拟合风险← 正确答案
  • D.实践中常用小网格搜索确定← 正确答案

答案：ACD。专家数与表达能力和过拟合风险相关，验证集指标呈 U 形，实践中常用 2、4、6、8 网格搜索。越多越好是错误直觉。

Q8. 两个任务特征差异较大且基本独立时，MMoE 门控会倾向表现为什么？

单选题 · hard

  • A.两个任务使用完全相同的专家权重
  • B.两个任务都平均使用全部专家
  • C.各任务使用差异化的专家组合← 正确答案
  • D.门控输出全部收敛为零

答案：C。任务差异大时，门控会学到差异化的专家权重组合，让每个任务重点使用适合自己的专家，这正是 MMoE 能缓解负迁移的原因。

Q9. 在做多任务模型的 AB 实验时，最合理的评估方式是？

单选题 · hard

  • A.只看主任务指标是否提升
  • B.同时关注所有任务与业务指标← 正确答案
  • C.离线 AUC 涨了就立即全量
  • D.只统计点击率不看显著性

答案：B。多任务模型可能提升主任务却伤害次要任务，必须同时观察所有任务指标和业务指标，并做显著性检验。只看离线或单一指标容易误判。

Q10. 关于 MMoE 门控机制，下列理解正确的有哪些？

多选题 · extreme

  • A.门控输入可用原始特征或共享层输出← 正确答案
  • B.门控参数与塔参数需要联合训练← 正确答案
  • C.门控输出经 Softmax 归一化后和为 1← 正确答案
  • D.门控完全不需要可学习参数

答案：ABC。门控输入既可以是原始特征也可以是共享层输出，门控参数随整个模型联合训练，softmax 输出保证各专家权重和为 1。门控本身就是可学习参数，D 说法错误。