Adaptive 数据配比：让训练过程本身告诉你数据该怎么混

触发动机

Emergent Mind 上追踪到一个 2026 年 4 月的新 topic：Adaptive Training Data Synthesis。它聚合了一批最新工作的共同思路——不再静态地准备数据集然后训练，而是在训练过程中根据模型的实时表现动态调整数据配比和合成策略。

这个思路其实不新（curriculum learning 已经存在多年），但 2026 年有两个变化让它变得真正可操作：

1. 合成数据技术成熟了：不再受限于”有什么数据用什么”，可以按需生成任意类型和难度的数据
2. 实时评估能力增强了：ADAPT（ICLR 2026）、Dynamic Loss Reweighting（ICLR 2025）等工作证明可以低成本地在训练中评估模型弱点

两者结合意味着：训练不再是”准备数据 → 喂进去 → 评估 → 下次再调”的串行过程，而是”边训边评边造数据”的闭环过程。

这与站内的”数据工程观察”专栏中反复出现的一个主题一致——数据评估从离线走向在线（ADAPT、Dynamic Loss Reweighting、JQL）。但现有 proposal 都是关于”造什么数据”，没有一篇关于”什么时候造、造多少、怎么动态调整”。本方案填补这个空白。

战略判断：为什么静态数据配比是一个正在被淘汰的范式

行业信号

1. Demystifying Synthetic Data in LLM Pre-training（arXiv:2510.01631）系统研究了合成数据在预训练中的效果，核心发现：相同的合成数据在不同训练阶段的边际收益差异巨大——早期阶段多领域混合最有效，后期阶段针对弱点的定向数据更有效。
2. MIT 的训练效率新方法（2026 年 2 月）利用空闲算力动态调整数据加载策略，将训练速度提升了一倍。
3. ACL 2025 数据高效后训练 survey：数据选择（selection）和数据质量提升（enhancement）是后训练效率的两大杠杆，但大多数工作是静态选择，缺少在线动态选择。

核心问题

当前数据配比的做法是：领域专家凭经验设定”数学 20%、代码 30%、通用 50%“，然后训练完了评估。如果数学差了就下一轮多加数学。这有三个问题：

1. 粒度太粗：不是”数学”差，可能是”几何证明”差但”代数计算”已经很好了
2. 反馈太慢：训了几天才发现配比不对，已经浪费了算力
3. 没有考虑交互效应：多加数学可能损害代码能力（零和博弈），静态配比无法处理这种动态平衡

方法论

核心思路：构建”能力评估 → 数据合成 → 混合注入”的闭环

┌──────────────────────────────────────┐
│           训练循环（主循环）              │
│                                      │
│  训练 N 步                            │
│     │                                │
│     ▼                                │
│  能力快照（每 500 步）                   │
│     │                                │
│     ▼                                │
│  弱点诊断（30 个细粒度能力维度）          │
│     │                                │
│     ▼                                │
│  数据合成决策（哪些维度需要加强？）        │
│     │                                │
│     ▼                                │
│  动态混合下一个 N 步的数据               │
│     │                                │
│     └──────→ 回到训练循环               │
└──────────────────────────────────────┘

组件 1：细粒度能力维度定义

不是”数学好不好”，而是 30 个精确维度：

大类	细分维度	快速评估方法
推理	算术计算、代数推理、几何证明、概率统计、逻辑推理、因果推理	各 50 题，accuracy
代码	语法生成、单函数实现、多文件编排、调试定位、测试生成、代码审查	HumanEval 变体 + 自定义
语言	长文生成、摘要提炼、翻译、对话连贯性、指令遵循、格式控制	各 30 题
知识	STEM 知识、人文社科、时事常识、领域专业（法律/医学/金融）	MMLU 子集
Agent	工具选择、多步规划、失败恢复、状态追踪、元认知	简化版 Agent bench

组件 2：弱点诊断算法

每 500 步训练后：

1. 在 30 个维度上各跑评估题（总计 ~1,000 题，耗时 ~10 分钟）
2. 计算每个维度的”进步速率”和”绝对水平”
3. 识别三类需要干预的维度：
   • 停滞维度：连续 3 个检查点没有进步
   • 退化维度：最近检查点比上一个差
   • 瓶颈维度：绝对水平远低于其他维度（木桶最短板）

组件 3：数据合成决策引擎

def synthesize_next_batch(diagnostics, budget_tokens):
    """根据弱点诊断结果，决定下一批数据的组成"""
    
    # 1. 为每个维度计算"紧迫度"
    urgency = {}
    for dim in diagnostics:
        if dim.is_regressing:
            urgency[dim] = 3.0  # 退化 = 最紧迫
        elif dim.is_stagnant:
            urgency[dim] = 2.0  # 停滞
        elif dim.is_bottleneck:
            urgency[dim] = 1.5  # 瓶颈
        else:
            urgency[dim] = 0.5  # 正常进步
    
    # 2. 按紧迫度分配 token 预算
    total_urgency = sum(urgency.values())
    allocation = {
        dim: int(budget_tokens * u / total_urgency) 
        for dim, u in urgency.items()
    }
    
    # 3. 为每个维度合成对应难度的数据
    data = []
    for dim, tokens in allocation.items():
        difficulty = dim.current_level + 0.5  # 略高于当前能力
        data += synthesize(dim, tokens, difficulty)
    
    return data

组件 4：合成器库

每个能力维度对应一个数据合成器：

维度	合成方法	难度控制
算术	模板生成，控制数位和运算步骤	步骤数 2-10
几何证明	从定理库选取，控制推理深度	推理步数 3-15
代码-多文件	从 GitHub 提取并简化	文件数 2-10
工具选择	从 MCP Server 组合生成	工具数 3-15
因果推理	从知识图谱路径生成	路径长度 2-8

中训练语料格式

这个方案的产出不是一个静态数据集，而是一个数据生产系统的设计。但系统运行过程中产出的数据本身可以作为中训练语料：

## 自适应训练日志：第 15,000-15,500 步

### 能力快照
| 维度 | 得分 | 趋势 | 紧迫度 |
|------|------|------|--------|
| 几何证明 | 0.42 | ↓ 退化 | 🔴 高 |
| 多文件编排 | 0.38 | → 停滞 | 🟡 中 |
| 因果推理 | 0.65 | ↑ 进步 | 🟢 低 |

### 数据配比调整
- 几何证明：20% → 35%（退化，需要紧急补充）
- 多文件编排：15% → 25%（停滞，增加难度更高的样本）
- 因果推理：15% → 8%（进步正常，减少以腾出预算）
- 其他维度：保持不变

### 本轮合成数据示例
[几何证明，难度 7/10]
已知三角形 ABC 中...

规模估算

这不是一个”产出 N 亿 token”的方案，而是一个框架。框架本身需要的开发工作：

组件	工作量
30 维快速评估题库	~1,500 题（含自动评分）
弱点诊断算法	~500 行 Python
决策引擎	~300 行 Python
30 个合成器	每个 ~200 行，共 ~6,000 行
总开发量	~2 周

框架运行后，按中训练规模（假设 500B token），预计 20-30% 的数据由自适应合成器动态生成 = 1000-1500 亿 token 的动态合成数据。

落地路径

1. Week 1：定义 30 维能力框架 + 评估题库（可复用已有 benchmark 子集）
2. Week 2：实现弱点诊断算法 + 决策引擎
3. Week 3-4：实现 6 个核心维度的合成器（数学×3 + 代码×2 + 推理×1）
4. Week 5-6：在小模型（7B）上做端到端验证：自适应 vs. 静态配比
5. Week 7-10：扩展到全部 30 个维度 + 在大模型上验证

与已有方案的关系

这个方案是”元方案”——它不产出特定类型的数据，而是决定什么时候产出什么数据。站内所有其他 proposal（形式化验证 CoT、科研工作流、CI/CD 诊断等）都可以作为这个框架的”合成器”接入。框架负责调度，合成器负责生产。