paper-self-review

# 论文自评审 **目的：确定审稿人可能指出的潜在问题，在投稿前就把它们解决掉。** 方法叫 **Adversarial writing**：自己 review 自己的论文， 考虑 reviewer 可能会问的所有问题，并一一解决。 --- ## 一、论文被接收需要做到三点 1. **Contribution 足够**——需要包含以下几点中的若干： Novel task / Novel pipeline / Novel pipeline module / Novel design choices / New experimental findings / New insights 2. **实验效果比之前的方法好。** 3. **Ablation studies 和 comparison experiments 充分。** --- ## 二、五方面拒稿检查清单 逐条过一遍，就知道这篇论文是否该被拒。**每一条都要给出"是/否 + 证据"，不要泛泛而过。** ### 1. 技术贡献是否足够（论文有没有给读者带来新知识） - [ ] 1.1 想解决的 failure cases 是不是**很常见**？ - [ ] 1.2 提出的技术是不是**已经被 well-explored** 了，该技术带来的 performance improvement 是**可预见的 / well-known 的**？ - [ ] 1.3 技术是不是比较 straightforward？ > 如果 1.1 或 1.2 命中，问题出在选题而不是写作——回到 `research-ideation` > 检查是否落入了"四种情况"的前两种。这时候改写作救不回来。 ### 2. 论文写作是否清楚 - [ ] 2.1 Introduction 是否**清楚描述论文贡献**？ - [ ] 2.2 Pipeline figure 是否**清楚描述 pipeline 与技术贡献**？ - [ ] 2.3 是否**缺少技术细节、不可复现**？ - [ ] 2.4 **每个方法模块是否都写了 motivation**？ > 修复方法见 `paper-revision`。 ### 3. 实验效果是否足够好 - [ ] 3.1 是否只比之前的方法好了**一点点**？ - [ ] 3.2 虽然比之前的方法好，但**效果本身是否仍然不够好 / 不够 impressive**？ ### 4. 实验测试是否充分 - [ ] 4.1 是否**缺少 ablation studies**？ - [ ] 4.2 是否**缺少重要的 baselines**？是否**缺少重要的 evaluation metric**？ - [ ] 4.3 **数据是否太简单**，无法证明方法是否真的 work？ ### 5. 方法设计是否合理 - [ ] 5.1 实验的 **setting 是否不实际**？ - [ ] 5.2 方法是否**存在技术缺陷、看起来不合理**？ - [ ] 5.3 方法的**鲁棒性**：是否需要在每个场景上调超参？ - [ ] 5.4 新的方法设计在带来 benefit 的同时，是否**引入了更强的 limitation**， 导致新方法的**净收益为负**？ > 5.4 的判据：**一篇论文要提升一个 metric，并且不明显损害其他 metrics。** --- ## 三、必查的两条硬要求 **1. 所有 claim 必须成立且有实验 support。** > **论文中所有的 claim（特别是 abstract 和 introduction 里的 claim）， > 需要不犯错，也得有实验 support。不然一些 reviewer 会直接以此拒掉论文。** 做法：把 abstract 和 introduction 里的每一句断言列出来， 逐条标注它由哪个 table / figure / section 支撑。找不到支撑的，要么补实验，要么改写。 **2. Related work 里必须讨论和自己方法最相关的论文。** 漏掉最相关的工作，一些 reviewer 会直接以此拒稿。 --- ## 四、输出模板 评审产出用这个格式。**每一条都要带位置和证据**—— "introduction 写得不够清楚"对作者没有任何用，"§1 第三段引出 technical challenge 时 直接跳到了我们的方法，没有说明 recent method 2 为什么会存在"才有用。 ```markdown ## 自评审：<论文标题>　<日期> **总判**：<接收 / 边缘 / 会被拒>　主要风险：<一句话> ### 命中项（按严重度排序） | # | 类别 | 位置 | 问题 | 证据 | 修复动作 | 需要多久 | |---|---|---|---|---|---|---| | 1 | 4.1 缺 ablation | §5.2 | core contribution B 没有单独的 ablation | 表 3 只有 A+B 和 baseline | 补 A-only 一行 | 2 天实验 | | 2 | 2.4 缺 motivation | §3.3 第一段 | 模块 C 直接给了设计，没说为什么需要它 | | 补一句 problem-driven 开头 | 30 分钟 | ### 五方面逐条判定 1. 技术贡献是否足够：<是/否 + 依据>　1.1 ☐　1.2 ☐　1.3 ☐ 2. 写作是否清楚：2.1 ☐　2.2 ☐　2.3 ☐　2.4 ☐ 3. 实验效果是否够好：3.1 ☐　3.2 ☐ 4. 实验测试是否充分：4.1 ☐　4.2 ☐　4.3 ☐ 5. 方法设计是否合理：5.1 ☐　5.2 ☐　5.3 ☐　5.4 ☐ （☐ = 未命中即通过；☒ = 命中，需在上表出现） ### Claim 审计 | Abstract/Intro 里的 claim | 支撑它的 table/figure/section | 成立？ | |---|---|---| | | | | ### 时间可行性 距截稿 <N> 天。上表中来得及修的：<#…>；来不及的：<#…，建议怎么处理> ``` 最后一节很重要：**在截稿前三天报出一条需要两周实验的问题，等于没报。** 来不及修的项要给出降级方案（改写 claim、加进 limitation、把强断言改成受限断言）， 而不是让作者干着急。 ## 五、Review 别人论文时 用完全相同的五方面清单和同一张表，逐条过一遍就能得出结论。 区别只是不需要"时间可行性"一节。 --- ## 六、把自评审做成论文的一部分 **在论文的最后加一个自我评审的 question lists**，按上面五方面分别提问题， 然后根据这些问题改论文。改完再过一遍，直到清单上没有命中项。 **追求完美主义是保证论文质量的非常重要的方式。** --- ## 七、超出"不被拒"之后 清单只保证不被拒。要让论文**收获好 review**，还有一层： > **把论文做得漂亮、美观，让人第一印象觉得这篇论文很高级。** > 三个抓手：好看的 teaser figure / pipeline figure；好看的表格和结果图；整齐的排版。 要让工作**有影响力**（而不只是被接收）：把算法推到更难的数据上、面向下游研究群体做 demo，见 `research-experiment`； 选题层面的影响力判据见 `research-ideation`。