什么是好的数据 Taste?

如果具象的来看大模型领域数据 Taste 这个事情，可以围绕一次完整的数据闭环流程来看这个事情，包括数据采集、筛选数据、用数据、数据质量、数据评测这几个阶段。

序

What Makes a High-Quality Training Dataset for Large Language Models: A Practitioners’ Perspective

• 这是 24 年采访的 219 位来自不同国家的 LLM 从业者，看大家如何理解训练数据质量这个事情：
  • 高质量数据的 top3 特征：可靠性（来源可靠）、相关性（和目标是否相关）、准确性（是否无明显错误）
  • 验证数据质量的 top3 方式：人工抽样、定量指标、数据可视化
  • 难题：缺少统一数据处理流程、无法确认清洗到什么程度可 work、清洗后的数据无法做指标量化

从这里就可以看出来 LLM 领域里关于数据的好坏，一直没有一个标准答案，大家都是根据自己的数据 Taste 在解决问题。

Training Compute-Optimal Large Language Models:

• DeepMind 经典的 Scaling Law 论文，固定训练算力时，参数量 (N) 和训练 token 数 (D) 应近似按 (C^{0.5}) 同步增长。
• Chinchilla 用 70B 参数、1.4T token，在近似相同训练算力下击败了 280B 参数、300B token 的 Gopher，同时推理更便宜。

在这篇 paper 里，DeepMind 的 Chinchilla 证明了数据规模的扩大，是可以提升模型上限，模型越大，能吃的数据越多（并且至今在模型架构的不断演进下，单位模型/算力能吃的数据已经越来越多了）。所以这个定理也基本上告诉了所有做基模的公司：不要低估模型的上限，赶紧找数据吧！

找到好的数据

当前大模型，在没有线上反馈数据和外部供应商采买的情况下，通常数据来源下面 4 个地方：

• 爬虫: 当前 LLM 基模大部分数据的来源，爬虫得到的数据，一般来说良莠不齐，需要做大量清洗和处理才能得到自己想要的数据，两篇经典的 paper:
  • https://arxiv.org/abs/1911.00359: 爬的文本数据，用 FastText 做分类和置信度过滤，用 Wikipedia KenLM 来做 perplexity(困惑度)分层
  • The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale: FineWeb 在做过滤时发现，爬虫出来的原始数据，如果经过严格的过滤（filter 和 dedup），反而会让实验效果下降
• 开源数据集: HuggingFace 是个好地方，即使是 Kimi 这样的基模厂，在很多新领域也用了 HF 里的数据作为 seed，来完成初始化；但是开源数据集的质量通常会比爬虫质量高一些，但是也存在很多瑕疵（尤其是现在很多 dataset 都是基于若干个 dataset 的集合+合成，带有了大量的 LLM rewrite 错误），所以对于关注数据的公司：
  • 做一个 HuggingFace 监控日报，每天观测自己所在领域的数据集
  • 拿到 dataset 后，先看来源，是否是知名公司/实验室，一般来说这一步等同于给 dataset 质量打分
  • 分析 dataset 的覆盖度、数据有效性、格式、处理代码是否开源等等
• 合成：通常用于，自己想要的数据量很少时（如缺乏高质量数据、缺乏面向 xx 任务的数据等），需要通过各种手段，把这批数据给生成出来，一般有几种方式：
  • 蒸馏：Stealing Reasoning Traces from Proprietary LLM APIs: 近期最经典是这篇文章，揭秘了如何蒸馏 Opus 系列模型(这个漏洞已经被封上了)
  • Agent 驱动：下面有个 AgentRL 数据合成，讲的是这部分，主要是通过 harness 让 Agent 在 simulation environment 里遵循规则游走，然后用 reject sampling 方式留下高质量数据
  • 数据改写：这也是很场景的操作，比如基于长文本来生成高质量的跨 context 的 QA，来保证 LLM 的长文本能力， Kimi3 里重点强调了这类方式：利用 SOTA model 通过对长文本的大量改写，最大化利用高质量的长文本数据
  • 模态转换：比如图片转文字，视频转文字等，有机会获取到普通网页里不存在的信息（比如数学教材数据等）；

选择好的数据

在找到好数据后，选择好的数据也非常重要。最近看到一个有意思的 post：说的是两年前很火的 “Data Selection” 方向消失了，主要观点是：数据筛选在模型逐步 scale up 之后不重要，过多的 filter 反而会导致样本分布偏离影响模型效果。

但从我的视角上看，Data Selection 一直是一个很重要的课题，尤其是对于部分 startup 来说，如何低成本初始化一个基模，选到关键数据和高质量数据，是最重要的问题，没有之一。

至于后面找不到更多的高质量数据，以及需要进一步挖掘数据背后关联的深层信息，那么利用好各种跨领域数据和低质量数据也是不得不做的事情。

• What Makes Good Data for Alignment? :
  • 24 年美团发的 paper，讲的是利用 Complexity x Quality x Diversity 的关系，利用 GPT 构造“进化序列”(这条链路被定义为 “DEITA”)，生成更高质量数据，能够有更好的模型效果。
  • 这篇文章是在 7B/13B 模型上实验，结论在当前的大模型规模下未必是合理的

• Large-Scale Data Selection for Instruction Tuning :
  • 25 年的 paper，发现过去很多 paper 里提到的高质量 data selection（如 topK）的方法在原始数据到百万/千万量级失效（因为有可能这些数据有偏或是满足了 judge model 的偏好），提出了一种新的 RDS+ 的数据筛选方法，基本原理是利用 hidden states 来表示数据特征（这样似乎比外置的 filter 更加合理一些），但是 hidden states 每一层的表现也不一样，所以我预计这个方法也没那么的稳定。

ATLAS

• 24 年 Google 的 paper，进一步证明 Data Selection 的重要性，通过 LLM 模型的实验，这里面有几个关键结论：
  • 跨语言迁移具有方向性: 比如西班牙语能显著帮助加泰罗尼亚语，A->B 有帮助，B->A 不一定有帮助，要搞清楚哪些源 token 对目标的边际贡献最高
  • 多语言有成本（互相挤压信息空间），但是正迁移能抵消一部分，比如语言数量从 K 翻到 2K，参数只需要 1.18x，数据 1.66x，计算 token 1.96x，原有数据只需要 83%，就能保持原有的训练 loss
  • 小众语言不能无限 overfit：小众语言数据少，但是超过 1 个 epoch 后，重复数据的有效收益快速下降

合适的时机使用合适的数据

通常来讲，我们在 pretraining、sft、rl 阶段需要使用不同的数据：

• pretraining：使用广泛且多样性的数据，建立广泛的语言、知识和基础能力
• SFT：使用高质量、覆盖目标任务分布的指令—回答示范数据，让模型掌握初步的、简单的指令遵循、回答格式和典型任务的解决方式
• RL: 利用反馈信号（如模型、人类打标），进一步优化模型，提升和人类专家的对齐程度，更充分的激发 pretraining 习得的潜力

DeepSeek-R1 的纯 RL 出现可读性差和语言混杂；

• R1 通过精筛 + 模型判断 + 人为判断得到高质量 SFT 数据
• RL 再通过 accuracy + format + length + language 等 reward 进一步强化 CoT 推理轨迹的数据质量；

Nemotron

NVIDIA 开源的 Nemotron 方案里对于 agent 模型训练做了非常详细的拆解和分析：

• Pre-Training: 23.5T，广泛覆盖 web、代码、学术、多语言等各个领域
• SFT：1.5T，高质量、合成、STEM、教材

其中对于不同的能力，需要在不同的阶段为不同的数据：

1. 增强长上下文能力： CPT：最长 512k 的训练序列 SFT：长上下文平均为 128k，上限为 256k

其中使用了大量可控制的合成任务，例如：

• 把答案所需信息放在很远的位置；
• 在多个文档中分散证据；
• 加入无关干扰文档；
• 要求跨文档、多跳组合答案；
• 保留可以自动验证的标准答案。

2. Agent 能力 SFT 阶段：这里是因为 pretraining 本质上还是在训练 p(next token|previous tokens)，但是 SFT 这一步骤要把 Agent、多轮、CoT 这些能力都加上去，本质上是在训 P(action|state)，

3. Reasoning 能力 Recipe 还把 reasoning control 做进训练数据：

• 大约 10% 样本去掉 reasoning，用来训练 reasoning on/off；
• 大约 3% 推理轨迹被截断到不同 token budget；
• 推理时达到预算后插入 ，要求模型根据不完整思考给出最终答案。 这意味着 reasoning budget 并不是纯推理端功能。模型必须提前见过：
• 不思考直接回答；
• 短思考；
• 长思考；
• 思考中途被终止后仍然收束答案。

反共识：脏数据也有价值？

• A Bitter Lesson for Data Filtering: 数据”脏”点也没关系。主要的实验方法有两个：

1. 用很多 Filter（比如语言、感叹词、去重）清晰得到高质量数据，但是同样规模的 Model 下，学习的远没有全量数据来的充分
2. 注入一些打乱顺序的低质量数据，Model 依旧能学到低质量数据里的一些词语的关联关系

但这篇 paper 也未必客观，因为他是建立在“高质量数据有限”的前提下的，而实际情况是，所有人都在想法设法的创造更多的高质量数据（包括基于低质量数据做合成）。

如何判断数据质量？

DataDecide: How to Predict Best Pretraining Data with Small Experiments:

• 25 年的文章，主要是想验证，能否使用小模型来较低成本的判断哪份 training data 会更好？几个关键结论：
  • 用 150M 模型的排名预测 1B 模型的排名，平均可以做对约 80% 的数据对决策
  • 小模型不看 Accuracy，而是看 logits 里答案的 prob，对于 MBPP/HumanEval 很明显，小模型做不对，但是答案的 likelihood 已经包含了信号，数据排名预测准确率可提升到约 80%（如果这样的话，很明显是他的计算 budget 没有给够）

这个方法其实有一定道理，很明显，我们没有办法每改变一次数据，都对完整的数据集和 base 模型来一次 pretraining，有一个可靠的 baseline 是一件很重要的事情。

DataMan: Data Manager for Pre-training Large Language Models:

• 25 年阿里巴巴发的一篇文章，用 GPT-4 标注 3.57w 篇 doc，按 13 个维度分类打分，得到打分结果后，微调 Qwen2-1.5B 得到 DataMan 模型，然后在 LLaMA 上实验，证明只用 score=4/5 的数据训练效果要显著高于随机采样得到的数据。

微调一个 Model 来作为自己私域内的评测模型，是一个还比较合理的做法，Kimi 在 Data Pipeline 里也大量使用这种方法。

DataRater: Meta-Learned Dataset Curation:

• 一个 50M 参数的 transformer，每次训模型的时候，把 data 输入进这个 transformer 算一个分数，在原模型 loss 作为 label；
• 每次有新数据输入，走这个模型，拿到评分，丢弃掉低分数据，本质上是在选择能够给模型更大梯度的数据

这个方法很理想，但问题还是比较大的，因为每个模型的特性都不一样，对大模型的影响未必可以转化成小模型的 loss 表征，以及梯度大未必一定是一个好事。

合成数据：高质量低成本的便宜数据

对于 Agent 数据，由于采集和互联网上，没有大量可公开的数据集，所以对于 Agent 长程任务基本都采用合成的方式来完成大部分数据的收集。

Kimi K3: Open Frontier Intelligence: 对于 Kimi-K3 的 Agent 轨迹合成，K3 Report 介绍使用了知识图谱的方式，根据全互联网的信息来构建 Agent Task Graph，无限挖掘（带去重和概念合并）Agent 可能存在的 Task 和轨迹。

Qwen-AgentWorld: Language World Models for General Agents

• Qwen 关于通用 Agent 的文章，里面提到了如何利用种子数据来实现大量 Agent 轨迹的合成。

WeAgent-MMSearch: Native Text-Vision Interaction for Multimodal Search Agents

• 对于微信多模态搜索的场景，想加强 WeAgent 的读图能力。数据合成上采用的是逆向生成的方法，他们先从互联网上找到一个必须由图片来回答的问题，然后在这个基础上不断地向前做 Multi-Hop 合成并保证实际可执行性，产出长程的 Agent Trajectory，最后通过 reject sampling 拿到一批高质量轨迹。

如何评测数据？

Understanding the Dataset Practitioners Behind Large Language Model Development:

• Google Research 团队发布的，他们在 24 年就发布了这个问题。对模型团队里，不同的人做了不同的调研，结果发现他们关注的角度完全不同，比如训练团队关注评测效果，产品关注真实的用户分布等等。但是，他们的观察方式都是一样的：
  • eyeballing：肉眼观察数据，根据直觉给出结论，但是往往没有代表性，且经常出现因果颠倒的情况（带着结论找证据）
  • notebook：做一些数据分析，如分布等，但是这种方式高度定制化，难形成共识，更难标准化

这其实是当前研发过程中比较痛的点，但应该也没有太好的办法，就像互联网产品里，每做一个改动，都得去看对应的 A/B 指标一样，需要一个全面可靠的 A/B 实验平台来作为模型迭代的重要参考。