Replay buffer 与 EWC Fisher

1. 新任务微调，旧能力塌

底盘上物体检测模型加了新 SKU 类，fine-tune 两周后旧类 recall 掉十五点——典型灾难性遗忘。不是数据不够，是新任务梯度覆盖旧任务学到的表示。持续学习没有银弹，但 replay buffer 在工程上最实用；EWC、LwF 是正则约束选项，实现复杂，小团队常 replay 就够。

2. Replay buffer：混合旧 batch

最简单做法：维护旧任务样本 buffer，每个 training step 混合一定比例的旧 batch 与新 batch。比例百分之十到三十是常见起点；buffer 大小受存储限制，可 reservoir sampling 固定容量。

python

new_batch = next(new_loader)
old_batch = sample(replay_buffer, k=32)
batch = concat(new_batch, old_batch)
loss = criterion(model(batch), labels)

关键：评估必须新旧任务都报。只报新任务 metric 会掩盖 forgetting。旧任务 val set 固定，每次 fine-tune 后对比同一 checkpoint 协议。

3. EWC 与 Fisher 信息

Elastic Weight Consolidation 用 Fisher 信息矩阵估计参数对旧任务的重要性，新任务 loss 加惩罚 $\sum_{i} F_{i} (θ_{i} - θ_{i}^{*})^{2}$ ，限制重要权重偏离旧最优。实现需存 Fisher 和旧参数 snapshot；多任务时 Fisher 可累加或取 max。

LwF 用旧模型 soft label 约束新模型输出，不需存旧数据——但 teacher 也是旧 checkpoint，分布 drift 大时效果有限。multi-head：共享 backbone、每任务独立 head，新任务只训新 head 时 forgetting 最轻，但 head 数随任务增长。

4. 工程取舍

数据能存则 replay 优先；存储受限试 EWC 或 LwF；任务边界清晰用 multi-head。没有 universally best——按存储、任务结构与评估成本选。

5. 失败模式

无 replay 纯 fine-tune 全参数 → 高 forgetting 风险。只增大新任务数据不 replay → 旧类仍被压制。eval 只报新任务 → 上线后旧场景崩。buffer 只存 easy sample → replay 效果差，应保留 hard 和代表性样本。

6. 案例：旧类 recall 被 silently 牺牲

某次发版只报新 SKU 精度，旧 SKU 召回掉未告警——客户投诉后才发现。持续学习评估协议必须覆盖全任务，发版 gate 含旧任务 regression 阈值。

7. 验收

新任务 metric 达标，旧任务 val metric 相对 fine-tune 前下降可控。
replay 比例与 buffer 大小 ablation 有记录。
checkpoint 含旧任务 eval 结果，可跨版本对比。
多任务 eval 协议固定，不随版本删旧 val set。

8. 落地与衔接

持续学习发版把回放比例、缓冲区容量与采样策略写进配置，并与检查点同版本归档。每次微调后自动跑全任务验证，旧任务指标相对基线跌超阈值则阻断合并。存储受限时优先保留困难与代表性旧样本，而不是只存简单样本。多任务头方案要在文档里写清任务与输出头映射，避免新任务误训共享层却未更新评估列表。发版材料必须附全任务对比表，不能只报新任务精度。

9. 案例复盘

某商品识别增量发版只报新类别精度，旧类别召回掉十五点直到客户投诉才暴露。复盘后固定回放比例百分之二十，并在持续集成里跑旧验证集回归门槛。下一版新类达标且旧类召回仅掉一点以内，说明评估协议比算法花哨更先决。团队现在把全任务指标表贴进合并请求模板，灾难性遗忘不再悄然发生。后续改回放策略前先在小流量上验证旧任务稳定性。

持续学习是遗忘与适应的权衡。Replay 是最可落地的默认；EWC 和 multi-head 按存储与任务结构选。eval 覆盖全部任务，否则 forgetting 上线才暴露。把全任务 eval 当作发版 gate，比事后补测旧场景便宜一个数量级。存储与算力允许时，replay 仍是小团队最省心的默认路径。