Position: Let’s Strengthen Verifiability If We Can’t Enforce Reproducibility¶

会议: NeurIPS 2026 — Position Paper Track（立场论文，非普通方法主会论文）
arXiv: 2609.35854
代码: https://github.com/giddyyupp/position-enforce-verifiability
领域: 其他（科研可复现性与同行评审政策）
关键词: 可验证性、可复现性、实验日志、指标核验、同行评审

一句话总结¶

本文以五个 ML/CV 顶会 2021–2025 年的代码可用性调查为依据，主张在难以强制完整复现的现实下，把实验日志检查和预测文件上的指标重算纳入投稿、评审与出版流程；这是部分一致性核验提案，而非已经证明有效的反作弊系统。

研究背景与动机¶

公开代码通常被视为计算机科学复现的入口，但“论文提供了一个链接”“仓库可以克隆”“含有训练或测试代码”“能够复现论文结果”是四件不同的事。模型权重只能让外部使用者运行某个已训练模型，不能说明训练时到底用了哪些数据；即使源代码公开，隐藏的测试时增强、集成策略、检查点选择和高昂计算需求，也可能让论文与实际执行之间存在落差。作者关心的不是再制定一份代码发布倡议，而是这些落差如何在论文被接收前进入评审视野。

论文调查发现，部分会议早在 2023 年就出现代码公开比例下降，2025 年则呈现更普遍的下滑；与此同时，有官方代码的论文平均引用超过无代码论文的两倍。这种关联并没有使代码公开成为普遍规范，也不能证明公开代码导致更多引用。单纯等待论文发表后由热心研究者复现，既依赖额外算力与时间，又可能让无法核实的 SOTA 长期成为后续工作的比较门槛。

完整代码审查虽然更有保障，却会遇到商业保密、许可、隐私和审稿人资源不足。本文因此缩小审查对象：不要求审稿人重新训练和推理，而是检查作者交出的实验痕迹，以及由固定预测结果重算指标的过程。核心 idea：把“实验材料与论文是否一致”变成接收前可检查、出版后可见的正式状态，同时明确这一状态不等于完整可复现或结果真实。

方法详解¶

整体框架¶

这里的方法是会议审核机制，不是神经网络架构。作者随主实验提交日志、预测文件、评估代码与必要真值；审稿人在 Level 1 检查日志，在 Level 2 检查并运行评估代码，随后领域主席（AC）与程序主席（PC）汇总一致性状态。接收后再核实可选软件链接，并在出版页面展示状态与材料。

日志核验、指标核验、状态治理与软件核实构成四个关键设计。前两项检查不同证据：日志侧重训练和执行过程的可见痕迹，指标核验侧重预测输出到论文数字的计算链路。流程可以先采用 Level 1，再逐步引入 Level 2；图中的串行次序表达这种分级政策及报告汇总，不表示指标重算必须等待日志“通过”。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["作者投稿<br/>主实验与核验材料"] --> B["日志核验<br/>审稿人检查 Level 1"]
    B --> C["指标核验<br/>指定审稿人执行 Level 2"]
    C --> D["状态治理<br/>AC 汇总与 PC 决策"]
    D -->|论文接收后| E["软件核实<br/>可选仓库与出版展示"]
    E --> F["读者看到状态与材料<br/>不等于完整复现认证"]

整个机制没有模型训练目标、推理时数据流或损失函数。调查中的 InternLM 用于识别代码链接和分析仓库，不是提案中强制审稿人使用的自动核验模型；设想中的安全 LLM 审计平台也只是未来方向。

关键设计¶

1. 日志核验：让每条主要经验结论能追溯到一次运行

论文中的最终指标通常只展示结果，看不见这个结果来自哪次训练、用了多少数据以及如何挑选模型。作者要求为支持主要经验主张的实验提交已有日志，并把曲线或记录明确关联到论文的具体实验，例如 SOTA 表中的某一行；消融日志可选。这不是让审稿人从一堆截图中自行猜测对应关系，而是由作者先建立“主张—运行”的证据连接。

附录 B.1 指定共同字段包括实验引用、数据集规模、GPU/CPU 利用率、参数量和 FLOPs 或同类计算估计；训练日志还应包含训练方案、训练参数和随步数或轮数变化的损失，验证日志则应给出最终评估指标。TensorBoard、MLflow 与 Weights & Biases 都可以导出相关材料，因此作者主张复用开发中已有的记录，而不是新建一种专有日志系统。

审稿人检查训练过程、收敛和性能波动是否符合论文，结合轮数、批大小与迭代数观察是否存在使用更多数据等迹象，必要时在 rebuttal 请求补充说明。日志也可能提示挑选检查点的问题，但这些只是可见证据上的一致性检查：作者能够伪造日志，且看似合理的曲线不能排除数据泄漏或按样本标识查答案。

2. 指标核验：只重算输出到指标，不重新训练或生成输出

公开完整方法实现往往代价高，但评估代码通常短得多。本文把核验任务限定在作者已经生成的输出文件上：作者提供对应实验的 JSON 预测文件、指标定义或标准评估代码链接、必要真值以及下载和运行说明；自定义指标则提交匿名评估代码，必要时附带评估所用模型。指定审稿人检查样本覆盖、真值与代码的合理性，再执行评估并对照论文数字。

作者推荐匿名 Colab 类 notebook，把输出、真值及其下载步骤和评估代码打包，尽量减少安装障碍。独立核验仍允许指标计算本身可接受的随机变化，因此检查的是足够一致，而非机械要求每个浮点数完全相同。主文的五名有经验审稿人小调查显示，短脚本平均约需 5 分钟，长脚本约需 45 分钟到 1 小时；这个样本不足以证明所有论文都能低成本审核。

这种切分能发现指标实现或报告错误，也能检查是否删掉困难样本，却不能证明预测文件确实由声称的模型生成。对于敏感输出或私有真值，材料可用性和匿名性必须单独处理：原文要求核验阶段不通过需要签署许可协议的方式获取私有数据，以免暴露作者或审稿人身份。不能满足要求时应走有理由的豁免，而不是把评估失败视为通过。

3. 状态治理：把核验结论纳入正式评审，而不是另附荣誉徽章

在作者提交材料后，审稿人的一致性评论与评级成为正式 review 的一部分，影响推荐意见；AC 在 meta-review 中总结证据并解释最终一致性建议，PC 据此给论文赋予状态。会议可以每篇指定一名实验或指标审稿人，以减少重复执行。与只在接收后发放的可复现徽章不同，这一安排把核验放在接收前，但没有规定“任何缺材料论文一律拒稿”。

原文表 1 分别记录日志、指标和软件，而非把三者压成一个万能可信分数。日志区分一致、不确定、不一致和不可用；指标区分足够相近、差异存疑、明确不同和不可用；软件则区分仓库链接、专有和未维护。它们是分类状态，没有连续评分公式，也没有跨任务通用的数值容差阈值。

理论论文、隐藏测试服务器、私有数据和过大输出可以提出豁免理由，由审稿人和 AC 判断。作者还希望未来论文在论证和结果表中突出已核验或有可复现软件的比较对象，但不禁止引用无代码论文。旧论文默认没有此项核验状态；“未核验”不等于“不可靠”，以新标签评价旧工作尤其需要保留这一边界。

4. 软件核实：接收后核查实际仓库，而不是奖励发布承诺

“代码即将公开”并不意味着会议召开时真的会有软件。作者提出在 camera-ready 前申报软件状态和可选仓库链接，并在会议开始前由指定审稿人检查仓库是否实际含有所期待的软件；有效链接随后进入论文集页面。这项工作可以利用自动仓库检查，再对失败案例人工复核，但不审查实现完整性，也不要求运行完整训练。

最终出版信息包括实验一致性评级、软件可用性状态与实验材料，使读者能够判断比较结果所依赖的证据。软件获取阶段可以出现许可协议，与前述匿名指标核验阶段的要求不同。仓库存在依然不保证所有数据、训练策略、增强或集成配置都齐全，因此不能把这一检查宣传为完整代码认证。

一个完整示例¶

以下是依据提案组织的说明性场景，不是论文新增实验或已实施的会议案例。

设论文用某个公开数据集上的主要结果支持一个性能主张。作者把该结果关联到具体运行日志，提交全部目标样本的预测 JSON，并用标准评估工具构造匿名 notebook；审稿人先查看曲线、数据量和训练配置，再检查预测样本集合与真值来源，最后运行 notebook。

如果重算结果接近论文数字，指标状态可以记为“足够相近”；如果日志无法判断训练过程，日志状态仍为“不确定”。AC 需要分别解释这两种判断，PC 将其纳入最终决策，而不能用指标一致掩盖日志证据不足。

论文接收后，作者若给出仓库链接，检查者确认其中确有软件，再公开相应软件状态。读者此时得到的是“这些文件能重算出所报指标”等有限结论，而不是“模型使用正确数据训练且输出从未伪造”的保证。

实验关键数据¶

主实验¶

本文没有提出训练模型，也没有与 SOTA 方法比较准确率。下面是附录表 2–6 的代码可用性调查摘要：代码可用表示检测到训练或测试代码，不能理解为成功复现。

会议与比较年份	主会接收数：较早年 → 2025	有训练或测试代码：较早年 → 2025	调查解读
CVPR，2024 → 2025	2719 → 2872	1255 → 1267	代码数略增，但接收数增长更快
ICCV，2023 → 2025	2160 → 2701	1035 → 1108	双年会议；不是 2024 到 2025 的逐年比较
ICLR，2024 → 2025	2296 → 3827	1199 → 1964	绝对数量增加不等于比例增加
ICML，2024 → 2025	2634 → 3339	1150 → 1485	此两年比例并未下降，不能把总体叙述套到每个表项
NeurIPS，2024 → 2025	4037 → 5290	2056 → 2608	接收规模增速超过代码数量增速

数值按原表保留。尤其 ICML 的 1150/2634 与 1485/3339 表明 2025 年比例略升，而主文称 2025 年所有会议均明显下降；本文保留这一原文叙述与表格的冲突，不自行修改作者数据。论文还明确提醒接收数与成功下载数存在差异，因此使用不同分母也会影响比例。

消融实验¶

没有标准模型消融。下表汇总调查分析和核验负担证据，不把小样本计时或经验观察包装成政策有效性的对照试验。

证据项目	原文数值或结论	能支持什么；不能支持什么
自动调查规模	55,377 篇；提示词对照样本为 100 篇	说明调查覆盖广；没有全量人工标签和有意义的误差条
代码与引用，图 3	有官方代码论文平均引用超过无代码论文的两倍	支持关联；不能推出发布代码的因果收益
被致谢仓库，图 1(c)	被致谢最多的 20% 仓库占 81.5% 致谢	说明复用集中；不是这些仓库贡献了 81.5% 性能提升
指标核验用户调查	5 名有经验审稿人；短脚本约 5 分钟；长脚本 45 分钟–1 小时	支持两个脚本的可行性；不代表所有任务的总审核成本
AC 经验观察，附录 C.1	74 份投稿中 16 份附代码；相关 48 份 review 中仅 2 份提到代码	说明提交代码不等于实际审查；样本不完整且有主题偏差
已公开仓库的复现相关 issue，附录 C.2	2023：1.9%；2024：2.3%；2025：4.0%	原文统计的 issue 信号；不是经审计确认的复现失败率

关键发现¶

调查从官方论文 PDF 与补充材料提取链接，解析项目页，再克隆仓库并判断训练代码、测试代码与权重等状态；只看摘要或只统计 GitHub 链接会遗漏材料或把空仓库当代码。
InternLM（internlm3-8b-instruct）的提示词在 100 篇随机论文上调整至与人工判断一致，作者称剩余误差略偏向高估代码和权重可用性；这不是独立留出测试，也没有量化全量分类误差。
附录称各会议的仓库致谢数逐年增加，但 NeurIPS 表 6 的 2024 → 2025 为 765 → 758；应保留表格，而不重复无例外的增长结论。
核验节约成本来自不重跑训练与推理。是否能真正减少错误论文、提高审稿一致性或改变作者行为，仍需会议试点验证。

亮点与洞察¶

把复现拆成证据层级，而不是二元地要求“全开源或完全不查”。日志和指标各自有清晰检查对象，也各自保留真实性方面的缺口。
审查最小计算链路具有可迁移性：对于计算代价高但指标计算相对轻的任务，可以先核验固定输出上的结果，而不声称已经复现输出生成过程。
让状态跟随论文进入出版页面，有助于读者辨认比较对象的证据强度。标签有价值的前提是保留核验范围、豁免理由和不确定状态，避免变成新的泛化信誉分数。

局限与展望¶

作者承认日志和预测文件都能被伪造；指标一致不能排除训练泄漏、查表输出、方法与代码不一致等问题。
适用范围主要是可重复的虚拟实验与数学定义明确的指标，不直接覆盖真实机器人操作、人类主观评测等实验。
五名审稿人的两类脚本计时，没有覆盖复杂依赖、超大输出、多数据集或昂贵评估模型；“通常不到一小时”主要是作者的负担估计。
调查依赖链接抽取、仓库抓取和 LLM 判别，且不同年份的论文发布时长不同。缺少独立人工审计和误差条，不能直接把代码可用性变化等同于真实复现成功率变化。
状态公开可能给未核验旧论文或合理豁免论文带来不当惩罚。值得试点记录豁免分布、实际核验时间、审稿人一致性与发现错误类型，而不是仅统计获标签比例。
安全第三方执行平台和 LLM 代码审计是未来设想，涉及托管费用、保密和运维；论文没有证明该平台已经可用。

评分¶

新颖性: 4/5 — 将轻量证据核验、正式决策和出版状态连接起来，政策粒度较清楚。
实验充分度: 2/5 — 大规模描述性调查有价值，但存在叙述冲突、小样本负担评估与缺少政策试点。
写作质量: 4/5 — 角色、材料和边界明确；部分总体趋势表述与附录表格不一致。
价值: 4/5 — 为无法强制完整开源的会议提供可试行方案，价值取决于真实实施成本与标签治理。