挖掘 GitHub Issues 中的论文复现踩坑记录：一类被忽视的高质量训练数据

动机：合成数据的天花板

当前主流的代码推理训练数据生成路径是「合成」——用强模型写代码、自我验证、蒸馏。这条路有明显上限：模型生成的复现轨迹，本质上是它已经知道答案之后的反向还原，缺乏真实的试错张力。更关键的是，真实的论文复现失败往往不是代码 bug，而是细节理解偏差：tokenization 策略、数据集分割方式、评估协议的微妙差异——这些坑，模型几乎不会主动”合成”出来，因为它不知道自己不知道。

GitHub 上沉淀了十几年的论文复现讨论，是一座天然的专家诊断知识库。一个典型案例是：某用户在 fairseq 的 Issue 里描述”我按 BLEU 论文跑出 28.4，但论文报 32.7”，随后另一用户回复”你是不是用了 sacrebleu 默认的 tokenizer，原论文用的是 Moses tokenizer”，问题得到闭合。这条三轮对话，浓缩了：问题现象的精确描述、假设生成、根因定位、验证方法——完整的专家推理链，且完全是真实发生的。

这类数据有一个独特属性：它记录的是人类专家在不确定性下的诊断过程，而非已知答案的展示。这正是当前 LLM 在科研代码任务上最缺乏的能力。

---

数据分布：踩坑的类型学

基于对 Papers with Code 高引论文（BERT、ResNet、PPO、DeiT 等）对应代码仓库的初步调研，复现踩坑可归纳为以下几类：

错误类型	典型描述	占比估计
超参数差异	学习率 warmup 步数、batch size 缩放规则	~30%
数据集版本/预处理	数据集年份版本、tokenization 方式、归一化参数	~25%
评估协议差异	beam size、后处理步骤、指标实现版本	~20%
框架/依赖版本	PyTorch 版本行为差异、CUDA 版本对结果的影响	~15%
随机种子与硬件差异	多卡训练不确定性、FP16 精度差异	~10%

这种分布意味着，这类数据覆盖了「超参数敏感性」「实验可重复性」「框架迁移」等科研代码任务的核心难点。一个能在这些类型上展示正确诊断推理的模型，在科研代码 Agent 场景中会有实质性优势。

---

系统化采集方案

第一步：确定目标仓库集合

以 Papers with Code（pwc）作为论文-代码仓库的索引入口。PWC 的 API 提供了论文与 GitHub 仓库的对应关系：

import requests

def get_pwc_repos(page=0, items_per_page=50):
    url = f"https://paperswithcode.com/api/v1/repositories/"
    resp = requests.get(url, params={"page": page, "items_per_page": items_per_page})
    return resp.json()["results"]

目标仓库优先级：PWC 上 star 数 > 200、被引次数 > 50 的论文对应仓库，预计覆盖约 2 万个高质量仓库。

第二步：GitHub API 批量拉取 Issues/Discussions

from github import Github
import time

def fetch_issues_for_repo(repo_full_name: str, g: Github):
    repo = g.get_repo(repo_full_name)
    issues = repo.get_issues(state="all", labels=["reproduction", "results"])
    # 同时拉取无 label 的，依赖后续关键词筛选
    all_issues = repo.get_issues(state="all")
    return [
        {
            "title": i.title,
            "body": i.body,
            "comments": [c.body for c in i.get_comments()],
            "state": i.state,
            "created_at": str(i.created_at),
            "closed_at": str(i.closed_at),
            "reactions": i.reactions.total_count,
        }
        for i in all_issues
        if is_reproduction_issue(i)
    ]

def is_reproduction_issue(issue) -> bool:
    keywords = [
        "reproduce", "replication", "results don't match",
        "reported in paper", "paper reports", "cannot reproduce",
        "got X but paper says", "复现", "指标对不上"
    ]
    text = (issue.title + " " + (issue.body or "")).lower()
    return any(k in text for k in keywords)

GitHub API 有速率限制（5000 req/hour for authenticated），采集 2 万仓库约需 40–80 小时，建议分布式跑多个 token 轮换。Discussions API 需要 GraphQL 接口单独处理。

第三步：结构化提取对话链

一条高质量的训练样本应具备完整的推理链结构：

{
  "repo": "facebookresearch/fairseq",
  "paper": "Attention Is All You Need",
  "issue_id": 1423,
  "problem_statement": "我的 BLEU 是 28.4，论文报 32.7",
  "hypothesis_chain": [
    "可能是 beam size 不同",
    "可能是 tokenizer 不同"
  ],
  "root_cause": "使用了 sacrebleu 默认 tokenizer 而非 Moses tokenizer",
  "resolution": "切换到 --sacrebleu --tokenizer moses 参数",
  "has_code_snippet": true,
  "is_resolved": true,
  "error_type": "evaluation_protocol"
}

结构化提取可以用 LLM 辅助完成（对已有的 raw issue 做 structured extraction），但原始对话本身作为训练数据的价值不依赖提取质量。

---

质量筛选策略

筛选的核心原则是优先完整推理链，具体评分维度：

1. 已关闭 + 有明确解决方案（+3分）：closed issue 且有 “resolved by” / “fixed in” 等标记
2. 有代码片段（+2分）：包含 ``` 代码块，说明诊断过程有可验证性
3. 多轮对话（+1分）：评论数 ≥ 3，说明有来回的假设-验证过程
4. 高互动（+1分）：reactions ≥ 5 或被引用，说明问题有普遍性
5. 量化的性能差距（+1分）：包含具体数值（“28.4 vs 32.7”），精确度更高

过滤掉：纯 feature request、环境配置问题（CUDA 安装等）、无任何回复的 issue。

目标是保留「问题描述清晰 + 诊断过程可见 + 解决方案明确」的三角完整案例。

---

规模估算

• Papers with Code 收录论文：~12 万篇（截至 2025 年），其中约 4 万篇有关联代码仓库
• 有 Issues 功能的活跃仓库：约 2 万个
• 每个仓库平均 Issues 数：~150 条（含 closed）
• 与复现相关的 Issue 比例：约 8–12%（基于对 50 个高引仓库的人工抽样）
• 通过质量筛选（分数 ≥ 4）的比例：约 30%

粗略估算：

20,000 repos × 150 issues × 10% relevance × 30% quality = ~90,000 条

加上 GitHub Discussions（部分仓库迁移到 Discussions），总量估计在 8 万–15 万条高质量复现诊断对话。这是一个可观的规模，足以支撑专项微调或作为 RLHF 的偏好数据对。

---

与论文代码复现 Benchmark 的关系

这类数据与「科研版 SWE-bench」构成互补关系：

• SWE-bench 提供的是任务（给定一个失败的测试，修复代码）
• 复现踩坑数据提供的是参考轨迹（一个真实专家是如何思考和诊断的）

具体应用路径：

1. 作为 L1 任务（环境配置/依赖对齐）的诊断示例：框架版本类 issue 直接映射到「给定错误日志，定位版本冲突」任务
2. 作为 L2 任务（性能复现）的推理链监督：超参数/评估协议类 issue 提供了「gap 分析 → 假设 → 验证」的完整范式
3. 作为偏好对：同一问题的「正确诊断」vs「错误诊断」可以构造 DPO 训练对，教模型区分有效推理和无效猜测

---

下一步行动

1. 小规模验证：选取 PWC NLP 榜单前 100 论文的代码仓库，手工标注 500 条 issue，验证规模估算和分类准确率
2. 采集流水线：实现 GitHub API + GraphQL Discussions 的并行采集脚本，目标 2 周内完成 top-2000 仓库的全量采集
3. 结构化提取：用 GPT-4o / Claude 对 raw issue 做 structured extraction，验证提取质量（与人工标注对比 F1）
4. 数据集发布：整理为 HuggingFace Dataset，与科研版 SWE-bench 配套发布，推动社区验证

这类数据的价值在于它的不可合成性：它记录的是人类专家在真实不确定性中的推理，而不是事后的知识展示。用它训练的模型，将在科研代码任务上具备更接近真实专家的诊断直觉。