[v2] Sandbox 作为数据合成核心资产：从执行副产品到训练主力军

核心洞察

当前 AI 科研 agent 的训练数据有一个共同的弱点：错误轨迹要么是合成的（不够真实），要么是随机注入的（没有科研针对性）。

本提案提出一个几乎未被论文触及的视角：

同一个实验，在不同 Sandbox 配置下跑出不同结果，这个差异本身就是最真实的「错误诊断」训练数据。

这不是 bug，这是数据金矿。

科研实验的「可复现性危机」在学术界已讨论多年——同样的代码、在不同环境、不同时间、不同硬件上跑出不同结果，几乎是常态。过去这被当作一个需要解决的问题。但换一个角度：如果我们主动、系统地制造这种差异，每一对「成功配置 vs 失败配置」就是一条带有完整上下文的诊断轨迹。

这个视角的新颖性在于：它把 Sandbox 从「运行环境」重新定义为「数据生产机器」。

---

什么样的 Sandbox 变体会产生有价值的错误

并非所有差异都值得收集。有价值的错误需要满足两个条件：可诊断（有明确的根因）和有科研意义（根因指向真实的科研执行挑战）。

以下五类变体是高价值来源：

1. 依赖版本差异

• 变体示例：PyTorch 1.12 vs 2.0，CUDA 11.3 vs 11.7，transformers 4.28 vs 4.38
• 典型错误模式：API 变更导致的 AttributeError，精度差异导致的结果偏移，显存分配策略变化导致的 OOM
• 诊断价值：版本兼容性是论文复现最高频的失败原因，占比超过 40%

2. 硬件差异

• 变体示例：单 GPU vs 多 GPU，A100 vs V100，不同显存上限
• 典型错误模式：多卡通信错误，batch size 无法适配，混合精度在不同架构上的行为差异
• 诊断价值：硬件相关错误往往需要对底层计算有深刻理解，是高难度诊断能力的训练来源

3. 随机种子

• 变体示例：固定种子 vs 不固定，不同种子值（42, 0, 12345, …）
• 典型错误模式：结果方差过大（论文声称±0.1%，实际跑出±3%），某些种子触发数值不稳定
• 诊断价值：帮助模型学习区分「复现失败」和「统计正常波动」，这是科研诊断中极其微妙的判断

4. 数据集版本差异

• 变体示例：ImageNet 的不同预处理脚本，GLUE benchmark 的不同下载源，自建数据集的不同 split 方式
• 典型错误模式：指标系统性偏低，训练集泄漏，评估集构成不一致
• 诊断价值：数据问题是最难发现的错误类型，因为代码运行正常但结果不对，需要更深层的溯源能力

5. 超参数微变

• 变体示例：学习率 1e-4 vs 1e-3，warmup steps 100 vs 500，dropout 0.1 vs 0.2
• 典型错误模式：训练不收敛，loss 震荡，过拟合提前出现
• 诊断价值：超参数敏感性分析是科研实践的核心技能，微小变化导致大幅性能差异的场景是高质量训练数据

---

数据生产方式：Matrix Testing 系统化流程

核心方法是笛卡尔积配置矩阵（Matrix Testing）——对每篇论文代码，系统地枚举关键维度的取值组合，批量生产配置对。

流程设计

输入：一篇开源论文代码仓库
         ↓
Step 1: 配置维度提取
  - 自动解析 requirements.txt / environment.yml / Dockerfile
  - 识别关键超参数（argparse / config file）
  - 标注硬件依赖项
         ↓
Step 2: 矩阵生成
  - 定义「锚点配置」：能成功复现论文结果的配置（经人工验证或自动验证）
  - 对每个维度生成 N 个变体值
  - 笛卡尔积展开（可设优先级过滤，避免组合爆炸）
         ↓
Step 3: 批量执行
  - 在 Sandbox 集群中并行运行所有配置
  - 完整记录：环境信息 / stdout+stderr / 中间 checkpoint / 最终指标
         ↓
Step 4: 结果分类
  - 成功：指标落在论文声称范围内（±容差）
  - 部分成功：代码运行完成但指标偏差超阈值
  - 失败：运行报错终止
         ↓
Step 5: 诊断轨迹构建
  - 以「锚点配置」为正例
  - 以每个失败/偏差配置为负例
  - 生成「正例 + 负例 + 根因标注」三元组

一条诊断轨迹的数据结构

{
  "paper_id": "arxiv:2301.xxxxx",
  "anchor_config": {
    "pytorch": "1.12.1",
    "cuda": "11.3",
    "seed": 42,
    "lr": 1e-4,
    "result": {"accuracy": 0.847}
  },
  "variant_config": {
    "pytorch": "2.0.1",
    "cuda": "11.7",
    "seed": 42,
    "lr": 1e-4,
    "result": {"error": "AttributeError: 'Tensor' object has no attribute 'data_ptr'"}
  },
  "delta_dimensions": ["pytorch_version", "cuda_version"],
  "diagnosis": {
    "root_cause": "PyTorch 2.0 移除了 .data_ptr() 的隐式转换，需显式调用 .contiguous().data_ptr()",
    "fix_patch": "...",
    "difficulty": "medium",
    "category": "api_deprecation"
  },
  "trajectory": [
    {"step": 1, "action": "run training", "output": "..."},
    {"step": 2, "action": "observe error at epoch 0", "output": "AttributeError..."},
    {"step": 3, "action": "search error message", "output": "..."},
    {"step": 4, "action": "apply fix", "output": "..."},
    {"step": 5, "action": "verify fix", "output": "accuracy: 0.845"}
  ]
}

---

与现有方案的关系：把副产品变成主产品

这个提案处于两条现有路线的交叉点：

Agent Sandbox（基础设施层） 提供了可控、可重现的实验执行环境。但 Sandbox 当前的角色是「工具」——用来跑实验。本提案把它升级为「数据工厂」。

论文代码复现（数据来源层） 已经在系统性地收集复现轨迹。但当前的数据收集是线性的：一次复现 = 一条轨迹。本提案引入矩阵化维度，让一次复现工作扩增为 N×M 条训练数据。

这个交叉点的价值在于：

1. 边际成本极低：一旦锚点配置建立，矩阵测试可以大规模并行，边际数据成本接近于零
2. 质量护城河：这类数据只能通过「真实运行」产生，无法通过 LLM 合成高质量替代品
3. 领域特异性：错误轨迹来自真实科研代码，而非随机软件工程场景，训练出的诊断能力有科研领域针对性

---

潜在规模与质量分析

规模估算

以 Papers With Code 上约 10,000 个可运行的开源仓库为基础：

• 平均每个仓库可提取 5 个关键配置维度
• 每个维度平均 3 个变体值
• 笛卡尔积取子集（取 20 个代表性组合）
• 预计成功率：约 30% 配置成功运行

10,000 仓库 × 20 配置 × 70% 失败率 = 约 140,000 条失败轨迹
× 平均诊断步骤 8 步 = 约 1,120,000 个带标注的诊断动作

质量对比

数据来源	真实性	科研针对性	可规模化	成本
完全合成（LLM 生成）	低	中	高	低
随机 bug 注入	中	低	高	中
Sandbox 矩阵测试（本方案）	高	高	高	中
人工标注复现轨迹	高	高	低	极高

本方案在真实性和科研针对性上接近人工标注，但可以规模化——这是当前其他方案无法同时做到的组合。

🔄 [v2 改进]

规模估算修正（第一性原理重推导）

原始估算「140,000 条失败轨迹」建立在两个问题假设上：(1) 70% 统一失败率；(2) 忽略计算成本约束。重新从第一性原理推导：

步骤 1：任务时长分布

10,000 个仓库按执行时长分布如下（基于 Papers With Code 仓库类型分析）：

• L1 任务（CPU-only, <10min）：NLP 小模型、数学证明、图算法类 ≈ 30% = 3,000 仓库
• L2 任务（单 GPU, <1h）：中等规模图像/NLP 实验 ≈ 50% = 5,000 仓库
• L3 任务（多 GPU, >1h）：大模型训练、大规模视觉 ≈ 20% = 2,000 仓库

步骤 2：计算预算约束

若总预算上限 = 10,000 GPU 小时（可行的初期投入）：

• 10,000 仓库 × 20 配置 × 均值 30 分钟 = 100,000 GPU 小时（预算不足 10 倍）
• 即便只跑 L1 任务：3,000 × 20 × 10min = 10,000 CPU 小时（可行）

步骤 3：修正后规模

采用分级策略，预算分配：L1 占 60%，L2 占 30%，L3 占 10%：

• L1 可行实验数：3,000 仓库 × 20 配置 = 60,000 次
• 结合修正后失败率（见下节）约 40%：≈ 24,000 条失败轨迹
• 经诊断价值过滤后（见后文）：≈ 12,000 条有效高质量轨迹

这比原估算的 14 万条少一个数量级，但每条质量更高，且预算可行。

---

开放挑战与风险

计算资源：矩阵测试需要大量 GPU 时间。缓解方案：优先运行低成本实验（NLP 小模型 > 大规模视觉模型），建立运行时长预算上限。

根因标注质量：自动标注根因是难点，LLM 辅助标注 + 人工抽查是初期方案，后续可以用标注好的数据训练专门的根因分类器形成飞轮。

仓库质量参差不齐：Papers With Code 中相当一部分仓库连锚点配置都难以建立。需要设计仓库质量过滤流程，优先处理有 Dockerfile 或详细 README 的仓库。

🔄 [v2 改进]

「70% 失败率」分类修正

原始估算使用统一 70% 失败率，但不同变体类型失败率差异极大，统一数字严重高估了整体失败率。基于文献与工程经验，按 5 类变体分别估算：

变体类型	失败率估算	依据
依赖版本差异	60–80%	主要 API 变更约每两个大版本发生一次；PyPA 兼容性矩阵数据
硬件差异	30–50%	多卡通信错误约 20%，batch size 不适配约 15%，精度差异约 10%
随机种子	10–20%	大多数差异为统计波动，非「失败」；真正触发不稳定的种子约占 10-20%
数据集版本差异	40–60%	split 变更、预处理脚本升级影响指标，但不报错
超参数微变	20–40%	收敛失败通常集中在学习率极端值；dropout 微变影响有限

综合加权估算：假设 5 类变体各占约 20%，加权失败率 ≈ 32%–50%，取中位约 40%，显著低于原始 70%。

修正影响：原估算 140,000 条 → 修正为约 48,000 条（基于可行 L1+L2 仓库，失败率 40%）。

🔄 [v2 改进]

「诊断价值过滤」机制

「跑崩了但没有错误日志」的失败对训练毫无价值——模型从中学不到任何可诊断的知识。需在进入训练集之前增加以下过滤层：

过滤标准（满足任一条件才保留）：

1. 有效错误信号：存在非空 stderr 输出，或指标值与锚点相差超过预设阈值（如 >5% 性能差距）
2. 可诊断关键词：stderr 中包含可解析的错误类型（如 AttributeError、CUDA error、ImportError），而非裸的 SIGKILL、OOM 或空输出
   • 排除类：Killed（纯 OOM，无上下文）、Segmentation fault（无 Python traceback）、空 exit 1
   • 保留类：Python traceback 完整、有具体 CUDA error code、有版本不兼容的明确提示
3. 上下文完整性：失败发生时有中间 checkpoint 或足够的运行日志，可以定位到失败步骤

预期过滤比例：约 50% 的失败为「无诊断价值失败」（主要是 OOM、超时、随机崩溃）

修正后有效样本估算：

• 基于修正失败率（40%）和 L1 可行规模：48,000 条原始失败 × (1 - 50% 过滤) ≈ 24,000 条有诊断价值的轨迹
• 考虑根因标注人工成本，Phase 1 目标为 5,000–8,000 条高精度标注轨迹

🔄 [v2 改进]

评估闭环：如何验证这批数据对下游模型有效

仅构建数据还不够，需要一套验证「数据 → 模型能力提升」的实验闭环：

Step 1：构建评估基准（Diagnostic Benchmark）

从已标注轨迹中留出 10–15% 作为 held-out 测试集（不参与训练），构建两类测试：

• 诊断准确性测试：给定失败配置的错误日志，让模型预测根因类别（版本/硬件/数据/超参），与人工标注对比
• 修复建议测试：给定失败场景，让模型生成修复方案，由人工评估方案的正确性和可操作性

Step 2：消融实验设计

对比以下训练配置，在同一基座模型上训练：

• 基线：仅使用成功复现轨迹（无失败数据）
• +随机注入失败：在成功轨迹中随机注入错误
• +本方案矩阵失败数据（不同规模：1k/5k/20k 条）

指标：诊断准确率、修复建议采纳率（人工评估）、在真实复现任务上的 end-to-end 成功率

Step 3：在线 A/B 测试

Phase 2 后，在真实科研 Agent 系统上进行 A/B 测试：对照组（原模型）vs 实验组（加入矩阵失败数据训练的模型），收集用户反馈和任务完成率。

---

建议的推进路径

Phase 1（1-2 个月）：选取 50 个高质量论文仓库，手工建立锚点配置，开发矩阵测试 pipeline，验证数据质量。

Phase 2（3-4 个月）：扩展到 500 个仓库，引入 LLM 辅助根因标注，建立质量评估 benchmark。

Phase 3（6 个月+）：全规模运行，数据与模型训练形成飞轮——用训练好的诊断模型辅助标注新数据，降低人工成本。

---

总结

Sandbox 不只是运行实验的工具，它是一台数据生产机器。

把「可复现性危机」从问题翻转为资产——这是本提案的核心立场。科研 AI 最稀缺的能力之一是错误诊断：当实验结果不对时，能快速定位是环境问题、数据问题还是超参数问题。这种能力需要大量真实的错误-诊断轨迹来训练，而 Sandbox 矩阵测试是目前最具性价比的生产方式。

这个方向目前在论文里几乎是空白，是值得抢占的数据基础设施先机。

---

相关研究：论文代码复现提案 | Agent Sandbox 全景 | 科研能力数据体系：三条路线全景

原始版本：sandbox-as-data-synthesis-asset