很多团队在指令微调里看到cross entropy抖动就会顺手打开Label Smoothing。训练看板通常立刻变好看loss更平、异常batch更少、早期收敛也更顺。⚠️ 真到线上抽检问题却会反过来出现答案更圆滑工具参数更含糊代码标识和引用字段更容易差一两个字符。根子往往不在“平滑”这个方向错了而在生成任务把每个token都当成精确提交。Label Smoothing本质是在目标分布里加入一层均匀噪声它能减轻过拟合也会把罕见但关键的正确token一起压平。 当训练集同时混有聊天、工具调用和结构化输出时模型最先学到的不是更稳而是更保守的高频表达。图 1训练曲线先变平不代表精确生成能力也一起变强全局平滑最先伤到的往往正是长尾精确位点这一退化在长回答和结构化字段里最明显。自动回归生成会把惩罚累加到每一步JSON key、函数参数、引用编号和代码标识原本就属于长尾token一旦统一加上epsilon模型会更偏好语义接近但频率更高的安全词。 离线loss看起来下降真实任务却从“精确命中”退成“差不多正确”。更麻烦的是很多团队把它当成通用稳态按钮却没有同步做置信度回收。生成模型不是分类器温度、采样和解码约束会把这种分布变钝继续放大。️ 如果训练阶段统一抹平推理阶段又沿用偏保守的temperature和top_p最终得到的往往是更长、更稳、但信息密度更低的答案。方案训练loss std事实问答F1工具参数精确匹配平均回答长度不做平滑1.00x74.8%81.2%312全局epsilon0.050.82x71.6%75.4%346选择性平滑 回收0.87x74.1%80.1%319图 2真正被压扁的不是噪声本身而是那些必须精确命中的稀有 token一组 7 B 指令模型回放把问题暴露得很直接一组7 B指令模型回放把差距拉得很直接。数据约32万条覆盖问答、工具调用、代码修复和引用生成基线组不做平滑第二组全局epsilon0.05第三组只对自然语言token做平滑并给工具参数、代码标识和引用位加confidence recovery。 观察窗口放到6 k step后稳定性和可用性开始分叉。全局平滑组把训练loss std压低了18%但事实问答F1掉了3.2个点工具参数精确匹配掉了5.8个点平均回答长度反而涨了11%。✅ 选择性平滑虽然只多了一点掩码逻辑却把长度膨胀压回去工具精确匹配恢复到接近基线线上人工抽检也不再频繁出现“意思对了字段错了”的问题。exact_maskbuild_exact_token_mask(batch,fields[tool_args,citation_id,code_span],)losssmoothed_cross_entropy(logitslogits,labelslabels,epsilon0.05,smoothing_mask~exact_mask,)loss0.02*confidence_recovery_loss(logitslogits,labelslabels,target_maskexact_mask,)label_smoothing:epsilon:0.05skip_fields:-tool_args-citation_id-code_spanmonitors:-answer_entropy-exact_match-length_drift-tool_arg_edit_distance图 3更稳的训练波动不该靠牺牲精确位点来换生产里该把平滑当成噪声治理而不是默认开关生产里更稳的做法不是彻底禁用Label Smoothing而是把它当成有边界的噪声治理工具。 对聊天类自然语言段落它可以缓解脏标注和模板过拟合对JSON、函数调用、代码、引用编号这类精确位点最好直接跳过或单独设更小的epsilon。⏱️ 同时持续看exact_match、answer_entropy和length_drift否则平台只会把“更稳的训练曲线”买成“更虚的线上回答”。笔者认为接下来3 - 6个月更值得做的不是谁把平滑系数调得更细而是谁先把“稳定正则”和“生成校准”拆开治理。 训练侧用token级掩码和噪声分层推理侧再用温度回收、约束解码和任务切片评测兜底Label Smoothing才会从省心开关变成可审计能力。你们现在追的是更漂亮的loss curve还是更可靠的精确生成结果图 4把平滑做成分层治理问题稳定性收益才不会被精确性亏空