Synthetic Data & Augmentation
Synthetic Data Augmentation
Synthetic data 最容易被误解成“数据不够就让模型多编一点”。这很危险。真正有效的 synthetic data，不是为了把 dataset 变大，而是为了把 coverage 变合理、把 eval 变更有杀伤力、把模型盲区更早暴露出来。
所以这页的重点不是教你批量生成文本，而是 AI engineer 怎么把 synthetic data 用在更靠谱的 augmentation workflow 里。
先说结论：先补 coverage，不要先追规模
很多 team 一缺数据，就先追 10 倍、100 倍扩充。
更稳的顺序应该是：
- 找出真实数据缺口
- 明确要补哪类 case
- 生成后做 verification 和 dedup
- 最后才考虑规模化生产
如果 coverage 没想清楚，synthetic data 只会把偏差放大。
Synthetic Data 最适合用在哪
| 场景 | 为什么适合 |
|---|---|
| eval set 扩充 | 补 edge case 和 rare case |
| safety / refusal 测试 | 生成 jailbreak、policy 边缘样本 |
| 格式化 extraction | 批量生成结构相近但内容多样的输入 |
| locale / style variation | 补不同语言和表达方式 |
| low-resource task bootstrap | 先快速搭一个可训练/可评估起点 |
它最值钱的地方，通常不是训练主数据，而是评估和覆盖补洞。
最常见的错误用法
| 错法 | 后果 |
|---|---|
| 让同一个模型生成再评估 | 很容易自嗨，误判质量 |
| 只做 paraphrase | 看起来很多样，实际信息量很低 |
| 不做 provenance | 后面不知道哪批数据污染了结果 |
| train / test 混源 | leakage 后评估会失真 |
Synthetic data 不是越多越强，失控后反而会让你更难判断真实能力。
一个更稳的 Generation Pipeline
gap analysis
-> generation prompt
-> judge / filter
-> dedup
-> difficulty tagging
-> split and version
这个 pipeline 里最容易被跳过的是 middle steps。
但恰恰是 judge、dedup 和 tagging，决定了这批数据能不能用。
常见的生成方式
| 方法 | 适合做什么 |
|---|---|
| paraphrase | 补表达多样性 |
| template expansion | 补实体、行业、locale 变量 |
| adversarial generation | 补攻击样本、边界样本 |
| source-grounded generation | 基于真实文档生成 Q&A / citation case |
其中最靠谱的往往是最后一种。
因为它最接近真实任务，也更容易做 correctness check。
Verification，不能靠“看起来没问题”
Synthetic item 至少应该经过：
| 检查项 | 为什么要做 |
|---|---|
| format validation | 保证结构能进 pipeline |
| faithfulness check | 确保没有偏离 source |
| safety filter | 避免带入不该有的内容 |
| manual spot check | 自动 judge 也会漏 |
| duplicate control | 避免虚假多样性 |
如果没有这些，后面你看到的提升可能只是 dataset contamination。
Provenance 和 Versioning 很关键
每条 synthetic sample 最少记录这些字段：
- source
- generation model
- generation prompt version
- judge result
- tags
- difficulty
- split
没有 provenance，后面一旦出现坏样本、奇怪提升或 regression，你几乎没法追。
难度分层比平均分更重要
AI engineer 用 synthetic data 时，最值得做的是 difficulty tagging。
| 难度层 | 例子 |
|---|---|
| easy | 常规格式、常规表达 |
| medium | paraphrase、轻度歧义 |
| hard | 多约束、长上下文、边界 case |
| adversarial | injection、诱导、格式破坏 |
这样你才能知道模型到底是普遍提升了，还是只在 easy case 看起来变好了。
什么时候别急着继续扩 synthetic data
| 情况 | 为什么 |
|---|---|
| 真实数据 pipeline 还没整理好 | 你会一直在 synthetic 上兜圈 |
| judge 机制不稳 | 扩得越多，噪声越大 |
| bad case 都没复盘 | 生成再多也补不到点上 |
| 团队没有版本治理 | 数据越来越难维护 |
Synthetic data 是放大器，不是替代真实数据治理的捷径。
Practice
拿你现在一份 eval set，先不要扩 10 倍。
先回答这 4 个问题：
- 缺的是哪类 case
- 哪些 case 值得用 synthetic 补
- 生成后怎么 judge
- 如何记录 provenance
这 4 个问题想清楚后，再开始批量生成。