大语言模型 (LLM) 的性能在很大程度上依赖于其预训练数据集的质量和规模。然而，最先进的开源 LLM，如 Llama 3 和 Mixtral 的预训练数据集尚未公开，我们对它们的创建方式知之甚少。

最近，我们发布了 🍷 FineWeb，一个新的大规模 (15 万亿 Tokens，44TB 磁盘空间) 的数据集，用于大语言模型 (LLM) 的预训练。FineWeb 来源于 96 次 CommonCrawl 快照，其生成的 LLM 表现优于其他开源预训练数据集。为了在机器学习领域提供更多透明度，并推动对如何训练高质量 LLM 的公开理解，我们仔细记录并分析了 FineWeb 中使用的所有设计选择，包括对去重和过滤策略的深入研究。本长篇报告深入探讨了如何创建一个大规模高质量的网络数据集用于 LLM 预训练。数据集 🍷 FineWeb 本身可以在 这里 获取。

在本报告中，我们还介绍了 📚 FineWeb-Edu，这是 FineWeb 的一个子集，使用可扩展的高质量自动注释构建，具有教育价值，并且在多个教育基准测试 (如 MMLU, ARC 和 OpenBookQA) 上优于所有公开可访问的网络数据集。📚 FineWeb-Edu 提供两种规模/过滤级别：1.3 万亿 (非常高质量的教育内容) 和 5.4 万亿 (高质量的教育内容) Tokens (所有 Tokens 均使用 GPT2 Tokenizer 进行测量)。你可以在 这里 下载。

这两个数据集均根据宽松的 ODC-By 1.0 许可 发布。

TLDR: 这篇博客讨论了大规模数据质量的处理和评估、🍷 FineWeb 的制作 (列出并解释了我们的所有设计选择) 以及创建其 📚 FineWeb-Edu 子集的过程。

网络数据

寻找原始数据

一个常见的问题是：“他们从哪里获得所有这些数据？”通常有两种选择：

• 你可以自己爬取，就像 OpenAI 或 Anthropic 等公司所做的那样 (见 这里 和 这里)。

• 你可以使用公共存储库中的爬取网页，比如非盈利组织 CommonCrawl 维护的存储库。

为了构建 🍷 FineWeb，我们遵循了过去许多 LLM 训练团队的做法，使用了 CommonCrawl (CC) 作为起点。Common Crawl 非营利组织自 2007 年以来一直在爬取网络，通常每 1 到 2 个月发布一个新的爬取，包含 200 到 400 TiB 的通过自动网络爬取获得的文本内容。

例如，最新的 CC 爬取 (2024 年 4 月) 包含 27 亿个网页，总计 386 TiB 的未压缩 HTML 文本内容注意，大小因爬取而异。另外，在本报告中我们交替使用“转储”或“爬取”两个词。。自 2013 年以来，共发布了 96 次爬取，从 2008 到 2012 年发布了 3 次，这些爬取采用了不同的 (较旧的) 格式我们没有处理这三个较旧的爬取。。

大规模处理

考虑到涉及的数据量巨大，我们必须克服的主要挑战之一是拥有一个模块化、可扩展的代码库，使我们能够快速迭代处理决策，并轻松尝试新想法，同时适当地并行化我们的工作负载，并提供对数据的清晰洞察。

为此，我们开发了 datatrove，一个开源的数据处理库，使我们能够无缝扩展我们的过滤和去重设置到数千个 CPU 核心。创建 🍷 FineWeb 所涉及的所有数据处理步骤都使用了这个 库。你可以在 datatrove 存储库 中找到我们使用的确切脚本。

什么是好数据？

在创建数据集时，这可能是需要牢记的主要问题。在大多数情况下，特别是在大语言模型 (LLM) 预训练的背景下注意，本报告专注于用于预训练大语言模型 (LLM) 的大规模网络数据集 (“大规模”通常指从网络中获得的超过 1000 亿个 Tokens)。我们并不打算涵盖任何其他领域的数据集创建，也不认为本文所发展的教训或假设可以扩展到除这个特定领域之外的任何领域。，“高质量”并不是一个非常明确的术语，甚至不是人类通过直接观察可以总是清晰感知的文档属性。

在大多数情况下，模型通常会在被认为“干净”的语料库上进行训练 (通常是 Wikipedia尽管如上所述，“干净”的概念如此模糊，以至于它可能不应被视为与 Wikipedia 类型的文本等同。)，并用它来检查我们试图整理的数据集的困惑度。不幸的是，这并不总是与在一组感兴趣的下游任务上的性能改善相关联，因此，另一种常用的方法是训练小模型“小”是相对于当今 LLM 的标准尺寸，即相对于 7-70 亿参数来说的“小”。在这项工作中，“小”是指大约 1-2 亿参数。 在我们数据集的代表性子集上，并在一组评估任务上对其进行评估。使用小模型是因为训练成本和时间是模型大小的函数。在这种方法中，选择多样化和代表性的数据集评估任务，并尽量避免对任何一个单独的基准过度拟合非常重要，因为这可能会损害预训练后获得的 LLM 的通用性。

另一种比较不同数据集的方法是分别在每个数据集上训练一个模型，并让人类对模型的生成进行评级和比较 (例如在 LMSYS Chatbot Arena)。这无疑能提供最可靠的结果，以代表实际的模型使用情况，但通过这种方式获得消融结果不幸的是既昂贵又缓慢。它还通常需要模型经历指令微调阶段以获得对话能力，因为预训练的模型并不直接设计为遵循指令，因此对提示细节更加敏感。

在这项工作中，我们采用了训练小模型并在一组“早期信号”基准任务上评估它们的方法。我们认为这是衡量用于训练这些模型的数据质量的合理代理，但要牢记上面提到的关于在评估基准上过度拟合的警告。

消融和评估设置

为了比较给定处理步骤的影响，我们在数据集的两个版本上训练了两个模型，一个版本经过了额外的步骤 (我们希望评估的步骤)，另一个版本则没有这个步骤 (切掉/删除)。除了数据外，这两个模型将完全相同：相同的参数数量、架构超参数，并在从每个数据版本中随机采样的相等数量的 Tokens 上训练一个周期——唯一的区别是训练数据。然后我们在相同的一组任务上评估每个模型并比较平均分数。

我们的消融模型使用 nanotron 进行训练。我们的“消融模型”有 1.82 亿参数 (包括嵌入)，使用 Llama 架构，序列长度为 2048，全局批量大小约为 200 万 Tokens，使用 GPT2 Tokenizer。对于大多数消融，我们训练了约 280 亿 Tokens (大约是这个模型大小的 Chinchilla 最优训练规模)。为了在每一步过滤后确认相对性能改进，我们进行了更长时间的训练，处理了 3500 亿 Tokens，详见下文。

我们使用 lighteval 对模型进行了评估。我们通过选择在相对较小规模上 (训练在只有“几亿” Tokens 的“小”模型) 提供良好信号的基准来仔细选择消融基准。我们通常使用以下标准从 lighteval 中提供的所有基准中选择这些基准：

• 在使用相同数据集的不同采样训练的运行之间差异较小：我们希望我们的运行能够代表整个数据集，结果分数在可能的范围内对确切的数据点选择比对过滤效果更敏感。

• 在训练运行期间性能单调增加 (或接近)：理想情况下，随着看到的 Tokens 数量增加，高信号基准上的性能不应下降 (这表明在小规模上的结果不可靠)。

• 此任务的性能至少超过随机基线几个标准差：由于我们的消融模型和训练通常无法在任何基准上达到非常高的分数，但我们希望确保得到的分数高于随机噪声。

经过考虑，我们选择了以下基准列表：

• CommonSense QA
• HellaSwag
• OpenBook QA
• PIQA
• SIQA
• WinoGrande
• ARC
• MMLU

为了确保我们的检查点评估在有限的时间范围内完成，我们将较长的基准限制在 1000 个样本内 (在 8 个 GPU 的单节点上进行的壁钟时间评估少于 5 分钟 - 与训练并行进行)。

🍷 FineWeb 配方

在接下来的子章节中，我们将解释生成 FineWeb 数据集所采取的每一步骤。

起点：文本提取

CommonCrawl 数据有两种主要格式：WARC 和 WET。WARC (Web ARChive 格式) 文件包含爬取的原始数据，包括完整的页面 HTML 和请求元数据。WET (WARC Encapsulated Text) 文件提供这些网站的纯文本版本。

许多数据集都以 WET 文件为起点。根据我们的经验，Common Crawl 用于创建这些 WET 文件的默认文本提取对于 LLM 预训练的目标来说是次优的特别是我们怀疑它保留了太多的样板内容和导航菜单。，并且有各种开源库提供更好的文本提取。我们使用 trafilatura 库从 WARC 文件中提取文本内容，从视觉检查结果来看，与其他库相比，提供了良好的提取质量。

为了验证这一决定，我们直接使用 WET 文件和使用 trafilatura 从 WARC 文件中提取的文本处理了 2019-18 转储。我们对每个文件应用相同的处理 (我们的基础过滤+minhash，详见下文) 并训练了两个模型。虽然 WET 数据集的结果数据大约大 25% (大约 2540 亿 Tokens)，但它证明质量比使用 trafilatura 从 WARC 文件中提取文本的那个 (大约 2000 亿 Tokens) 差得多。对一些样本的目视检查证实，WET 文件中许多额外的 Tokens 是不必要的页面样板。

然而，重要的是要注意，文本提取是我们处理过程中成本最高的步骤之一，因此我们认为使用现成的 WET 数据对于预算较低的团队来说可能是一个合理的权衡。

基础过滤

过滤是整理过程中的重要部分。它包括删除部分数据 (无论是单词、行甚至是完整文档)，这些数据降低了模型的性能，因此在我们的评估驱动数据集制作过程中被视为“低质量”。

作为我们过滤的基础，我们使用了 RefinedWeb 的部分设置。即：

• 使用 黑名单 应用 URL 过滤以删除成人内容

• 应用 fastText 语言分类器 仅保留得分 ≥ 0.65 的英文文本

• 应用来自 MassiveText 的质量和重复过滤器 (使用默认阈值)

将这种过滤应用于每个提取的文本转储 (目前有 96 个转储) 后，我们获得了大约 36 万亿个 Tokens 的数据如本报告中各处所述：这是使用 gpt2 Tokenizer 时的 Tokens 数量。。

数据去重

去重是创建用于 LLM 预训练的大型网络数据集时最重要的步骤之一。去重方法尝试识别并从数据集中删除冗余/重复的数据。

为什么要去重？

网络上有许多聚合器、镜像站点、模板页面或只是分布在不同域和网页上的重复内容。有时，这些重复页面甚至可能由爬虫本身引入，当不同的链接指向同一页面时。

去除这些重复 (去重) 已被证明与模型性能的提高相关，以及减少预训练数据的记忆，这可能有助于更好的泛化。此外，通过去重获得的性能提升可以等同于提高训练效率：通过删除重复内容，模型可以在更少的训练迭代中达到相同的性能水平——或者相当于在给定的训练 Tokens 数量下，模型将看到更多样的数据。

有不同的方法可以识别甚至定义重复数据。常见的方法依赖于哈希技术来加快过程，或构建高效的数据结构来索引数据 (如后缀数组)。方法还可以是“模糊的”，通过使用某些相似度指标将文档标记为重复，或者“精确的”，通过检查两个文档 (或行、段落或使用的任何其他粒度级别) 之间的精确匹配。请注意，这里即使我们讨论“模糊”去重，我们也仅使用基于字符/单词匹配的方法，即表面级文本。更复杂的去重概念涉及“语义”去重：比较/删除相对于相同概念的文本，并使用例如同义词或释义。在此我们不讨论这些主题，但请注意它们在大规模合成数据生成领域可能很重要 (参见我们关于该主题的 Cosmopedia 发布)。。

我们的去重参数

遵循 RefinedWeb，我们决定应用 MinHash，这是一种模糊哈希去重技术，能够高效扩展到许多 CPU 节点，并允许我们调整相似度阈值 (通过控制桶的数量和大小) 以及所考虑的子序列长度 (通过控制 n-gram 的大小)。我们选择收集每个文档的 5-grams我们的单位是“单词”，使用 MinHash 处理函数 通过 语言特定的单词分词器 计算。 并使用 112 个哈希函数计算 minhash，将它们分成 14 个桶，每个桶 8 个哈希——目标是至少 75% 相似的文档。任何桶中的 8 个 minhash 相同的文档被认为是彼此的重复。

这意味着对于两个相似度 (s) 为 0.7, 0.75, 0.8 和 0.85 的文档，它们被标记为重复的概率分别为 56%, 77%, 92% 和 98.8% (1-(1-s^8)^{14})。下面的图显示了我们的设置 (112 个哈希) 与 RefinedWeb 的设置 (9000 个哈希，分成 450 个桶，每个桶 20 个哈希) 之间的匹配概率比较 (后者需要大量的计算资源，因为每个单独的哈希必须计算、存储，然后与其他文档的哈希进行比较)：

虽然 RefinedWeb 中大量的哈希函数允许更陡峭、更明确的截止 (相似度接近阈值的文档更有可能被正确识别)，但我们认为计算和存储的节省是一个合理的权衡。

还应该注意，文档内去重已由我们的重复过滤器处理，该过滤器删除包含许多重复行和段落的文档。

更多去重总是更好吗？

最初，我们假设更多的去重总是更好的，所以我们的第一个方法是将整个数据集 (所有 90 多个转储) 作为一个大数据集使用 MinHash 去重。

我们以迭代方式进行了这项工作：从最新的转储 (当时是 2023-50) 开始，按时间顺序进行，直到我们处理到最旧的爬取。我们不仅在每个转储内去重，还删除了与之前处理过的转储中的任何其他文档匹配的任何文档。

例如，对于第二个最新的转储 (当时是 2023-40)，我们在其自身内去重的同时，也与最新的转储去重。因此，转储越旧，它与之去重的转储数量越大，我们从中删除的数据越多 (实际上，在最旧的转储中，去重步骤删除了超过 90% 的基础过滤数据)。

以这种方式去重数据集得到 4 万亿个 Tokens，但令人惊讶的是，当在随机抽取的 3500 亿 Tokens 子集上训练时，我们的消融模型显示出几乎没有比未去重数据集上训练的模型改进，在我们的任务集合上得分远低于其前身 RefinedWeb (见下图)。

这挑战了我们对更多去重必然会导致更高基准分数的假设，所以我们决定仔细查看一个最旧的转储，即 2013-48：

• 去重前，这个转储有大约 4900 亿 Tokens。

• 在我们的迭代 MinHash 之后，剩下大约 310 亿 Tokens (94% 的数据被删除)。

作为实验，我们尝试在从以下数据中抽取的 280 亿 Tokens 上训练两个模型：

• 完全去重后剩下的大约 310 亿 Tokens (原始保留数据)。

• 从原始去重过程中删除的约 4600 亿 Tokens 中单独去重 (不考虑其他转储) 后获得的 1710 亿 Tokens (原始删除数据)。虽然原始保留数据中可能有类似于原始删除数据的文档，但我们估计重叠很小 (约 40 亿 Tokens)。。

这些结果表明，对于单独考虑的这个较旧转储，保留的数据 (10% 的原始数据) 实际上比我们删除的 90% 的数据。请注意，这些消融模型仅在此转储中的数据上进行训练，因此独立于所有其他转储。 更糟糕。这也得到了视觉检查的证实：原始保留数据包含更多的广告、关键字列表和通常格式错误的文本，而不是原始删除数据。

退一步：单个转储去重

我们决定尝试另一种方法：我们用 MinHash 对每个转储单独去重 (独立于其他转储)。这产生了 20 万亿个 Tokens 的数据。

当从这个数据集中随机抽样进行训练时，我们看到它现在与 RefinedWeb 的性能相匹配 (见下图)：

我们假设去重带来的主要改进是去除了每个转储中存在的大型集群 (你会在 RefinedWeb 论文中找到这些集群的例子，每个包含数十万个文档) 并且进一步去重低重复数量的集群 (少于约 100，即转储的数量)实际上会损害性能：在任何其他转储中没有找到重复匹配的数据实际上可能是质量较差/更多分布外的 (如 2013-48 数据的结果所示)。

虽然当去重几个转储在一起时你可能会看到性能改进，但在整个数据集 (所有转储) 的规模上，由于这种低质量数据的上采样副作用更为显著。

需要考虑的一种可能性是，随着过滤质量的提高，这种效果可能不那么明显，因为过滤可能能够删除一些这种低质量数据。我们还尝试在单独去重的转储上应用不同且通常“更轻”的去重方法。你可以在下面进一步阅读它们。

关于衡量去重效果的说明

鉴于去重的性质，其效果在数据集的较小切片中并不总是很明显 (例如 280 亿 Tokens，这是我们用于过滤消融的大小)。此外，在所有 CommonCrawl 转储中进行去重时，还必须考虑到一些特定的影响，因为某些 URL/页面会从一个转储到下一个转储重新抓取。

为了可视化扩展训练 Tokens 数量对衡量去重影响的效果，我们考虑了以下 (非常极端且不现实的关于重复程度的情况) 理论场景：

• 有 100 个 CommonCrawl 转储 (大致准确)

• 每个转储已经完美地单独去重 (每个文档在这个转储中都是唯一的)

• 每个转储是彼此的完美副本 (跨转储最大可能的重复，实际上是最糟糕的情况)

• 每个转储有 2000 亿个 Tokens (总共 20 万亿，是上面单独去重的结果规模)

• 每个转储由 1000 Tokens 的文档组成 (每个转储 2 亿文档)

然后，我们模拟从这个总计 20 万亿 Tokens 的数据集中均匀采样文档，以获得 1B、10B、100B、350B 和 1T Tokens 的子集。在下面的图像中，你可以看到每个文档会重复的频率。

对于 1B 几乎所有文档都是唯一的 (重复次数=1)，尽管在整个数据集中每个文档重复了 100 次 (每个转储一次)。在 100B 规模 (总数据集的 0.5%) 开始看到一些变化，大量文档重复两次，少数甚至重复 4-8 次。在 1T 的较大规模 (总数据集的 5%)，大多数文档最多重复 8 次，有些甚至最多重复 16 次。

我们在 350B 规模上运行了去重数据的性能评估，在这个理论场景下，由大量重复到 8 次的文档组成。这个模拟说明了在去除最大的重复集群后，在 LLM 训练中测量去重影响的固有困难。

其他 (失败的) 全局方法

为了在我们新发现的方法 (独立去重每个转储) 的基础上进行改进。我们尝试通过进一步使用替代的全局 (跨所有转储) 去重方法来改进性能。我们探索了以下方法：

• URL 去重：我们只保留每个标准化（小写）URL 对应的一个文档（去除 71.5% 的 Token，剩余 5.6T）—— FineWeb URL 去重。

• 行去重：
  • 删除所有重复行，仅保留一个（随机选择）（去除 77.8% 的 Token，剩余 4.4T）—— FineWeb line dedup
  • 同上，但只删除至少包含 10 个单词的重复行，并在去重后删除少于 3 个句子的文档（去除 85% 的 Token，剩余 2.9T）—— FineWeb line dedup w/ min words
  • 删除所有重复的连续 3 行，仅保留一个，并在查找重复时将每个数字视为 0（去除 80.9% 的 Token，剩余 3.7T）—— FineWeb 3-line dedup

在每一个的性能都比原始单独去重的数据差 (即使在不同程度上)：

附加质量过滤

到目前为止，我们已经达到了我们试图复现和扩展的前一工作的性能：RefinedWeb，使用我们的基础过滤和独立 MinHash。尽管如此，在我们的任务集合中，另一个经过大量过滤的数据集 C4 数据集 在我们评估套件中的一些基准上仍显示出更强的性能。

因此，我们着手寻找新的过滤步骤，以首先使我们的性能达到 C4 的水平，并在第二阶段超过它。一个自然的起点是研究 C4 本身的处理。

C4: 一个经受住时间考验的数据集

C4 数据集 于 2019 年首次发布。它来自 2019-18 CommonCrawl 转储，通过删除非英语数据、在行和文档级别应用一些启发式过滤、在行级别去重并删除包含某些词汇表中词汇的文档来创建。

尽管这个数据集已经过时，且按当前标准来说规模有限（大约 1750 亿 gpt2 Token），但直到今天，它仍然是典型的大语言模型 (LLM) 训练中常见的子集，被用于像最近的 Llama1 这样的模型 [31]。这一成功归因于在该数据集上训练的模型表现出的强大性能，尤其是在我们“早期信号”组中信噪比最高的基准之一 Hellaswag 上。我们实验应用了每个 C4 处理步骤到独立去重的 FineWeb 2019-18 转储的基线上：

• 应用“所有过滤器” (删除不以标点符号结尾的行，提及 JavaScript 和 Cookie 通知 + 删除长度阈值外的文档，包含“lorem ipsum”或大括号的文档 {) 使我们达到了 C4 的 Hellaswag 性能 (“所有过滤器”对比“C4”曲线)。

• 大括号过滤器和单词长度过滤器仅提供了小的提升，分别删除了 2.8% 和 4.3% 的 Tokens。

• 终端标点过滤器本身提供了最大的单独提升，但删除了大约 30% 的所有 Tokens (!)。

• lorem_ipsum, JavaScript 和政策规则每个删除不到 0.5% 的训练 Tokens，所以我们没有单独训练它们。

• “除 (非常破坏性的) 终端标点外的所有过滤器”比单独终端标点表现更好，同时总共删除更少 (~7%)。

我们决定应用上述所有 C4 过滤器，除了终端标点过滤器。我们通过更长时间的运行验证了这些结果，你将在下一节的图表中看到。

开发启发式过滤器的统计方法

为了开发新的启发式过滤器并选择其阈值，我们设计了一个系统过程：

1. 我们首先收集了我们数据集的大量高层次统计数据 (超过五十个不同的指标)，从常见的文档级别指标 (例如行数、平均行/词长度等) 到文档间重复指标 (灵感来自 MassiveText)，在高质量和低质量的网络数据集上；
2. 我们选择了 Wasserstein 距离在两个分布 (在每个数据集上计算的指标) 之间较大的指标；
3. 我们检查了两个分布的直方图，并根据经验选择了一个阈值，使低质量数据集在该指标上的分布更接近高质量数据集；
4. 我们通过在参考数据集上使用该过滤器 (指标-阈值对) 并进行小型消融来验证结果。

由于我们 (新的) 假设全局 MinHash 大大增加了最旧转储中的低质量数据比例，我们在 2013-48 和 2015-22 爬取的独立 MinHash 版本和 (质量较差的) 全局 MinHash 版本上计算了这些指标。然后我们从宏观层面比较了这些指标的分布。

也许不出所料，考虑到我们对去重的发现，我们发现大多数指标在两个去重方法上的差异显著。例如，line-char-duplicates 指标 (重复行中的字符数/字符数) 从独立去重 (2015-22 为 0.0053，2013-48 为 0.0058) 到全局去重 (2015-22 为 0.011，2013-48 为 0.01) 翻倍，表明后者的文档间重复率更高。

按照上述步骤对这些数据集进行的过程产生了十七个候选指标-阈值对。你可以在下面的图像中看到其中三个直方图：

例如，我们检查了“以标点符号结尾的行的比例” (见上图) 的直方图，发现全局 MinHash 的文档密度增加了约 0.12。然后我们用这个阈值进行了过滤，发现被移除的数据有更多的短列表或仅由文档布局文本 (“主页”、“注册”等) 组成。

我们随后通过在 2019-18 爬取上进行 28B tokens 消融评估，评估了这十七个新创建的过滤器的效果。在所有这些运行中，我们确定了三个过滤器 (基于上述直方图) 在综合得分上表现出最显著的改进：

• 删除以标点符号结尾的行比例 ≤ 0.12 的文档 (删除 10.14% 的 tokens) ——相对于原始 C4 终端标点过滤器的 30%
• 删除重复行中的字符比例 ≥ 0.1 的文档 (删除 12.47% 的 tokens) ——原始 MassiveText 阈值为该比率的 ≥ 0.2
• 删除短于 30 个字符的行比例 ≥ 0.67 的文档 (删除 3.73% 的 tokens)
• 当一起应用这三个过滤器时，删除了约 22% 的 tokens。

这些过滤器使我们能够进一步提高性能，并显著超越 C4 数据集的性能，同时提供了更大规模的数据集。

最终的 🍷 FineWeb 数据集

最终的 🍷 FineWeb 数据集包含 15T tokens，并包括以下之前提到的步骤，按顺序排列，每个步骤都在我们的基准任务组上提供了性能提升：

• 基础过滤
• 每个转储独立的 MinHash 去重
• 选择的 C4 过滤器
• 我们的自定义过滤器

与其他网络规模数据集的比较

我们将 🍷 FineWeb 与以下通常被认为是最高质量的公开可访问的网络规模数据集进行了比较 (我们还为每个数据集指出了公开版本中的大致 tokens 数量)：

• RefinedWeb (500B tokens)
• C4 (172B tokens)
• Dolma v1.6 (3T tokens) (CommonCrawl 部分)Dolma 有一个较新的版本 v1.7，规模较小。
• The Pile (340B tokens)
• SlimPajama (627B tokens)
• RedPajama2 (20T tokens) (去重)
• 和我们新的 🍷 FineWeb (15T tokens) (本文报告)

你会发现使用 3500 亿 tokens 训练的消融模型是公开可访问的，并聚集在 这个集合 中。我们在每 1000 个训练步骤上传了检查点。你还会发现我们的完整 评估结果。

🍷 FineWeb 因此是——据我们所知——当前公开数据集中，训练数万亿 tokens 时导致最高模型性能的开放数据集。

📚 FineWeb-Edu

📚 FineWeb-Edu 是 FineWeb 的一个额外发展，我们很高兴在本技术报告中介绍并公开发布。📚 FineWeb-Edu 基于一种新方法，这种方法最近出现，用于过滤 LLM 训练数据集：使用合成数据开发分类器以识别教育内容。这种技术在 Llama 3 和 Phi3 的训练中显著使用，但据我们所知，其在网络数据过滤方面的大规模影响尚未得到充分探索。

流行的 Phi3 模型训练了 3.3 和 4.8 万亿个 tokens，论文 说明：

我们的训练数据包括来自各种公开互联网资源的根据“教育水平”重度过滤的公开网络数据，以及合成的 LLM 生成数据。

同样，Llama 3 博客文章 提到：

我们发现之前几代的 Llama 擅长识别高质量数据，因此我们使用 Llama 2 帮助构建推动 Llama 3 的文本质量分类器。

然而，这些分类器和过滤的数据集尚未公开。为了进一步提升 🍷 FineWeb 的质量，我们开发了一个教育质量分类器，使用 Llama-3-70B-Instruct 生成的注释来创建 📚 FineWeb-Edu。

大规模教育质量注释

我们使用 Llama-3-70B-Instruct 对 🍷 FineWeb 的 50 万个样本进行了注释，对每个样本的教育质量进行 0 到 5 分的评分。

我们探索了各种提示格式以使用 LLM 自动提取教育评分，发现 Yuan 等人 的加法量表效果最好。该量表允许 LLM 推理每个额外分数的理由，不同于单一评分 Likert 量表，该量表将样本装入预定义的框中。然后，为了避免 LLM 偏向于高技术页面如 arXiv 摘要和提交，我们专注于小学和中学水平的知识。通过在过滤过程中设置 3 的阈值 (在 0 到 5 的量表上)，我们还能保留一些高水平的教育页面。

在用于注释数据的公开权重模型方面，我们实验了几个模型，包括 Mixtral-8x7B-Instruct 和 Mixtral-8x22B-Instruct，Llama-3-70B-Instruct 以及一个收集这三个模型评分的陪审团。在我们的实验中，我们发现单独使用 Llama3 提供了最可靠的结果。

训练分类器

为了将我们的注释扩展到 FineWeb 中的数万亿 tokens，我们使用 Llama3-70B 的注释训练了一个小型分类器。我们使用的模型是 Snowflake-arctic-embed 嵌入模型，上面有一个带有单个回归输出的分类头。我们在 45 万个 Llama 3 注释上训练了该模型 20 个周期，学习率为 3e-4，冻结嵌入和编码器层。我们保存了在我们的保留验证集 (45k 样本) 上 F1 分数最高的检查点，将 Llama 3 注释视为真值。训练后，我们将分数四舍五入为 0 到 5 的整数。

然后，我们将问题转化为一个二元分类任务，通过使用固定阈值来确定文件是否具有教育性。使用阈值 3 时，模型在验证集上达到了 82% 的 F1 分数，表明在区分高质量教育内容方面表现出强劲的性能。

该分类器可在：HuggingFaceFW/fineweb-edu-classifier。训练和推理代码可在 GitHub 上找到。

过滤和结果

我们将分类器应用于 🍷 FineWeb 的 15T tokens，过程需要 6000 小时的 H100 GPU 时间。我们调查了使用不同阈值进行过滤的影响，发现使用阈值 3 的结果最好。尽管使用高于 3 的阈值会在知识和推理密集型基准上提高性能，但它会显著降低 HellaSwag 和 PIQA 的性能。下图显示了与 FineWeb 相比，不同阈值在六个不同基准上的性能；它使用了在 8B tokens 上训练的 1.82B 模型。

注意： 这次消融是在 2024-10 转储中的 8B tokens 上进行的，包括 FineWeb 和 FineWeb-Edu 子集，这可能无法代表整个数据集。下一次消融显示，阈值 3 的发现适用于从所有 FineWeb 转储中抽取的 350B tokens 的较长运行，除了 HellaSwag，我们注意到其性能略有下降。

我们通过过滤掉得分低于 3 的样本构建了 📚 FineWeb-Edu。这删除了 92% 的数据集，留下了 1.3 万亿个教育 tokens。为了评估这种过滤在较大规模上的效果，我们进行了一个消融，使用一个在 3500 亿 tokens 上训练的 1.82B 模型，类似于上面提到的 FineWeb 过滤消融：

以下是上述消融结果的关键亮点：

• 📚 FineWeb-Edu 超越了 🍷 FineWeb 和所有其他开放网络数据集，在 MMLU、ARC 和 OpenBookQA 等教育基准上有显著改进。
• 它以显著更少的数据实现了相同的性能，匹配 MMLU 结果需要的 tokens 比 C4 和 Dolma 少 10 倍。
• 这证明了使用 LLM 注释训练的分类器进行大规模数据过滤的有效性。

鉴于阈值 2 也展示了强劲的性能，同时保留了更多数据，我们发布了一个额外的数据集，使用这个阈值过滤，包含 5.4 万亿个 tokens，在 HuggingFaceFW/fineweb-edu-score-2 下。

你可以在这个集合中找到两个数据集以及用于过滤的分类器。

附加内容：CommonCrawl 随时间变化

就像美酒一样，并非所有爬取都是平等的。

在消融过滤步骤时，我们注意到某些爬取的性能比其他爬取高出许多。我们决定调查这种现象。

按爬取的基准性能

对于每个爬取，我们在从该爬取的数据中随机抽取的 270 亿 tokens 上训练了两个 1.8B 模型 (经过基础过滤和 MinHash 去重步骤后)，每个运行有不同的随机 270 亿 tokens 抽样。我们训练了 192 个这样的模型，总共超过 60000 小时的 H100 GPU 时间。然后我们将两次运行的最后三个检查点的平均值绘制为每个爬取的 6 个数据点的平均值。

下图清楚地显示了某些转储的性能远低于其他转储。每年有不同的颜色，每年的爬取数量也不同。

我们调查了可能的原因，例如每个转储中最常见 URL 的变化，以及潜在的基准污染，但未能找到任何结论性解释。我们将进一步研究留给未来的工作。

合成数据

我们想知道，最近几个爬取的强劲表现是否部分归因于存在更多的合成数据 (由 LLM 生成的数据)。这样的变化并不令人惊讶，因为最近 LLM 的流行度显著增加，尤其是 ChatGPT。

据我们所知，没有万无一失的方法来检测合成数据，我们选择使用一个代理指标：我们测量每个爬取中以下词汇的频率："delve", "as a large language model", "it's important to note", "rich tapestry", "intertwined", "certainly!", "dive into"，所有这些词汇都是 ChatGPT 常用的。

重要的是要注意，并非所有包含这些短语的样本都是由 ChatGPT 生成的 (也有许多 ChatGPT 生成的样本不包含任何这些短语)，但假设不同爬取之间的合成数据量不变，你会期望这些频率随时间保持大致不变。

结果如下图所示：

虽然频率在 2023-14 (ChatGPT 于 2022 年底发布) 之前大致保持不变，但我们发现最近爬取中的代理指标急剧增加。虽然这个简单的测试不足以得出结论认为 ChatGPT 补全和其他合成数据正在提高最新爬取的质量，但至少它似乎并没有显著损害它。

我们预计将继续在新的 CC 爬取中看到越来越多的合成数据。然而，对于相对较小的训练，这些数据似乎不会损害性能 (实际上可能会提高性能)，但尚不清楚这是否适用于更大规模的训练。

结论和展望

通过我们的开放科学努力，我们希望继续揭示训练高性能大语言模型的黑箱，并使每个模型训练者能够创建最先进的 LLM。我们很高兴继续改进 FineWeb，并以完全开放和可重复的方式发布越来越好的网络数据过滤子集。

在短期内，我们期待将从 (英语) FineWeb 中学到的应用于其他语言。尽管英语目前在 LLM 领域占主导地位，但我们认为尽可能广泛地提供高质量的其他语言网络数据将具有非常大的影响力。

简而言之：研究大规模和开放环境中创建数据集的科学，前景光明且令人兴奋 🤗。