研究提案

[v2] 论文代码复现：构建科研版 SWE-bench，训练「用代码做科学」的执行能力

Papers with Code 上 10 万+ 论文是天然的训练数据素材。给模型论文 + 代码仓库，要求它复现核心实验、结果和原论文对齐——产出的执行轨迹是目前质量最高的科研能力训练数据，直接对应 terminal-level 的科研执行能力。

2026年3月29日论文复现代码执行 SWE-bench 科研执行中训练数据 Papers with Code Terminal Science

核心想法

Papers with Code 上有超过 10 万篇论文，每篇都有对应的开源代码仓库和可验证的实验结果。

这是天然的「科研版 SWE-bench」素材库。

SWE-bench 的任务是：给 GitHub issue，要求模型写代码修复，有测试用例验证。

这条路线的任务是：给论文 + 代码仓库，要求模型复现核心实验，以原论文的 Table / Figure 数值验证——模型不只是读懂论文，还要真正「用代码把实验跑出来」。

产生的执行轨迹是前两个提案无法达到的质量层级：不是模型自说自话的文字推理，而是有真实执行反馈的迭代过程。

一、为什么这条路线不同于前两个

前两个提案都在文字层面工作：

反向假设生成：给论文课题，要求推导出论文——输出是文字推论
综述反向构建：给原始论文集合，要求写综述——输出是结构化文字

论文代码复现在执行层面工作： 模型必须写代码、跑实验、看数字、和论文对比、诊断差距、修正。

这个「写代码→执行→观察结果→诊断→修正」的循环，产生的轨迹质量有本质差别——每一步都有外部现实（代码执行结果）作为锚点，不允许「自洽的错误推导」存在。

这是训练「可证伪性」的数据。

科学方法论的核心是可证伪性（falsifiability）——一个好的科学主张，必须能被实验反驳。模型在纯文字空间里可以无限自洽，但面对跑出来的数字，自洽就行不通了。这种压力是让模型真正具备科研能力的关键训练信号。

二、任务设计

2.1 基本框架

输入：
  - 论文全文（重点：实验设计、评估方法、核心 Table/Figure）
  - 对应的代码仓库（GitHub）
  - 实验环境规格（硬件、依赖版本）

任务：
  - 分析论文的核心实验设计
  - 理解代码结构和实现
  - 修改/配置代码，设计复现实验
  - 执行实验，获取结果
  - 与论文数据对比，分析一致性和差距

验证：
  - 核心指标与原论文偏差 < X%（可配置）
  - 完整的复现报告（方法、结果、差距分析）

2.2 三种难度层级

L1：配置复现（最基础）

代码仓库完整，有官方复现脚本，只需要正确配置环境和参数。

任务：读 README → 配置依赖 → 运行脚本 → 对比结果
技能：环境管理、参数理解、结果解读
适合领域：有完善复现文档的论文（如 NeurIPS/ICML 的代码仓库）

L2：局部实现（中等）

代码仓库存在但不完整，需要模型补全某个关键模块或实验。

任务：理解现有代码 → 识别缺失部分 → 实现缺失模块 → 验证整体跑通
技能：代码理解、模块设计、调试
适合领域：提供了基础框架但需要补全的论文

L3：从论文重新实现（最难）

只给论文，不给代码（或代码仅供事后验证）。

任务：读论文方法描述 → 独立实现 → 运行 → 与论文数据对比 → 迭代
技能：算法理解、端到端实现、科研级调试
适合领域：方法描述清晰、核心算法不过于复杂的论文

2.3 轨迹捕捉的关键环节

执行过程中产生的这些轨迹是数据的核心价值：

读论文阶段：

「核心实验是表 2 的第 3 行，评估方法是 BLEU-4 和 ROUGE-L」
「方法描述里有一个关键超参数 α，默认值在附录 B.2」

代码分析阶段：

「train.py 的第 127 行是模型的核心 forward pass，对应论文公式 (3)」
「config.yaml 里的 batch_size 需要根据显存调整，论文用的是 A100 80G」

实验执行阶段：

「第一次跑出来 BLEU-4 是 28.3，论文报告的是 31.7，差距较大」
「检查发现数据预处理步骤里 tokenization 方式不对，论文用的是 BPE 而不是 WordPiece」

诊断修正阶段：

「修正 tokenization 后结果是 30.9，和论文 31.7 差距缩小，剩余差距可能来自随机种子或硬件差异」
「在可接受误差范围内，复现成功」

这四个阶段的轨迹，完整呈现了「从理解实验设计到跑通实验」的全过程——这是目前训练数据里最稀缺的认知过程。

三、与 SWE-bench 的对比

维度	SWE-bench	论文代码复现
任务定义	修复 GitHub issue	复现论文核心实验
验证方式	单元测试通过	实验数值与论文对齐
成功标准	二元（通过/失败）	连续（偏差百分比）
所需能力	代码理解 + Bug 定位 + 修复	论文理解 + 实验设计 + 代码实现 + 科研判断
数据来源	GitHub issues	Papers with Code
数量规模	~2000 个任务	10 万+ 论文（可大规模扩展）
领域覆盖	主要是软件工程	全 AI/ML 子领域

SWE-bench 代表了「让模型能修软件 bug」，本方案代表了「让模型能做科研实验」。前者的数据规模有限且构建成本高，后者有 Papers with Code 这个天然的大规模数据源。

🔄 [v2 改进：与 SWE-bench 的实质性差异化]

上表列出了表面对比，但更深层的差异是任务的认知结构：

SWE-bench 验证「代码修复能力」：任务是找到一段有 bug 的代码并修复它，验证信号是单元测试（二元）。模型的认知负荷主要在「理解现有代码结构」和「局部修改」。

本方案验证「科研实验执行能力」：任务是从零理解一项研究、设计实验、执行并诊断结果。模型的认知负荷跨越「理解科学论文」、「规划实验」、「工程调试」和「科研判断」四个层面。

为什么不能直接扩展 SWE-bench？

SWE-bench 的 issue 定义假设了代码有 bug，而论文复现的失败往往来自「实现正确但参数/协议理解有偏差」——这是完全不同的失败模式

SWE-bench 的验证是功能性的（测试通过即可），科研复现的验证是数值性的（结果在误差范围内），需要不同的评估框架

科研数据的独特价值：训练模型理解「什么是足够好的复现」这种带有领域判断力的模糊标准，而 SWE-bench 只训练「正确/错误」的二元判断

因此，即使 SWE-bench 扩充了更多软件工程任务，它也无法覆盖「科研实验执行」这种需要跨领域科学理解的能力类型。

四、数据价值：为什么是「质量最高」的科研数据

1. 不可自洽的外部验证

文字推理可以「自说自话」，代码执行不行——数字是数字，差 10% 就是差 10%。这让每条轨迹都有无法绕过的现实锚点。

2. 多步骤有依赖的推理链

读论文→理解代码→配置实验→执行→对比→诊断→修正，每一步都依赖上一步的输出。这种有内在依赖的长推理链，是中训练最稀缺的数据类型。

3. 领域知识与工程能力的交叉

这类任务同时需要：理解论文中的算法原理（科学知识）+ 写出能跑的代码（工程能力）+ 判断结果是否合理（科研判断力）。三者交叉才能完成任务，产出的数据覆盖了模型能力的多个维度。

4. 难度可系统化分层

L1/L2/L3 的难度分层，加上论文本身的复杂度（方法是否清晰、代码是否完整、复现难度如何），可以构建从基础到高难度的系统化课程。

五、工程挑战与应对方案

这条路线的工程难度显著高于前两个，主要挑战：

5.1 代码执行沙箱

挑战：执行模型生成的代码，必须在隔离环境中，防止恶意代码、无限循环、资源耗尽。

方案：

参考 SWE-bench 和 TerminalBench 的沙箱设计
Docker 容器隔离 + 资源限制（CPU / 内存 / 时间上限）
文件系统只读（除指定输出目录）
网络隔离，仅允许访问预下载的数据集

5.2 依赖环境管理

挑战：不同论文的代码依赖差异极大，自动配置环境是最大的工程难点。

方案：

优先选择有完整 requirements.txt / environment.yml 的论文
使用 conda + Docker 实现依赖隔离
维护常见框架（PyTorch / TensorFlow / JAX）的基础镜像，减少配置成本
对依赖配置失败的案例，标注为「L3 级别任务」（需要模型自己排查依赖问题）

5.3 执行规模控制

挑战：Full training run 可能需要数天，无法用于数据生成。

方案：

只复现论文的「核心小实验」而非完整训练
优先选择有「quick demo」或「ablation study」的论文（通常小时级跑完）
对于训练时间过长的论文，使用「小数据集代理」验证方法正确性
设定硬性时间上限（如 2 小时/任务），超时标记为不可用

5.4 结果对齐标准

挑战：实验结果受随机种子、硬件差异影响，不同机器跑出来的数值本来就不完全相同。

方案：

以「数量级对齐」而非「完全复现」为标准（偏差 < 5% 视为成功）
记录环境差异（硬件、随机种子），纳入轨迹元数据
复现报告必须包含「合理的差距解释」

🔄 [v2 改进：结果对齐标准分任务类型细化]

原方案「偏差 < 5% 视为成功」对所有任务类型使用同一标准，但这个标准在随机性高的任务上过于严格——连原论文作者自己重跑也未必能过 5%。需要按任务类型分层设置容忍度：

任务类型推荐容忍度理由
确定性任务（分类、NER、精确匹配） ±3-5% 结果应高度可复现
NLP 生成任务（翻译、摘要、BLEU/ROUGE） ±5-8% tokenizer 差异、beam search 随机性
强化学习任务（Atari、MuJoCo、Policy Gradient） ±10-15% 探索策略和随机种子影响巨大，同一代码多次运行差距可达 20%
GAN / 扩散模型（FID 指标） ±10% FID 的随机性来自采样，运行次数不足时方差极大

处理随机性高任务的具体方案：

多次运行取均值：对 RL/生成类任务，运行 3-5 次，报告均值和标准差，只要均值落在容忍区间内即算成功

固定随机种子套件：优先选择代码仓库中已提供 --seed 参数且有 deterministic 模式的论文

降级验证：若无法满足数值容忍度，退而求其次验证「结果方向正确性」（如 A > B 而非精确数值），标注为「L2 验证」而非「L1 精确复现」

直接排除：对随机性极高（多次运行方差 > 20%）且无 checkpoint 可用的任务，标注为「不适合作为复现验证数据」，但可作为「诊断类训练数据」

任务类型	推荐容忍度	理由
确定性任务（分类、NER、精确匹配）	±3-5%	结果应高度可复现
NLP 生成任务（翻译、摘要、BLEU/ROUGE）	±5-8%	tokenizer 差异、beam search 随机性
强化学习任务（Atari、MuJoCo、Policy Gradient）	±10-15%	探索策略和随机种子影响巨大，同一代码多次运行差距可达 20%
GAN / 扩散模型（FID 指标）	±10%	FID 的随机性来自采样，运行次数不足时方差极大

六、数据来源与选题策略

Papers with Code 的利用

Papers with Code 提供了：

10 万+ 论文 + 代码的关联
各论文在标准 benchmark 上的结果（方便自动评估）
按任务类型、数据集、方法分类的结构化检索

选题优先级：

优先级	标准	理由
⭐⭐⭐	有官方代码 + 有复现记录 + 核心实验 < 2h	成功率高，数据质量稳定
⭐⭐	有代码 + benchmark 结果可验证	有自动评估锚点
⭐	代码存在但环境配置复杂	成功率较低，但 L3 任务价值高

三个条件的实际筛选方法

条件一：有官方代码——Papers with Code API 直接过滤 is_official=True。启发式补充：仓库 owner 与论文作者同名，或 README 含「Official implementation」字样。

条件二：有复现记录——社区已复现过，说明代码可以跑通。检测信号按可靠性排序：

信号	获取方式
Papers with Code 有 Results 表（社区复现数值）	直接查 API
GitHub Stars > 50	有人真的用过
Issues 里含「reproduced」「results match」关键词	搜 issue 标题/正文
有 `reproduction.md` 或 `REPRODUCE.md`	仓库文件检索
有预训练 checkpoint（releases 或 HuggingFace 链接）	说明作者自己跑过完整实验

条件三：核心实验 < 2h——没有直接字段，用代理指标组合估算：

代理指标	获取方式	逻辑
论文标注的 GPU 机时	解析 Experiments 章节	直接来源，但不是所有论文都写
数据集规模	Papers with Code dataset 字段	小数据集 → 实验快
有 `eval_only.sh` / `quick_start.sh` / `demo.py`	GitHub 文件检索	存在快速评估路径
Ablation study 有「each row takes X GPU hours」注释	解析表格 caption	可直接估算单次实验时长
仓库有预训练权重可下载	检索 `.pt` / `.ckpt` / HuggingFace 链接	跳过训练，只跑 inference 评估

最可靠的实践路径：有预训练权重 + 只跑评估脚本。把训练阶段换成加载官方 checkpoint，只验证 inference 结果和论文对齐——大多数 NLP/CV 论文可以在 30 分钟内跑完一个核心指标。

完整筛选 pipeline（可自动化）：

Papers with Code API
  → is_official = True
  → has_results_table（社区已有复现数值）
  → GitHub stars > 50
  → 有预训练 weights（搜索 .pt / .ckpt / huggingface.co 下载链接）
  → 有 eval_only 脚本 OR 数据集 < 10GB

10 万篇论文经过这套过滤，预计剩余几千篇高可用论文，是 L1 数据集的核心素材库。

🔄 [v2 改进：真实筛选漏斗推算——「几千篇」背后的数字]

原文「预计剩余几千篇」缺乏推导依据。以下是基于 Papers with Code 公开数据的第一性原理估算：

筛选层级条件估算数量数据来源
起点 Papers with Code 总论文数 ~120,000 PWC 官方统计（2025年）
L1 is_official=True（含作者提供代码） ~18,000 PWC API 实测约 15%（含 official+informal）
L2 有社区 Results 表（说明有人跑过） ~9,000 约 50% 的有代码论文有 results 记录
L3 GitHub Stars > 50 ~6,000 约 65% 的有 results 论文 stars > 50
L4 有预训练权重或 eval_only 脚本 ~3,500 约 55-60% 的论文提供 checkpoint 或快速评估路径
L5 核心实验预估 < 2h（有权重则跑 inference） ~2,800 约 80% 有权重的论文可以 30 分钟内跑完 inference
最终可用 L1 素材 以上全部满足 ~2,500-3,000 篇 第一性原理推算

关键洞察：

「几千篇」的直觉数字基本成立，但上限不会超过 ~3,000 篇（而非 10,000+ 篇）

瓶颈在 L4（有权重/快速评估脚本），这是工程可行性的核心约束

通过放开「核心实验 < 2h」到「< 4h」，可以扩充到约 5,000 篇，但运行成本加倍

L2/L3 级（代码不完整，需要模型补全）另有约 5,000-8,000 篇，但数据收集成本更高

筛选层级	条件	估算数量	数据来源
起点	Papers with Code 总论文数	~120,000	PWC 官方统计（2025年）
L1	`is_official=True`（含作者提供代码）	~18,000	PWC API 实测约 15%（含 official+informal）
L2	有社区 Results 表（说明有人跑过）	~9,000	约 50% 的有代码论文有 results 记录
L3	GitHub Stars > 50	~6,000	约 65% 的有 results 论文 stars > 50
L4	有预训练权重或 eval_only 脚本	~3,500	约 55-60% 的论文提供 checkpoint 或快速评估路径
L5	核心实验预估 < 2h（有权重则跑 inference）	~2,800	约 80% 有权重的论文可以 30 分钟内跑完 inference
最终可用 L1 素材	以上全部满足	~2,500-3,000 篇	第一性原理推算

领域分配（初期建议）：

NLP 方法论类（40%）：代码规范、复现文档完善
计算机视觉（20%）：实验规模可控
强化学习（20%）：有独特的执行反馈信号
其他 AI/ML 子领域（20%）：保持多样性

七、与三个提案的整体关系

三个方案合在一起，构建的是一套完整的「科研能力」训练数据体系：

                    科研能力
                       │
        ┌──────────────┼──────────────┐
        │              │              │
   推理链能力      整合能力        执行能力
（单点深推）   （多源聚合）    （代码+现实）
        │              │              │
  反向假设生成   综述反向构建   论文代码复现
  （本系列一）  （本系列二）  （本系列三）
        │              │              │
   纯文字轨迹    纯文字轨迹    代码执行轨迹
   中等难度      较高难度      最高难度

三者的数据质量递增，工程复杂度也递增。可以按这个顺序逐步推进，每一个都有独立的价值，不需要等前一个完成才能启动后一个。

八、实施路径

阶段一：可行性验证（1-2 周）

从 Papers with Code 选取 20 篇 L1 级论文（有完整复现文档）
手动验证这 20 篇在 2 小时内可以跑通
设计评估框架：复现成功率 + 结果偏差分布
构建基础沙箱环境（Docker + 资源限制）
让当前最强模型跑 5 篇，观察执行轨迹质量

验证目标：沙箱稳定、20 篇论文中 ≥ 15 篇可以在 2 小时内跑通

阶段二：数据规模化（3-5 周）

扩展到 200 篇（L1：L2：L3 = 5:3:2）
自动化 pipeline：论文筛选 → 环境配置 → 执行 → 结果对比 → 轨迹收集
质量筛选：执行轨迹完整 + 结果偏差在合理范围内
按难度分层，构建训练集

阶段三：中训练实验（4-8 周）

以 Qwen2.5-7B 做消融实验
对比：无代码执行数据 / 加代码数据（静态，不含执行轨迹）/ 加代码执行轨迹
评估：SWE-bench / TerminalBench + 内部科研执行评测

🔄 [v2 改进：评估闭环——训练后如何验证效果？]

原文「SWE-bench / TerminalBench + 内部科研执行评测」指出了评估方向，但缺乏具体方案。以下是可操作的评估闭环设计：

推荐评估基准（优先级排序）：

SciCode（首选）：专为科研代码能力设计的 benchmark，包含 338 个来自多个科学领域的真实科研编程任务（数学/物理/化学/生物），直接对应本方案训练的能力。评估指标：sub-problem 解决率。

TerminalBench 科研子集：TerminalBench 包含 terminal 环境下的长程任务，其中「科研子集」（research tasks）与本方案高度对齐。评估指标：任务完成率。

内部科研执行评测（自建）：从阶段一的「20 篇验证集」中保留 5 篇作为 hold-out 测试集，在中训练实验中作为人工评估锚点。

评估实验设计：
消融实验（以 Qwen2.5-7B 为基座）：
  Condition A：Base model（无额外训练）
  Condition B：+ 静态论文文本（无执行轨迹）
  Condition C：+ 执行轨迹数据（本方案完整数据）
  Condition D：+ 执行轨迹 + SWE-bench 数据（联合训练上限）

预期：C > B >> A，C ≈ D（说明执行轨迹是主要贡献因子）
关键验证问题： 如果 B ≈ C（即静态论文文本和执行轨迹效果相当），说明模型从执行反馈中学习的能力需要进一步研究。这个对照实验的结果对整个方案的价值判断至关重要，必须在阶段三中优先验证。

九、核心价值总结

论文代码复现方案解决的是一个核心问题：模型能不能真正「用代码做科学」，而不只是「谈论科学」。

这两者之间有巨大的鸿沟。当前模型能写出看起来合理的科研推导，但面对真实的代码执行结果时往往表现退化。原因很简单：没有这类训练数据。

Papers with Code 提供了一个独特的机会——把已有的 10 万+ 论文变成高质量的执行型科研训练数据，系统性地填补这个空白。

本提案是「科学推理能力中训练数据」系列的第三篇：
· 反向假设生成（系列一）
· 综述反向构建（系列二）
· 论文代码复现（本文，系列三）

参考：Papers with Code | SWE-bench | TerminalBench

本提案基于 2026-03-29 讨论整理。

原始版本：paper-code-reproduction-proposal