1. 先说清楚：审稿人看baseline时，到底在看什么
做研究的人大概都经历过这个场景：模型跑通了，指标涨了，兴冲冲把论文投出去，结果审稿意见回来一句“The baselines are not competitive”或者“The comparison is not fair”，瞬间心态就崩了。不少人在这一步栽跟头，不是因为方法本身不行，而是对比实验没做到位，让审稿人抓住了把柄。
先说结论：baseline对比实验不是“跑几个方法、填一张表”的体力活，它本质上是一场说服工作——你要说服审稿人相信三件事。第一，你的方法确实有效，不是调参调出来的偶然结果；第二，你对自己的方法有足够清晰的认识，知道它强在哪里、弱在哪里；第三，你给整个领域提供了可复现、可参考的基准，而不是在“田忌赛马”。
审稿人面对一篇论文时，通常会有几个默认的怀疑。他们会想：你的baseline是不是挑软的捏？你是不是只用了对自己有利的数据集？你的改进是不是来自更多参数、更多计算量，而不是方法本身的贡献？你的结果是不是只跑了一次，运气好？这些问题，每一项都需要用对比实验的设计来正面回答。换句话说，对比实验是你的方法走向“可信”的唯一途径。
这篇我就把整套逻辑拆开来讲：从baseline怎么选、怎么跑、怎么保证公平，到结果怎么分析、怎么呈现、怎么回应审稿人的质疑，每个环节的关键操作和常见坑点都过一遍。无论你是刚开始做研究的硕士生，还是正在赶论文的博士生，只要按这条线把对比实验做扎实，审稿人那一关会好过很多。
2. 选baseline：不是越多越好，是越“对”越好
2.1 先搞清楚baseline的四类角色
很多人在选baseline的时候有个误区：以为把能想到的方法全跑一遍，堆出七八个对比方法，论文就显得很扎实。实际上，审稿人并不傻，一堆无关方法只会让人觉得你在凑数。真正有说服力的baseline组合，应该覆盖四个不同的角色。
第一类是经典方法/传统方法。这类方法代表某个任务在深度学习兴起之前的成熟方案，或者是早期深度模型。它们的作用是提供“底线参照系”，告诉读者这个问题在一个相对简单、成熟的方案下能做到什么程度。比如文本分类里的TF-IDF+SVM、图像分类里的HOG+SVM，虽然老，但如果你的任务在这些老方法上表现依然不错，那说明任务本身有难度，也侧面证明你的新方法确实有增益。
第二类是近年的代表性SOTA。这是审稿人最看重的一类，它直接决定了你的方法是不是“领先”。选择标准不是“越新越好”，而是“与你的方法处于同一技术流水线上”。比如你做的是Transformer变体，那至少要把标准Transformer、BERT系列的某个代表性版本跑上；你做的是图神经网络，那GCN、GAT、GraphSAGE这类里程碑工作是躲不掉的。审稿人如果发现你避开了某个和你的方法同源的强方法，基本一定会提出来。
第三类是方法变体/消融对象。这类baseline不一定是“别人的方法”，而是你自己方法的不同配置——去掉某个模块、换成某个更简单的实现、减少某部分监督信号。它的作用是回答“我的每个设计选择是不是都有用”这个问题，是说服审稿人的关键证据链。
第四类是oracle/upper bound。它不是一个真正能用的方法，而是一种理论上限的估计。比如做生成任务时，把真实结果的部分信息作为输入，得到一个“理想化表现”。它的价值在于让审稿人知道你的方法离上限还有多远，也能防止你把自己的方法吹过头。
2.2 选baseline的具体操作清单
实际操作中，我建议按下面几个维度来锁定最终的baseline名单。
- 论文发表时间维度：从近3-5年的顶会/顶刊论文里，找出每个子方向的代表性方法，同时保留1-2个经典老方法作为底线参照。
- 方法亲缘关系维度：与你方法最接近的2-3个方法必须包含在内，哪怕它们的效果不如某些新方法，因为审稿人会用它们来判断你的增量贡献到底来自哪里。
- 公开代码可得性维度：优先选择有官方代码或可靠复现的方法。遇到复现成本极高的方法，可以引用原论文数据，但必须注明出处，并说明对比条件是否一致。这一点后面会详细讲。
- 数据集覆盖维度：不同数据集上，baseline的表现排名可能会变化。如果条件允许，建议每个数据集都评估一遍候选baseline，而不是只在自己方法效果最好的数据集上挑几个能打的。
我自己常用的做法是：先列一个“理想对比list”，包含上面四种角色各1-2个，再根据计算资源和代码可得性做删减，最后保证每个实验数据集上的baseline数量不低于4个。数量太少会显得单薄，过多又容易稀释重点。
2.3 一个实际选择案例
拿一个典型的多模态情感分析任务来举例。如果我的方法是一个基于跨模态注意力融合的新模型，那么我的baseline名单大概会是这样：
- 经典方法：SVM + 手工特征（text+audio）、LSTM + 早期融合
- 同源强方法：标准Transformer、BERT-based single-modal baseline、MulT（跨模态Transformer）、MAG-BERT
- 消融对象：去掉跨模态注意力模块的我的方法简化版、把融合方式改成拼接/求和的简化版
- 上限：使用真实标签模态信息的upper bound
这个名单的逻辑是：从“经典到新潮”、从“无关到同源”、从“别人的方法到自己的方法”全覆盖，每一个baseline都能回答一个具体的、审稿人可能问的问题。这不是模板，但构建思路可以迁移到任何任务上。
3. 跑baseline：公平性不是态度，是技术
3.1 数据划分：从源头杜绝“不公平”
对比实验的第一道公平性关卡，不在模型，而在数据。审稿人最常抓的问题之一就是“你们的训练/验证/测试划分是否一致”。这个问题看似简单，但实际操作中踩坑的人非常多。
最保险的做法是：所有方法共用同一份划分文件或同一个随机种子下的划分方式。由于部分数据集会提供官方划分，那么所有方法都必须使用官方划分，不要自己重新split——自己重新划分后，理论上可以和baseline结果共同出现的，权利就在你手上。
如果必须自己划分，例如某些任务找不到官方标准划分，我的建议是：固定一个随机种子，生成train/val/test划分后，把每个样本的id和对应划分结果保存下来，作为整个项目的固定配置文件。所有baseline和你的方法都从这个配置文件读划分，而不是每个方法各写一套划分逻辑。这个细节虽然简单，但能避免很多“复现时发现划分对不上”的尴尬。
此外还有一个容易忽略的点：验证集不能用于任何形式的早停或调参，否则最终提交的模型其实是在测试集上过拟合了。对baseline和你的方法都要严格保持“只在训练集上学习、在验证集上选优、最后跑一次测试集”的流程，否则你的方法如果在验证集上被调了很多轮，而baseline只是按默认参数跑了一轮，这就是典型的隐性不公平。
3.2 训练配置：把“隐性优势”挤干净
第二个公平性关卡是训练配置。审稿人不会只看你报告的数字，他们会看你有没有“隐藏的优势”，例如参数量、计算量、训练时长、是否用到了额外的预训练模型等。如果你在方法里用了更大规模的预训练模型，而baseline只用了随机初始化，这样的对比没有任何说服力。
一个具体的检查清单可以这样列：
- 模型参数量：记录每一个对比模型的参数量，尽量保证可比。如果方法本身参数量更多，要么在分析部分坦白说明，要么设计一个“减少参数量后性能依然领先”的对比实验。
- 超参数搜索：给每个baseline做超参数调优，不能只跑默认参数。我见过很多人在这里犯懒，用自己的方法调了几百组超参，baseline却跑了默认配置，然后报告里写“我们的方法显著优于baseline”——审稿人不是傻子，一旦发现你连baseline的学习率都没调过，整篇文章的可信度都会崩塌。
- 训练轮数与早停：采用相同的早停策略（例如验证集上连续N轮不提升就停止），并记录每个模型的实际训练轮数。差异过大时要注意解释原因，例如收敛速度不同等。
- 优化器与学习率：如果不做特殊设计，所有方法应使用相同的优化器类型、相同的学习率调度策略。只有当某种baseline的论文明确说明其对优化器有特殊需求时，才可以单独调整，但必须在实现细节里写明。
- 随机种子：建议使用3-5个不同的随机种子进行重复实验，报告均值和标准差。这既能让结果更稳定，也能在审稿人质疑“是不是运气好”时拿出证据。
- 推理效率：训练好之后，记录推理时间、显存占用等指标，特别是现在许多论文强调高效方法，效率对比可以成为加分项。
这里我特别强调一下为baseline做超参调优。很多新手觉得“我用的都是论文里报告的最优参数”，但论文里的最优参数通常是在他们特定的数据划分和预处理下得到的，换到你的环境不一定最优。最稳妥的方式是：对每个baseline，至少在训练集或验证集上做一次小范围的网格搜索或贝叶斯搜索，选择验证集上效果最好的配置作为最终对比配置。这个工作量不小，但它是“公平对比”四个字的硬件要求。
3.3 评测口径：一项一项对齐
第三个公平性关卡是评测口径。再好的模型，如果在评测指标上做文章，也经不起推敲。评测时要重点核对以下几点：
- 指标定义：同一个指标名的计算方式可能在不同代码库里有细微差别。例如多标签分类的F1是micro还是macro、排序任务的NDCG截断在哪个位置，都需要在文本中明确定义。
- 评测代码：建议所有方法使用同一套评测脚本。如果你的代码库和baseline的官方代码在评测时对输出结果做了不同的后处理（例如是否做softmax归一化、是否抑制重复token），对比结果就会失真。
- 不可复现结果的引用方式：某些baseline的原论文结果极难复现，或者需要消耗极大的计算资源。这种情况下，可以引用原论文报告的数字，但必须明确标注“结果来自原论文”，并且在正文中说明双方的计算设备、数据划分等条件是否一致。如果条件不同，就要谨慎讨论。
- 多次运行取均值：正如上面提到的，单次运行的指标不具备统计意义。建议至少跑3次（更多更好），报告mean±std。如果论文篇幅紧张，正文中可以只放均值，但附录或开源代码里应提供完整的多次运行数据。
3.4 计算量记录：现在审稿人越来越看重这个
近几年，很多审稿人会额外关注计算效率。同样一个效果，如果你的方法训练时间只有baseline的十分之一，这就是一个重要卖点；反过来，如果你的方法比baseline多用几十倍显存和算力才换来1个点提升，那审稿人的评价可能就完全不一样了。
所以，跑实验的时候就要顺手记录每个方法的训练时间、单轮迭代时间、GPU型号、显存占用、模型参数量、FLOPs。这些数据后面写论文时会非常有用。不要等到实验全部做完了再回头去查，那样大概率会漏掉几组数据，还得重跑。这些环境配置都记录下来，会省掉大量后期补实验的时间。
4. 结果分析：数字背后的“可解释性”才是杀手锏
4.1 从“我的方法最高”到“我的方法为什么最高”
很多论文把对比实验简化成一张表格：三行baseline、一行Ours，Ours全是最佳，然后就没了。这种做法在好一点的期刊会议上很难过关。审稿人看到表格后的第一反应往往是：这有什么奇怪的？你的方法当然要跑得更高，不然你写这篇论文干嘛？
因此，对比实验的进阶要求是解释差距。也就是说，你不仅要报告成绩单，还要解释为什么你的方法在每个数据集上能取得更好的结果。这种解释通常分为几个层面：
- 方法层面：从模型设计角度说明，你的模块针对任务的哪个难点做了改进，而baseline缺乏这种机制。例如“跨模态注意力模块能够显式建模文本与图像之间的细粒度对齐，而仅使用拼接融合的baseline被迫在高维空间中隐式学习这种对齐，所以效果受限”。
- 数据层面：按数据子集或难度分层来展示。例如把测试集按照样本长度、类别频率、难易程度分组，分别计算性能。如果发现你的方法在某一类样本上提升明显，而在另一类样本上反而略有下降，这种诚实的分析会让审稿人觉得你对自己的方法有深入理解。
- 错误模式层面：找出你的方法能解决而baseline解决不了的典型样本，做成case study；同样，也要找出你们都会犯错的案例，探讨未来的改进空间。
4.2 消融实验：把“贡献归因”做扎实
消融实验本质上是“关于你自己方法的对比实验”。它的目的是拆解你的方法，验证每个设计选择的必要性。常见的消融维度包括：
- 模块消融：逐个去掉你的核心模块，例如跨模态注意力、图传播层、对比学习损失等，观察性能变化。
- 组件替换：把你的核心模块替换成一个更简单的替代方案。例如用了门控机制，就换成普通加和或拼接；用了某种复杂损失函数，就换成交叉熵。这样做能证明你选择的并不是“随便什么都行”，而是有明确优势的。
- 超参敏感性：对关键超参数（如隐层维度、温度系数、融合比例等）做扫描，画一条趋势曲线或给出表格。这能说明你的方法对参数不是特别敏感，或者参数选择有规律可循，而不是靠某个“魔法数字”撑起来的。
消融实验做得好的话，可以在没有更多baseline的情况下大幅增强说服力。因为审稿人从消融中能看到你的方法从“完整版”退化为“简化版”的过程，这会让他们更加相信你的性能提升是结构性的，而不是调参的偶发现象。
4.3 统计检验：显著性不是可选项
到了这一步，很多论文依然只报mean±std，不做任何统计检验。如果你的某个数据集上，你的方法比baseline高了一点点（例如准确率高了0.3%），而标准差就有0.5%，审稿人会认为这个差异不显著。这种情况，论文里只放一个数字而不做说明，反而是给自己埋雷。
统计检验的常见做法是配对t检验或Wilcoxon符号秩检验。基本流程是：在多个随机种子下，得到你的方法和每个baseline的指标序列，然后逐对进行显著性检验，在表格中用*或标注p值。
这里要特别提醒：做配对检验时，必须确保每个随机种子的数据划分和初始化条件是可配对的。也就是说，第i次运行你的方法和第i次运行baseline的随机种子要相同，这样两列结果才能构成配对样本。如果你给baseline用了不同的种子集合，配对检验就不成立了。
4.4 效率对比和可视化分析
除了性能，建议增加一个效率和可视化维度。效率对比包括训练时间、推理延迟、模型参数量、理论FLOPs等，做成一个辅助表格，很多审稿人会非常喜欢。如果方法性能略低但效率明显更高，这也能成为一个卖点。
可视化分析则根据任务类型灵活选择。文本任务可以看attention权重可视化、语义表示分布的PCA/t-SNE图；视觉任务可以看feature map、CAM热力图；生成任务可以放生成样例对比。可视化不是锦上添花，它提供的是“性能提升之外的解释性证据”——让人看到你的模型确实学到了不同的东西。很多时候，一个清晰的可视化图比一大段解释性文字更有说服力。
5. 怎么写进论文：表格、图表与措辞的细节
5.1 baseline表格的基本规范
表格是审稿人最先看的内容之一，它的排版和信息组织直接影响审稿人的第一印象。基本的规范包括：
- 最佳结果加粗，推荐同时用上标或下划线辅助区分，防止黑白打印时看不清。
- 每列指标务必写清单位和方向（越高越好还是越低越好）。
- 报告mean±std，不能只报一个裸数字。
- 表格中注明是否使用预训练、参数量等关键信息。可以通过脚注或列注释的形式呈现，让审稿人不需要翻正文就能判断对比的公平性。
- 对于引用原论文的结果，用注释标明来源。如果自己的复现结果和原论文存在明显出入，还应在正文或附录中解释可能的原因（例如数据版本不同、实现细节差异等）。
- 大表格放在正文，扩展版本或详细结果放在附录。但审稿人通常也会认真看附录，不能把“更详细的对比”全部丢到附录就完事。
5.2 收敛曲线与误差条：图形语言的加分项
文字表格之外，一两条精心设计的性能曲线往往能传达文字无法表达的信息。最常用的是训练/验证损失曲线和测试性能随训练轮数的变化曲线。
曲线图的关键在于：每个模型都要在相同的训练轮数区间内展示，不要只截取对你自己方法有利的那一段。纵轴范围不要拉得太小，否则差异会被无限放大，显得很不专业。给出多次运行的均值曲线，并画上误差条或阴影区域，更能说明稳定性。
还有一种类似的图是“在不同训练数据规模下的性能曲线”，即横轴是训练样本量从10%到100%，纵轴是测试指标。如果你的方法在小数据下优势更明显，或是在小数据下不比大方法差太多，这种趋势往往能成为一个重要的经验性发现，也更容易说服审稿人你的方法不是“纯靠大数据堆出来的”。
5.3 正文措辞：把“公正”写出来
正文中描述对比结果的语气同样重要，过于夸张的措辞容易被审稿人贴标签。我推荐一套比较稳定的写法模板：
- 先总结整体趋势：“表X展示了各方法在所有数据集上的性能对比。总体来看，我们的方法在Y个数据集上取得了最佳结果，在Z个数据集上与最佳baseline持平。”
- 再承认个别失败案例：“在数据集A上，方法B取得了与本方法相当的性能，我们推测原因是该数据集的样本分布相对简单，模块C带来的增益不明显。”
- 最后做机制解释：“我们进一步分析了...发现...，这验证了模块C在处理结构化特征时的有效性。”
这套写法的核心是先展示、再解释、不回避。你主动暴露弱点的同时，也给出合理的分析和解释，审稿人就会觉得你看问题全面，对实验有掌控力。
5.4 Related Work里怎么配套呼应
Related Work中也要注意与baseline选择相呼应。很多人在Related Work里把别人的方法评得一文不值，到了实验部分却偷偷把那个方法设为baseline，这种“前贬后用”的做法极易激怒审稿人。
正确做法是：在Related Work中客观描述已有工作的贡献和适用场景，明确指出哪些方法属于“与我们最紧密相关、因此作为主要对比对象”的类别。这样实验部分出现这些baseline、甚至出现你复现的结果低于原论文的情况时，都有一个合理的框架来解释，不会显得像是刻意贬低。
6. 审稿人常问的问题，以及你该怎么提前防住
6.1 高频问题速查表
我总结这些年自己和周围人遇到的审稿意见，把与baseline相关的高频问题整理成一个速查表。
| 常见质疑 | 背后的审稿人心理 | 预防策略 |
|---|---|---|
| 为什么没有对比某某方法？ | 他认为该方法对你的结果构成威胁，或与你的工作高度相关 | 在Related Work和实验部分主动说明，并解释被排除的原因（如方法依赖特殊数据、复现成本过高等） |
| 你的对比不公平（baseline结果低于原论文） | 他怀疑你弱化了baseline | 把所有方法的实现细节、超参数范围、训练配置写入附录；必要时附上可复现代码 |
| 性能提升幅度太小，可能是随机波动 | 他需要统计显著性证据 | 报告多次运行mean±std，做显著性检验，用可视化解释为什么差异虽然是小的但却是真实的 |
| 你的方法是不是用了更多参数？ | 他想确认增益来源是不是模型容量 | 提供参数量对比，并做同参数规模下的对比实验或参数量消融 |
| 你的方法在小数据集上表现如何？ | 他想验证泛化能力，防止你只挑自己优势数据集 | 补充多个数据集，或做训练数据规模扫描曲线（10%、20%、50%、100%） |
| 这个case是你挑出来的吧？ | 他怀疑case study存在选择偏差 | 提供case selection的规则，例如随机抽取、按类别分层抽样，同时展示失败案例 |
6.2 一个必须重视的“补实验”策略
看到审稿意见要求补实验时，先不要慌。大部分“补实验”请求其实可以被理解为：审稿人觉得你证据不足，但并不代表你的方法没有价值。补实验时有几条原则：
- 优先补低成本、高说服力的实验：例如超参敏感性曲线、训练数据规模扫描。这些实验容易实现，而且能增加非常多的信息密度。
- 念好“公平”这门经：补实验的核心观感是“我也给baseline调了参，我也用了同样的评价代码”，而不只是“我补了一个数字”。
- 逐条回复，不要跳过任何质疑：即使你认为某个质疑不合理，也要给出礼貌而充分的解释。切忌用“感谢审稿人意见”一句话带过然后什么都补。
- 能将补实验的结果纳入正文最好，避免“我们应审稿人要求补充了实验，限于篇幅未能呈现”这种说法——既然补了，就把它当成正式分析的一部分，而不是应付差事。
6.3 审稿人视角的“反推法”
最后分享一个我平时常用的技巧：写完对比实验部分后，我会切换到“一个苛刻的审稿人”视角，把自己的论文从头读一遍，专门找“还可以质疑的地方”。我会问自己：
- 如果我是审稿人，我会怎么攻击这张表？
- 我会觉得哪个实验是“特意挑出来”的？
- 我会怀疑哪个编号的复现结果是否真的可信？
- 哪一段文字在“过度解释”那些不显著的提升？
这相当于给自己的论文做一次“红队测试”。通常我都能从自己的论文里找出几个明显可以被攻击的点，然后赶在投稿之前修掉。这个方法不需要额外的计算资源，只需要诚实地面对自己的论文。
7. 最后再分享一点实际操作的体会
对比实验做到最后，拼的其实不是“跑得多”，而是“想得全”。我见过一些工作，方法设计很出彩，但因为baseline这个环节没有做扎实，审稿人提出了大量质疑，最终被拒稿；也见过一些工作，方法本身并不复杂，但对比实验非常完整，从多个角度证明了自己的贡献扎实可信，审稿人反而给出了很高的评价。对比实验不是论文的佐料，它是审稿人判断你这篇工作“是否认真”的第一道窗口。
我自己的习惯是：在设计方法之前，就先把baseline名单列出来，同时评估这些baseline是否容易复现。如果发现某个关键baseline在这个数据集上没有实现，我会提前安排时间自己跑或复现，而不是等到实验阶段再临时抱佛脚。另外，我会把每个实验的配置、日志、输出结果、随机种子全部归档在一个结构清晰的目录下。后期写论文时，任意一个数字都能快速溯源到具体的日志文件，这种“实验可追溯”的习惯在回应审稿人时非常有用。
如果你现在正被对比实验折磨，不妨按这篇文章的脉络逐条自查一遍：baseline有没有覆盖四类角色、每一条对比是否公平、有没有做显著性检验和消融、表格和曲线是否专业、正文措辞是否客观。把这些问题都回答清楚了，你的论文在“对比实验”这块就基本不会翻车。
