第十九课：大模型数据集、清洗、标注、切分、版本管理与质量治理原理

为什么先讲数据，而不是先讲训练参数

很多初学者一进入大模型领域，就会先被这些词吸引：

• 7B
• 14B
• LoRA
• QLoRA
• Flash Attention
• Tensor Parallel
• vLLM

这些当然都重要。

但如果你的目标不是“跟着别人把命令敲通一次”，而是要真正具备：

• 搭平台
• 带项目
• 做架构
• 查问题

的能力，那你必须尽早接受一个现实：

大模型项目的上限，往往先由数据决定，然后才由模型和训练技巧决定。

为什么？

因为模型再强，如果吃进去的是：

• 脏数据
• 低质量数据
• 错误标注数据
• 泄漏数据
• 侵犯隐私的数据
• 和任务无关的数据

那结果通常就是：

• 训练白费
• 指标虚高
• 线上表现差
• 合规风险大

所以这一课要解决的不是“会不会下载数据集”，而是把数据这条线真正讲透。

你学完之后，至少应该能回答：

1. 大模型数据集到底有哪些类型？
2. 一条训练样本到底长什么样？
3. 原始数据和训练数据有什么区别？
4. 为什么要清洗、切分、标注和去重？
5. 为什么要有 train / val / test？
6. 数据版本、数据卡、数据血缘分别是什么？
7. 企业里为什么数据治理往往比训练本身还难？

---

先给你一张数据全景图

你先记住，大模型系统里并不是只有一种“数据集”。

至少可以分成下面几类：

原始数据
  -> 清洗后语料
  -> 预训练数据
  -> 继续预训练数据
  -> SFT 指令数据
  -> 偏好数据
  -> 评测集
  -> RAG 文档库
  -> 线上反馈数据

很多初学者一说“数据集”，脑子里只出现一种模糊印象：

• 一堆文本

这不够。

你必须分清：

• 哪些数据是拿来学语言分布的
• 哪些数据是拿来学指令行为的
• 哪些数据是拿来学偏好的
• 哪些数据不是训练用，而是评估用
• 哪些数据不是训练用，而是检索用

如果你不分清这些类别，后面几乎一定会把：

• 训练
• 微调
• RAG
• 评测

混成一锅粥。

---

第一章：什么叫“一条数据样本”

这一点看似简单，实际上是所有数据工程的起点。

样本不是“一个文件”

很多人第一次接触数据，会以为：

• 一个文件就是一个样本

这不准确。

文件只是存储容器。

真正的样本，是：

被拿去参与某个训练、微调、评估或检索过程的最小记录单元。

例如：

• 一篇清洗后的文档，可以是一个样本
• 一轮对话，可以是一个样本
• 一个 prompt + chosen + rejected，也可以是一个样本
• 一个问答题，也可以是一个评测样本

所以以后你要问的不是：

• 数据文件有几个

而是：

• 一共有多少有效样本
• 每个样本的 schema 是什么

样本最关键的是 schema

schema 可以先简单理解成：

• 这一条数据有哪些字段
• 每个字段是什么含义

比如一条最简单的预训练样本：

{"text": "Kubernetes 是一个用于自动部署、扩缩容和管理容器化应用的平台。"}

这里 schema 就是：

• text

而一条 SFT 样本 schema 可能是：

{
  "messages": [
    {"role": "user", "content": "什么是 Pod？"},
    {"role": "assistant", "content": "Pod 是 Kubernetes 中最小的可部署单元。"}
  ]
}

这里 schema 就复杂多了：

• messages
• 每个 message 又包含 role
• 和 content

这就是为什么数据工程不是“把东西存下来”这么简单，而是：

先定义清楚，每一类数据的最小记录长什么样。

---

第二章：原始数据和训练数据不是一回事

这是非常重要的一层边界感。

原始数据是什么

原始数据是你刚收集回来、还没治理过的数据。

它常常包含：

• HTML 标签
• 广告
• 重复内容
• 敏感信息
• 低质量文本
• 编码问题
• 无关噪声

比如我们这次示例里的原始数据：

• 00-raw-corpus.jsonl

里面故意包含了：

• HTML
• 电话号码
• 营销噪声
• 代码文本

这非常接近真实世界。

因为真实原始数据通常都不是干净的。

训练数据是什么

训练数据是经过治理后，真正允许进入训练或微调流程的数据。

例如：

• 去掉 HTML 垃圾
• 脱敏
• 去重
• 标准化格式
• 加上质量分

我们对应的示例是：

• 01-cleaned-corpus.jsonl

你会看到它已经有这些字段：

• sample_id
• source_doc_id
• text
• quality_score
• pii_removed
• dedup_group

这说明它不再只是文本，而是：

被治理过、可追踪、可进入后续流程的数据资产。

为什么一定要强行分这两层

因为如果你把原始数据直接送进训练：

• 敏感信息可能被模型记住
• 重复样本会污染分布
• 脏格式会浪费 token
• 低质量文本会拉低模型学习效果

所以专家的默认思维一定是：

raw data
!=
training-ready data

---

第三章：大模型里最常见的 6 类数据集

这一章你必须吃透，因为后面平台设计、训练任务、评估体系都围绕这些类型展开。

第一类：预训练语料

预训练语料的目标是：

让模型学会语言分布、世界知识、代码模式和通用表达。

它最常见的 schema 非常简单：

{"text": "..."}

也可能包含一些元数据：

{"text": "...", "lang": "zh", "source": "public-web"}

重点不是“答案对不对”，而是：

• 文本本身是否有价值
• 语言分布是否合理
• 覆盖面是否广

第二类：继续预训练语料

它和预训练语料很像，但目标不同。

它不是为了让模型从零学语言，而是：

在已有基础模型上，继续喂某个领域的大规模原始文本，让模型更懂这个领域。

例如：

• 医疗
• 法律
• 金融
• 公司内部技术资料

第三类：SFT 指令数据

SFT = Supervised Fine-Tuning

目标是：

• 教模型按要求回答
• 教模型遵循聊天格式
• 教模型做任务

我们的示例文件是：

• 02-sft-messages.jsonl

这里你能看到 3 类非常典型的 SFT 样本：

1. 基础知识问答
2. 技术概念重写
3. 安全拒答

这说明 SFT 不只是教“会答题”，也在教：

• 风格
• 格式
• 边界
• 安全策略

第四类：偏好数据

偏好数据的核心不是一个标准答案，而是：

• 哪个回答更好
• 哪个回答更差

我们的示例文件是：

• 03-preference-dpo.jsonl

它适合用于：

• DPO
• RLHF 相关流程
• 对齐训练

第五类：评测集

评测集不是拿来训练的。

它是用来问：

• 模型真的变好了吗？
• 新版有没有退化？
• 安全和事实性是否过关？

我们的示例文件是：

• 04-eval-set.jsonl

第六类：RAG 文档库

这类数据也非常重要，但它不是“训练数据”。

它是：

• 检索增强生成的知识源

我们的示例文件是：

• 05-rag-documents.jsonl

这类数据更关心的是：

• 文档质量
• 更新时间
• 来源可信度
• 切分质量

而不是是否适合梯度训练。

一句话总结这 6 类

预训练/继续预训练：教模型“懂语言和领域”
SFT：教模型“按要求输出”
偏好数据：教模型“更符合人类偏好”
评测集：测模型“到底有没有变好”
RAG 文档：给模型“回答时临时查资料”

---

第四章：数据到底从哪里来

真实项目里，数据来源通常比模型结构更早决定项目成败。

常见来源有：

1. 公共开放语料

例如：

• 公共网页
• 开源代码
• 开放论文
• 公共问答数据

优点：

• 起步快
• 成本低

风险：

• 版权
• 重复
• 质量参差
• 噪声多

2. 企业内部数据

例如：

• 客服对话
• 工单
• wiki
• 产品文档
• 研发知识库

优点：

• 对业务帮助最大

风险：

• 隐私
• 商业机密
• 合规

3. 人工标注数据

例如：

• 专家手写问答
• 标注员做任务样本
• 安全团队做拒答样本

优点：

• 质量高
• 目标明确

缺点：

• 成本高

4. 合成数据

也就是：

• 让已有模型生成更多训练样本

优点：

• 扩量快

风险：

• 错误被放大
• 风格被模型自己污染

所以以后你要形成一个非常重要的习惯：

不只问数据量，还要问数据来源和法律边界。

---

第五章：数据为什么不能直接拿来训练

因为原始数据天然会有 7 类常见问题：

1. 格式脏

例如：

• HTML
• 脚本
• 错乱换行

2. 内容重复

同一篇文章可能来自：

• 原站
• 镜像站
• 抓取副本

重复会导致模型对某些模式过度强化。

3. 含敏感信息

例如：

• 手机号
• 身份证
• 邮箱
• 住址

如果不处理，模型可能把敏感信息“学进去”。

4. 低质量噪声

例如：

• 灌水帖
• 广告
• 机器生成垃圾文本

5. 任务不匹配

比如你要做技术问答，却喂了大量娱乐八卦文本。

6. 标签错误

在 SFT 或偏好数据中，错误标注会直接把模型往错误方向教。

7. 数据泄漏

最典型的是：

• 评测题其实已经混进训练数据

这样你会误以为模型很强，但其实只是“见过答案”。

所以数据工程的第一原则不是：

• 先训练

而是：

• 先把数据变得可信

---

第六章：清洗到底在洗什么

“清洗”这个词经常被说得很轻，但它其实包含很多具体动作。

1. 格式清洗

例如：

• 去 HTML 标签
• 去脚本
• 去控制字符
• 统一 UTF-8

2. 文本规范化

例如：

• 统一空格
• 统一换行
• 中英文标点规范化

3. 脱敏

例如：

• 手机号替换为 [PHONE]
• 邮箱替换为 [EMAIL]

4. 去重

例如：

• 完全相同文本去重
• 近似重复去重

5. 质量过滤

例如：

• 过短样本丢弃
• 太多乱码丢弃
• 广告内容丢弃
• 语言不匹配丢弃

6. 安全过滤

例如：

• 高风险违法内容
• 极端仇恨内容
• 明显恶意样本

7. 任务格式转换

例如：

• 把原始 FAQ 转成 messages
• 把工单对话转成问答对
• 把多轮会话裁成固定窗口

所以“清洗”不是一个脚本，而是一条流水线。

---

第七章：去重为什么特别重要

很多人低估去重的重要性。

实际上它至少影响 4 件事：

1. 训练效率

重复文本太多，会浪费大量 token 和训练算力。

2. 分布质量

重复文本会让模型过度偏向某些语料。

3. 指标真实性

如果评测集和训练集内容重复，评测就失真。

4. 成本

你喂进去的 token 越多，训练成本越高。

所以在我们示例的清洗文件里，我专门保留了：

• dedup_group

这就是在提醒你：

数据去重不只是“删行”，而是要记录重复关系，方便追溯和分析。

---

第八章：切分到底在切什么

切分这个词也很容易被说得太笼统。

真实工程里至少有三种切分：

1. 文档切分

把长文档切成较短片段，便于：

• 进入训练上下文
• 进入 RAG chunk

2. 对话切分

把超长聊天记录切成可训练样本。

例如：

• 只取最近几轮
• 或按任务边界切开

3. 数据集切分

也就是：

• train
• validation
• test

这三个“切分”不是一个概念，但很多人会混用。

---

第九章：为什么一定要有 train / validation / test

这部分很基础，但很多团队其实没真正做好。

Train

用来训练参数。

Validation

用来：

• 选模型
• 调超参数
• 观察是否过拟合

Test

用来：

• 最终验收
• 尽量模拟“从未见过的新样本”

为什么不能只要 train 和 test

因为如果你反复根据 test 调整策略，那 test 就不再“纯净”了。

最大的坑：数据泄漏

最危险的情况是：

• test 数据在训练里出现过
• 或 train / test 是近似重复

这样你会得到虚假的高分。

所以专家在做数据切分时，不只会随机分，还会看：

• 时间切分
• 主题切分
• 用户切分
• 文档来源切分
• 近重复隔离

---

第十章：标注到底在标什么

很多人听到“标注”，以为就是给图片画框。

在大模型场景里，标注更广泛。

1. 问答标注

给问题写标准答案。

2. 对话标注

把真实业务对话整理成：

• system
• user
• assistant

3. 安全标注

明确哪些请求应该：

• 拒答
• 转向安全替代方案

4. 偏好标注

对多个回答排序，标出：

• 哪个更好
• 哪个更差

5. 分类标注

例如给样本打：

• 领域标签
• 难度标签
• 风险标签

所以标注不是“多一个人工步骤”而已，它本质上是在定义：

你希望模型学会什么行为。

---

第十一章：SFT 数据和偏好数据的核心区别

这是一个必须明确区分的点。

SFT 数据

它在告诉模型：

• 面对这个输入，理想输出长什么样

本质是监督学习。

偏好数据

它在告诉模型：

• 面对这个输入，A 比 B 好

本质不是给单一标准答案，而是给相对偏好。

这两者分别适合解决什么问题

SFT 更适合：

• 让模型学会任务格式
• 学会基本回答习惯

偏好数据更适合：

• 提升回答风格
• 降低不安全输出
• 强化人类更偏好的响应方式

所以实际工程中常见顺序是：

先 SFT
再偏好优化

---

第十二章：评测集为什么不能被“顺手拿来训练”

因为评测集的使命不是提升模型，而是验证模型。

如果你把评测集混入训练，会出现两个严重问题：

1. 指标虚高

模型只是记住了题，不是真会了。

2. 决策失真

你可能会错误判断：

• 这个版本可以上线

这会在生产中带来非常大的风险。

所以评测集通常需要：

• 单独权限
• 单独存放
• 尽量减少暴露

这就是为什么我们给评测集单独放了：

• 04-eval-set.jsonl

它在生态中的地位和训练集完全不同。

---

第十三章：RAG 文档为什么不能和训练集混着管理

这是企业里非常常见的混淆点。

很多团队会说：

• “这些知识库文档就是训练数据”

这不一定对。

如果它们是拿来：

• 做 embedding
• 进向量库
• 在回答时被检索

那它们属于：

• 检索知识库数据

而不是：

• 参数训练数据

这两类数据的治理重点不同。

训练数据更关注

• 分布
• 标注
• 学习目标
• token 成本

RAG 文档更关注

• 来源可信度
• 更新时间
• chunk 质量
• 可引用性
• 删除与更新及时性

所以在平台里，这两类数据最好从一开始就分开管理。

---

第十四章：为什么数据版本管理是硬需求

很多团队刚开始做项目时，会把数据放在一个目录里，文件名类似：

• final.jsonl
• final_v2.jsonl
• final_v2_new.jsonl

这是非常危险的。

因为一旦模型效果变了，你将很难回答：

• 到底是哪份数据导致的

数据版本管理至少要回答 6 个问题

1. 这份数据叫什么？
2. 它是什么日期生成的？
3. 从哪些原始来源加工来的？
4. 用了哪个清洗脚本？
5. 包含哪些 split？
6. 它被哪次训练任务使用过？

这就是为什么真实数据平台通常需要：

• 数据版本号
• 元数据
• lineage
• dataset card

我们这次示例里放了一个：

• 06-dataset-card.yaml

它展示的就是最小版数据卡思路。

---

第十五章：数据卡 Dataset Card 到底是什么

你可以把数据卡理解成：

给数据集写的身份证和说明书。

它至少应该包括：

1. 基本信息

例如：

• 名称
• 版本
• owner

2. 用途

例如：

• 适合做什么
• 不适合做什么

3. 来源

例如：

• public-web
• internal-wiki
• manual-labeling

4. 规模

例如：

• raw 有多少条
• cleaned 有多少条
• sft 有多少条

5. 风险说明

例如：

• 是否含敏感信息
• 是否仅教学用途
• 是否禁止生产训练

6. 质量检查

例如：

• dedup
• pii_masking
• schema_validation

数据卡的价值不是形式主义，而是让你以后能回答：

• 这份数据到底是什么
• 能不能安全使用
• 出问题时该追到哪

---

第十六章：数据血缘 Lineage 是什么

血缘的核心问题只有一句话：

这份数据是从哪来的，又经过了哪些变换，最终变成了现在这样？

例如：

raw-002
  -> 脱敏
  -> 去 HTML
  -> 格式标准化
  -> cleaned-002
  -> 被抽取进 SFT 样本

为什么血缘重要？

因为没有血缘，你无法可靠地做：

• 问题追踪
• 责任定位
• 重新生成
• 合规审计

所以以后你做平台时，要默认认为：

数据不是静态文件，而是一个会不断流转和变形的对象。

---

第十七章：企业里最容易出问题的数据治理点有哪些

至少有下面 8 类：

1. 隐私泄漏

训练数据里混入手机号、身份证、邮箱、地址。

2. 版权风险

来源不清的网页和文档被直接拿来训练。

3. 标签不一致

不同标注员标准不一致。

4. 样本重复严重

导致训练成本高、分布失真。

5. 评测污染

测试题进了训练集。

6. 版本混乱

不知道线上模型对应哪份数据。

7. 质量漂移

新数据批次质量明显变差，却没人发现。

8. 删除请求无法回溯

当某些数据需要删除时，你不知道它进入过哪些训练。

这就是为什么成熟团队会把数据治理看得非常重。

---

第十八章：从平台视角看，大模型数据系统通常需要哪些能力

如果你以后要在这套 Kubernetes 环境上真正搭平台，数据侧至少要有下面这些能力：

1. 原始数据存储

例如：

• 对象存储
• NFS / PVC

2. 数据处理流水线

例如：

• ETL Job
• 清洗任务
• 脱敏任务
• 去重任务

3. 数据版本登记

例如：

• dataset registry
• 元数据库

4. 标注与审核流程

例如：

• 标注平台
• 审核流
• 质量抽检

5. 评测集隔离

防止训练污染。

6. 数据权限控制

谁能看 raw，谁能看 cleaned，谁能拿去训练，不能混着来。

7. 合规与审计

知道：

• 哪些数据进过训练
• 谁操作过
• 哪个版本上线了

8. 血缘追踪

把数据和训练任务、模型版本真正串起来。

所以以后你搭平台时，数据侧不是“一个目录”，而是一套系统。

---

第十九章：把这次示例目录和概念图对上

为了让你不是只看文字，我这次特地补了一组最小示例数据：

• README.md
• 00-raw-corpus.jsonl
• 01-cleaned-corpus.jsonl
• 02-sft-messages.jsonl
• 03-preference-dpo.jsonl
• 04-eval-set.jsonl
• 05-rag-documents.jsonl
• 06-dataset-card.yaml

你可以把它们对应到下面这张图：

00 raw corpus
  -> 01 cleaned corpus
  -> 02 sft messages
  -> 03 preference dpo
  -> 04 eval set (独立维护)
  -> 05 rag documents (检索用，不等于训练集)
  -> 06 dataset card (治理元数据)

这样你不只是在“知道有这些名词”，而是真的能摸到它们的形状。

---

第二十章：小白最容易犯的 12 个数据误区

误区 1：数据集就是很多文本堆一起

不对。

数据集必须有明确目标、schema 和治理规则。

误区 2：原始数据可以直接训练

不对。

必须经过清洗、脱敏、去重、格式统一。

误区 3：SFT 数据和预训练数据差不多

不对。

SFT 更强调任务行为和对话格式。

误区 4：评测集也可以顺便拿来训练

不对。

这会直接污染指标。

误区 5：RAG 文档就是训练集

不一定。

大多数情况下它属于检索知识库，而不是训练数据。

误区 6：数据多就一定好

不一定。

低质量数据和重复数据会伤害模型。

误区 7：数据清洗只是去空行

不对。

它涉及脱敏、去噪、去重、标准化、过滤、安全治理。

误区 8：版本管理只对代码重要

不对。

数据版本同样关键，甚至经常更关键。

误区 9：有模型管理就够了，不用管数据血缘

不对。

你必须知道模型吃了哪份数据。

误区 10：只要标注员多，数据质量自然就好

不对。

标注规范、抽检和一致性更重要。

误区 11：脱敏做一次就行

不对。

不同批次、不同来源、不同下游使用场景都要复查。

误区 12：数据工程不如训练工程重要

不对。

对大多数企业项目来说，数据工程往往才是成败关键。

---

最后把整条数据线压缩成一句话

你可以先把大模型数据工程理解成这样：

把来源复杂、质量不一、可能带风险的原始内容，经过清洗、切分、标注、去重、脱敏、版本管理和质量治理，变成可以安全、稳定、可追踪地支撑训练、评测和检索的标准化数据资产。

这句话里每个词都很重要：

• 清洗决定能不能用
• 切分决定上下文结构
• 标注决定学什么行为
• 去重决定分布和成本
• 脱敏决定合规边界
• 版本管理决定可复现
• 质量治理决定长期可持续

---

你接下来最应该继续学什么

如果这一课你已经吃透，下一步最自然的不是再讲“数据是什么”，而是继续进入：

1. Tokenizer 和 token budget
2. SFT / LoRA 训练链
3. Checkpoint、adapter、merge 和模型产物管理
4. 评测体系和线上反馈闭环

如果你愿意，我下一课可以继续写：

• 20-第二十课-大模型训练-SFT-LoRA-Checkpoint-Adapter与模型产物原理.md

这样就能把“数据是什么”自然接到“模型怎么被训练出来”。