面经策

请详细讨论微调时如何防止灾难性遗忘问题？ ​

  • 标签：大模型、AI、微调

🏛 业务架构师 ​

灾难性遗忘指微调后模型把预训练学到的通用能力"忘掉了"——客服话术微调完，模型不会写代码了、常识问答翻车。这在业务上是重大事故：一个模型服务多场景时，为 A 业务微调把 B 业务打坏。

成因：微调数据分布窄，梯度更新把参数往新任务拉，覆盖了旧能力的表征。

缓解策略我按投入产出排：

  1. 优先用 LoRA 而非全量微调：冻结主干，遗忘天然被限制——这是 PEFT 在企业落地的隐性福利。
  2. 回放/混入通用数据（Rehearsal）：微调数据里掺 10%~30% 通用指令数据（开源通用 SFT 数据集或自采），让模型"复习旧课"。
  3. 控制训练强度：低学习率（LoRA 常用 1e-4~2e-4）、少 epoch（1~3 轮）、早停——训得越狠忘得越多。
  4. 数据多样性：领域数据覆盖足够多的任务形态，避免只学一种范式。
  5. 上线前双评测：领域评测集+通用能力 Benchmark（MMLU 类）都过，才允许发布——把它写进发布流程。

治理建议：把"通用能力回归测试"设为企业模型发布的强制卡点，遗忘是慢性病，等业务方投诉才发现就晚了。

🏗 系统架构师 ​

灾难性遗忘 = 微调后模型在新任务上变好、在原有通用能力上退化（不会跟指令了、常识问答变差）。我从机理到缓解讲：

机理：微调在预训练的损失面上移动参数到新任务的局部最优，新数据分布与原分布差异越大、学习率越高、epoch 越多，参数漂移越远，原有能力被"覆写"。

缓解策略（按性价比排序）：

  • LoRA/PEFT 本身就是第一道防线：主干冻结，通用能力物理性保留，只训低秩增量；
  • 数据混合（replay/mixout）：微调数据里掺 5%~20% 通用指令数据（如开源通用 SFT 集），让梯度不偏离原分布太远——最实用的手段；
  • 小学习率 + 少 epoch：1e-5 级学习率、1~2 epoch，减小参数漂移幅度；
  • 正则化：EWC（对重要参数加弹性约束）、L2-SP（约束参数不远离初始点）——学术有效，工程上数据混合更简单常用；
  • 两段式训练：先继续预训练注入领域知识，再通用 SFT 恢复指令能力。

生产纪律：微调后必须跑通用能力回归集（通用指令遵循、常识、代码抽查），和微调任务评测一起作为发布门禁——我见过只测领域指标就上线、结果客服模型连寒暄都不会的真实事故。

💻 全栈开发专家 ​

灾难性遗忘：模型学新任务时把旧的通用能力「冲掉」——微调完领域问答变好了，但不会写代码、不会算数了。我防它用五招，按性价比排序：

  1. LoRA/QLoRA 代替全量（结构性防御）：主干权重完全不动，遗忘天然轻微，这是 PEFT 最大的隐藏福利。
  2. 通用数据回放（Replay）：训练集里混入通用指令数据（ShareGPT/OpenHermes 抽样），领域:通用 ≈ 1:1 到 2:1。全量微调时这一招是保命项：
python
dataset = concatenate_datasets(
    [domain_sft, general_sft.shuffle().select(range(len(domain_sft)))])
  1. 更小学习率 + 更少 epoch：lr 大、训得猛，旧知识被冲刷得越狠；全量微调 lr 1e-5 量级、1~2 epoch。
  2. EWC / L2-SP 正则：对重要权重加「别动太多」的惩罚项，理论优雅但工程上用得少（算 Fisher 信息麻烦），任务敏感时才上。
  3. 模型合并兜底：任务 LoRA 与基座按系数插值（model merging / task arithmetic），可以事后回调通用能力。

监控手段：微调前后各跑一次「通用能力哨兵集」（50 条数学/代码/常识题），分数掉超过 5% 就回滚调参。这个检查项要写进流水线自动化，靠人肉记是靠不住的。