很多团队把对话、代码修复、工具调用和安全拒答一起塞进同一轮训练离线平均分常先涨线上主任务却先掉点。⚠️ 表面看是数据变多实际是把标签密度和损失尺度完全不同的任务绑进一条梯度链路模型学会的往往只是“哪类样本最容易降loss”。问题不在多任务本身而在权重和节奏仍按静态配置处理。 指令跟随样本句式短、监督信号密工具调用和安全样本更稀疏却梯度更尖锐如果系统从第一步就等权混训优化器会先追逐下降更快的支路主任务能力就会被边路目标挤压。图 1多任务联合训练最危险的信号不是平均分而是主任务先掉主任务掉点往往不是数据不够而是更新预算被分错了第一层问题是loss量纲不等价。 代码补全常按token级交叉熵累计拒答或路由任务却只在少量位置产生监督当一个batch同时出现长答案和短标签等权平均会让“更长、标签更密”的任务天然占更多更新预算。 训练看板只看总loss很容易把这种偏置误判成收敛变好。第二层问题是梯度方向冲突。️ 主任务要求模型把回答展开得更完整安全或工具路由任务却强调克制、格式约束和早停二者同时回传时关键表示层会被拉向相反方向。没有warmup、分桶采样和冲突裁剪模型就在共享层来回震荡最后就会表现为主任务指标下滑。方案主任务胜率工具成功率安全误拒率典型现象单任务主干71.4%62.8%4.1%主任务稳辅助能力不足四任务等权混训66.2%74.6%2.3%平均分上涨主任务掉点Warmup 冲突投影72.1%73.9%2.5%主任务回稳辅助收益保留图 2真正需要对齐的不是任务名字而是每类任务吃掉多少梯度预算一组 13 B 训练回放把根因暴露得很直接在一组13 B指令模型回放里团队把四类样本混在18万条数据中。 基线组先做单任务主干训练第二组直接四任务等权混训第三组增加loss weight warmup、按任务长度分桶并在反向阶段对冲突梯度做投影。 观察窗口拉到8k step后差距不在平均loss而在主任务slice的持续性。✅结果很直接等权混训组的工具成功率和拒答覆盖率都涨了但主任务问答胜率从71.4%掉到66.2%代码修复Pass1也掉了4.8个点。 第三组把前15%训练步只留给主任务再把辅助任务权重缓慢拉到目标值主任务胜率回到72.1%同时保住工具和安全收益。根因不是多任务不能做而是辅助目标过早抢走了表示层预算。task_weightsramp_weights(stepstep,total_stepstotal_steps,warmup_ratio0.15,target{main:1.0,code:0.45,tool:0.35,safety:0.25},)lossescompute_task_losses(batch)merged_gradsproject_conflicting_grads(losseslosses,weightstask_weights,cosine_floor-0.05,)optimizer.step(merged_grads)multitask_schedule:main_only_warmup_ratio:0.15bucket_by:prompt_and_response_lengthconflict_projection:pcgradmonitor:-main_slice_win_rate-task_grad_cosine-weight_ramp_progress图 3联合训练要看的不是总分更高而是主任务和辅助任务能否同时成立联合训练更像预算编排系统而不是数据拼盘生产里更稳的做法是把多任务训练当成“预算编排”而不是“数据拼盘”。 每个任务都要有长度分布、标签密度和回放指标训练过程中持续看main_slice_win_rate、task_grad_cosine与weight_ramp_progress一旦发现主任务先掉、辅助任务先涨就优先回调权重和采样。⏱️ 只有把任务收益拆到slice层联合训练才不是一场平均分幻觉。笔者认为未来3 - 6个月更有效的联合训练会走向“主任务锚定 辅助任务渐进接入 冲突可观测”的治理模式。 当团队能回答“这一步是谁在吃梯度预算、谁在拖主任务表示”多任务训练才开始从经验活变成工程系统。你们现在的联合训练是在扩能力边界还是在拿主任务精度为平均分买单图 4把联合训练做成可观测的预算系统主任务收益才不会先被透支