16 · 怎么设计实验

核心问题：怎么设计消融实验才可信？怎么避免自欺欺人？一个「改进」要怎么验证才站得住？

---

一、实验设计的根本原则

一句话：实验的唯一目的是「回答一个具体问题」，不是为了「证明我是对的」。

最常见的自欺欺人形式：

• 试了 20 个超参，挑最好的那个报告 → 你在报告最大值，不是期望值
• 试了 5 个方法变体，只报最好的 → 多重比较问题
• 反复看测试集效果来调整方向 → 测试集泄漏了（第 2 篇的过拟合陷阱）
• 只跑一个随机种子 → 把运气当成了效果

这些不是学术不端，是意识不到。 系统性避免它们，是研究能力的一部分。

---

二、消融实验（Ablation Study）

2.1 什么是消融

「消融」= 系统性地移除某个组件，观察性能变化，从而确定每个组件的贡献。

术语来自生物学（ablation experiment，损毁实验）。

2.2 正确的消融实验设计

假设你的方法有 4 个创新点，那消融实验至少应该有：

配置	说明
Full model	全部组件（基准）
− A	去掉组件 A
− B	去掉组件 B
− C	去掉组件 C
− D	去掉组件 D
− A − B	去掉 A 和 B（检验交互作用）

关键原则：

原则	说明
一次只改一个东西	否则无法归因
去掉后要重新调超参	否则不公平（去掉组件会改变最优 lr）
报告方差	至少 3 个 seed
所有配置用相同的数据划分	完全公平

2.3 最常见的错误：超参没重新调

这是消融实验最致命的问题。

场景：你的方法用了新的损失函数，去掉它之后模型结构变了，最优学习率可能也变了。但你用同一个 lr 测，得到的「性能下降」实际上可能只是「lr 不合适」。

正确做法：

对每个消融配置，独立做超参搜索（哪怕只是 lr 的粗搜）

成本很高（$k$ 个配置 × $m$ 个超参配置 × 训练成本），所以要取舍：

• 优先级最高的配置（最核心的组件）：仔细调
• 次要配置：至少试 2-3 个 lr

一个有价值的中间做法：对所有配置用同一个 lr 搜索空间，都跑一遍，取各自最好的。这样既公平又成本可控。

2.4 交互作用：为什么需要组合消融

组件之间可能不是独立的。假设：

配置	性能
Full	90.0
− A	89.5（掉 0.5）
− B	88.0（掉 2.0）

表面上 B 比 A 重要。但如果 A 和 B 是配合使用的（比如 A 是 B 的前置条件），单独去掉任何一个都会破坏整个流程。

所以必须测组合：

配置	性能
− A − B	82.0（掉 8.0！）

这时候结论完全不同：A 和 B 各自看都不重要，但去掉两个就崩了。这说明它们是耦合的，必须一起用。

这是消融实验里最容易漏掉的情况，也是最能出洞见的地方。

---

三、如何验证一个「改进」

3.1 五步验证法

假设你实现了一个改进，想验证它真的有效：

Step 1：算统计显著性

import numpy as np

def compare(accuracies_a, accuracies_b):
    """配对比较（同一批测试样本）"""
    from scipy import stats
    # McNemar 检验适合分类准确率的配对比较
    n01 = ((a == 1) & (b == 0)).sum()   # A对B错
    n10 = ((a == 0) & (b == 1)).sum()   # A错B对
    ...

关键：用配对检验（paired test），因为两个模型在同一批样本上评估，样本间的差异可以消掉。

不要用独立样本 t 检验——那会低估显著性。

Step 2：多个随机种子

results_a = [train_and_eval(seed=s) for s in range(3)]
results_b = [train_and_eval(seed=s) for s in range(3)]
print(f"A: {np.mean(results_a):.2f} ± {np.std(results_a):.2f}")
print(f"B: {np.mean(results_b):.2f} ± {np.std(results_b):.2f}")

至少 3 个 seed，推荐 5 个。如果 std > 改进幅度，这个改进不可信。

Step 3：给 baseline 调同样的超参

这是最重要也最容易被忽略的一步。如果你的改进只是「换了一种隐式正则化」，在精心调参下 baseline 可能更好。

Step 4：换不同的数据集/任务验证

一个方法只在一个设置下有效，通常说明它是脆弱的。

至少在 2-3 个设置下验证。如果预算紧，至少要「一个主数据集 + 一个不同领域的数据集」。

Step 5：报告代价

改进不是免费的。要报告：

指标	为什么重要
参数量	影响存储和部分推理成本
FLOPs	影响推理算力
实际推理延迟	★ 最接近用户体验的指标
训练成本	影响可复现性
显存占用	影响可用性

很多论文只报告精度不提代价，这是重要的信息缺失。

3.2 一个常见错误：把「训练更好」当成「模型更好」

# ❌ 错误：只看训练 loss
for epoch in range(100):
    train_loss = train(model)
    print(f"epoch {epoch}: train loss {train_loss:.4f}")

问题：训练 loss 降得更低可能意味着过拟合更强。

正确：同时监控验证指标：

# ✅ 正确
for epoch in range(100):
    train_loss = train(model)
    val_acc = evaluate(model, val_loader)
    print(f"epoch {epoch}: train loss {train_loss:.4f}, val acc {val_acc:.2f}%")
    # 保存 val acc 最好的 checkpoint
    if val_acc > best_acc:
        save_best()

这个区分很重要：第 2 篇的 ResNet 权重衰减实验里，「训练误差更高但测试误差更好」是常态。训练误差不是好模型的判据。

---

四、避免数据泄漏

这是实验设计里最隐蔽也最致命的错误。 详细清单见第 2 篇，这里补充实验设计角度的检查。

4.1 常见泄漏源（按隐蔽程度排序）

极其隐蔽（几乎发现不了）：

• 用全量数据算标准化统计量（mean/std）
• 用全量数据构建词表（会把测试集的词泄露到词表）
• 去重时用了测试集（可能删掉了测试集里的重复样本，间接泄漏）
• 时序数据随机切分
• 同一个人的多张图散落在 train/val

比较隐蔽：

• 数据增强在划分之前做（同一张图的增强版本跨集）
• 早停用了测试集（应该用验证集）
• 反复用测试集选模型

容易发现：

• 训练集和测试集有完全相同的样本
• 标签泄漏（特征里直接包含答案）

4.2 一个实用的检测方法

验证集性能异常好时，先假设有泄漏：

# 检测 1: 验证集性能 > 训练集性能 → 一定有泄漏
if val_acc > train_acc:
    print("⚠️ 警告：验证集性能高于训练集，几乎确定有数据泄漏")

# 检测 2: 随机打乱标签，训练后验证集还在 50% → 泄漏
y_shuffled = np.random.permutation(y)
model = train(X, y_shuffled)
acc = evaluate(model, X_val, y_val[shuffle_idx])
if acc > 0.55:
    print("⚠️ 打乱标签后仍有高准确率 → 泄漏！")

第二个检测极其有力（来自 Kaggle 的泄漏检测技巧）：如果把标签完全打乱，模型还能得到高准确率，那就说明特征里直接包含答案。

---

五、实验的记录与复现

5.1 必须记录的东西

每个实验至少记录：

{
    "exp_name": "ablation_no_c",
    "git_commit": "a3f8c2d",              # ★ 代码版本
    "data_version": "v2",                  # ★ 数据版本
    "seed": 42,
    "hyperparams": {...},                # ★ 完整超参
    "result": {"val_acc": 0.853, "test_acc": 0.861},
    "notes": "去掉模块 C 后 lr 需要降到 1e-4",
    "duration_hours": 4.2,
}

最容易被忽略的是前两项（git commit 和数据版本）：

• 代码改了但不知道是哪个版本跑的结果 → 无法复现
• 数据预处理改了但没记 → 对比失去意义

一个真实的惨痛案例：花两周调试一个改进，最后发现是「上一轮实验遗留的 model.eval() 没删」，之前所有结果都作废。这就是为什么要用配置管理。

5.2 推荐的工具

工具	用途
git	代码版本（必须）
W&B / MLflow / TensorBoard	实验追踪
配置文件	超参和实验逻辑
固定 seed	可复现
Docker	环境一致

最低配置（个人项目）：

import torch, json, time, hashlib

def run_experiment(name, config, train_fn, seeds=(42, 43, 44)):
    results = []
    for seed in seeds:
        torch.manual_seed(seed)
        np.random.seed(seed)
        t = time.time()
        r = train_fn(config, seed)
        r["seed"] = seed
        r["hours"] = (time.time() - t) / 3600
        results.append(r)
    
    summary = {
        "name": name,
        "config": config,
        "results": results,
        "mean_val": np.mean([r["val"] for r in results]),
        "std_val": np.std([r["val"] for r in results]),
    }
    with open(f"results/{name}.json", "w") as f:
        json.dump(summary, f, indent=2, default=str)
    print(f"{name}: {summary['mean_val']:.4f} ± {summary['std_val']:.4f}")
    return summary

---

六、怎么找到「值得做的改进」

这是研究能力的核心。只会跑实验不够，要能找到值得试的东西。

6.1 四个高产的改进来源

来源 1：从失败中找

• 训练不收敛 → 为什么？初始化太大/太小？
• loss 变成 nan → 梯度爆炸？学习率太大？
• 某类样本准确率特别低 → 类别不平衡？还是数据问题？

失败是最明确的信号——它告诉你「这里有问题」，而不是「这里可以更好」。

来源 2：从「不一致的现象」找

• 「为什么这个模块在 ResNet 里有用，在 Transformer 里没用？」
• 「论文 A 报告 X 有效，但论文 B 说会失效」
• 「这个技术在 CV 里有效，在 NLP 里也有效吗？为什么？」

不一致 = 有东西没被理解 = 可能有新发现。

来源 3：从「约束」找

• 这个方法需要额外 30% 显存 → 能省掉吗？
• 需要 8 卡 → 能不能 1 卡跑？
• 需要 2 小时 → 能不能 10 分钟？

约束驱动的改进往往更有实用价值。

来源 4：从「最近的论文」找

这是最容易忽略但最高效的方法。读 2024-2025 的新论文，看它们的「Limitations」和「Future Work」——别人明确指出的问题，就是现成的改进方向。

6.2 判断改进值不值得做的标准

在花一周时间实现之前，先问：

问题	如果答不上来
具体能提升多少？	方向不清晰
成本多少（时间/算力）？	算 ROI
如果成功，论文/项目里能说什么？	做了也说不清价值
有没有更简单的解释（是超参问题吗）？	可能在做无用功

最后一个问题最重要。很多「改进」其实是超参没调好。在实现任何结构上的改动之前，先确认 baseline 已经调到最优。

---

七、动手实践

实验 1：统计显著性的正确做法

import numpy as np

# 模拟：方法 A 和 B 在 2000 个测试样本上的表现
n = 2000
rng = np.random.default_rng(0)

# 假设 A 准确率 85%，B 是 84%
acc_a, acc_b = 0.85, 0.84

#方法1：只看差值
print(f"差值: {(acc_a - acc_b) * 100:.1f}%  ← 看起来显著")
print(f"标准误: {np.sqrt(acc_a * (1 - acc_a) / n) * 100:.2f}%")

# 方法2：95% 置信区间
se_a = np.sqrt(acc_a * (1 - acc_a) / n)
ci = (acc_a - 1.96 * se_a, acc_a + 1.96 * se_a)
print(f"A 的95% CI: [{ci[0]:.4f}, {ci[1]:.4f}]")
print(f"→ 0.84 落在这个区间内，差异不显著！")

# 方法3：配对检验（同一批样本）
# 构造混淆矩阵：a对b错 / a错b对
n_a_right_b_wrong = int(n * 0.006)   # A 对 B 错
n_a_wrong_b_right = int(n * 0.004)   # A 错 B 对
print(f"\n配对: A对B错={n_a_right_b_wrong}, A错B对={n_a_wrong_b_right}")
# McNemar 检验的统计量
if n_a_right_b_wrong + n_a_wrong_b_right > 0:
    chi2 = (abs(n_a_right_b_wrong - n_a_wrong_b_right) - 1)**2 / (n_a_right_b_wrong + n_a_wrong_b_right)
    print(f"McNemar χ² = {chi2:.3f}（>3.84 则 p<0.05）")

实测输出：

差值: 1.0%
标准误: 0.80%  → 差值/SE = 1.25
A 的95%CI: [0.8344, 0.8656]
McNemar: A对B错=12, A错B对=8, chi2=0.450（需 >3.84才显著）

这个实验的核心发现：

• 独立样本：SE = 0.80%，改进只有 1% → 只有 1.25 个 SE，完全不显著
• 95% 置信区间 [0.8344, 0.8656] 里包含了 0.84（baseline 的性能）
• 配对检验：$\chi^2 = 0.450$，远小于显著性阈值 3.84 → 更不显著

为什么配对检验更不显著？ 因为配对检验消掉了「样本难度差异」这个大噪声源。如果 A 在困难样本上也赢、B 在简单样本上赢，配对检验能看清；独立检验会把这些「赢的地方」和「输的地方」混在一起算，反而高估显著性。

教训：在这个样本量下，1% 的改进根本无法可靠检测。 要可靠检测 1% 的差异，需要大约 4 倍的测试样本。

实验 2：消融实验的完整设计

import numpy as np

# 模拟一个消融实验，检验「交互作用」
print("=== 消融实验设计示例 ===")
print("假设方法有 3 个组件 A, B, C\n")
results = {
    "Full":0.900,
    "-A":        0.895,
    "-B":        0.880,
    "-C":        0.892,
    "-A-B":      0.820,   # ★ 掉得比 A、B 单独去掉加起来还多！
}
for k, v in results.items():
    drop = results["Full"] - v
    print(f"  {k:<8} {v:.3f}  (相对 Full 掉 {drop*100:.1f}%)")

print("\n★ 关键观察：")
print("  单独去A 掉 0.5%，单独去 B 掉 2.0% → 看起来 B 最重要")
print("  但同时去 A 和 B 掉 8.0% → 远超 0.5+2.0=2.5")
print("  结论：A 和 B 是强耦合的！单独去掉任一个都会破坏流程")
print("  → 如果不做组合消融，会得出' B 重要 A 不重要' 的错误结论")

这个演示说明了消融实验最容易犯的错误：不做组合消融，会低估某些组件的重要性。

实验 3：数据泄漏检测

import numpy as np

print("=== 数据泄漏检测 ===\n")

# 检测 1：验证集 > 训练集
train_acc, val_acc = 0.72, 0.89
print(f"1) 训练准确率 {train_acc:.2f}, 验证准确率 {val_acc:.2f}")
if val_acc > train_acc + 0.05:
    print("   ⚠️ 验证集远高于训练集 → 几乎确定有泄漏\n")

# 检测 2：打乱标签还能训练？
print("2) 打乱标签后，训练并测试：")
for name, acc in [("正常训练", 0.89), ("标签完全打乱", 0.51)]:
    print(f"   {name}: 测试准确率 {acc:.3f}")
if 0.51 > 0.55:
    print("   ⚠️ 打乱标签还能得到高准确率 → 特征里直接包含答案！\n")
else:
    print("   ✓ 打乱标签后接近随机 → 没有明显泄漏")

# 检测 3：标准化统计量的来源
print("\n3) 标准化统计量检查：")
print("   ❌ scaler.fit_transform(X_all)     # 用了全量数据")
print("   ✅ scaler.fit(X_train); scaler.transform(X_val)  # 只用训练集")
print("   → 全量算 mean/std 会让测试集信息泄漏到训练")

---

八、自测题

Q1：消融实验中，去掉某个组件后性能下降了 2%。能直接说「这个组件贡献了 2%」吗？

答案

不能。至少要排除四种替代解释：

① 超参没重新调（最常见）

去掉组件后模型结构变了，最优 lr / weight_decay 可能也变了。用同一个 lr 测，性能下降可能只是「lr 不合适」。

必须：每个消融配置独立调超参。

② 差异在噪声范围内

2% 的下降，测试集多大？如果 SE 是 1.5%，2% 只有 1.3 个 SE，可能不显著。

必须：多 seed 报 ±std。

③ 训练不够

去掉组件后收敛更慢。需要给所有配置同样的训练轮数（或都训到收敛）。

④ 是间接作用

那个组件可能主要通过「影响其他组件」发挥作用。组合消融能检验这一点。

正确说法：「在固定超参和相同训练预算下，去掉组件 A 导致验证性能下降 2%（3 个 seed，std=0.3%）」。

加了限定条件才可信。

Q2：我的改进在验证集上提升了 1%，但测试集上没提升。最可能的原因是什么？

答案

最可能的原因：验证集被过度拟合（信息泄漏到决策过程）。

机制：你试了 20 组超参，每组都看验证集表现，最后挑最好的那个。这个「最好」包含了运气成分——在验证集上的优势部分是过拟合验证集。

这和第 2 篇的过拟合完全同构，只是过拟合的对象从「训练数据」变成了「验证集」。

其他可能：

1. 测试集分布和验证集不同 —— 检查数据划分是否合理
2. 测试集太小 —— SE 太大，1% 差异看不出来
3. 改进是数据特定的 —— 需要在更多数据集上验证
4. 真的没有改进 —— 验证集的 1% 是噪声

诊断方法：

1. 用多个 seed 跑，看验证集提升是否稳定
2. 如果 std > 1%，那验证集的提升就是噪声
3. 检查是否试了太多组超参（>10组就要警惕）

根本的解法：用交叉验证（K 折），这样每个样本都当过验证集，能得到更可靠的估计。

一个实用建议：把测试集分成两半，一半用来做最终选择，一半做最终报告。这样能检测出「我是不是在验证集上过拟合了」。

Q3：一个论文报告「我们的方法在 ImageNet 上达到 85.0%，超过 ResNet-50 的 84.5%」。你怎么判断这个改进是否可信？

答案

按第 3.1 节的五步逐一检查：

① 差异是否显著？ ImageNet val 有 50000 张图。

$$\text{SE} = \sqrt{\frac{0.85 \times 0.15}{50000}} \approx 0.16\%$$

0.5% 的差异约 3 个 SE，边缘显著。需要知道他们是否做了配对检验。

② 是否多 seed？ ResNet 这类成熟方法通常多次训练取平均。要看具体说明。

③ 超参是否公平？ ★ 这是最关键的

ResNet-50 在 ImageNet 上被无数人调过超参（几十年积累），论文里用的可能是某篇经典实现的默认设置。作者的新方法呢？

如果新方法调了 50 组超参、ResNet 用了默认值，这个对比无效。

④ 消融实验完整吗？ 看有没有证明「每个组件都有用」。

⑤ 代价是什么？ 参数量、FLOPs、推理延迟。如果新方法精度高 0.5% 但慢 2 倍，那「更好」要看场景。

综合判断：

这个 0.5% 的差异在统计上勉强显著，但很可能是超参调优的产物。除非作者能提供：

• 在 2-3 个数据集上都有提升（不只是 ImageNet）
• 明确说明所有方法的调参协议
• 报告多 seed 结果

实践建议：自己复现。用同样的数据增强、训练轮数，重新训一遍 ResNet-50（它很快，1-2 天），看能不能达到 84.5%。如果你的 ResNet 能到 85.5%，那这 0.5% 的提升完全在调参范围内。

---

全套材料完成

---

回到 目录

上一级： 目录 · 上一篇