回归测试与消融实验

一句话定义

回归测试保证「新的改动没有弄坏旧的 capability」，消融实验回答「这次提升到底是谁的功劳」——两者合起来把微调从手工作坊变成可迭代的工程。

为什么重要

没有回归测试的团队会在第三次迭代时发现「领域变好了、通用崩了」却说不清从哪一版开始崩的；没有消融习惯的团队会把数据、模板、超参的改动混在一次实验里，提升不知道该归功谁，失败不知道该怪谁。微调是高频迭代活动，没有这套机制的团队迭代三轮后必然失控。

前置知识

kp-025 的三层评估体系与冻结评测集。

核心概念

• 回归测试集：领域评测集（能力要变好）+ 通用回归集（能力不能变坏，见 kp-020）的固定组合。
• 单变量原则：一次实验只改一个因素（数据/模板/lr/rank/epoch 之一）。
• 实验台账：配置指纹（数据版本 + 全部超参 + 代码 commit + 随机种子）与评测结果的映射。
• 显著性意识：小样本评测上的分数波动可能是噪声，结论要结合差距幅度与题量。

原理与机制

回归测试的流程设计：每次产出候选 checkpoint 自动跑双评测集，与上一版分数并排展示；任何一栏跌破阈值（如通用回归跌超 3 个点）即拦截，无论领域分多好看。消融的机制逻辑：微调结果 = f(数据, 模板, 超参, 方法, 种子)，多变量同时变动时结果不可归因；控制变量的对照实验是唯一能建立因果的方向。种子方差要预先测量：同配置跑 2-3 个种子，了解指标天然波动带（常见 ±1-2 个点），小于波动带的「提升」不构成结论。

图示

候选模型 ─► 自动跑双评测 ─► 对比表
                            v2: 领域 84(+3) 通用 86(0)  → 通过
                            v3: 领域 87(+3) 通用 81(-5) → 拦截(遗忘)
消融: 只动一个变量 → 归因: +3 = 数据清洗(+2) + rank16→32(+1)

直观类比

回归测试像 App 发版前跑测试用例（新功能上线不能弄崩老功能）；消融像 A/B 测试的控制变量法（促销效果要剔除天气因素）；种子方差像多次测量取平均，单次读数不作数。

实例或案例

迭代记录（摘自真实风格台账）：

v3 的教训：一次改两个变量，的提升被误归因给 rank；v4/v5 拆开后才发现新模板才是关键。

操作步骤

1. 建实验台账（表格即可）：版本号、改动清单、数据版本、完整配置、双评测分数、结论。
2. 固定回归脚本：候选模型 → 自动跑领域 + 通用双评测 → 生成对比表。
3. 设定拦截阈值：通用回归跌幅 >3 点或任一关键场景跌幅 >5 点自动拦。
4. 立单变量纪律：每次迭代计划先写「本版只改 X」，评审通过才训练。
5. 测种子方差：关键结论前用 2 个种子复跑，差异带内不宣称提升。
6. 每季度清理：无产出的方向记录后关闭，台账不养僵尸实验。

排错清单

• 分数波动大无法比较：检查评测集是否被改动过（版本冻结纪律）、推理温度是否统一。
• 提升总是无法归因：回到单变量纪律，把最近的混合改动拆开重跑。
• 回归拦截太频繁：阈值结合种子波动带重新校准，不要拍脑袋定 1 个点。
• 台账没人维护：把「填台账」做成训练脚本的自动输出，而不是人工义务。

常见误区

• 一次改多个「明显该改」的东西：直觉上都该改的东西合并后出了问题，永远不知道怪谁。
• 只跟上一版比：要与基线与最近稳定版三方对比，防止「温水煮青蛙」式缓慢退化。
• 小差距当结论：100 题评测上 1 个点=1 道题，在种子波动带内，不构成任何结论。

与其他知识点的关系

通用回归集的来历见 kp-020；评测集本体见 kp-025；被消融的变量（超参/rank）见 kp-016 与 kp-006；DPO 迭代同样适用本节流程见 kp-023。

延伸阅读

本节不适用：回归与消融是通用工程方法论在微调场景的应用，无领域专属经典文献。

自测题

1. 回归测试集为什么必须是「双评测」？

答：领域评测防「没变好」，通用回归防「变好了但搞坏了别的」（灾难性遗忘），缺一边拦截能力就不完整。

1. 消融实验的第一原则是什么？

答：单变量原则——一次只改一个因素，否则结果不可归因。

1. 100 题评测上提升 1.2 个点，能下结论吗？

答：不能。1.2 个点≈1 道题，通常在种子波动带内；应复跑种子确认差距超出波动带再下结论。