Welcome to the Data Alchemy Era / 欢迎来到数据炼金时代

数据是工程化产物，不是开采产物

2024年，大模型训练撞上了一堵墙。

不是参数墙——Llama 3已经把参数推到了405B的天花板附近。 不是算力墙——H100集群已经做到万卡互联，下一代Blackwell架构在路上。

是数据墙。The Data Wall。

Epoch AI在2024年发布的那份报告你应该看过：高质量文本数据（被定义为"经过人类撰写、经过编辑、经过事实核查"的文本）的存量，大约在2026年前后会被现有的大模型训练pipeline消耗殆尽。这不是"未来某天可能"的问题——这是"我们正在按月倒计时"的问题。

而更隐蔽、更难解的问题在于质量塌方。十年前Stack Overflow上挤满了认真思考技术问题的工程师，提问里带着错误日志、带着思考过程、带着挫败感；今天的Stack Overflow，至少有一半是ChatGPT生成的"看起来正确但其实没回答问题"的套话。GitHub上新增的PR里，AI辅助提交的占比已经超过40%。把这些数据喂给下一代模型，等于让学生用自己昨天的作业当教材——他不会变好，他会原地打转，甚至退步。这就是Shumailov等人在Nature 2024那篇著名论文里讲的model collapse（模型坍缩）。

所以"数据"这个词，在2025年发生了一次根本性的语义位移。

过去十年，整个AI行业信奉的是"Data is the new oil"——数据是埋在地下的原油，挖得越多，模型越好。机器学习的教科书开篇第一段，都在教你如何"采集更多数据"、"清洗更多数据"、"标注更多数据"。

2025年之后，这个比喻彻底失效了。

数据不再是被挖出来的原油。它更接近于一种被工程化制造出来的中间品（manufactured intermediate）——和芯片、电池、或者一台汽车类似。你需要设计它、生产它、测试它、迭代它。如果你不做这些事，你造出来的就是一堆工业垃圾。

举三个具体的数字。

第一个数字：40%。Meta在训练Llama 3时，合成数据的占比从Llama 2的不到5%飙升到了超过40%。这些合成数据包括：用上一代Llama生成的对话样本、用代码模型生成的函数-单元测试对、用reward model筛选的高质量数学推理链。

第二个数字：100%。Microsoft的Phi系列模型，从Phi-1.5到Phi-3，训练数据中"textbook quality"的合成内容占比接近100%。他们没有去挖更多网页，他们重新发明了教材。

第三个数字：0%。Anthropic在训练Claude 3时公开承认，他们完全没有使用任何用户提交的对话作为训练数据——所有的训练样本要么来自公开授权的语料，要么来自合成。

三个数字，三种策略，但指向同一个结论：合成数据已经从"补充"变成了"主食"。

我在过去两年和50多家公司（包括至少8家估值超过10亿美元的AI创业公司）的工程师聊过这个话题，几乎所有人都提到了同一件事——他们现在花在"造数据"上的时间，比花在"挖数据"上的时间多得多。

但"造数据"到底包含哪些事情？这就是我接下来要拆解的——

现代数据引擎的四大支柱

如果你以为"合成数据"等于"用GPT生成一批文本，然后拿来训练"，那你把这本书当成了40页的电子手册。三篇博客就够了，不需要一本书。

合成数据不是一个孤立的技术。它是一整个数据引擎（Data Engine）的核心组件。这个引擎还包含数据清洗、数据标注、以及让整个系统自增强的飞轮机制。任何一个齿轮掉了链子，合成数据本身毫无意义。

我把这个引擎拆解成四个相互咬合的齿轮：清洗（Cleaning）、标注（Annotation）、合成（Synthesis）、飞轮（Flywheel）。

```mermaid flowchart LR Raw[Raw Data<br/>原始数据] --> Cleaning[Cleaning<br/>清洗] Cleaning --> Annotation[Annotation<br/>标注] Annotation --> Ready[Training-Ready<br/>可训练数据] Ready --> Training[Model Training<br/>模型训练]

Synthesis[Synthesis<br/>合成] --> Ready Synthesis --> Annotation Synthesis --> Cleaning

Flywheel((Flywheel<br/>飞轮)) -.-> Cleaning Flywheel -.-> Annotation Flywheel -.-> Synthesis Flywheel -.-> Training ```

这张图不是流水线。流水线是单向的，你把数据从左边推进去，从右边拉出来训练好的模型，然后这条产线就完成了它的历史使命。

这张图是一个有反馈的生态系统。飞轮（Flywheel）是那个让整个系统自增强的引擎——它决定了什么数据被保留、什么数据被丢弃、什么数据被生成、什么数据被重写。没有飞轮，合成数据就会退化成"模型自慰"——模型用自己的输出来训练自己，最终坍缩成一堆无意义的重复。

下面我快速过一遍四个齿轮的职责。每一颗齿轮，我都会在后面独立的章节里展开成80到100页的深度内容，这里只给你一个mental model。

Cleaning 清洗

清洗是数据引擎的入口，也是最容易被低估的一环。

绝大多数团队对"清洗"的理解停留在"去重 + 去空值 + 标准化格式"。这种理解在2020年还凑合，在2025年是灾难性的。

2025年的清洗工作需要处理至少六类问题：

1. PII和合规脱敏（GDPR、CCPA、各国数据出境法规） 2. 重复与近似重复检测（MinHash、SimHash、语义embedding去重） 3. 质量过滤（用小模型或规则筛掉低质量样本） 4. 去污染（把评估集从训练集中剔除，这一步做错的团队能排到街尾） 5. 归一化（统一编码、长度截断、字段对齐） 6. 来源溯源（每一个样本的出处、版本、license，这一步是合规审计的命根子）

举个具体的例子。假设你在做法律领域的RAG系统，你的原始语料是10万份判决书。清洗pipeline需要做哪些事？

```python

清洗pipeline的核心步骤（伪代码）

def clean_legal_documents(raw_docs):

Step 1: 去重 - 同一份判决书可能有多个来源

docs = deduplicate(raw_docs, threshold=0.85)

Step 2: 个人信息脱敏

docs = [redact_pii(doc, patterns=[ r'\d{17}[\dXx]', # 身份证号 r'1[3-9]\d{9}', # 手机号 r'[\u4e00-\u9fa5]{2,}(?:律师|法官|代理人)', # 人名+称谓 ]) for doc in docs]

Step 3: 质量过滤 - 用小模型打分

quality_scores = quality_model.batch_score(docs) docs = [d for d, s in zip(docs, quality_scores) if s > 0.6]

Step 4: 去污染 - 剔除与评估集重合的样本

docs = remove_eval_contamination(docs, eval_set)

Step 5: 来源标注

docs = [add_provenance(d, source="court.gov.cn", license="public", fetched_at=now()) for d in docs] return docs ```

但真正的难点从来不是"如何写这段代码"。真正的难点是"如何在清洗的破坏性和数据量之间取得平衡"。清洗得太狠，数据量从10万掉到1万，模型学不到东西；清洗得太松，模型把脏东西学进去，评估时一脸困惑。这是一种工程权衡，不是技术问题。

第4章到第5章会专门讲这个权衡。

Annotation 标注

标注是把"原始数据"变成"训练数据"的关键步骤。

传统意义上的标注 = 人力标注 = 找一个众包平台，雇一堆临时工，手动给文本打标签。2020年的ImageNet就是这么干的，代价是2500万美元和数百万小时的人力。

2025年的标注已经进化成了一个三件套：

1. Human-in-the-Loop (HITL)：人类标注员，但只标注最难的、最有争议的样本 2. LLM-as-Judge：用大模型给数据打分，再人工抽样验证 3. Constitutional / Rubric-based：用一套规则或价值观体系来自动评估

一个典型的2025年标注pipeline长这样：

``` 原始数据 ↓ [简单规则层] → 自动拒掉/接收 80% 的样本 ↓ [LLM初筛] → 用GPT-4o给剩下 18% 的样本打初始标签 ↓ [人类专家] → 处理剩下 2% 的高难度/争议样本 ↓ [质量审计] → 随机抽样 5% 做一致性检查 ↓ 已标注数据 ```

但标注最容易踩的坑不是"怎么标"，是"你的标签体系真的能区分你关心的差异吗"。

举一个让我印象深刻的真实案例。某金融科技公司做贷款违约预测，他们最初定义了三个标签：`will_pay` / `will_default` / `uncertain`。模型训练出来，AUC 0.92，看起来不错。上线之后跑偏了——后来发现，标注员对`uncertain`的判断标准完全不一致，有人把"客户还在犹豫"标为uncertain，有人把"客户明确说不还"也标为uncertain。

修正方案：把`uncertain`拆成六个细分子类（`pending_documents` / `active_negotiation` / `hard_decline` / `soft_decline` / `defer_request` / `no_response`），重新标注，AUC掉到0.89，但业务效果提升40%。

AUC更高不代表业务更好。这是一个反直觉的、但2025年每一个ML工程师都会反复撞上的事实。

第6章到第7章会拆解这个案例，并给出可复用的标注体系设计框架。

Synthesis 合成

合成是这个引擎的心脏。

但"合成"这个词被滥用了。在2025年的语境下，至少有七种完全不同的合成技术，它们的目标、原理、风险各不相同：

1. Self-Instruct（Wang et al., 2022）：用种子指令让LLM自己生成新指令 2. Evol-Instruct（WizardLM）：在已有指令基础上做难度进化 3. Magpie（Xu et al., 2024）：直接用LLM的query log作为合成数据 4. Backtranslation：用模型把无标签数据翻译成有标签 5. Distillation：用大模型的输出来训练小模型 6. Persona-driven generation：用人物角色驱动多样化生成 7. World-model simulation：用agent在模拟环境中产生轨迹数据

每一种技术都有自己的失败模式。比如Self-Instruct的失败模式是"指令多样性塌缩"——生成到第5000条的时候，所有指令都开始长得像，模型学到的就是"如何用一种方式回答所有问题"。Magpie的失败模式是"分布偏移"——它生成的数据是LLM偏好的分布，不是真实用户的分布。

没有银弹。这本书的合成部分（第8章到第11章）会逐个拆解这七种技术，给出每一种的代码实现、评估方法、失败模式诊断清单。

合成数据最容易犯的错误，我提前剧透一个：

> 把合成数据当成"无限便宜的免费午餐"，结果训练出来的模型在评估集上漂亮，在生产环境里胡说八道。

怎么避免？靠评估。靠严格的、与生产分布对齐的评估。这又回到飞轮。

Flywheel 飞轮

飞轮是让整个引擎自增强的机制。

一个最简单的飞轮长这样：

``` 模型A生成数据 → 清洗标注 → 训练模型B ↓ 模型B在生产中产生反馈 ↓ 反馈回流到训练数据 ↓ 训练模型C（更好） ↓ 模型C生成更好的合成数据 ↓ 回到第一步 ```

飞轮不是一项技术。飞轮是一种系统设计。它需要解决至少五个工程问题：

1. 数据选择：模型B产生的100万条反馈，哪些值得回流？ 2. 数据加权：新数据和旧数据怎么混合，比例怎么定？ 3. 评估闭环：怎么知道模型C真的比模型B好，而不是在评估集上过拟合？ 4. 负反馈处理：用户投诉、bad case、safety violation——这些怎么进飞轮？ 5. 衰减控制：飞轮跑久了，分布偏移累积怎么办？

最后一个问题是最致命的。Notion AI的工程团队在2024年的一篇技术博客里提到，他们曾经跑过一条飞轮，跑了6个月，模型在内部评估集上的分数从0.78涨到0.91，但用户投诉率反而上升了15%。根因分析发现：飞轮选择的"高质量样本"实际上是模型自己偏好的样本，不是用户偏好的样本。模型越来越擅长生成"它自己喜欢"的内容，但和用户想要的东西渐行渐远。

这就是为什么飞轮必须有外生信号（exogenous signal）来纠偏——用户反馈、专家评审、在线A/B测试。任何纯内生的飞轮，最终都会坍缩。

第12章到第15章会用一个完整的工业级案例，把飞轮的五个工程问题逐一拆解。

---

高级读者需要的是实践手册，不是综述

如果你已经读过了Synthetic Data for ML、Generative AI with Synthetic Data这类survey性质的书，你大概率已经知道合成数据的定义、分类、评估指标这些基础知识。

这本书不做survey。

市场上有足够多的survey了。Arxiv上每个月新增200多篇关于synthetic data的论文。Google Scholar上"synthetic data"的相关文献在2024年突破了2万篇。如果你想要一个学术全景图，去读survey papers。

但你翻开这本书，说明你不是来读survey的。

你是工程师。你是技术lead。你是某个AI产品的负责人。你想造一个能上线、能跑数据、能迭代的系统。你想知道：

• 清洗pipeline的具体配置参数应该怎么设
• 标注体系应该怎么和业务目标对齐
• 合成数据生成时temperature设成0.7还是0.9
• 飞轮跑偏了怎么诊断、怎么修
• 哪些坑是survey里不会写、只有踩过才知道的

这本书的目标读者是"已经会做但想做得更好的工程师"，不是"还没开始做但想了解的人"。

我假设你已经：

• 训练过至少一个深度学习模型
• 用过PyTorch或JAX
• 读过attention is all you need
• 知道RLHF、PEFT、quantization这些词是什么意思
• 写过一个能跑通的end-to-end pipeline

我不假设你已经知道：

• 合成数据的失败模式诊断
• 飞轮工程的具体实施细节
• 工业级数据引擎的架构选择
• 在多团队协作时数据治理的最佳实践

这就是实践手册和综述的本质区别：它假设你有基础，它给你的是"如何把这事做对"。

另一个区别是观点性（opinionated）。

Survey会告诉你"有方法A、方法B、方法C，各有优劣"。这本书会告诉你"在2025年的生产环境里，我推荐方法B，理由是X、Y、Z"。我不写"看起来都对"的章节——那种章节对决策毫无帮助。

如果你不同意我的观点，那很好。邮件告诉我，我们可以吵一架。 比起正确但模糊的建议，一个错的但具体的建议更有价值。

这本书的第三个特征是：它是双语 + 轻松 + 代码密集型。

"双语"意味着中英文术语混用。LLM、fine-tuning、reward model这些词不会硬翻译成中文，因为这些就是行业里的工作语言。用语言习惯去迁就术语是本末倒置。

"轻松"意味着我会讲段子、举反例、说脏话（偶尔）。技术书不一定要板着脸写。一本让你读起来想打瞌睡的书是一本失败的书。

"代码密集"意味着每一章都有至少一段可以复制粘贴运行的代码，而不是伪代码。代码是工程实践的载体。一本没有代码的工程实践书是一本失败的书。

---

这本书怎么读

这本书一共有15章，分成四个部分。我把书做成四个部分不是因为结构美观，是因为学习曲线需要这个分层。

第一部分：危机与基础（第1章到第3章）

• 第1章（你现在读的）：建立数据引擎的mental model
• 第2章：The Data Wall——为什么我们被迫转向合成数据
• 第3章：评估的黑暗森林——怎么知道你的合成数据真的有用

这一部分的目标是校准你的认知。很多人对合成数据的态度要么是"万能解药"要么是"自欺欺人"，这两种态度都是错的。第2章和第3章会给你一个更精确的判断框架。

第二部分：清洗与标注（第4章到第7章）

• 第4章：清洗pipeline的架构选择
• 第5章：去污染——评估集泄漏是工业级事故的最大单一来源
• 第6章：标注体系设计——标签不是越多越好
• 第7章：HITL +