图像分类模型的排行榜，从来都不是中立标尺。同一组模型，只要换一下预处理、随机种子、增强策略或者训练轮数，榜单顺序很可能重新排列。配置变化导致模型排名大幅波动，这不是实现失误，而是一个系统性问题：评价基准本身就写满了实现者的偏好。我经常对团队说，无中立基准的意思是，没有一份榜单能脱离配置独立存在；你能做到的是把配置说清楚，把波动范围算出来，再得出一个比“谁是第一”更有意义的结论。
如果你经常做模型选型、跑 benchmark、给内部团队出评估报告，这篇文章值得看完。我会先解释排名为什么不稳，再用一个小型图像分类实验演示配置变化如何重排榜单，接着整理容易把排名打乱的配置变量，以及怎么判断模型差异是真领先还是噪声，最后给出一套可以长期使用的内部评测流程。
1. 为什么一个图像分类榜单会被配置改写
1.1 基准不是自然事实，而是一堆决策叠加的结果
很多人把“图像分类模型排名”理解成一场考试：试卷固定，阅卷标准固定，考生按分数排队。事实上，模型评测更像一个比赛，但出题人、监考人、阅卷人和考试场地全都参与了结果生成。
一份基准看起来只是数据集加准确率，拆开之后至少包含这些环节：
- 数据集怎么划分，训练集、验证集、测试集有没有交叠
- 图片怎么解码、缩放、裁剪、归一化
- 训练时用哪种优化器、什么学习率、多少轮
- 有没有数据增强，增强强度多大
- 推理时输入分辨率是多少，是否使用多尺度测试
- 指标是单一 Top-1 平均准确率，还是每个类别单独统计之后再平均
- 多轮训练时随机种子是否一致
任何一个环节发生变化，都会改变模型拿到的信息、训练过程和最终输出。
问题在于，大多数时候我们比较两个模型，默认它们“在相同条件下测试”，但实际落地时“相同条件”非常难保证。不同项目可能用了不同的预处理库，不同分支可能改了数据增强，不同团队可能对同一份数据做了不同拆分。表面上是模型排名，实际上是评价配置在排名。
1.2 配置变化不是不公平，而是让排名失去可解释性
有人可能会说：既然所有人都在同样的 benchmark 上报成绩，排名不就是公平的吗？
关键在于“同样的 benchmark”指什么。如果你只看论文里那张排行榜，所有模型确实都报了 ImageNet 测试集准确率，但训练细节、增强策略、推理技巧可能差得远。两个模型的准确率可能只差 0.2%，但其中一个用了更复杂的测试时增强，另一个用的是朴素推理。这种差距是真的模型能力差距，还是配置红利，很难区分。
另一个更隐蔽的问题是：即便两个模型在同一份测试集上测出来分数接近，也不代表它们在真实业务场景中接近。测试集只能反映数据分布的一部分，而模型排名依赖测试集和评价协议。没有中立基准，只有适合当前任务的基准。
我认为比较合理的态度是：不把榜单当成真理，而是当成一份需要参数说明的观察记录。
1.3 精确的小数点掩盖了统计噪声
很多排行榜会显示类似“92.41% vs 92.38%”的差距。单看数字，前者确实更高。但这个差距可能完全落在随机波动范围内。
模型训练本身是随机过程，随机种子一变，最后准确率就可能浮动零点几个百分点。测试阶段如果使用随机增强、重复采样或动态批处理，推理结果也可能有波动。统计噪声没有被纳入比较时，任何细微的配置差异都可能改变模型排名。
我一般会先问三个问题：
- 这个分数是单次运行还是多次运行的平均值
- 两个模型的评估代码是否来自同一套管线
- 0.3% 以内的差距在本任务中是不是噪声
如果这三个问题都不清楚，排行榜上的先后顺序基本不具备决策价值。
2. 用一个可控实验演示：配置一变，排名就翻
2.1 实验设计
为了把“配置变化导致模型排名大幅波动”这件事具体化，我在内部做过一个简化实验。这里不给具体性能数据，只讲实验方法和结果形态，因为真实数据会随数据集和机器变化。你可以直接用同一套流程在自己环境里复现。
实验目标：比较 3 个能力接近的图像分类模型，看不同配置下排名是否稳定。
准备条件：
- 小型图像分类数据集，几百张图片，5 个类别
- 3 个模型，结构差异不大，比如两个同规模模型加一个有轻微结构差异的版本
- 3 套配置，每套只改数据增强、训练轮数和随机种子
- 每套配置下每个模型独立训练、独立测试
这里的关键是：模型不变、数据集不变、测试集不变，唯一变化的是训练配置。如果配置改变后排名重排，就说明榜单本身受配置影响很大。
2.2 实验流程示例
下面是一个简化版运行流程，用来记录多个配置下的模型排名。
# 伪代码，仅用于展示评估流程 import itertools configs = [ {"seed": 0, "epochs": 30, "augment": "light"}, {"seed": 1, "epochs": 50, "augment": "strong"}, {"seed": 2, "epochs": 30, "augment": "strong"}, ] models = ["model_a", "model_b", "model_c"] results = {} for cfg in configs: for model in models: acc, std = train_and_evaluate(model, cfg, repeats=3) results[(model, cfg)] = acc print(model, cfg, acc, std) # 对每个配置生成一个排行榜 for cfg in configs: rank = sorted(models, key=lambda m: results[(m, cfg)], reverse=True) print(cfg, "排名:", rank)实际使用中，train_and_evaluate会包含数据加载、预处理、训练、验证、测试和结果记录。这里建议至少重复 3 次取平均，否则单次结果很容易受随机波动影响。
2.3 我遇到的一类结果形态
跑完后的结果通常会呈现下面这种形态，注意这里只是结构示意，不是某个具体模型的成绩。
| 配置 | 第一名 | 第二名 | 第三名 |
|---|---|---|---|
| 配置 A | 模型 A | 模型 B | 模型 C |
| 配置 B | 模型 B | 模型 A | 模型 C |
| 配置 C | 模型 C | 模型 A | 模型 B |
三个模型在不同配置下分别拿过第一。如果把某个配置下的排名当成最终结论，就会得到三个互相矛盾的故事。
更常见的情况是：模型 A 在某个配置下领先很多，换一个配置后落后；模型 B 在多数配置下都处于中游，但某个配置下冲到第一。这就是典型的不稳定排名：优势没有跨配置一致性。
2.4 实验后第一件事不是选模型，而是算波动范围
做完这种实验，我建议把每个模型在多配置下的准确率看成一组数字，而不是一个排名位置。
对每个模型画出均值加减标准差的范围，然后看两个模型的范围是否重叠。如果重叠很大，说明这两个模型在此评测流程中没有明显优劣。如果完全不重叠，再谈排名才有意义。
不要一上来就写结论“模型 A 排名最高”，而是先写“模型 A 和各配置的相对领先范围在 0.1% 到 1.2% 之间，配置敏感度较高”。这样后续决策才靠谱。
3. 图像分类评测里，哪些配置最容易把排名打乱
3.1 数据侧：归一化、增强和拆分都是隐藏杠杆
数据侧最容易被忽略，影响却最直接。
归一化方式会影响模型输入分布。有的模型适合用 ImageNet 统计量做标准化，有的模型更贴近零中心数据。如果所有模型共同使用同一组归一化参数，可能对某些模型更友好，对另一些模型不友好。最后排名里可能包含“谁更适配这套预处理”的成分。
数据拆分也很关键。训练集和测试集如果划分方式不同，单个类别的难度会产生变化。尤其是类别样本不均衡时，随机划分可能让某类测试图片集中到特定子集里，导致某个模型偶然占便宜。
数据增强强度的影响更大。轻增强下，模型容易过拟合，小模型可能表现更好；强增强下，大模型能吃更多数据变化，反而可能翻身。增强策略本质上在改变训练任务的难度分布。
建议在对比实验中固定同一份拆分、同一个增强策略、同一套预处理代码，并把增强参数写进配置记录。
3.2 训练侧：随机种子、学习率、训练轮数和 batch size
训练侧每一项都可能改变最终权重。
随机种子影响权重初始化、数据批次顺序和 dropout 行为。不同种子下，同一个模型的准确率可能差出 0.2% 到 0.5%，这在排行榜上足够改变相邻位置。
学习率是超参数里最敏感的一个。一个模型可能在默认学习率下表现一般，但在更低学习率下慢慢收敛到更好结果。另一个模型可能恰好相反。
训练轮数同样关键。有的模型 30 轮就过拟合，有的模型 60 轮才稳定。如果统一训练 30 轮，等同于给慢收敛模型设置上限。
batch size 影响梯度估计和 BatchNorm 统计量。同一模型在 batch size 64 和 256 下的结果可能明显不同。
这些变量很难完全公平。实际做法不是追求绝对公平，而是把所有变量固定并公开，让排名结果可以追溯。
3.3 推理侧：输入分辨率、TTA 和混合精度
很多人在训练配置上很较真，一到推理阶段就随便设置，这也会造成排名波动。
输入分辨率是最常见的干扰项。有些模型在 224 分辨率下表现一般，在 384 分辨率下提升明显。如果不同模型用相同分辨率，可能对某些需要更大分辨率的模型不公平；如果用各自最优分辨率，榜单又不再统一。
测试时增强 TTA 的影响也很大。一个模型用了多尺度测试加水平翻转，另一个模型只做单次推理，前者分数会明显更高。这种增益不代表模型能力更强，只代表推理策略更复杂。
混合精度推理偶尔会带来微小误差。大规模模型在 FP16 下可能出现数值偏差，导致个别样本预测变化。对比实验里要固定是否开启混合精度。
建议把所有推理参数和测试策略写进评测协议，不能只看“测试集准确率”五个字。
3.4 指标侧：Top-1、宏观平均和子集成绩不是同一件事
很多人把“准确率”理解成唯一指标，实际上“准确率”的定义可以拆成好几种。
Top-1 准确率看预测类别是否等于真实类别。Top-5 准确率看真实类别是否出现在前五个预测里。两者各有偏向，有的模型 Top-1 不高，Top-5 很高。
类别平均准确率是先算每个类别的准确率，再对所有类别取平均。当类别不均衡时，类别平均和整体准确率会有差异。一个在大类上表现好、小类上差劲的模型，整体准确率可能更高，但类别平均更低。
还有人只报告某个子集上的成绩，比如“夜间图片准确率”、“容易混淆类别上的准确率”。这类子集指标容易受测试样本数量的影响，稳定性更差。
| 层级 | 典型配置项 | 对排名的影响 | 建议 |
|---|---|---|---|
| 数据 | 归一化、增强、拆分 | 高 | 固定并记录，禁止各自调整 |
| 训练 | 种子、学习率、轮数、batch size | 高 | 多种子取均值 |
| 推理 | 分辨率、TTA、混合精度 | 中高 | 统一推理协议 |
| 指标 | Top-1、类别平均、子集 | 中 | 同时报告多个指标 |
4. 怎么判断一个模型是不是真的更好
4.1 先看差异置信区间，再看先后名次
要判断模型 A 是否真的优于模型 B，不能只看各自准确率的点估计。点估计像是一次抽签结果，可能今天 A 高，明天 B 高。
更好的做法是对同一测试集做多次重复评测，或者对测试集做 bootstrap 采样，得到准确率分布。然后计算 A 和 B 的准确率差值分布。
如果差值分布的大多数值都大于 0，说明 A 领先 B 的证据比较强。如果差值分布在 0 左右来回跨越，说明两者差异在统计噪声范围内。
4.2 一个简单的差值计算方法
import numpy as np # 示意代码：对测试集预测结果做多次采样，估计准确率差值分布 def bootstrap_accuracy(preds, labels, n_bootstrap=1000): n = len(labels) accs = [] for _ in range(n_bootstrap): idx = np.random.choice(n, n, replace=True) acc = np.mean(preds[idx] == labels[idx]) accs.append(acc) return np.array(accs) preds_a = np.array([...]) # 模型A的预测结果 preds_b = np.array([...]) # 模型B的预测结果 labels = np.array([...]) # 真实标签 diff = bootstrap_accuracy(preds_a, labels) - bootstrap_accuracy(preds_b, labels) print("差值置信区间:", np.percentile(diff, [2.5, 50, 97.5]))如果置信区间跨过 0，保守结论是“无法判断哪个模型更优”。如果区间整体大于 0，才能下结论说 A 在当前评测协议下更优。
需要注意的是，Bootstrap 只能反映测试集采样带来的波动，不能覆盖训练随机性。如果训练阶段也受种子影响，还要对每个模型跑多个种子。
4.3 用成对胜率矩阵替代“唯一排行榜”
很多内部评测最终要输出一张排行榜，但排行榜天然只有一个第一名。团队需要知道的不只是第一名是谁，还有两两比较时谁更稳定。
我会额外输出一个成对胜率矩阵。比如模型 A 和模型 B 在多组配置下比较，A 胜出几组、B 胜出几组、分不出胜负几组。
| 对比 | A 胜 | B 胜 | 无明显差异 |
|---|---|---|---|
| 模型 A vs 模型 B | 5 | 3 | 2 |
| 模型 A vs 模型 C | 4 | 4 | 2 |
| 模型 B vs 模型 C | 2 | 6 | 2 |
矩阵比单列排名更能反映真实稳定性。只有某个模型在和所有候选对比中都稳定胜出，才适合写进最终结论。
4.4 设一个“可接受差异”阈值
不要只看 p 值，还要看差异有没有业务意义。假设模型 A 比模型 B 高 0.1%，统计检验显示显著，但这个提升可能不值得增加一倍推理耗时。
我建议在评测前先定一个业务阈值：比如准确率提升超过 0.5% 才认为候选模型可以替代基线；低于这个阈值，不推荐切换。这样能避开“统计显著但业务无用”的决策陷阱。
5. 把内部评测从一次评选改成一套可复现流程
5.1 先冻结评测协议
正式评测开始前，用文字或代码仓库固定协议，至少包含：
- 数据集和拆分方式
- 预处理与增强策略
- 训练超参数
- 推理参数
- 评估指标
- 随机种子范围
冻结之后不许在评测中途修改。一旦发现配置有问题，停止评测，修改协议后重新开始。
5.2 配置即代码，记录即复现
尽量把训练和评测封装成脚本，所有配置写进文件。目录结构可以这样组织：
experiment/ configs/ baseline.yaml model_a.yaml model_b.yaml data/ dataset_info.json scripts/ train.py evaluate.py results/ metrics.csv per_class.csv predictions/每次跑完，把配置文件、版本号、commit hash、GPU 信息、运行时间一并保存。这样后续排查“这个成绩怎么来的”会快很多。
5.3 不要只保存一项准确率
很多评测只保存一个最终准确率，这会导致一个问题：榜单变了，不知道是因为模型确实更好，还是因为某个类别的样本被改动。
建议至少保存：
- 总体准确率
- 每类准确率
- 混淆矩阵
- 每个测试样本的预测结果
- 多次运行的均值、标准差
- 关键配置快照
这些信息在后期做诊断时非常有用。比如某次实验模型 A 突然超过模型 B，打开每类准确率，可能发现是某个小类别被模型 A 意外处理得更好，而不是整体能力提升。
5.4 多配置、多种子跑，而不是运气好跑一次
我在实际项目中会为每个模型至少跑 3 个种子。如果资源紧张，至少也要在测试阶段用多份数据采样评估多次，得到稳定性指标。
种子数越多，排名越可靠。单个种子下的第一名经常是随机抽签结果。多个配置和多个种子下的中位排名，比一次运行的最高准确率更有参考价值。
5.5 任何环节变更后，都要重新评估
数据集换版本、代码升级、预处理库变动、模型训练框架变化，都可能改变测试结果。
变更后不要只在旧结果上补一句“逻辑等价”，建议重新跑一遍关键对比。尤其是预处理库的边界行为，比如 resize 插值方式和归一化默认值，在不同版本之间可能悄无声息地变化。
6. 踩坑记录：排名翻车的常见原因和排查顺序
6.1 榜单上的分数不是同一套协议
最常踩的坑，是把不同来源的准确率拉到一起比较。论文里的分数可能使用了多尺度测试，内部实验用的是单尺度；某个模型的其他复现版本可能调整过训练轮数。
遇到这种情况，先不要问“为什么模型 A 一到我这里就比不过模型 B”，要问“我复现的是不是它报告里那一套协议”。
6.2 第一次跑出来的高分数，后面复现不了
出现这种情况时，优先检查四件事：
- 随机种子：是否固定，是否因为环境变量导致每次初始化不同
- 数据加载：图片读取顺序、缓存、解码库有没有差异
- 归一化：有没有在数据增强流程里意外重复归一化
- 精度模式：混合精度开关是否一致
很多时候问题不在模型结构，而在数据管线的偶然差异。
6.3 测试集信息污染
这是更严重的问题。如果训练时不小心把测试集图片放进验证集做早停，或者数据增强过程使用了测试集统计信息，模型分数会虚高。这种问题比较隐蔽，因为代码能跑通，损失也在下降，但实际结果不可信。
评测前先用数据哈希或集合交集检查训练集和测试集是否存在重叠。大模型领域更要注意预训练数据是否包含与测试类别高度相似的图片，这也是很多外部榜单在特定场景下失效的原因。
6.4 只看平均准确率，不看失败模式
两个模型平均准确率相同，但失败样本可能完全不一样。模型 A 在纹理复杂的图片上表现好，在低光图片上差；模型 B 正好相反。
如果业务场景是低光图片，模型 B 即使整体准确率略低，也是更适合的选择。通过每类准确率和错误样例对比，能避免被榜单误导。
6.5 遇到模型排名突然变化时的排查顺序
我一般按这个顺序查：
- 先确认测试集是否同一份，文件数量和标签是否对得上
- 再对比预处理配置，尤其是裁剪方式、归一化参数、插值方法
- 然后检查训练配置，种子、轮数、学习率是否发生变动
- 接着看推理配置，分辨率和 TTA 是否一致
- 最后做多轮重复验证，确认变化是稳定趋势还是随机噪声
如果排到第 5 步还是没有结论，我会生成一组对照实验，固定单一变量，逐步定位哪一项配置造成了排名反转。
评测模型排名这件事，本质上是在控制所有变量之后，再讨论能力差异。无中立基准不是一个悲观的结论，它提醒我们：先让配置、日志和重复性变得可信，排名才具有参考价值。我更建议把单次跑分当成起点，把多配置、多种子、差异区间和成对胜率当成正式结论。踩过几次坑之后你会发现，很多“模型翻车”根本不是模型的问题，而是评测流程没有把变量锁住。
