关于 ICLR 2025 基于 LM 的评审反馈代理随机研究的个人思考
去年，ICLR 2025 宣布了一项有趣的实验“协助 ICLR 2025 审稿人提供反馈”。不幸的是，我当时由于其他职责，不得不拒绝了 ICLR 2025 的审稿人邀请，错过了参与这项有趣实验的机会。
从那时起，我一直等待实验结果和社区反馈，因为我对这类工作非常感兴趣。事实上，我之前曾向不同会议的组织者提出过类似的想法。也有一些人建议我借鉴他们的系统用于我所服务的某些会议，所以我的期望很高。几天前，ICLR 2025 发布了一篇后续博客文章，同时还有一篇预印本，题为“LLM 反馈能否提升评审质量？ICLR 2025 2万份评审的随机研究”。
我写这篇博文是为了分享我对这项工作的个人想法，重点关注实验设计和评估。
概述
我认为其他会议很难将其方法直接应用于他们的评审系统。此外，我无法接受预印本 (v1) 中报告的许多发现和结论，因为我认为实验的评估和分析不足以支持他们的主张。如果您是某个会议/期刊的组织者，并且倾向于根据这些发现引入该方法，我建议您首先阅读该预印本。
让我简要介绍一下您可以（或不可以）直接借鉴他们的工作的地方。
可以借鉴的地方
- 提示
- 示例代码
预印本展示了作者在实验透明度方面的努力，提供了实验中使用的所有提示、大量统计数据以及运行其提出的评审反馈代理的最小示例代码。如果其他会议想要实施类似的方法，这些可能都是很好的参考。
其他会议很难直接借鉴此方法
首先，该实验使用**从 PDF 文件解析的论文内容作为提示的一部分，但他们只考虑了专有基于 LM 的 API**：GPT-4o、Gemini 1.5 Flash 和 Claude Sonnet 3.5。
ICLR 传统上公开（几乎）所有涉及其评审过程的内容，包括提交的论文，甚至在评审期间也是如此，这可能使得组织者能够将论文内容提供给专有 API。我不确定专有 API 服务使用了哪些条款和计划，但如果这些允许提供商存储和/或使用论文内容来训练他们自己的模型，我假设组织者需要事先获得作者的同意，特别是如果提交的论文尚未公开。
目前尚不清楚 ICLR 2025 提交论文的作者是否收到过任何形式的批准，允许其提交内容暴露于专有基于 LM 的 API。
现在我转换一下话题，分享我对这项工作本身的个人看法。
主要担忧
- 这项工作没有展示任何关于生成评审反馈的真实用户反馈。
- 许多发现都基于基于 LM 的 API 所做的分析，这些分析似乎被（盲目地）相信，而对其准确性没有太多怀疑。
1. 没有真实的 用户反馈
我所说的真实用户是指那些参与评审过程的人，例如作者、评审员和 ACs。
在论文最终决定发布后，我们将向作者、审稿人和 ACs 分发一份匿名、自愿的调查问卷，以收集反馈。我们将仔细分析回复，以评估试点系统的影响，并指导未来迭代的改进。
在这项工作中，尽管ICLR 早期博客文章中的上述声明，我没有发现任何关于生成的评审反馈和/或其影响的真实用户反馈（即来自作者、评审员和 ACs 的反馈）。虽然这项工作表明在收到评审反馈后更新的评审字数略多，但评审略长并不一定意味着评审得到了改进。
有“两名人类人工智能研究员”对初始和修改后的反驳前评审进行了盲法偏好评估。这两位研究员检查了 100 个符合某些标准的示例，并在 89% 的情况下更偏好修改后的评审。然而，我认为这并非高质量评审的强烈信号。这类评估应基于真实用户的反馈，因为他们是评审质量可能影响的参与者。如果这两位研究员之前被认为是高质量评审员，并且根据评审指南评估修改和原始评审，那可能就是另一回事了。但是，这项工作未能提供详细信息。
最重要的是，这 100 个示例并非随机抽样，而是从作者声称“我们发现，当审稿人收到的反馈项较少时，他们更有可能采纳更多（甚至所有）的项”的群体中提取的。因此，我不认为基于这 100 个示例的发现代表了平均（预期）体验。
值得注意的是，73.4% 收到生成反馈的评审“未更新”。尽管这低于对照组的 90.6%，但如果我们能从真实用户反馈中学习到一些东西来提高审稿人的参与度，那将是一个有趣的讨论。
这项工作的目标是提高评审质量，但我认为“评审质量”在这项工作中既没有明确定义，也没有得到适当评估。我认为，如果没有来自作者、审稿人或 ACs 的积极反馈，就很难声称生成的反馈确实提高了评审质量。
2. 依靠基于 LM 的 API 做出判断，且未讨论准确性
案例一：“撰写良好”的评审
不到 8% 的选定评审没有收到反馈，原因有二：2,692 份评审原本就写得很好，不需要反馈；而 829 份评审的反馈未能通过可靠性测试。
这项工作没有解释他们如何发现 2,692 份评审写得很好。根据他们的提示，
如果您对评审完全没有异议，请回复：“感谢您的辛勤工作！”
我假设这个结论是根据基于 LM 的 API 的预测得出的，这项工作没有讨论这些预测的准确性。
案例二：衡量审稿人采纳反馈的程度
在更新评审的审稿人中，我们希望衡量他们采纳一项或多项所提供反馈的比例。这项分析有助于我们估算有多少审稿人认为该反馈有用。……为了系统地进行这项分析，我们开发了一个基于 LLM 的管道来运行所有更新后的评审（参见补充图 S2A）。我们使用 Claude Sonnet 3.5 模型来评估审稿人收到的每个反馈项是否已纳入其修改后的评审中。
同样，这项发现是基于有多少评审采纳了审稿人反馈，而这又是基于 Claude Sonnet 3.5 的估算。同样，对于这项特定任务，没有讨论 Claude Sonnet 3.5 预测的准确性。
案例三：可靠性测试
在向审稿人分享生成的反馈之前，反馈需要通过四项测试。可靠性测试是自动化的（可能使用专有 API）。但是，这项工作没有讨论每项测试的质量或错误率。
我还觉得以下提示调整策略可能会导致过拟合。
为了优化我们的评审反馈代理的流程和提示，我们对测试集评审进行了验证性可靠性测试，直到达到 100% 的通过率。
建议
然而，我仍然认为 ICLR 2025 团队通过自动化方法提高评审质量是一项伟大的举措。我相信这项实验是该团队完成的众多任务之一，根据我的经验，即使没有这项实验，运行一个常规的评审过程也极具挑战性，并让他们忙碌不已。
在这篇博文中，我特意避免讨论他们的评审反馈代理方法，因为我没有找到可靠的评估来讨论所提出方法的有效性（尽管高层级的管道设计看起来合理）。如果其他会议进行类似的实验，我希望看到基于作者、评审员和/或 ACs 的反馈对评审质量的讨论。
具体来说，我想会议组织者和期刊编委会成员会更感兴趣的是，评审过程中的用户对生成的反馈和评审质量的看法，而不是 ICLR 2025 团队提供的那些实验统计数据。
我还想建议那些关注此实验的组织者讨论使用专有基于 LM 的 API 的风险，例如其服务条款是否表明输入到 API 的论文内容可能被存储或用于其模型训练，以及作者是否接受其论文暴露于此类外部 API，同时考虑为其实验使用开源/权重模型。
亲爱的 ICLR 2025 作者、评审员、ACs 和研究社区，您对这项实验有什么看法？
在这篇博文中，我分享了对 ICLR 2025 所做实验的个人看法。如前所述，我这次没有参与 ICLR 2025 的评审过程，也没有向该会议提交论文。如果您有 ICLR 2025 评审过程的经验，我非常渴望听到您对这项实验的看法，生成的反馈对您有多大帮助，以及您所看到/收到的评审质量等。由于我幸运地能够提出并技术支持此类实验，**如果您能分享您的经验和对这项实验的反馈，那将非常有帮助！**
即使您没有参与 ICLR 2025 的评审过程，我仍然想听听您对这项工作的看法！
附注
我将此内容交叉发布到 Medium，以防您没有 Hugging Face 帐户来发表评论。如果您也没有 Medium 帐户，请回复我的 Bluesky 或 X 帖子。