1. 从“炼丹”到“炼金”：为什么数据集是大模型成败的基石

最近和几个做AI的朋友聊天，发现一个挺有意思的现象：大家聊起大模型，张口闭口都是“千亿参数”、“MoE架构”、“SOTA性能”，但一提到“你的数据从哪来的？怎么处理的？”，场面往往就安静了。这感觉就像一群人在热烈讨论如何用最顶级的厨具、最复杂的烹饪技法做出一道绝世美味，却没人关心食材本身是否新鲜、产地是否正宗。大模型训练，本质上就是一场数据驱动的“炼金术”。你喂给它什么，它最终就会变成什么。参数和架构是“炉子”和“火候”，而数据集，才是那块决定最终是“黄金”还是“废渣”的“原矿石”。

标题里提到的“770+TB”，这个数字听起来很唬人，但它背后真正揭示的趋势是：大模型的发展已经从比拼“模型有多大”，悄然转向了比拼“数据有多好、多全”。预训练、微调、对齐、评估……模型生命周期的每一个环节，都对应着截然不同的数据需求和数据处理哲学。一个在万亿token通用语料上预训练出的“通才”，如果没有经过高质量指令数据的微调，它可能连“写一首关于春天的诗”这样简单的任务都完成得磕磕绊绊；一个在数学推理数据上表现优异的模型，如果没有经过人类偏好对齐，它可能会给出一个逻辑正确但充满冒犯性言论的答案。

所以，这篇内容我不想再重复那些模型结构的原理，而是想沉下来，和大家一起盘一盘大模型背后这些“沉默的巨人”——数据集。我们将按照模型训练的完整Pipeline，梳理从海量无监督预训练，到有监督微调，再到人类偏好对齐，乃至最终评估和垂直领域应用，每一个阶段都需要什么样的数据，以及这些数据是如何被收集、清洗和构建的。无论你是刚入门想自己动手微调一个模型玩玩，还是资深的算法工程师在为公司寻找某个垂直领域的最优数据解决方案，希望这篇近万字的“数据集地图”都能给你带来一些实实在在的参考。

2. 预训练数据：构建模型“世界观”的原始语料库

如果把大模型比作一个人类，那么预训练阶段就是它的“童年”和“青少年”时期，通过阅读海量的文本（或图文对）来建立对世界的基本认知和语言能力。这个阶段的数据，追求的是“广”和“量”。

2.1 数据来源与构成：互联网的“压缩饼干”

目前主流大模型的预训练数据，几乎都来自于对互联网的爬取和清洗。这包括了：

• 通用网页 ：如Common Crawl项目，它每月抓取数十亿网页，是最大的开源网络文本来源。但原始数据噪声极大，包含大量广告、导航栏、重复内容和低质量文本。
• 学术文献与书籍 ：如arXiv论文、Project Gutenberg的电子书、各大出版商的学术库。这部分数据语言规范、逻辑严谨、信息密度高，对于提升模型的推理和专业知识能力至关重要。
• 代码仓库 ：如GitHub上的公开代码。代码具有严格的语法和逻辑结构，对提升模型的逻辑思维、结构化输出能力有奇效。这也是为什么很多模型在代码生成任务上表现突出的原因之一。
• 多语言数据 ：包括维基百科各语言版本、其他语种的新闻网站和文学网站等，用于构建模型的多语言理解与生成能力。

一个核心挑战：去重与质量过滤。 直接使用网络数据会引入大量重复和低质内容。例如，同一篇新闻可能被成千上万个网站转载。如果不进行去重，模型会过度学习这些重复模式，浪费算力并可能导致记忆而非泛化。质量过滤则通过启发式规则（如词汇多样性、标点符号使用、句子长度）或基于小规模高质量数据训练的 分类器模型 ，来剔除垃圾文本。

实操心得 ：不要盲目追求数据量。我曾参与一个项目，初期为了快速启动，使用了未充分清洗的Common Crawl数据。结果模型很快就在验证集上过拟合，生成了大量包含网页模板字符（如“© 2022”、“Privacy Policy”）的胡言乱语。后来我们花费了相当于训练时间两倍的周期来做数据清洗，才让训练回到正轨。 数据清洗的成本，永远比用脏数据训练然后debug的成本要低。

2.2 数据配比与混合策略：营养均衡的“食谱”

有了干净的食材，下一步是如何搭配。不同来源的数据质量、领域、语言分布差异巨大，如何混合它们是一门艺术，直接决定了模型的“气质”。

• 领域配比 ：一个通用的中文大模型，其数据配比可能是：50%中文通用网页，20%中文百科与知识库（如百度百科），15%中文书籍与文学，10%代码，5%多语言数据（以英文为主）。如果目标是专业领域模型（如医学、法律），则需要大幅提高该领域专业文本的比例（可能提升至30%-50%），同时保留足够的通用语料以保证语言流畅性。
• 质量加权 ：在训练时，可以对不同来源的数据设置不同的采样权重。例如，书籍和学术论文的权重通常高于随机网页。一种常见做法是，根据数据源的“困惑度”（Perplexity，用一个小型高质量语言模型评估该文本的“意外程度”，意外程度低则质量高）来动态调整采样概率。
• 时间窗口 ：数据具有时效性。用2021年之前的数据训练的模型，可能不知道“ChatGPT”是什么。因此，需要定期注入新鲜数据，或构建包含最新时讯的数据集。

以LLaMA系列为例 ，其公开的数据配方就非常值得研究：它混合了Common Crawl、C4、GitHub、维基百科、书籍、ArXiv等多个来源，并经过了严格的质量过滤和去重。这种精心设计的“食谱”，是其能在相对较小参数量下取得优异性能的关键之一。

3. 微调数据：为模型注入“任务灵魂”

预训练模型是一个“通才”，它知道语言怎么组织，但不知道如何具体执行你的指令。微调（Fine-tuning）阶段，就是用特定任务的数据，教会模型“听话”和“做事”。根据任务形式，微调数据主要分为两大类：指令跟随数据和对齐数据。

3.1 指令微调数据：从“知道”到“做到”

指令微调的目标是让模型理解并执行人类以自然语言形式下达的指令。其数据格式通常是 (指令 Instruction, 期望输出 Output) 对。

• 数据构造方法 ：
  1. 人工撰写 ：质量最高，但成本昂贵。通常由标注人员根据任务清单（如“写一封商务邮件”、“用Python实现快速排序”、“解释光合作用”）来创作指令和回答。这构成了种子数据集。
  2. 自我指导 ：利用已有的高质量种子数据集，让一个较强的教师模型（如GPT-4）生成新的指令，然后再由它自己或另一个模型生成回答，最后经过人工或规则过滤。这种方法能低成本地大规模扩充数据，但需要警惕质量滑坡。
  3. 数据集转化 ：将现有的自然语言处理（NLP）数据集转化为指令格式。例如，将情感分类数据集（“这句话是正面还是负面？”）转化为指令（“请判断以下评论的情感倾向：……”）。
• 数据多样性是关键 ：指令的表述要丰富多样。同一个任务，“总结这篇文章”可以表述为“为这段文字写一个摘要”、“用几句话概括主要内容”、“提炼核心要点”等。这能增强模型的鲁棒性。
• 实操中的坑——格式不一致 ：在整合多个来源的指令数据时，最容易出现的问题是格式混乱。有的数据指令字段叫 “instruction” ，有的叫 “prompt” ；有的输出字段叫 “response” ，有的叫 “output” 。在训练前必须进行严格的字段对齐和清洗，否则模型会感到困惑。

3.2 对齐数据：塑造模型的“价值观”与“风格”

对齐，特别是基于人类反馈的强化学习，目的是让模型的输出更符合人类的偏好（更有帮助、更无害、更诚实）。其数据构造更为复杂。

• 偏好对齐数据 ：格式为 (提示 Prompt, 获胜回答 Chosen Response, 失败回答 Rejected Response) 。构造方法有：
  • 人工排序 ：给定一个提示，让标注员生成多个回答，并对其进行排序。质量最高，但极耗人力。
  • 模型生成+人工评判 ：用模型针对大量提示生成多个回答，然后让标注员或利用一个 奖励模型 来评判哪个更好。这是当前的主流方法。
  • 合成数据 ：利用规则或模型，自动构造一些显而易见的偏好对。例如，对于有害提示，拒绝回答的响应应优于执行有害指令的响应。
• 安全对齐数据 ：专门用于训练模型拒绝回答有害、非法、不道德的请求。数据形式通常是 (有害提问, 安全拒绝回答) 。构建这类数据需要特别谨慎，既要覆盖尽可能多的有害场景，又要避免模型变得过于“胆小”而拒绝回答正常问题。

重要提示 ：对齐数据是一把双刃剑。过度对齐可能导致模型能力下降，变得过于保守和无聊（俗称“被阉割”）。在实践中，通常会在指令微调后，混合使用指令数据和对齐数据进行多阶段训练，或在训练中设置一个 KL散度惩罚项 ，防止模型偏离原始预训练模型太远，从而在“有用性”和“安全性”之间取得平衡。

4. 评估数据：衡量模型表现的“标尺”

如何知道一个模型是好是坏？全靠评估数据。评估数据集不用于训练，只用于测试。一个全面的评估体系需要多维度、多任务的数据集。

4.1 通用能力评估

• 知识问答 ：如MMLU（大规模多任务语言理解），涵盖STEM、人文、社科等57个学科的选择题，考察模型的世界知识和推理能力。还有像C-Eval这样的中文综合考试评测集。
• 推理能力 ：如GSM8K（小学数学应用题）、MATH（数学竞赛题）、BBH（Big-Bench Hard，一系列复杂的推理任务）。这些数据集要求模型进行多步逻辑推理。
• 代码能力 ：如HumanEval（手写编程问题）、MBPP（基础Python编程问题），评估模型生成可执行、符合要求的代码的能力。
• 综合评测基准 ：如 AGIEval （面向人类考试的评测）、 OpenCompass 、 MT-Bench 等，它们集成了上百个数据集，对模型进行全方位体检。

4.2 安全与对齐评估

• 毒性评估 ：如RealToxicityPrompts，提供一系列可能引发有毒输出的提示，评估模型生成有毒内容的概率。
• 偏见评估 ：如CrowS-Pairs，测量模型在涉及性别、种族、宗教等群体描述时是否表现出刻板印象。
• 真实性评估 ：如TruthfulQA，测试模型在对抗性设置下产生虚假信息的倾向。

评估的陷阱 ：模型可能会在评估集上“过拟合”。如果某个开源评估集被广泛使用，其测试题目可能会被无意中泄露到模型的训练数据中。因此，最新的研究趋势是构建 动态的、未公开的评估集 ，或者采用 基于模型的评估 （如用GPT-4作为裁判来评分），以更真实地反映模型在未知问题上的能力。

5. 垂直领域与特定任务数据：通往专业化的“窄门”

当大模型要落地到具体行业时，通用数据就远远不够了。这时需要高度专业化、结构化的领域数据。

• 金融 ：上市公司财报、券商研报、宏观经济指标、金融新闻、交易规则、合规条文。数据需要极高的准确性和时效性。处理时需注意脱敏，去除个人和公司敏感信息。
• 医疗 ：医学教科书、临床指南、电子病历（需严格匿名化处理）、医学论文、药品说明书。对术语的一致性要求极高，且必须考虑伦理和隐私。
• 法律 ：法律法规、司法判决书、合同范本、法律咨询问答。数据具有极强的逻辑性和规范性，需要模型理解复杂的法律条文和推理链条。
• 编程 ：除了GitHub代码，还有Stack Overflow的问答对、API文档、代码审查记录、提交日志（Commit Message）。这些数据能训练模型理解代码意图、调试和编写文档。

构建领域数据的挑战 ：

1. 数据稀缺与获取难 ：领域数据往往封闭在机构内部，公开可用的高质量数据很少。
2. 数据标注门槛高 ：需要领域专家（医生、律师、金融分析师）参与，成本巨大。
3. 知识更新快 ：特别是科技和金融领域，知识迭代迅速，数据集需要持续更新。

一种可行的策略——主动学习与数据合成 ：先从有限的专家标注数据开始训练一个初始模型，然后用这个模型去对大量未标注数据进行预测，筛选出模型最“不确定”或最可能出错的样本，交给专家标注。如此循环，可以最高效地利用专家资源。同时，可以利用领域内的结构化知识（如知识图谱）和规则，合成一部分训练数据。

6. 数据工程实战：从原始文本到训练就绪的流水线

了解了需要什么数据，我们来看看如何把它们变成模型能“吃”的格式。这是一个标准的NLP数据工程流水线：

6.1 数据收集与爬取

• 工具选择 ：对于公开网页， Scrapy 、 BeautifulSoup 是经典组合。对于需要渲染JavaScript的现代网站，可能需要 Selenium 或 Playwright 。大规模爬取务必遵守 robots.txt 协议，并设置合理的请求间隔，避免对目标网站造成压力。
• API利用 ：许多平台提供官方API（如arXiv、GitHub、维基百科），这是获取结构化数据最稳定、最合规的方式。对于没有API但数据量大的情况，可以尝试寻找社区维护的镜像或数据集（如Hugging Face Datasets）。

6.2 数据清洗与预处理

这是最繁重但最关键的一步。一个典型的清洗Pipeline包括：

1. 去重 ：
   • 精确去重 ：移除完全相同的文档。
   • 模糊去重 ：使用MinHashLSH、SimHash等算法，移除内容高度相似的文档（如转载文章）。这一步能有效防止数据冗余和记忆。
2. 语言识别与过滤 ：使用 langdetect 等工具，只保留目标语言的文本。
3. 质量过滤 ：
   • 规则过滤 ：移除过短/过长的文本、符号占比过高的文本、包含大量乱码或非常用字符的文本。
   • 模型过滤 ：训练一个二分类器（如基于RoBERTa），区分高质量文本（如维基百科）和低质量文本（如垃圾评论），用其对全网数据进行打分过滤。
4. 毒性/敏感内容过滤 ：使用预训练的毒性检测模型（如 HateSonar 、 Perspective API ）识别并移除包含仇恨、侮辱、暴力等内容的文本。
5. 标准化 ：统一全角/半角字符、繁体/简体中文、英文大小写等。

6.3 数据格式化与分词

• 格式化 ：将清洗后的文本，按照预定的格式（如每行一个JSON对象，包含 “text” 字段）存储。
• 分词 ：使用与目标模型一致的 分词器 。例如，训练LLaMA系列需使用其对应的 SentencePiece 分词器，训练Qwen则使用其 tiktoken 分词器。错误的分词器会导致训练时出现大量未登录词 <UNK> ，严重影响效果。
• 序列长度处理 ：将文本切分成模型最大上下文长度（如4096个token）的片段。通常采用滑动窗口的方式，并保留完整的句子或段落边界，避免在句子中间切断。

6.4 数据管理与版本控制

• 使用数据集库 ：强烈推荐使用 Hugging Face Datasets 库。它提供了高效的数据加载、缓存、流式读取功能，并且天然支持版本控制。
• 数据版本化 ：像管理代码一样管理数据。每次数据更新（如添加新来源、调整清洗规则）都应创建一个新版本，并记录变更日志。这对于实验的可复现性至关重要。
• 元数据记录 ：为数据集保存详细的元数据，包括数据来源、收集时间、清洗步骤、统计信息（如token数量、语言分布、领域分布）。这有助于后续分析和调试。

7. 未来趋势与个人思考

回顾这770+TB数据所涵盖的庞大图景，我们可以看到几个清晰的趋势：

第一，从“规模为王”到“质量与多样性为王” 。单纯堆砌数据量的时代正在过去。未来的竞争焦点在于如何构建更干净、更多样、更具挑战性的数据。特别是 合成数据 和 强化学习数据 的生成与利用，将成为提升模型能力的核心杠杆。

第二，评估的复杂化与动态化 。静态的、公开的评测集越来越容易被“刷榜”。未来的评估将更侧重于 真实世界任务的模拟 、 人类主观偏好的直接评估 以及 模型在长周期交互中的稳定性 。像 Chatbot Arena 这样基于众包两两对战、使用Elo评分系统的动态评估平台，可能会成为更主流的评价方式。

第三，数据隐私与版权问题日益尖锐 。随着法律监管的加强和版权方意识的觉醒，完全依赖未经授权的网络爬取数据将面临巨大风险。 合法授权、数据合作、隐私计算 等技术，以及 完全使用合成数据或开源许可数据 来训练模型，会成为重要的解决方案。

从我个人的项目经验来看，数据工作的投入产出比正在急剧升高。早期我们可能把80%的精力放在模型调参上，20%在数据上。而现在，一个成功的项目，数据（包括收集、清洗、标注、评估）的精力投入至少占50%，甚至更多。 当你为一个效果问题焦头烂额时，不妨回过头来，花双倍的时间仔细检查一下你的数据——答案，很可能就藏在其中。 最后分享一个小技巧：在开始大规模数据工程前，先用一个极小的、精心清洗的高质量数据子集（比如1GB）跑一个训练实验。如果这个小实验效果都不好，那么问题很可能出在模型架构或训练代码上，而不是数据量不够。这能帮你快速定位问题方向，避免在错误道路上浪费大量计算资源。