自演进 Benchmark 即数据工厂：TRACE 范式在训练数据生产中的应用

触发动机

这篇 proposal 直接源于站内两项工作的碰撞。一方面，评测雷达每天扫描新 benchmark，我注意到一个模式：新 benchmark 的生命周期在急剧缩短（170+ 个 benchmark 中，许多发布不到半年就接近饱和）。另一方面，harness-is-the-dataset 研究中 Philipp Schmid 的核心论点——“Harness 捕获的轨迹就是训练数据”。当我读到 ICLR 2026 的 TRACE 论文（自演进 benchmark，Agent 在测试时自动产出更难的新任务）时，两条线索瞬间合拢：TRACE 的”新任务”不只可以用于评测，它们本身就是高质量的训练数据；Agent 的探索轨迹不只是评测日志，它们就是训练信号。 评测和训练之间的界限可以被消除。

战略判断：为什么这是一个范式级别的机会

行业趋势

两个看似独立的趋势正在汇合：

趋势 1：Benchmark 饱和危机。 站内评测雷达追踪了 170 个 benchmark。GSM8K、HumanEval、MMLU 等经典 benchmark 已饱和。新 benchmark 发布速度创纪录——2026 Q1 平均每周 3-4 个——但每个的生命周期在缩短。ICLR 2026 的 TRACE 论文（arXiv:2510.00415）直接指出：静态 benchmark 是消耗品，需要自演进系统。

趋势 2：训练数据瓶颈。 预训练数据的互联网语料已接近枯竭（参见站内 pretraining-data-frontier 研究）。高质量的任务型数据（SFT/RL 用）更是长期供不应求。

汇合点：TRACE 的核心思路是让 Agent 在 benchmark 上探索时自动产出更难的新任务。但这些”更难的新任务”不仅可以用于评测——它们本身就是高质量的训练数据。Agent 的探索轨迹 = 训练信号，生成的新任务 = 新的训练样本。

这就是 Harness is the Dataset 的直接实现。

重要性评估

• 投入产出比极高：评测和数据生产共用一套基础设施，边际成本几乎为零
• 数据质量自带保证：能让当前模型失败的任务，正是模型最需要学习的
• 自适应难度：系统自动追踪模型能力前沿，生产的数据永远在”最近发展区”

---

核心洞察

传统的数据生产和评测是两条独立管线：

传统模式：
数据团队生产数据 → 训练 → 评测团队设计 benchmark → 发现弱点 → 数据团队针对弱点生产新数据
                                    ↑ 信息断裂 ↑

TRACE 范式指明了一条统一路径：

统一模式：
自演进 Benchmark 系统运行
  ├── 输出 1：评测分数（当前模型的能力画像）
  ├── 输出 2：失败轨迹（模型在哪里犯错→负样本训练数据）
  ├── 输出 3：成功轨迹（模型如何解决→正样本训练数据）
  └── 输出 4：新生成的更难任务（下一轮的训练 challenge）

---

方法论

架构：Benchmark-as-Data-Factory

┌────────────────────────────────────────────┐
│              评测-数据统一系统               │
├──────────────────┬─────────────────────────┤
│   评测循环        │   数据产出循环           │
│                  │                         │
│ 任务池 ──→ Agent │  成功轨迹 ──→ SFT 数据   │
│     ↑     ↓     │  失败轨迹 ──→ DPO 负例   │
│     │  执行结果   │  新任务   ──→ 中训练挑战  │
│     │     ↓     │  能力画像 ──→ 配比指导    │
│  任务进化器       │                         │
│  (生成更难变体)   │                         │
└──────────────────┴─────────────────────────┘

Step 1：任务进化器

TRACE 论文的核心贡献是”Validate-by-Reproduce”——Agent 探索出新的解法轨迹后，验证这条轨迹是否可复现。我们扩展这一机制：

任务变异策略（从简单到复杂）：

1. 参数变异：改变任务中的具体数值/文件名/API 参数
2. 约束添加：在原任务上增加额外约束（“用 Python 做”→“用 Rust 做且内存 <100MB”）
3. 组合升级：把两个独立的简单任务合并为一个多步任务
4. 环境扰动：改变执行环境（不同 OS、不同库版本、有网络限制）
5. 对抗注入：在环境中预埋常见陷阱（过时的 API、误导性的错误信息）

关键设计：每个变异后的新任务，必须有自动验证器。验证器可以从原任务的测试用例通过规则变换生成。没有验证器的任务不进入数据管线。

Step 2：轨迹采集与分类

系统在运行评测时，同时记录完整轨迹。轨迹按结果分为四类：

类别	描述	训练用途
Clean Success	一次通过，无回溯	SFT 正例
Recovery Success	犯错后纠正成功	高价值——错误恢复训练数据
Partial Success	完成部分子目标	拆分后，成功段做 SFT，失败段做分析
Complete Failure	完全失败	DPO 负例 + 能力缺口标记

Recovery Success 是最有价值的数据类别——它同时包含”正确做法”和”典型错误”，是一对天然的 DPO preference pair。

Step 3：数据配比自适应

系统自动维护一张”能力画像”——模型在每个维度上的通过率。数据产出优先聚焦于通过率 30-70% 的维度（太低说明模型完全不具备这个能力，需要先在中训练阶段注入基础知识；太高说明已经学会了，训练价值低）。

Step 4：与站内 Benchmark 体系整合

站内已有 170 个 benchmark 的结构化数据。初始任务池直接从这些 benchmark 导入：

优先级	来源	理由
高	SWE-bench / SWE-Rebench	代码修复轨迹最成熟，验证体系完备
高	GAIA / BrowseComp	Agent 搜索任务，轨迹长且有验证
中	GPQA / AIME	推理任务，可以做参数变异
中	KernelBench	GPU 内核编写，对应代码优化能力
低	MMLU / BBH	已饱和，但变异后可做为中训练基础数据

---

规模估算

初始阶段（基于 SWE-bench + GAIA 两个系统）：

• 原始任务：300 (SWE-bench Verified) + 466 (GAIA) = 766 任务
• 一轮变异后：766 × 5 变异 = 3,830 任务
• Agent 在每个任务上跑 3 次（不同温度）：11,490 条轨迹
• 分类后预估：~2,000 Clean Success + ~1,500 Recovery Success + ~3,000 Partial + ~5,000 Failure
• 训练数据产出：~3,500 条 SFT + ~1,500 条 DPO pair + ~3,830 个新任务加入下一轮

每月持续运转后，数据量滚雪球式增长。

---

与已有方案的关系

方案	关系
EverBench 动态评测体系（站内）	本提案是 EverBench 思路的数据生产侧实现
Harness is the Dataset（站内）	直接实现——Benchmark 系统 = Harness = 数据工厂
TRACE（ICLR 2026）	方法论基础，本提案将其从评测扩展到训练数据
质检轨迹作为训练数据（站内）	理念一致——系统运行的副产品就是训练数据

---

落地路径

1. Week 1-2：在 SWE-bench Verified 上搭建带轨迹采集的评测 harness
2. Week 3：实现参数变异和约束添加两种任务进化策略
3. Week 4：首轮运转——300 原始任务 × 5 变异 × 3 次执行 = 4,500 条轨迹
4. Week 5：轨迹分类 + 质量过滤 + 格式转换为训练数据
5. Week 6：扩展到 GAIA，第二轮运转