大型語言模型（LLM）的性能在很大程度上取決于其預訓練數據集的質量和規模。然而，像 Llama 3 和 Mixtral 這樣的前沿開源大語言模型的預訓練數據集并未公開，人們對其創建方式也知之甚少。

最近，我們發布了FineWeb，這是一個全新的大規模（包含 15 萬億詞元，占用 44TB 磁盤空間）大語言模型預訓練數據集。FineWeb 源自 96 個 CommonCrawl 快照，與其他開源預訓練數據集相比，使用它訓練出的大語言模型性能更優。為了讓機器學習領域更加透明，推動人們對如何訓練高質量大語言模型的公開理解，我們詳細記錄并剖析了 FineWeb 中所有的設計選擇，包括對去重和過濾策略的深入研究。這篇長篇報告深入探討了如何創建一個大規模、高質量的適用于大語言模型預訓練的網絡規模數據集。數據集??FineWeb 可在此處獲取。（https://huggingface.co/datasets/HuggingFaceFW/fineweb）

我們非常感謝 distill.pub 團隊（尤其是克里斯托弗?奧拉、尚?卡特、路德維希?舒伯特）創建的模板，這篇博客文章正是基于此模板創作。同時，也感謝他們精心撰寫的文章和博客，為我們帶來了靈感。

在本報告中，我們還介紹了FineWeb-Edu，它是 FineWeb 的一個子集，通過可擴展的自動高質量標注構建，具有教育價值。在多項教育基準測試中，如 MMLU、ARC 和 OpenBookQA，它的表現優于所有可公開獲取的網絡數據集。FineWeb-Edu 有兩種規模 / 過濾級別：1.3 萬億（極高教育內容占比）和 5.4 萬億（高教育內容占比）詞元（tokens）（所有詞元均使用 GPT2 分詞器進行統計）。你可以在此處下載。

這兩個數據集均依據寬松的 ODC-By 1.0 許可協議發布。

簡而言之：本博客討論了大規模數據處理和質量評估、??FineWeb 的構建方法（列出并解釋所有設計選擇），以及創建其??FineWeb-Edu 子集的過程。

（注釋：ODC-By 1.0 許可協議介紹

ODC-By 1.0（Open Data Commons Attribution License v1.0）是一種開放數據許可協議，旨在允許用戶在滿足特定署名要求的前提下，自由分享、修改和使用數據庫。

# 主要內容

1. 許可范圍：

   - 分享：允許用戶復制、分發和使用數據庫。

   - 創作：允許用戶基于數據庫生成作品。

   - 改編：允許用戶修改、轉換和基于數據庫進行進一步開發。

2. 署名要求：

   - 用戶在公開使用數據庫或基于數據庫生成的作品時，必須按照許可協議指定的方式進行署名。

   - 在使用或重新分發數據庫時，必須明確說明數據庫的許可協議，并保留原始數據庫中的所有相關通知。

3. 法律效力：

   - ODC-By 1.0 是一種版權和數據庫權利的許可協議，同時也是一份合同。

   - 它涵蓋了數據庫的版權和數據庫權利，但不包括數據庫中個別內容的版權。

4. 權利保留：

   - 許可方保留了在某些情況下收取版稅的權利（例如在某些司法管轄區的強制許可方案下）。

   - 許可方也可以選擇在其他條件下停止分發或提供數據庫。

5. 適用范圍：

   - 該許可協議適用于數據庫的整體權利，而不是數據庫中個別內容的權利。

   - 數據庫中的個別內容可能受到其他權利（如版權、專利、隱私權等）的保護，這些權利不在 ODC-By 1.0 的覆蓋范圍內。

6. 再許可：

   - 用戶不能對數據庫進行再許可。

   - 每次用戶將數據庫或其衍生作品傳遞給第三方時，許可方會自動以相同的條款向第三方提供許可。

# 如何應用 ODC-By 1.0

- 在所有相關位置顯著聲明：“This {DATA(BASE)-NAME} is made available under the Open Data Commons Attribution License: http://opendatacommons.org/licenses/by/1.0/”，并替換 `{DATA(BASE)-NAME}` 為數據庫的名稱。

- 如果無法使用超鏈接，需在聲明中包含許可協議文本的 URI。

# 注意事項

- 法律咨詢：在使用 ODC-By 1.0 許可協議之前，建議咨詢法律專業人士。

- 其他權利：數據庫或其內容可能受到其他法律權利（如商標、隱私權等）的約束，用戶需自行確認。

ODC-By 1.0 許可協議為開放數據的共享和使用提供了明確的法律框架，同時要求用戶在使用數據時必須進行適當的署名。）

1.網絡數據

1.1尋找原始數據

在訓練大語言模型時，關于網絡數據集經常會有人問到一個問題：“他們究竟從哪里獲取這么多數據？” 通常有兩種途徑：

• 自行爬取數據，像 OpenAI 或 Anthropic 等公司（以及其他公司）就是這么做的（詳見此處和此處 ）。
• 使用公共的網頁爬取資源庫，比如由非營利組織 CommonCrawl 維護的資源庫。

為了構建FineWeb，我們參照許多大語言模型訓練團隊以往的做法，以 CommonCrawl（CC）作為起點。非營利組織 CommonCrawl 自 2007 年起就開始爬取網頁，通常每隔 1 到 2 個月就會發布一次新的爬取數據，其中包含通過自動網頁爬取獲取的 200 到 400TiB 文本內容。

例如，最新的 CC 爬取數據（2024 年 4 月）包含 27 億個網頁，未壓縮的 HTML 文本內容總計 386TiB（請注意，每次爬取的數據規模會有所變化。在本報告中，“轉儲” 和 “爬取數據” 這兩個術語可互換使用）。自 2013 年以來，已發布了 96 次爬取數據，2008 年至 2012 年期間還有 3 次爬取數據，但格式不同（更舊），我們并未處理這 3 次較舊的爬取數據。

1.2大規模處理

鑒于涉及的數據量巨大，我們必須克服的主要挑戰之一是擁有一個模塊化、可擴展的代碼庫。這一代碼庫要能讓我們快速迭代處理決策，輕松嘗試新想法，同時合理地并行處理工作負載，并能清晰洞察數據情況。

為此，我們開發了datatrove（https://github.com/huggingface/datatrove），這是一個開源數據處理庫，它使我們能夠將過濾和去重設置無縫擴展到數千個 CPU 核心。創建FineWeb 所涉及的所有數據處理步驟都使用了這個庫。你可以在datatrove代碼庫中找到我們使用的具體腳本。

1.3什么是優質數據？

在創建數據集時，這可能是最需要牢記的問題。在大多數情況下，尤其是在大語言模型預訓練的背景下（請注意，本報告聚焦于用于預訓練大語言模型的網絡規模數據集這一特定領域，“網絡規模” 通常指從網絡獲取的超過 1000 億詞元的數據。這里的預訓練指的是模型訓練的第一步，從隨機權重開始。我們并不涵蓋其他數據集創建領域，也不認為本文中提出的經驗或假設能擴展到該特定領域之外的其他領域），“高質量” 并不是一個定義明確的術語，甚至不是僅通過直接人工觀察就能清晰感知的文檔屬性。

常見的做法是在一個被認為 “干凈” 的語料庫（通常是維基百科，盡管如上文所述，“干凈” 的概念定義模糊，不應簡單等同于維基百科類文本）上訓練模型，然后用它來檢查我們試圖整理的數據集的困惑度。遺憾的是，這并不總能與在一組感興趣的下游任務上的性能提升相關聯。因此，另一種常用方法是訓練小模型（相較于如今標準規模的大語言模型而言 “小”，即與 70 億至 700 億參數的模型相比規模較小。在本研究中，“小” 指的是約 10 億至 20 億參數），在我們數據集的一個代表性子集上進行訓練，并在一組評估任務上對其進行評估。使用小模型是因為訓練成本和時間與模型規模相關。在第二種方法中，選擇一組多樣化且具有代表性的數據集評估任務非常重要，并且要盡量避免過度擬合任何一個單獨的基準測試，因為這可能會損害預訓練后得到的大語言模型的通用性。

還有一種比較不同數據集的方法，是在每個數據集上訓練一個模型，然后讓人工對模型生成的內容進行評分和比較（就像在 LMSYS 聊天機器人競技場中那樣）。可以說，從代表模型實際使用情況的角度來看，這種方法能提供最可靠的結果。但遺憾的是，通過這種方式獲得消融實驗結果成本高昂且耗時。而且，這種方法通常要求模型經過指令微調階段以獲得對話能力，因為預訓練模型并非直接為遵循指令而設計，因此對提示細節更為敏感。

在本研究中，我們采用訓練小模型并在一組 “早期信號” 基準測試任務上進行評估的方法。我們認為，在牢記上述關于評估基準測試過度擬合的注意事項的情況下，這是衡量用于訓練這些模型的數據質量的合理替代方法。

（關于數據集的困惑度（Perplexity）。是一個用于評估語言模型性能的重要指標，它反映了模型對數據集的預測能力和理解程度。

# 定義與計算

- 困惑度通常被定義為在給定數據集上，語言模型預測下一個單詞或符號的平均不確定性的指數。在數學上，對于一個具有 \(n\) 個單詞的數據集 \(W = w_1, w_2, \cdots, w_n\)，語言模型 \(P\) 的困惑度 \(PP\) 計算公式為：\(PP = 2^{H(W)}\)，其中 \(H(W)\) 是數據集 \(W\) 的信息熵。信息熵 \(H(W)\) 的計算公式為 \(H(W)=-\frac{1}{n}\sum_{i = 1}^{n}\log_2 P(w_i|w_1, w_2, \cdots, w_{i - 1})\)。直觀地說，模型對每個單詞的預測概率越高，困惑度就越低，表明模型對數據集的擬合程度越好。

# 意義與作用

- 評估模型性能：困惑度是衡量語言模型在給定數據集上表現的關鍵指標。較低的困惑度表示模型能夠更好地理解數據集中的語言模式和規律，從而更準確地預測未知數據。例如，在訓練一個文本生成模型時，通過比較不同模型在相同驗證數據集上的困惑度，可以選擇出性能最優的模型。

- 比較不同數據集：困惑度也可用于比較不同數據集對于特定模型的難度。如果一個模型在數據集 \(A\) 上的困惑度明顯高于在數據集 \(B\) 上的困惑度，說明該模型在處理數據集 \(A\) 時面臨更大的挑戰，可能是因為數據集 \(A\) 的語言結構更復雜、主題更廣泛或者數據質量更低等原因。

- 監控訓練過程：在模型訓練過程中，困惑度是一個重要的監控指標。隨著訓練的進行，模型的困惑度通常會逐漸降低，如果困惑度在訓練過程中出現異常波動或不再下降，可能意味著模型出現了過擬合、欠擬合或者訓練參數設置不當等問題，需要及時調整訓練策略。

# 局限性

- 依賴數據質量：困惑度的計算完全依賴于給定的數據集，如果數據集中存在錯誤、噪聲或者標注不一致等問題，會影響模型對數據的學習和預測，進而導致困惑度不能準確反映模型的真實性能。

- 單一維度評估：困惑度只是從預測概率的角度來評估模型性能，它不能全面反映模型在語義理解、邏輯推理、上下文連貫性等其他重要方面的表現。例如，兩個具有相同困惑度的模型，在生成文本的質量和可讀性上可能存在很大差異。

- 缺乏絕對標準：困惑度的值沒有絕對的好壞標準，不同的數據集和任務可能有不同的合理范圍。在一個數據集上被認為是低困惑度的值，在另一個數據集上可能就不是很理想，因此需要結合具體的應用場景和對比實驗來評估模型的性能。）

（關于如何評價數據集的質量？這里提到的幾種方法：

1. 第一種方法：一般來說，人們常選像維基百科這種大家覺得“干凈”的語料庫（不過“干凈”沒有特別精準的定義，不能只認為是維基百科那種文本）來訓練模型。然后用訓練好的模型去檢查要整理的數據集的困惑度（可以理解為數據集的復雜程度或讓模型難以理解的程度）。但可惜的是，檢查出來的困惑度和模型在一些人們感興趣的下游任務（比如后續實際應用中的任務）上的表現提升沒有必然聯系。

2. 第二種方法：另一種常用的辦法是訓練小模型（這里的“小”是相對于現在標準的大語言模型來說的，標準大語言模型有70億到700億參數，小模型大概是10億到20億參數）。在要處理的數據集中選取有代表性的一部分來訓練小模型，再在一系列評估任務上對小模型進行測試。用小模型是因為模型規模越小，訓練需要的成本和時間就越少。在這種方法里，選的評估任務要多樣且能代表數據集的特點，還要避免模型對某個單獨的基準測試過度適應（就是模型只在這個測試上表現好，在其他任務上不行），因為這樣會影響預訓練后大語言模型在各種實際應用中的通用性（就是模型在不同任務和場景下的適應能力）。

3. 第三種方法：還有一種比較不同數據集的方式，就是在每個數據集上都訓練一個模型，然后讓人對這些模型生成的內容進行打分和比較（就像在 LMSYS 聊天機器人競技場里那樣）。從反映模型實際使用情況的角度來看，這種方法得出的結果最可靠。但不好的地方是，通過這種方式做消融實驗（就是分析每個因素對模型性能的影響）成本很高，而且很費時間。并且這種方法通常需要先對模型進行指令微調（就是讓模型學會按照人的指令工作），因為預訓練的模型不是直接為了按指令行動而設計的，所以對提示（就是給模型的輸入信息）的細節很敏感，不微調的話可能表現不好 。 ）

1.4消融實驗和評估設置

為了比較某個特定處理步驟的影響，我們在數據集的兩個版本上訓練兩個模型，一個版本經過額外處理步驟（即我們想要評估的步驟），另一個版本則去除了該步驟（即該步驟被消融 / 刪除）。除了數據不同，這兩個模型的其他方面完全相同：參數數量、架構超參數都相同，并且在每個版本的數據中隨機抽取相同數量的詞元進行單輪訓練，唯一的區別就在于訓練數據。然后，我們在相同的任務集上評估每個模型，并比較平均得分。

我們的消融模型使用nanotron進行訓練。我們的 “消融模型” 有 18.2 億個參數（包括嵌入層），采用 Llama 架構，序列長度為 2048，全局批量大小約為 200 萬個詞元，并使用 GPT2 分詞器。對于大多數消融實驗，我們在約 280 億個詞元上進行訓練（對于這個模型規模，大致符合 Chinchilla 最優訓練規模）。為了確認每次過濾步驟后相對性能的提升，我們如后文所述，在 3500 億個詞元上進行了更長時間的訓練。

（關于Nanotron。 Nanotron是一個用于預訓練 Transformer 模型的庫。它提供了一個簡單且靈活的 API，用于在自定義數據集上預訓練模型。Nanotron 的設計宗旨是易于使用、快速且可擴展。它基于以下原則構建：

- 簡單性：Nanotron 被設計為易于使用。它提供了一個簡單且靈活的 API，用于在自定義數據集上預訓練模型。

- 性能：針對速度和可擴展性進行了優化，Nanotron 使用最新技術以更快、更高效的方式訓練模型。）

我們很快會在 Nanotron 中提供重現這些消融模型的配置。

我們使用lighteval對模型進行評估。我們通過選擇能在相對較小規模（“小” 模型僅在 “幾十億” 詞元上進行訓練）下提供良好信號的基準測試，精心挑選了一組用于消融實驗的基準測試。在lighteval中所有可用的基準測試中，我們通常使用以下標準來選擇這些基準測試：

（關于Lighteval。Lighteval 是用于在多個后端（無論是 Transformers、TGI、VLLM 還是 Nanotron）輕松評估大型語言模型（LLMs）的全能工具包。通過保存和探索詳細到每個樣本的結果，深入了解模型的性能，以便調試并比較不同模型的表現。

-定制化觸手可及：您可以瀏覽我們現有的所有任務和指標，也可以輕松創建適合您需求的自定義任務和自定義指標。

-無縫地在 Hugging Face Hub、S3 或本地進行實驗、基準測試和存儲結果。）

• 同一數據集不同采樣訓練運行之間的方差較小：我們希望在數據子集上的運行能夠代表整個數據集，并且在可能的情況下，得到的分數對具體數據點選擇的敏感度低于對我們過濾器效果的敏感度。當我們在一個數據集的不同子集（采樣）上進行訓練時，我們希望這些訓練運行的結果能夠代表整個數據集。也就是說，我們期望從這些子集訓練得到的結果分數，在盡可能的情況下，對具體的數據點選擇的敏感度較低，而更多地體現出我們所使用的過濾器（數據篩選、處理方式等）的效果。例如，如果方差大，可能意味著結果受數據點選擇影響大，而不是真正反映過濾器的作用；方差小則說明結果更穩定，更能代表數據集整體特征以及過濾器效果。
• 性能在訓練過程中單調（或接近單調）提升：理想情況下，隨著所見詞元數量的增加，在高信號基準測試上的性能不應下降（否則表明小規模下的結果不可靠）。在理想情況下，隨著模型在訓練過程中所處理的token數量增加，在高信號基準測試（可以理解為有明確衡量標準且能反映模型能力的測試）上的性能不應下降。如果性能下降，那就表明在小規模訓練下得到的結果可能不可靠。比如在語言模型訓練中，隨著訓練的進行和看到的文本量增多，模型在相關任務（如文本生成、回答問題等）上的表現應該越來越好或者至少保持穩定，而不是變差，否則就說明訓練過程或模型本身可能存在問題。
• 任務性能至少比隨機基線高出幾個標準差：鑒于我們的小消融模型和訓練情況，我們通常在任何基準測試中都無法獲得極高的分數，但我們要確保得到的分數高于隨機噪聲。由于我們使用的是小規模的消融模型以及進行的訓練，通常我們在任何基準測試中都不會得到極高的分數。但是，我們必須確保得到的分數要明顯高于隨機噪聲水平。也就是說，模型的表現不能只是偶然地和隨機猜測差不多，而應該有足夠的能力，其分數要與隨機結果有顯著差異，這樣才能說明模型確實學到了東西，而不是靠運氣得到的結果。

經過考慮，我們選擇了以下基準測試列表：

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

為確保檢查點評估在有限時間內完成，我們將較長的基準測試限制在 1000 個樣本（在 8 個 GPU 的單個節點上進行的實際評估時間不超過 5 分鐘，與訓練并行進行）。

2 FineWeb 構建方法

在接下來的小節中，我們將解釋生成 FineWeb 數據集所采取的每一個步驟。

你可以在此處找到一個完全可重現的datatrove配置。

（FineWeb 數據處理流水線：

1. URL Filtering（網址過濾）：對輸入的網址進行篩選，排除掉不符合要求的網址，比如惡意網站、無關網站等 ，只保留合適來源的網址。

2. Text Extraction（文本提取）：從篩選后的網址所對應的網頁中提取文本內容，將網頁中的文字信息抽取出來，以便后續處理。 

3. Language Filtering（語言過濾）：對提取的文本進行語言甄別，篩選出指定語言（通常是目標訓練語言 ）的文本，過濾掉其他語言文本。

4. Gopher Filtering（Gopher過濾）：使用Gopher相關技術或規則進一步過濾文本，Gopher 可能是一種特定的過濾算法或工具，去除不符合特定標準的文本。 

5. MinHash dedup（最小哈希去重）：利用MinHash算法對文本進行去重處理，找出重復或高度相似的文本并去除，只保留獨特的文本內容。

6. C4 Filters（C4過濾器）：采用C4相關的過濾規則或方法對文本過濾，C4可能是一種預定義的數據集或過濾標準，進一步精煉文本數據。 

7. Custom Filters（自定義過濾器）：根據特定需求設置的自定義過濾規則，對文本進行個性化篩選，去除或保留符合特定條件的文本。 

8. PII Removal（個人身份信息去除）：識別并去除文本中包含的個人身份信息，如姓名、身份證號、聯系方式等，保護隱私。 ）

2.1起點：文本提取

CommonCrawl 數據主要有兩種格式：WARC 和 WET。WARC（網絡歸檔格式）文件包含爬取的原始數據，包括完整的頁面 HTML 和請求元數據。WET（WARC 封裝文本）文件則提供這些網站的純文本版本。

許多數據集都以 WET 文件為起點。但根據我們的經驗，Common Crawl 用于創建這些 WET 文件的默認文本提取方法，對于大語言模型預訓練的目標來說并不理想（我們尤其懷疑它保留了過多的樣板內容和導航菜單），有多種開源庫能提供更好的文本提取功能。我們使用 trafilatura 庫從 WARC 文件中提取文本內容，通過對結果的直觀檢查，與其他庫相比，它能提供高質量的提取效果。

你可以在此處找到一個比較幾種文本提取庫的基準測試。

為了驗證這一決策，我們直接使用 WET 文件處理 2019 - 18 轉儲數據，并使用 trafilatura 從 WARC 文件中提取文本（我們使用 trafilatura 的默認選項，并設置favour_precisinotallow=True）。我們對這兩種數據應用相同的處理（我們的基礎過濾 + 最小哈希，詳見下文），并訓練了兩個模型。雖然 WET 數據生成的數據集規模要大 25% 左右（約 2540 億個詞元），但事實證明，其質量遠不如使用 trafilatura 從 WARC 文件中提取文本生成的數據集（約 2000 億個詞元）。對一些樣本的直觀檢查證實，WET 文件中許多額外的詞元都是不必要的頁面樣板內容。

（

- CommonCrawl 數據格式：

  - WARC（Web ARChive）文件：包含爬取的原始數據，包括完整的網頁 HTML 和請求元數據。這種格式保留了網頁的完整結構和內容。

  - WET（WARC Encapsulated Text）文件：是從 WARC 文件中提取的純文本版本，主要用于簡化數據處理。它去掉了 HTML 標簽，只保留了文本內容。

# 問題

- 默認情況下，CommonCrawl 使用的文本提取方法生成 WET 文件時，可能會保留過多的“樣板內容”（如導航菜單、頁腳等），這些內容對于大語言模型的預訓練并不理想。因為這些內容通常是重復的、無關的，可能會干擾模型學習有用的語義信息。

# 解決方案

- 使用 Trafilatura 庫：

  - Trafilatura 是一個開源的文本提取庫，專門用于從 HTML 中提取高質量的文本內容。

  - 在實驗中，使用 Trafilatura 從 WARC 文件中提取文本，并設置參數 `favour_precisinotallow=True`，以優先保證提取的文本質量。

# 實驗設計

- 數據處理：

  - 使用 WET 文件直接處理 2019 - 18 轉儲數據。

  - 同時，使用 Trafilatura 從 WARC 文件中提取文本。

  - 對這兩種數據應用相同的處理流程，包括基礎過濾和最小哈希（MinHash）算法。

# 實驗結果

- 數據規模：

  - WET 數據生成的數據集規模更大，約 2540 億個詞元，比 Trafilatura 提取的數據集多出 25% 左右。

  - Trafilatura 提取的數據集規模約為 2000 億個詞元。

- 數據質量：

  - 盡管 WET 數據集規模更大，但其質量遠不如 Trafilatura 提取的數據集。

  - 通過對樣本的直觀檢查，發現 WET 文件中許多額外的詞元都是不必要的頁面樣板內容，這些內容對于模型訓練并無太大幫助。

# 結論

- 使用 Trafilatura 從 WARC 文件中提取文本，能夠生成更高質量的數據集，更適合用于大語言模型的預訓練。

- 即使 WET 數據集規模更大，但由于其中包含大量無關的樣板內容，其實際效用不如 Trafilatura 提取的數據集。

核心觀點是：在處理 CommonCrawl 數據時，使用 Trafilatura 庫從 WARC 文件中提取文本，比直接使用 WET 文件能夠生成更高質量的數據集，更適合用于大語言模型的預訓練。）

不過需要注意的是，文本提取是我們處理過程中成本最高的步驟之一，所以我們認為對于預算較低的團隊而言，使用現成的 WET 數據可能是一個合理的權衡。

aggregate score（綜合得分）應該是 CommonSense QA、HellaSwag、OpenBook QA、PIQA、SIQA、WinoGrande、ARC、MMLU 等）上的得分進行匯總計算。

2.2基礎過濾

過濾是數據集整理過程中的重要一環。它旨在去除部分會降低模型性能的數據（無論是單詞、行，甚至是整個文檔），在我們基于評估驅動的數據集構建過程中，這些數據被認為是 “質量較低” 的。

我們以 RefinedWeb 的部分設置作為過濾基礎，具體如下：

• 使用阻止列表進行 URL 過濾，去除成人內容。
• 應用 fastText 語言分類器，僅保留得分≥0.65 的英文文本。
• 應用 MassiveText 的質量和重復過濾器（使用默認閾值）。

對每個提取文本后的轉儲數據（目前有 96 個轉儲數據）應用此過濾后，我們大約得到了 36 萬億個詞元的數據（本報告中所有數據的詞元數量均使用gpt2分詞器統計）。

（# 1. 應用 fastText 語言分類器，僅保留得分≥0.65 的英文文本

- fastText 語言分類器：

  - fastText 是一種開源的文本分類和詞向量生成工具，由 Facebook AI Research 開發。

  - 在語言分類任務中，fastText 可以通過訓練好的模型來判斷文本所屬的語言，并為每個判斷結果分配一個置信度分數（通常是一個介于 0 到 1 之間的數值）。

  - 置信度分數越高，表示模型對文本屬于某種語言的判斷越有信心。

- 操作步驟：

  - 對每一段文本，使用 fastText 的語言分類器進行檢測。

  - fastText 會返回一個語言標簽（如 `en` 表示英文）以及一個置信度分數。

  - 如果置信度分數 ≥0.65，則認為該文本是英文，并保留這段文本；否則，丟棄這段文本。

- 目的：

  - 這一步的目的是確保數據集中只包含高質量的英文文本，排除其他語言的干擾。

  - 置信度閾值 0.65 是一個經驗值，用于平衡語言識別的準確性和召回率。較高的閾值（如 0.65）可以減少誤判，但可能會漏掉一些邊緣情況的英文文本。

# 2. 應用 MassiveText 的質量和重復過濾器（使用默認閾值）

- MassiveText：

  - MassiveText 是一個用于大規模文本數據處理的工具，通常用于數據清洗、去噪和去重等任務。

  - 它可以檢測文本的質量（如是否包含噪聲、是否是高質量的自然語言文本）以及文本的重復性（是否與其他文本高度相似）。

- 操作步驟：

  - 使用 MassiveText 的過濾器對文本數據進行處理。

  - MassiveText 會根據其內部算法和默認閾值，對每段文本進行質量評估和重復檢測。

  - 如果文本通過了質量過濾器（即被認為是高質量的文本）且未被標記為重復，則保留這段文本；否則，丟棄這段文本。

- 默認閾值：

  - MassiveText 的過濾器通常會有一些預設的閾值，用于判斷文本的質量和重復性。

  - 使用默認閾值意味著直接采用工具推薦的設置，而沒有手動調整這些閾值。

  - 默認閾值通常是經過優化的，適用于大多數場景，但也可以根據具體需求進行調整。

- 目的：

  - 質量過濾：去除低質量的文本（如包含大量噪聲、格式錯誤或非自然語言內容的文本），以提高數據集的整體質量。

  - 重復過濾：去除高度重復的文本，以避免數據集中的冗余，提高數據的多樣性和訓練效率。

# 總結

1. 使用 fastText 語言分類器，僅保留置信度≥0.65 的英文文本，以確保數據集中只包含高質量的英文內容。

2. 使用 MassiveText 的質量和重復過濾器（采用默認閾值），進一步提升數據的質量和多樣性，去除低質量或重復的文本。

通過這兩個步驟，可以顯著提高數據集的質量，為后續的模型訓練提供更可靠的數據基礎。）

2.3數據去重

去重是為大語言模型預訓練創建大型網絡數據集時最重要的步驟之一。數據集去重方法旨在識別并去除數據集中的冗余 / 重復數據。

2.3.1為什么要去重？

網絡上存在許多聚合網站、鏡像網站、模板化頁面，或者只是在不同域名和網頁上重復出現的內容。有時，爬蟲本身也可能引入這些重復頁面，比如不同鏈接指向同一頁面的情況。

去除這些重復內容（去重）與模型性能的提升以及預訓練數據記憶問題的減少相關，這可能有助于提高模型的泛化能力。此外，通過去重獲得的性能提升等同于訓練效率的提高：通過去除重復內容，模型可以用更少的訓練迭代次數達到相同的性能水平；或者說，對于給定數量的訓練詞元，模型能夠接觸到更多樣化的數據。

識別甚至定義重復數據的方法有很多。常見方法依賴哈希技術來加快處理速度，或者構建高效的數據結構對數據進行索引（如后綴數組）。去重方法還可以是 “模糊” 的，即使用某種相似度度量將文檔標記為重復，也可以是 “精確” 的，即檢查兩個文檔（或行、段落，或其他任何粒度級別）之間是否完全匹配（請注意，這里即使討論 “模糊” 去重，我們也僅采用基于字符 / 單詞匹配的方法，也就是文本表面層面的方法。更復雜的去重概念涉及 “語義” 去重：比較 / 去除與相同概念相關的文本，例如使用同義詞或釋義。我們在此不討論這些內容，但需要注意的是，它們在大規模合成數據生成領域可能很重要，例如可參考我們關于 Cosmopedia 的發布內容）。

2.3.2我們的去重參數

參照 RefinedWeb，我們決定應用 MinHash，這是一種基于模糊哈希的去重技術，可高效擴展到多個 CPU 節點，并且允許我們調整相似度閾值（通過控制桶的數量和大小）以及所考慮的子序列長度（通過控制 n - gram 大小）。我們選擇收集每個文檔的 5 - gram（在 MinHash 處理函數中，我們的單位是 “單詞”，使用特定語言的單詞分詞器進行計算），并總共使用 112 個哈希函數計算最小哈希值，將這些哈希函數分為 14 個桶，每個桶包含 8 個哈希函數，目標是識別相似度至少為 75% 的文檔。任何一個桶中具有相同 8 個最小哈希值的文檔都被視為彼此重復。

這意味著，對于相似度（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 中大量的哈希函數能實現更陡峭、更明確的截斷（實際相似度接近閾值的文檔更有可能被正確識別），但我們認為在計算和存儲方面的節省是一個合理的權衡。

還需要注意的是，文檔內去重已由我們的重復過濾器處理，該過濾器會去除包含大量重復行和段落的文檔。

（關于MinHash

 1. MinHash核心機制

   - 模糊哈希：與精確哈希不同，MinHash允許通過比較哈希值來估算兩個文檔的相似度（Jaccard相似度）。即使文檔存在局部差異，只要整體內容相似，仍能被識別為重復。

   - 擴展性：算法設計支持分布式計算，可在多個CPU節點上并行處理海量數據（如FineWeb處理的96個CommonCrawl轉儲）。

 2. 關鍵參數配置

   - n-gram大小（5-gram）：

     - 將文檔按單詞分割為長度為5的連續子序列（例如，"the quick brown fox jumps" → ["the quick brown fox jumps", "quick brown fox jumps over", ...]）。

     - 以單詞為單位而非字符，更適合捕獲語義層面的重復內容。

   - 哈希函數數量（112個）：

     - 每個5-gram通過112個不同的哈希函數計算哈希值，生成文檔的"簽名"（signature）。

     - 哈希函數數量越多，相似度估計越精確，但計算成本也越高。

   - 分桶策略（14個桶，每桶8個哈希函數）：

     - 將112個哈希值平均分配到14個桶中，每個桶包含8個哈希值。

     - 若兩個文檔在任意一個桶中的所有8個哈希值都相同，則判定為相似文檔。

  3. 實際效果

   - 識別能力：

     - 相似度≥85%的文檔幾乎100%被識別（概率≈98.8%）。

     - 相似度為70%的文檔約有56%的概率被識別。

   - 與RefinedWeb對比：

     - RefinedWeb使用更激進的參數（450個桶，每桶20個哈希函數），能實現更精確的截斷（如相似度75%時識別概率接近100%），但計算成本極高。

     - FineWeb通過減少桶數和哈希函數，在保持較高識別率的同時，大幅降低了計算和存儲開銷。

 4. 為什么這樣設計？

   - 平衡效率與質量：在處理96個CommonCrawl轉儲（總計36萬億詞元）時，若采用RefinedWeb的參數，計算資源消耗將不可接受。

   - 避免過度去重：實驗表明，對跨轉儲數據進行全局去重可能導致低質量數據被保留（如2013年轉儲中94%的數據被誤刪），而按轉儲獨立去重效果更佳。

   - 可擴展性需求：算法需支持在數千個CPU核心上并行運行，參數選擇需適應分布式計算框架。）

2.3.3去重越多越好，對吧？

最初，我們認為去重越多越好，所以我們的第一種方法是將整個數據集（所有 90 多個轉儲數據）整合在一起，使用 MinHash 進行去重。

我們以迭代的方式進行：從最新的轉儲數據（當時是 2023 - 50）開始，按時間順序處理，直到最舊的爬取數據。我們不僅對每個轉儲數據內部進行去重，還會去除與之前處理過的轉儲數據中任何匹配的文檔。

例如，對于當時第二新的轉儲數據（2023 - 40），我們除了對其內部進行去重外，還會與最新的轉儲數據進行去重對比。結果是，轉儲數據越舊，與之對比去重的轉儲數據數量就越多，從中去除的數據也就越多（實際上，在最舊的轉儲數據中，去重步驟去除了基礎過濾數據的 90% 以上）。

以這種方式對數據集進行去重后得到 4 萬億個詞元的數據。但令我們驚訝的是，在對隨機抽取的 3500 億個詞元的子集進行訓練時，我們的消融模型與在未去重數據上訓練的模型相比，幾乎沒有性能提升，在我們的綜合任務評估中，得分遠低于其前身 RefinedWeb（見下圖）。

這挑戰了我們 “去重越多必然導致基準測試得分越高” 的假設，所以我們決定更深入地研究最舊的轉儲數據之一 ——2013 - 48 轉儲數據：

• 在去重前，這個轉儲數據約有 4900 億個詞元。
• 經過我們的迭代 MinHash 去重后，大約剩下 310 億個詞元（94% 的數據被去除）。

作為一項實驗，我們嘗試在從 2013 - 48 轉儲數據中抽取的 280 億個詞元上訓練兩個模型，這些數據分別來自：

• 完全去重后剩下的約 310 億個詞元（最初保留的數據）。
• 在迭代去重過程中從該轉儲數據中去除的約 4600 億個詞元中，單獨進行去重（不考慮其他轉儲數據）后得到的 1710 億個詞元（最初去除的數據。雖然最初保留的數據中可能存在與最初去除的數據相似的文檔，但我們估計兩者的重疊部分較小，約為 40 億個詞元）。

這些結果表明，單獨來看這個較舊的轉儲數據，保留下來的數據（原始數據的 10%）實際上比去除的 90% 的數據質量更差（請注意，這些消融模型僅在該轉儲數據上進行訓練，因此是獨立于所有其他轉儲數據進行考量的 ）。通過肉眼檢查也證實了這一點：最初保留的數據中包含的廣告、關鍵詞列表以及格式不佳的文本，比最初去除的數據要多得多。

2.3.4退一步思考：單個轉儲數據去重

我們決定嘗試另一種方法：使用 MinHash 對每個轉儲數據單獨進行去重（不考慮其他轉儲數據）。這樣操作后得到了 20 萬億個詞元的數據。

當在該數據集的隨機樣本上進行訓練時，我們發現其性能現在與 RefinedWeb 相當（見下圖）：

我們推測，去重帶來的主要改進在于移除了每個轉儲數據中都存在的非常大的聚類（在 RefinedWeb 的論文中，你可以找到這些聚類的一些示例，每個聚類包含數十萬個文檔 ），而對重復數量較少（少于約 100 個，即轉儲數據的數量）的聚類進一步去重實際上會損害性能：在其他轉儲數據中找不到重復匹配的數據，其質量可能更差，或者更偏離分布（2013 - 48 數據的結果證明了這一點）。

雖然將幾個轉儲數據一起去重可能會看到一些性能提升，但在整個數據集（所有轉儲數據）的規模下，這種低質量數據上采樣帶來的副作用似乎影響更大。

一種可以考慮的可能性是，隨著過濾質量的提高，這種影響可能不會那么明顯，因為過濾可能能夠去除一些低質量數據。我們還嘗試在單獨去重后的轉儲數據基礎上，應用不同的、通常更 “輕量級” 的去重方法。你可以在下文進一步了解相關內容。

2.3.4關于衡量去重效果的說明

鑒于去重的性質，其效果在較小的數據集切片中（例如我們用于過濾消融實驗的 280 億個詞元規模）并不總是很明顯。此外，必須考慮到在對所有 CommonCrawl 轉儲數據進行去重時，存在一些特殊的影響因素，因為有些 URL / 頁面會在不同轉儲數據中被重新爬取。

為了直觀展示訓練詞元數量的變化對衡量去重效果的影響，我們考慮了以下（在重復程度方面非常極端且不切實際，但便于說明 ）的理論場景：

• 有 100 個 CommonCrawl 轉儲數據（大致符合實際數量）。
• 每個轉儲數據都已完美地單獨去重（該轉儲數據中的每個文檔都是唯一的）。
• 每個轉儲數據都是彼此的完美副本（不同轉儲數據間存在最大可能的重復，實際上這是最糟糕的情況 ）。
• 每個轉儲數據包含 2000 億個詞元（總計 20 萬億個詞元，與我們上述單獨去重后的結果規模相同 ）。
• 每個轉儲數據由 1000 個詞元的文檔組成（每個轉儲數據有 2 億個文檔）。

然后，我們模擬從這個包含 20 萬億個詞元的整個數據集中均勻采樣文檔，以獲得 10 億、100 億、350 億和 1 萬億詞元的子集。在下圖中，你可以看到每個文檔的重復頻率。

對于 10 億規模的數據，幾乎所有文檔都是唯一的（重復數量 = 1），盡管在整個數據集中，每個文檔會重復 100 次（每次轉儲出現一次）。在 1000 億規模（占總數據集的 0.5%）時，我們開始看到一些變化，大量文檔會重復兩次，還有一些甚至會重復 4 到 8 次。在 1 萬億規模（占總數據集的 5%）時，大多數文檔會重復多達 8 次，有些文檔甚至會重復多達 16 次。

我們在 3500 億規模的去重數據上進行了性能評估，在這個理論場景下，數據集中很大一部分文檔會重復多達 8 次。這個模擬說明了在去除最大的重復簇后，衡量去重對大語言模型訓練的影響所存在的固有困難。

2.3.5其他（失敗的）全局方法

在我們新發現的方法（獨立對每個轉儲進行去重）的基礎上，我們嘗試通過使用替代的全局（對所有轉儲）去重方法，對獨立進行最小哈希去重的 20 萬億個標記數據進一步去重，以提高性能。我們探索了以下方法：

• URL 去重：我們對每個規范化（小寫）的 URL 僅保留一個文檔（去除了 71.5% 的標記，剩余 5.6 萬億個標記）——FineWeb URL 去重。
• 行去重：

     a.對每個重復行僅保留 1 個（隨機選擇）出現的行（去除了 77.8% 的標記，剩余 4.4 萬億個標記）——FineWeb 行去重。

     b.與上述相同，但僅去除至少有 10 個單詞的重復行，并去除去重后少于 3 個句子的文檔（去除了 85% 的標記，剩余 2.9 萬億個標記）——FineWeb 含最少單詞的行去重。

     c.對每個由 3 個重復行組成的片段僅保留 1 個出現的片段，在查找重復項時，每個數字都視為 0（去除了 80.9% 的標記，剩余 3.7 萬億個標記）——FineWeb 三行去重。

在這些去重數據上訓練的模型性能始終比原始的獨立去重數據差（即使程度不同）。

2.4額外的質量過濾

在這一點上，我們通過基礎過濾和獨立的最小哈希，達到了之前我們試圖重現和擴展的研究（RefinedWeb）的性能。盡管如此，在我們的任務集合中，另一個經過大量過濾的數據集，即 C4 數據集，在我們評估套件的一些基準測試中仍然表現出更強的性能。

因此，我們著手尋找新的過濾步驟，首先使我們能夠達到 C4 數據集的性能，然后在第二階段超越它。一個自然的起點是研究 C4 數據集本身的處理方式。

2.4.1 C4：一個經受住時間考驗的數據集

C4 數據集于 2019 年首次發布。它是從 2019-18 年的 CommonCrawl 轉儲中獲取的，通過去除非英語數據、在線和文檔級別應用一些啟發式過濾器、在行級別進行去重，以及去除包含單詞黑名單中單詞的文檔。

盡管按照當前標準，它年代較久且規模有限（大約 1750 億個 GPT2 標記），但直到今天，這個數據集仍然是典型大語言模型訓練的常用子集，被用于如相對較新的 Llama1 等模型中。這種成功歸因于在這個數據集上訓練的模型所表現出的強大性能，特別是在 Hellaswag 基準測試中表現出色，這是我們 “早期信號” 組中具有最高信噪比的基準測試之一。我們嘗試將 C4 中使用的每個不同過濾器應用于獨立去重的 FineWeb 2019-18 轉儲的基線：

• “所有過濾器”（去除不以標點符號結尾的行，提及 JavaScript 和 cookie 通知 + 去除長度閾值之外的文檔，包含 “lorem ipsum” 或大括號 {} 的文檔）使我們能夠達到 C4 在 HellaSwag 上的性能（分別為 “所有過濾器” 和 “C4” 的曲線）。（比如刪掉結尾沒有標點的句子，去掉提到JavaScript和cookie通知的內容，把長度不符合要求的文檔，還有包含“lorem ipsum”（常用于排版設計的虛擬文本）或大括號“{}”的文檔都去除掉。）
• 大括號過濾器和單詞長度過濾器只帶來了很小的提升，分別去除了 2.8% 和 4.3% 的標記。
• 終端標點過濾器本身帶來了最大的單個提升，但去除了大約 30% 的所有標記（！）。
• “lorem_ipsum”、JavaScript 和策略規則各自去除的訓練標記不到 0.5%，所以我們沒有單獨在這些過濾器處理后的數據上進行訓練。
• “除了（非常具有破壞性的）終端標點之外的所有過濾器” 的表現優于單獨使用終端標點過濾器，同時總共去除的標記更少（約 7%）。

我們決定應用上述除終端標點過濾器之外的所有 C4 過濾器。我們通過更長時間的運行驗證了這些結果，你可以在下一部分的圖表中找到相關內容。

2.4.2 一種開發啟發式過濾器的統計方法

為了開發新的啟發式過濾器并選擇其閾值，我們設計了一個系統的過程：

1.我們首先收集了非常大量的數據集高級統計信息（超過五十種不同的指標），范圍從常見的文檔級指標（例如行數、平均行 / 單詞長度等）到文檔間重復指標（受 MassiveText 啟發），涵蓋高質量和低質量的網絡數據集。

2.我們選擇了兩個分布（在每個數據集上計算的指標）之間的 Wasserstein 距離較大的指標。

3.我們檢查了這兩個分布的直方圖，并根據經驗選擇了一個閾值，使得低質量數據集在這個指標上更接近高質量數據集。

4.我們通過在參考數據集上使用生成的過濾器（指標 - 閾值對）并運行小規模的消融實驗來驗證其有效性。

由于我們（新的）假設，即全局最小哈希會極大地對最舊轉儲中的低質量數據進行上采樣，我們計算了 2013-48 和 2015-22 爬取數據（兩個較舊的爬取數據）的獨立最小哈希版本和（質量較差的）全局最小哈希版本的指標。然后，我們通過查看每個指標的分布，在宏觀層面上比較了這些統計信息。

鑒于我們在去重方面的發現，我們發現兩種去重方法在大多數指標上存在顯著差異，這也許并不奇怪。例如，行字符重復指標（重復行中的字符數 / 總字符數）從獨立去重（2015-22 年為 0.0053，2013-48 年為 0.0058）到全局去重（2015-22 年為 0.011，2013-48 年為 0.01）大約翻倍，這表明后者的文檔間重復度更高。

按照上述過程處理這些數據集，得到了十七個候選的指標 - 閾值對。在下面的圖片中，你可以看到其中三個直方圖：

作為一個例子，我們檢查了 “以標點符號結尾的行的比例” 的直方圖（見上圖），并觀察到全局最小哈希在大約 0.12 處的文檔密度增加。然后我們用這個閾值進行過濾，發現被去除的數據中短列表的數量較多，或者僅由文檔布局文本（“主頁”、“注冊” 等）組成。

然后，我們通過在 2019-18 年的爬取數據上進行幾個 280 億標記的消融實驗，評估了這十七個新創建的過濾器的有效性。在所有這些運行中，我們確定了三個過濾器（基于上述直方圖的過濾器），它們在綜合得分上顯示出最顯著的改進：

• 去除以標點符號結尾的行的比例 ≤ 0.12 的文檔（去除了 10.14% 的標記）—— 與原始 C4 終端標點過濾器去除的 30% 相比。
• 去除重復行中的字符比例 ≥ 0.1 的文檔（去除了 12.47% 的標記）—— 原始 MassiveText 對此比例的閾值是 ≥ 0.2。
• 去除長度小于 30 個字符的行的比例 ≥ 0.67 的文檔（去除了 3.73% 的標記）。

當同時應用這三個過濾器時，大約 22% 的標記被去除。

這些過濾器使我們能夠進一步提升性能，并顯著超越了C4數據集的表現，同時提供了規模大得多的數據集。

2.5最終的FineWeb 數據集

最終的FineWeb 數據集包含 15 萬億個標記，并按順序包括以下前面提到的步驟，每個步驟都在我們的基準任務組上提供了性能提升：

1.基礎過濾。

2.對每個轉儲進行獨立的最小哈希去重。

3.選擇一些 C4 過濾器。

我們的自定義過濾器（在上一節中提到）。

2.5.1與其他大規模網絡數據集的比較

我們將??FineWeb 與以下通常被認為是最高質量的公開可用大規模網絡數據集進行了比較（我們還指出了每個數據集公開版本中大約的標記數量）：

• RefinedWeb（5000 億標記）
• C4（1720 億標記）
• Dolma v1.6（3 萬億標記）（CommonCrawl 部分）
• The Pile（3400 億標記）
• SlimPajama（6270 億標記）
• RedPajama2（20 萬億標記）（已去重）
• 我們新的FineWeb（15 萬億標記）（本報告中）

你會發現 3500 億標記訓練的消融模型是公開可用的，并收集在這個集合中。我們已經上傳了每 1000 個訓練步驟的檢查點。你也可以在這里找到我們的完整評估結果。

FineWeb 因此 —— 據我們所知 —— 是公開數據集，它在允許在數萬億個標記上進行訓練的同時，帶來了當前最高的模型性能。

3 FineWeb-Edu

FineWeb-Edu 在我們的評估任務組上優于 FineWeb 和所有其他公開的網絡數據集。

FineWeb-Edu 是 FineWeb 的一個額外開發成果，我們很高興在這份技術報告中介紹并公開發布。FineWeb-Edu 基于一種最近出現的用于過濾大語言模型訓練數據集的新方法：使用合成數據來開發用于識別教育內容的分類器。這種技術在 Llama 3 和 Phi3 的訓練中得到了顯著應用，但在我們看來，其對網絡數據過濾的大規模影響尚未得到充分的公開探索。

3.1大規模標注教育質量

我們使用 Llama-3-70B-Instruct 對??FineWeb 中的 50 萬個樣本進行了標注，對每個樣本的教育質量在 0 到 5 的范圍內進行評分。

我們探索了各種提示格式，以使用大語言模型自動提取教育分數，并發現 Yuan 等人的加法量表效果最好。這個量表允許大語言模型對每個額外的分數進行推理，這與將樣本歸入預定義類別的單等級李克特量表不同。然后，為了避免大語言模型偏向高度技術性的頁面，如 arXiv 摘要和提交內容，我們專注于小學和中學水平的知識。在過濾過程中設置閾值為 3（在 0 到 5 的范圍內），我們能夠保留一些高級教育頁面。

用于大語言模型標注的提示

用于 Llama3 教育分數標注的提示，也可在此處獲得。

在用于標注數據的開放權重模型方面，我們試驗了幾個模型，包括 Mixtral-8x7B-Instruct 和 Mixtral-8x22B-Instruct、Llama-3-70B-Instruct，以及一個匯集這三個模型分數的評審團。在我們的實驗中，我們發現僅使用 Llama3 能給出最可靠的結果。

3.2訓練分類器

為了將我們的標注擴展到 FineWeb 中的數萬億個標記，我們使用 Llama3-70B 的標注來訓練一個小型分類器。我們使用的模型是一個 Snowflake-arctic-embed 嵌入模型，在其頂部有一個帶有單個回歸輸出的分類頭。我們在 45 萬個 Llama 3 標注上訓練這個模型 20 個 epoch，學習率為 3e-4，凍結嵌入層和編碼器層。我們保存了在 4.5 萬個樣本的保留驗證集上具有最高 F1 分數的檢查點，將 Llama 3 的標注視為真實標簽。訓練后，我們將分數四舍五入為 0 到 5 的整數。

然后，我們通過使用固定閾值來確定一個文件是否具有教育性，將問題轉換為二元分類任務。使用閾值為 3 時，該模型在驗證集上的 F1 分數達到了 82%，這表明在區分高質量教育內容方面表現出色。

該分類器可在 HuggingFaceFW/fineweb-edu-classifier 獲取。訓練和推理代碼可在 GitHub 上獲取。

3.3過濾和結果

我們將分類器應用于 FineWeb 的 15 萬億個標記，這個過程需要 6000 個 H100 GPU 小時。我們研究了使用不同過濾閾值的影響，發現使用閾值為 3 時總體效果最佳。盡管使用高于 3 的閾值在知識和推理密集型基準測試上提高了性能，但在 HellaSwag 和 PIQA 基準測試上性能顯著下降。下面的圖表顯示了與 FineWeb 相比，每個閾值在六個不同基準測試上的性能；它使用了一個在 80 億標記上訓練的 18.2 億參數的模型。

注意：這個消融實驗是在 2024-10 轉儲的 80 億標記上對 FineWeb 和 FineWeb-Edu 子集進行的，這可能不能代表整個數據集。下一個消融實驗表明，除了 HellaSwag 基準測試（在該測試中我們注意到性能略有下降）之外，對于來自所有 FineWeb 轉儲的 3500 億標記的更長運行，閾值為 3 的結果仍然成立。

我們通過過濾掉分數低于 3 的樣本構建了 FineWeb-Edu。這去除了 92% 的數據集，留下了 1.3 萬億個教育標記。為了評估這種過濾在更大規模上的有效性，我們使用一個在 3500 億標記上訓練的 18.2 億參數的模型進行了消融實驗，類似于上述的 FineWeb 過濾消融實驗：

Here are the key highlights of the ablation results above:

（1）FineWeb-Edu 在教育基準測試（如 MMLU、ARC 和 OpenBookQA）上超越了 FineWeb 和所有其他公開的網絡數據集。

（2）它在顯著更少的數據量下達到了相同的性能，與 C4 和 Dolma 相比，匹配 MMLU 結果所需的標記數量少 10 倍。

（3）這證明了使用基于大語言模型標注訓練的分類器進行大規模數據過濾的有效性。

鑒于閾值為 2 時也表現出很強的性能，同時保留了更多的數據，我們發布了一個使用該閾值過濾的額外數據集，包含 5.4 萬億個標記，可在 HuggingFaceFW/fineweb-edu-score-2 獲取。

你可以在這個集合中找到這兩個數據集以及用于過濾的分類器。

4 額外內容：隨時間變化的 CommonCrawl

就像優質葡萄酒一樣，并非所有的爬取數據都是一樣的。

在對過濾步驟進行消融時，我們注意到某些爬取數據的表現明顯優于其他數據。我們決定研究這種現象。

4.1按爬取數據的基準性能

對于每個爬取數據，我們在從該爬取數據（在基礎過濾和最小哈希去重步驟之后）中隨機采樣的 270 億個標記上訓練了兩個 18 億參數的模型，每次運行都對這些數據進行不同的 270 億標記的隨機采樣。我們訓練了 192 個這樣的模型，總共花費了超過 6 萬個 H100 GPU 小時。隨后，我們取了兩次運行的最后 3 個檢查點，并繪制了每個爬取數據的這 6 個數據點的平均值。

下面的圖表清楚地顯示，有些轉儲的表現比其他轉儲差得多。每年用不同的顏色表示，每年的爬取次數也不同。

我們研究了這種行為的可能原因，例如每個轉儲中最常見 URL 的變化，以及潛在的基準污染，但沒有找到任何確鑿的解釋。我們將進一步的調查留作未來的工作。

4.2合成數據

我們想知道，最近幾次爬取數據的強大性能部分是否可歸因于大量合成數據（由大語言模型生成的數據）的存在。考慮到最近大語言模型（尤其是 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 的補全內容和其他合成數據提高了最新爬取數據質量的結論，但至少它似乎不會對其造成嚴重損害。

我們預計在新的 CommonCrawl 爬取數據中會繼續看到合成數據數量的增加。然而，雖然對于相對較小規模的訓練，這些數據似乎不會損害性能（甚至可能會提高性能），但對于更大規模的訓練，情況是否如此尚不清楚。

5 結論與展望

通過我們的開放科學努力，我們希望繼續揭示高性能大語言模型訓練這個黑箱，同時讓每個模型訓練者都有能力創建最先進的大語言模型。我們很高興繼續對 FineWeb 進行迭代，并以完全開放和可復現的方式發布質量越來越好的網絡數據過濾子集。

在短期內，我們期待將從（英語）FineWeb 中學到的經驗應用于其他語言。雖然目前英語在大語言模型領域占主導地位，但我們相信，使其他語言的高質量網絡數據盡可能易于獲取將產生巨大影響。

簡而言之，大規模創建開放數據集的科學研究前景光明且令人興奮。

-----------------------------------------

腳注：

（1）請注意，每次爬取的數據規模都會有所不同。還請注意，在本報告中，我們交替使用“轉儲”（dump）和“爬取”（crawl）這兩個詞。

（2）我們尚未處理這3次較舊的爬取數據。

（3）請注意，本報告專注于網絡規模數據集（“網絡規模”通常指從網絡中獲取的超過1000億個詞元）的特定領域，這些數據集用于預訓練大型語言模型（我們所說的“預訓練”是指模型訓練的第一步，從隨機權重開始）。我們并不打算涵蓋數據集創建的其他領域，也不認為我們在本文中提出的觀點或假設可以擴展到除這一特定領域之外的任何其他領域。

（4）盡管如上所述，“干凈”的概念定義如此模糊，以至于它可能不應被視為等同于維基百科類型的文本。

（5）“小”是相對于當今大型語言模型的標準規模而言的，即相對于70億到700億參數而言是小的。在本研究中，“小”指的是大約10億到20億參數。

（6）特別是我們懷疑它保留了過多的樣板內容和導航菜單。

（7）我們使用了 Trafilatura 的默認選項，并設置了 `favour_precisinotallow=True`。

（8）正如在本報告中其他地方提到的：這是使用 GPT-2 分詞器分詞后的詞元數量。

（9）請注意，即使在這里我們討論的是“模糊”去重，我們僅使用基于字符/單詞匹配的方法，也就是表面級文本操作。更復雜的去重概念是“語義”去重：比較并移除那些涉及相同概念的文本，例如使用同義詞或釋義。我們在這里不討論這些主題，但請注意它們在大規模合成數據生成領域可能很重要（例如，參見我們在這一主題上的 Cosmopedia 發布）。

（10）我們的單位是“單詞”，在 MinHash 處理函數中使用特定語言的單詞分詞器計算得出。

（11）盡管原始保留的數據中可能有與原始刪除的數據相似的文檔，但我們估計重疊部分很小（大約40億個詞元）。

（12）請注意，這些消融模型僅在此轉儲的數據上進行訓練，因此被視為獨立于所有其他轉儲。

（13）Dolma 有一個更新的版本，v1.7，它的規模更小。

本文轉載自??AIRoobt?? ，作者：HuggingFace