如何在Python中利用多任务学习（Multi-task Learning）提升效率？

先泼盆冷水：多任务学习（MTL）可不是什么“提升效率”的万能开关。它的核心价值在于，当不同的学习任务之间存在着真实的语义或结构关联时，通过共享底层表示来降低参数冗余、缓解小样本场景下的过拟合问题。用对地方了，事半功倍；用错了场景，反而会拖慢收敛，甚至让单个任务的精度都跟着遭殃。

所以，第一个核心问题就是：什么时候该上多任务学习？

答案很简单——看任务之间是否真的“有关”。强行把两个八竿子打不着的任务（比如一边做图像分类，一边预测股票价格）绑在一起训练，梯度会互相冲突，loss曲线震荡不停，模型半天都收敛不了。真正适合MTL的场景，其实有非常明确的共性，可以用一张表来概括：

• 输入相同，输出维度不同： 比如中文文本处理，同时做词性标注（POS Tagging）和命名实体识别（NER），这两个任务都高度依赖底层的词法和句法特征。
• 底层感知一致，高层目标不同： 比如自动驾驶，目标检测和深度估计都需要先理解场景的几何结构，但最终输出的结果不同。
• 数据分布偏斜但任务耦合： 比如推荐系统，点击率预测（Click，数据多）和购买转化预测（Purchase，数据少），后者可以借助前者的特征进行迁移学习。

判断标准其实很直观：你可以先试想一下，如果去掉共享层，单独为每个任务训练一个独立模型，它们的性能（baseline）是不是明显比联合训练要差？如果是，那就放心上MTL；如果差别不大，就别勉强了。

PyTorch实现：共享主干 + 多头，别踩这些坑

很多新手容易犯的一个错误，就是把所有的“任务头”（Task Head）一股脑塞进一个 nn.ModuleDict 里。结果运行时发现，要么 batch 维度没对齐，要么特征的 channel 数不匹配，最后报一个 RuntimeError: size mismatch，很是头疼。

正确的做法，是要在代码层面就清晰地分离“共享路径”和“私有路径”：

• 共享部分： 用一个单一的骨干网络（backbone），比如 BertModel 或 resnet18.features。它的输出形状必须统一，要么是 [B, D] 的向量，要么是 [B, C, H, W] 的特征图。
• 私有部分： 每个任务的 Head 单独定义为一个 nn.Sequential。这里有一个硬性要求：Head的输入形状必须严格匹配共享层的输出。比如，检测任务的 Head 期望输入是 [B, 1024, 7, 7]，那就别把它接在 AdaptiveA vgPool2d(1) 后面。
• 输出管理： forward 函数必须返回一个字典，用字符串作为键名（如 "detection"）。千万别用数字索引，否则后续计算loss时顺序一乱，你都不知道错在哪里。

来看一个标准的代码片段：

def forward(self, x):
    shared = self.backbone(x)  # 假设输出 shape： [B, 512, 7, 7]
    return {
        "cls": self.cls_head(shared.mean(dim=[2,3])),  # 分类头：先用全局平均池化将特征图展平
        "seg": self.seg_head(shared)                   # 分割头：保留空间维度做像素级预测
    }

Loss加权：别再用拍脑袋的静态权重了

像 0.7 * loss_cls + 0.3 * loss_seg 这种写法，在多数情况下会很快让强势任务主导整个训练过程。尤其是当不同任务的loss量纲差异巨大时（比如分类loss大约在0.5，而分割loss可能在2.3），这种静态加权基本等于没平衡。

更推荐的做法是采用不确定性加权（Uncertainty Weighting）：把每个任务loss的 log-variance 当作一个可学习的参数。在PyTorch里实现起来非常简洁，只需要加一行 self.log_var_task1 = nn.Parameter(torch.zeros(()))，然后把最终的loss改写为 torch.exp(-self.log_var_task1) * loss1 + self.log_var_task1。这样，模型会自动学会为不同任务分配最合适的权重。

这里有个提醒：像 GradNorm 这类依赖梯度范数的方法，在小批量（batch_size < 64）或训练早期（early epoch）时要慎用，因为此时的梯度噪声很大，反而会干扰优化方向。

另一个关键点是，要时刻监控每个任务的loss曲线。如果发现某个任务的loss连续十几个epoch都不下降，那多半不是权重设低了，而更可能是Head的输入形状错了，或者是Label编码不匹配（比如分割任务用了 nn.CrossEntropyLoss，但mask却是 float32 的0/1值，这里应该用 nn.BCEWithLogitsLoss 才对）。

验证评估：千万别只看总loss下降就以为万事大吉

训练过程中总loss下降，绝不等于所有任务都变好了。一个常见的陷阱是：分割Head在训练集上过度拟合了边缘细节，导致验证集的loss是涨的，但因为分类任务的loss比较稳定，总loss可能只是微微下降，很容易被误判为模型正在收敛。

正确的做法是：

• 分任务独立评估： 在每个epoch结束后，先调用 model.eval()，然后分别从输出字典里取出每个任务的预测结果，单独计算指标（比如分类用 f1_score，分割用 mIoU）。
• 早停策略要讲究： 早停（early stopping）的监控指标不能是总loss，而应该选你最关心的那个核心任务的指标。比如在推荐场景选 purchase_auc，在NLP场景选 ner_f1。
• 推理时的依赖关系： 如果某个Head的输入依赖于另一个Head的输出（比如分割Head需要根据检测Head提供的Bbox区域进行裁剪），那就必须先运行检测，再把结果传给分割Head，不能并行处理。这个直接影响了模型的部署延迟，必须在设计时就考虑清楚。

说到底，多任务学习真正的复杂之处，根本不在代码写了多长，而是在于：任务的边界是否清晰，Label的对齐是否毫无歧义，以及验证逻辑是否做到了彻底的解耦。 写完 model.forward 之后，花三倍的时间去检查 data loader 的输出和 eval loop 的逻辑，这比琢磨怎么调learning rate要重要得多。这才是真功夫所在。