第六章：项目实战之推荐/广告系统
第三部分：精排算法
第二节：精排算法模型精讲: DNN、deepFM、ESMM、PLE、MMOE算法精讲与实现
5.PLE（Progressive Layered Extraction）模型------ 最稳定、工业级多任务学习模型
5.1 PLE 想解决什么问题？
MMOE 虽然比 ESMM 好很多，但仍有两个工程上绕不开的问题：
| MMOE 问题 | 影响 |
|---|---|
| Gate 仍可能选错专家 → 任务污染仍在 | CTR 梯度把 CVR 专家拉偏，或反之 |
| 共享比例不可控 | 共享多少、独立多少，全由 Gate 决定，模型不透明 |
在推荐系统的 多目标场景（Mutil-Task，例如 CTR / CVR / WatchTime / Like / Follow / Comment） 中，这种不稳定会被无限放大。
工业界需要一个"共享可控、避免污染、可扩展" 的结构 → PLE 应运而生
所以一句话总结：
| 模型 | 核心共享策略 |
|---|---|
| Hard Sharing（如 ESMM） | 强共享，容易任务冲突 |
| MMOE | 软共享，但共享比例不可控 |
| PLE | 分层共享 + 专家分组 + 强约束共享路径（最稳定） |
5.2 PLE 结构核心思想：共享归共享，私有归私有
PLE 的关键策略：
| 组件 | 作用 |
|---|---|
| Shared Experts（共享专家） | 给所有任务共享的特征能力（如基础兴趣、通用语义） |
| Task-specific Experts（任务私有专家） | 各任务专属，不被其他任务污染 |
| Gates 多层选择 | 每一层都"逐步筛选"共享信息，越深越任务化 |
这一点像现实中的人类合作：
"有些能力是共同培养的（通识课）"
"有些能力必须专门训练（各自专业课）"
"并且共享不能一刀切，而要逐层递进"
5.3 PLE 模型结构（最容易理解的 ASCII 图）
以 2 任务（CTR / CVR）为例：
Embedding Layer（共享）
│
┌────────┴────────┐
│ Shared Experts │ ← 所有任务可用
└────────┬────────┘
┌──────────┼──────────┐
│ │ │
Task-specific Task-specific (Optional 更多任务)
CTR Experts CVR Experts
│ │
┌────────┴──────────┴────────┐
│ Layer 1 GATES │ ← 多任务各自 Gate 选择 Shared + Private
└────────┬──────────┬────────┘
│ │
CTR Tower CVR Tower
│ │
P(click) P(purchase)与 MMOE 最大区别：
| 结构项 | MMOE | PLE |
|---|---|---|
| 专家组成 | 全共享 | 共享专家 + 私有专家 |
| 共享比例 | Gate 自己决定 | 共享路径受结构约束 |
| 信息流动 | 一次性共享 | 逐层共享（Progressive） |
| 任务污染风险 | 中 | 低（更干净） |
工程落地效果：多个大厂验证后结论一致 → PLE 比 MMOE 更稳、更可控、更适合多目标推荐系统
5.4 PLE 公式（比 MMOE 更简单）
与 MMOE 唯一区别：
-
Gate 输入 =
共享专家 + 任务专家 -
Gate 输出 = Softmax 权重
-
任务自己永远能访问任务专家（有兜底）
-
共享专家只能"逐层抽取"
数学不展开，原因：训练逻辑与 MMOE 相同，只是输入源变了
→ 实现成本 ≈ MMOE，但效果更好
5.5 PLE 工业界价值
| 维度 | 表现 |
|---|---|
| 模型可控性 | 强 |
| 稳定性 | 强 |
| 任务扩展 | 强（可加 n 个任务） |
| 防任务污染能力 | 最强 |
| 工业适用性 | 最推荐 |
所以各大互联网广告系统（如 TikTok/阿里/腾讯/美团）多任务结构现在大多数采用：
PLE + 蒸馏 + MoE（大模型化）
小结：五模型对比（DNN → DeepFM → ESMM → MMOE → PLE）
| 模型 | 适用场景 |
|---|---|
| DNN | 单任务基线 |
| DeepFM | 单任务 CTR 预估 |
| ESMM | CTR+CVR 两任务（新手首选） |
| MMOE | 多任务但不太复杂 |
| PLE（最佳实践） | 工业级多任务（强烈推荐） |