ReproRepo：利用 GitHub 仓库问题扩展可复现性审计

论文信息

标题: ReproRepo: Scaling Reproducibility Audits with GitHub Repository Issues

作者: Shanda Li, Qiuhong Anna Wei, Jingwu Tang, et al.

发布日期: 2026-06-16

arXiv ID: 2606.18237v1

PDF 链接: 下载 PDF

3 分钟速览

研究问题：现有评估大语言模型（LLM）代理协助科研复现能力的基准难以规模化，因为强烈依赖人工标注、专家评分和手动准备任务。本文旨在提出一个可扩展、真实且易于更新的复现性评估框架。
核心方法：ReproRepo 框架将 GitHub 上用户报告的真实复现障碍（issues）作为自然产生的监督信号，让 LLM 代理在不执行代码的情况下静态审查论文及其代码仓库，预测潜在的复现问题，再通过与隐藏的人类报告进行语义比对来评估代理的能力。
关键结果：在涵盖 1149 篇近期机器学习论文的基准上，最佳配置（Codex + GPT‑5.5）对约 90% 的论文（ICLR 2026）能够识别出至少一个与人类报告语义相关的问题（见表 3）。
主要局限：GitHub issues 本身带有噪声且不完备；评估仅限于静态检查，无法捕获运行期错误、硬件差异等执行时故障；代理在精确错误定位上仍存在明显不足。
适合读者：关注科研可复现性、大语言模型自动化审计、科学工作流代理、开源仓库维护以及会议论文质量评估的研究者和工程师。

论文背景和研究动机

推动科学进步的核心环节之一是复现已有研究成果，尤其是在以代码和数据为驱动的机器学习领域。传统的复现性工作多依赖人工撰写检查清单、手动执行代码或专家评审，成本高昂且覆盖面窄。随着大语言模型代码和推理能力的提升，研究者开始探索能否用 LLM 代理辅助甚至自动化复现性的评估。然而，已有的评估基准（如表 1 所示）普遍面临可扩展性的瓶颈：它们通常需要专家设计复现任务、注入人为错误、编写评分大纲或手动评判，导致数据规模不足（通常不超过百篇论文）、更新困难，且多集中于高质量工件，难以反映真实研究中广泛存在的粗糙仓库和即时报错。

Repository 的 GitHub issues 天然记录了真实用户遇到的复现障碍。用户为了使用、测试或扩展论文代码，会在仓库中报告缺失的依赖、错误的命令、不一致的数据链接、训练或评估崩溃等问题。ReproRepo 的核心洞察在于，这些 issues 可以充当免费、持续生成且多样化的监督信号，从而绕开昂贵的人工标注。作者提出通过收集会议论文的公开代码仓库及其 issues，构建一个大规模、可自动更新的复现审计基准，让 LLM 代理在 “静态无执行” 的条件下尝试复现潜在问题，再用真实的用户 issues 来评估代理的输出质量。这一思路直击当前领域的痛点：用极低的人力成本换取了真实复现场景和多论文的广覆盖。

核心方法和技术细节

ReproRepo 框架分为数据构建、代理审计和评估三个环节（见图 1）。

数据构建 从顶会（NeurIPS 2022/2024 主会和数据集 & 基准 track，ICLR 2026）的接收论文出发，通过 Paper Copilot 和会议元数据自动获取公开仓库链接。只保留至少包含一个 “与复现相关” issue 的论文，并用 LLM 判断对 issues 进行过滤。随后为每个 issue 构建对应的仓库快照：对于未关闭 issue 使用默认分支的当前状态；对于已关闭 issue 则回溯到 issue 创建前的仓库状态（甚至对带有补丁记录的问题额外保留修复后的快照用于后验）。最终得到 1149 篇论文和 7553 个复现相关的 GitHub issues（含 150 个有明确代码补丁的封闭问题）。

代理任务 代理仅获得论文 PDF 和过滤掉 .git 历史的静态仓库快照，无网络、无 GPU、无代码执行权限。它被要求输出一份排序的 JSON 发现列表，每个发现应模仿 GitHub issue 的风格，描述一个用户可能遇到的复制障碍，并按发生概率由高到低排列。输出内容包括症状、触发条件、根因、证据文件路径等。任务定义为纯静态审计，强调使用 README、配置文件、脚本、论文声明中的不一致等可见痕迹。

评估使用独立的 LLM 评判器将代理的发现与隐藏的人类 issues 进行对比，为每一个隐藏 issue 分配标签：精确匹配（EM，几乎完全一致的复现问题）、语义匹配（SM，同属一个区域但具体触发点不同）或无匹配（None）。主要指标为 top‑ $k$ 报告预算下的 issue 级别匹配率和论文级别匹配率（论文 “任何 issue 被匹配” 和 “所有 issue 均被匹配”）。文中报告 $k=10$ 为主要结果，并考察了不同预算下的变化。为量化误报，对拥有补丁的已关闭 issue 运行修复后快照，检查代理是否仍然 “发现” 该问题，由此计算论文级别误报率（FPR），提供了一个保守的上界。

实验环境涵盖两类代理（Claude Code 和 Codex）搭配四种前沿模型（DeepSeek‑V4‑Pro、Claude Opus 4.7、GPT‑5.4‑Mini、GPT‑5.5），全部在静态、无执行条件下运行。

创新点和贡献

论文的贡献可归纳为三点：

以真实用户反馈驱动的可扩展框架：ReproRepo 首次将 GitHub issues 作为可复现性评估的内生监督，无需专家编纂问题或人为注入错误。这种机制天然支持持续更新，新论文发布后可按相同流水线自动入库，解决了现有基准快速过时的根本缺陷。
大规模、多会议的基准实例化：构建了包含 1149 篇论文、7553 个真实复现障碍的数据集，跨越三个顶会、两年跨度与两个 track，远超过以往工作（通常 ≤100 篇）。问题类别涵盖安装崩溃、运行时崩溃、静默错误配置和静默结果错误，且各会议的类别分布高度一致（见图 2），表明基准反映的是普遍性问题模式，而非某个会场的特定规范。
系统化的静态审计能力评估：首次系统揭示了无执行条件下 LLM 代理的复现问题发现能力。发现代理大概率能覆盖人类提出的问题区域（语义匹配率高），但难以精确定位确切触发条件。同时通过消融实验证实，加上论文信息能显著提升精确匹配率（约 8.98 个百分点，表 6），说明仅审查代码能感知风险区域，但需结合论文才能落实到真正的复现障碍。

实验结果分析

主要发现：静态审计远非无效 在 ICLR 2026 的验证集上，GPT‑5.5 + Codex 配置的 issue 级精确匹配率（EM@10）为 25.4%，语义匹配率（SM@10）高达 58.1%；论文级 “任何 issue 匹配” 的语义匹配率更达到 89.7%（表 3）。该模式在不同会议和年份上保持稳定（表 4），表明静态检查能够捕捉到大量仓库中 “看得见” 的复现风险，这一结果对于那些担心代理只会产生无效告警的观点是一种有力对冲。

精确定位仍是瓶颈 语义匹配率远高于精确匹配率，这一差距贯穿所有模型和会场（如表 3、4）。说明代理常常能指出 “大致哪个工作流或哪个配置文件有问题”，但无法确切复现用户报告的根因。例如，代理可能识别出某个检查点缺失，却说不清究竟是文件名错误还是路径未公开。这表明可以将代理用作问题范围的初步筛选工具，而不能替代细粒度的人工排查。

误报率极低 对于有补丁修复的封闭 issue，在修复后快照上代理报告该问题的比例仅为 1.4%–3.5%（见表 3）。说明代理的发现并非大而化之的 “万能告警”，大部分告警在 repo 状态改变后会自动消失，进一步增强了将代理输出用于实际审查的信心。

各类失败的检测差异性 图 4 显示，代理对 “静默错误配置”（如配置不一致、缺少评估脚本）和 “立即崩溃”（如导入错误）的召回率较高，而对 “延迟崩溃” 和 “静默错误数值” 的发现能力明显不足。原因在于后两类问题往往需要实际运行、下载大型数据集或对照实验结果，难以从静态文件中直接推断。

成本与报告预算 最经济的 DeepSeek‑V4‑Pro 模型每次审计成本仅 $0.29，却能在论文级任意匹配的语义指标上达到 89.0%（表 3），与最优模型相当。匹配率在较少报告条目（ $k=4$ 左右）即接近饱和（图 3），表明代理能把最可能的真实问题排在报告前列，适合带宽受限的人工审阅。

附加分析 对排名靠前但未匹配人类 issue 的代理发现进行人工审查发现，几乎所有此类发现都有静态证据支撑，很多属于并行复现风险，只因用户未报告或仅遇到第一个屏障而未被人类 issue 覆盖（表 5）。这进一步说明，代理产出的 “未匹配” 发现并非无效，而是当前稀疏人工标注带来的低估，框架本身的召回潜力可能比指标显示的更高。

实践建议

ReproRepo 的成果可直接应用于工程落地场景：

会议论文初筛工具：论文委员会或程序主席可将该框架嵌入投稿流程（类似 checklist 助手），自动对每篇论文的公开仓库进行静态审计，生成一份排序的风险清单供审稿人快速浏览。实验表明，静态审计可在无额外计算资源下覆盖约 90% 论文的已知风险区域，大幅降低人力初筛负担。
仓库维护者自检面板：开源项目维护者可将 ReproRepo 作为持续集成的一环，每次提交后自动运行静态审计，并将预测问题与已有 issues 交叉比对，快速定位未发现的文档缺失、配置不一致等潜在陷阱。低误报率使这种审计可切实纳入常规 devops 流程。
研究者的自我复现预检：研究者在发布代码前可运行代理，模拟外部用户首次尝试复现的过程，提前修正 README 中的命令错误、补充缺失的模型/数据链接、标注环境依赖的精确版本等，从而提升首次用户体验，减少后期 issue 涌入。
与执行环境结合：尽管当前框架聚焦于静态检查，但在未来可将其与 CORE‑Bench 等执行型基准结合。先用静态审计快速归类高风险论文和问题区域，再针对性地分配 GPU 计算执行检查，兼顾覆盖率和成本。
动态基准维护：由于 GitHub issues 天然随时间增长，ReproRepo 可以定期抓取新 issue 更新基准，无需一次性大规模人工标注，保持对快速演进的机器学习研究生态的持续适配。组织可将此管道作为内部工具，跟踪本机构产出的仓库健康度。

综合来看，ReproRepo 为 “自动化复现审计” 这一方向提供了低成本、可操作且易于复现的起点，将有望推动学术界与工业界在科研质量保障上的广泛应用。