大型語言模型（LLM）的性能在很大程度上取決于其預(yù)訓(xùn)練數(shù)據(jù)集的質(zhì)量和規(guī)模。然而，像 Llama 3 和 Mixtral 這樣的前沿開源大語言模型的預(yù)訓(xùn)練數(shù)據(jù)集并未公開，人們對其創(chuàng)建方式也知之甚少。

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

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

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

這兩個數(shù)據(jù)集均依據(jù)寬松的 ODC-By 1.0 許可協(xié)議發(fā)布。

簡而言之：本博客討論了大規(guī)模數(shù)據(jù)處理和質(zhì)量評估、??FineWeb 的構(gòu)建方法（列出并解釋所有設(shè)計選擇），以及創(chuàng)建其??FineWeb-Edu 子集的過程。

（注釋：ODC-By 1.0 許可協(xié)議介紹

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

# 主要內(nèi)容

1. 許可范圍：

   - 分享：允許用戶復(fù)制、分發(fā)和使用數(shù)據(jù)庫。

   - 創(chuàng)作：允許用戶基于數(shù)據(jù)庫生成作品。

   - 改編：允許用戶修改、轉(zhuǎn)換和基于數(shù)據(jù)庫進行進一步開發(fā)。

2. 署名要求：

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

   - 在使用或重新分發(fā)數(shù)據(jù)庫時，必須明確說明數(shù)據(jù)庫的許可協(xié)議，并保留原始數(shù)據(jù)庫中的所有相關(guān)通知。

3. 法律效力：

   - ODC-By 1.0 是一種版權(quán)和數(shù)據(jù)庫權(quán)利的許可協(xié)議，同時也是一份合同。

   - 它涵蓋了數(shù)據(jù)庫的版權(quán)和數(shù)據(jù)庫權(quán)利，但不包括數(shù)據(jù)庫中個別內(nèi)容的版權(quán)。

4. 權(quán)利保留：

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

   - 許可方也可以選擇在其他條件下停止分發(fā)或提供數(shù)據(jù)庫。

5. 適用范圍：

   - 該許可協(xié)議適用于數(shù)據(jù)庫的整體權(quán)利，而不是數(shù)據(jù)庫中個別內(nèi)容的權(quán)利。

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

6. 再許可：

   - 用戶不能對數(shù)據(jù)庫進行再許可。

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

# 如何應(yīng)用 ODC-By 1.0

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

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

# 注意事項

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

- 其他權(quán)利：數(shù)據(jù)庫或其內(nèi)容可能受到其他法律權(quán)利（如商標、隱私權(quán)等）的約束，用戶需自行確認。

ODC-By 1.0 許可協(xié)議為開放數(shù)據(jù)的共享和使用提供了明確的法律框架，同時要求用戶在使用數(shù)據(jù)時必須進行適當(dāng)?shù)氖鹈＃?/p>

1.網(wǎng)絡(luò)數(shù)據(jù)

1.1尋找原始數(shù)據(jù)

在訓(xùn)練大語言模型時，關(guān)于網(wǎng)絡(luò)數(shù)據(jù)集經(jīng)常會有人問到一個問題：“他們究竟從哪里獲取這么多數(shù)據(jù)？” 通常有兩種途徑：

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

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

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

1.2大規(guī)模處理

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

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

1.3什么是優(yōu)質(zhì)數(shù)據(jù)？

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

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

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

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

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

# 定義與計算

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

# 意義與作用

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

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

- 監(jiān)控訓(xùn)練過程：在模型訓(xùn)練過程中，困惑度是一個重要的監(jiān)控指標。隨著訓(xùn)練的進行，模型的困惑度通常會逐漸降低，如果困惑度在訓(xùn)練過程中出現(xiàn)異常波動或不再下降，可能意味著模型出現(xiàn)了過擬合、欠擬合或者訓(xùn)練參數(shù)設(shè)置不當(dāng)?shù)葐栴}，需要及時調(diào)整訓(xùn)練策略。

# 局限性

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

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

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

（關(guān)于如何評價數(shù)據(jù)集的質(zhì)量？這里提到的幾種方法：

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

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

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

1.4消融實驗和評估設(shè)置

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

我們的消融模型使用nanotron進行訓(xùn)練。我們的 “消融模型” 有 18.2 億個參數(shù)（包括嵌入層），采用 Llama 架構(gòu)，序列長度為 2048，全局批量大小約為 200 萬個詞元，并使用 GPT2 分詞器。對于大多數(shù)消融實驗，我們在約 280 億個詞元上進行訓(xùn)練（對于這個模型規(guī)模，大致符合 Chinchilla 最優(yōu)訓(xùn)練規(guī)模）。為了確認每次過濾步驟后相對性能的提升，我們?nèi)绾笪乃?，?3500 億個詞元上進行了更長時間的訓(xùn)練。

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

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

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

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

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

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

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

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

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

經(jīng)過考慮，我們選擇了以下基準測試列表：

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

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

2 FineWeb 構(gòu)建方法

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

你可以在此處找到一個完全可重現(xiàn)的datatrove配置。

（FineWeb 數(shù)據(jù)處理流水線：

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

2. Text Extraction（文本提?。簭暮Y選后的網(wǎng)址所對應(yīng)的網(wǎng)頁中提取文本內(nèi)容，將網(wǎng)頁中的文字信息抽取出來，以便后續(xù)處理。 

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

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

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

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

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

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

2.1起點：文本提取

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

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

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

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

（

- CommonCrawl 數(shù)據(jù)格式：

  - WARC（Web ARChive）文件：包含爬取的原始數(shù)據(jù)，包括完整的網(wǎng)頁 HTML 和請求元數(shù)據(jù)。這種格式保留了網(wǎng)頁的完整結(jié)構(gòu)和內(nèi)容。

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

# 問題

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

# 解決方案

- 使用 Trafilatura 庫：

  - Trafilatura 是一個開源的文本提取庫，專門用于從 HTML 中提取高質(zhì)量的文本內(nèi)容。

  - 在實驗中，使用 Trafilatura 從 WARC 文件中提取文本，并設(shè)置參數(shù) `favour_precisinotallow=True`，以優(yōu)先保證提取的文本質(zhì)量。

# 實驗設(shè)計

- 數(shù)據(jù)處理：

  - 使用 WET 文件直接處理 2019 - 18 轉(zhuǎn)儲數(shù)據(jù)。

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

  - 對這兩種數(shù)據(jù)應(yīng)用相同的處理流程，包括基礎(chǔ)過濾和最小哈希（MinHash）算法。

# 實驗結(jié)果

- 數(shù)據(jù)規(guī)模：

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

  - Trafilatura 提取的數(shù)據(jù)集規(guī)模約為 2000 億個詞元。

- 數(shù)據(jù)質(zhì)量：

  - 盡管 WET 數(shù)據(jù)集規(guī)模更大，但其質(zhì)量遠不如 Trafilatura 提取的數(shù)據(jù)集。

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

# 結(jié)論

- 使用 Trafilatura 從 WARC 文件中提取文本，能夠生成更高質(zhì)量的數(shù)據(jù)集，更適合用于大語言模型的預(yù)訓(xùn)練。

- 即使 WET 數(shù)據(jù)集規(guī)模更大，但由于其中包含大量無關(guān)的樣板內(nèi)容，其實際效用不如 Trafilatura 提取的數(shù)據(jù)集。

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

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

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

2.2基礎(chǔ)過濾

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

我們以 RefinedWeb 的部分設(shè)置作為過濾基礎(chǔ)，具體如下：

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

對每個提取文本后的轉(zhuǎn)儲數(shù)據(jù)（目前有 96 個轉(zhuǎn)儲數(shù)據(jù)）應(yīng)用此過濾后，我們大約得到了 36 萬億個詞元的數(shù)據(jù)（本報告中所有數(shù)據(jù)的詞元數(shù)量均使用gpt2分詞器統(tǒng)計）。

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

- fastText 語言分類器：

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

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

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

- 操作步驟：

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

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

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

- 目的：

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

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

# 2. 應(yīng)用 MassiveText 的質(zhì)量和重復(fù)過濾器（使用默認閾值）

- MassiveText：

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

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

- 操作步驟：

  - 使用 MassiveText 的過濾器對文本數(shù)據(jù)進行處理。

  - MassiveText 會根據(jù)其內(nèi)部算法和默認閾值，對每段文本進行質(zhì)量評估和重復(fù)檢測。

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

- 默認閾值：

  - MassiveText 的過濾器通常會有一些預(yù)設(shè)的閾值，用于判斷文本的質(zhì)量和重復(fù)性。

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

  - 默認閾值通常是經(jīng)過優(yōu)化的，適用于大多數(shù)場景，但也可以根據(jù)具體需求進行調(diào)整。

- 目的：

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

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

# 總結(jié)

1. 使用 fastText 語言分類器，僅保留置信度≥0.65 的英文文本，以確保數(shù)據(jù)集中只包含高質(zhì)量的英文內(nèi)容。

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

通過這兩個步驟，可以顯著提高數(shù)據(jù)集的質(zhì)量，為后續(xù)的模型訓(xùn)練提供更可靠的數(shù)據(jù)基礎(chǔ)。）

2.3數(shù)據(jù)去重

去重是為大語言模型預(yù)訓(xùn)練創(chuàng)建大型網(wǎng)絡(luò)數(shù)據(jù)集時最重要的步驟之一。數(shù)據(jù)集去重方法旨在識別并去除數(shù)據(jù)集中的冗余 / 重復(fù)數(shù)據(jù)。

2.3.1為什么要去重？

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

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

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

2.3.2我們的去重參數(shù)

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

這意味著，對于相似度（s）分別為 0.7、0.75、0.8 和 0.85 的兩個文檔，它們被識別為重復(fù)文檔的概率分別為 56%、77%、92% 和 98.8%（計算公式為 1-(1-s^8)^{14}）。以下圖表對比了我們使用 112 個哈希函數(shù)的設(shè)置與 RefinedWeb 使用 9000 個哈希函數(shù)（分為 450 個桶，每個桶 20 個哈希函數(shù)，這種設(shè)置需要大量的計算資源，因為每個哈希值都必須計算、存儲，然后與其他文檔的哈希值進行比較）的匹配概率：

雖然 RefinedWeb 中大量的哈希函數(shù)能實現(xiàn)更陡峭、更明確的截斷（實際相似度接近閾值的文檔更有可能被正確識別），但我們認為在計算和存儲方面的節(jié)省是一個合理的權(quán)衡。

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

（關(guān)于MinHash

 1. MinHash核心機制

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

   - 擴展性：算法設(shè)計支持分布式計算，可在多個CPU節(jié)點上并行處理海量數(shù)據(jù)（如FineWeb處理的96個CommonCrawl轉(zhuǎn)儲）。

 2. 關(guān)鍵參數(shù)配置

   - n-gram大?。?-gram）：

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

     - 以單詞為單位而非字符，更適合捕獲語義層面的重復(fù)內(nèi)容。

   - 哈希函數(shù)數(shù)量（112個）：

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

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

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

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

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

  3. 實際效果

   - 識別能力：

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

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

   - 與RefinedWeb對比：

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

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

 4. 為什么這樣設(shè)計？

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

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

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

2.3.3去重越多越好，對吧？

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

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

例如，對于當(dāng)時第二新的轉(zhuǎn)儲數(shù)據(jù)（2023 - 40），我們除了對其內(nèi)部進行去重外，還會與最新的轉(zhuǎn)儲數(shù)據(jù)進行去重對比。結(jié)果是，轉(zhuǎn)儲數(shù)據(jù)越舊，與之對比去重的轉(zhuǎn)儲數(shù)據(jù)數(shù)量就越多，從中去除的數(shù)據(jù)也就越多（實際上，在最舊的轉(zhuǎn)儲數(shù)據(jù)中，去重步驟去除了基礎(chǔ)過濾數(shù)據(jù)的 90% 以上）。

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

這挑戰(zhàn)了我們 “去重越多必然導(dǎo)致基準測試得分越高” 的假設(shè)，所以我們決定更深入地研究最舊的轉(zhuǎn)儲數(shù)據(jù)之一 ——2013 - 48 轉(zhuǎn)儲數(shù)據(jù)：

• 在去重前，這個轉(zhuǎn)儲數(shù)據(jù)約有 4900 億個詞元。
• 經(jīng)過我們的迭代 MinHash 去重后，大約剩下 310 億個詞元（94% 的數(shù)據(jù)被去除）。

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

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

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

2.3.4退一步思考：單個轉(zhuǎn)儲數(shù)據(jù)去重

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

當(dāng)在該數(shù)據(jù)集的隨機樣本上進行訓(xùn)練時，我們發(fā)現(xiàn)其性能現(xiàn)在與 RefinedWeb 相當(dāng)（見下圖）：

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

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

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

2.3.4關(guān)于衡量去重效果的說明

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

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

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

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

對于 10 億規(guī)模的數(shù)據(jù)，幾乎所有文檔都是唯一的（重復(fù)數(shù)量 = 1），盡管在整個數(shù)據(jù)集中，每個文檔會重復(fù) 100 次（每次轉(zhuǎn)儲出現(xiàn)一次）。在 1000 億規(guī)模（占總數(shù)據(jù)集的 0.5%）時，我們開始看到一些變化，大量文檔會重復(fù)兩次，還有一些甚至?xí)貜?fù) 4 到 8 次。在 1 萬億規(guī)模（占總數(shù)據(jù)集的 5%）時，大多數(shù)文檔會重復(fù)多達 8 次，有些文檔甚至?xí)貜?fù)多達 16 次。

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

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

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

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

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

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

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

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

2.4額外的質(zhì)量過濾

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

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

2.4.1 C4：一個經(jīng)受住時間考驗的數(shù)據(jù)集

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

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

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

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

2.4.2 一種開發(fā)啟發(fā)式過濾器的統(tǒng)計方法

為了開發(fā)新的啟發(fā)式過濾器并選擇其閾值，我們設(shè)計了一個系統(tǒng)的過程：

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

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

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

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

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

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

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

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

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

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

當(dāng)同時應(yīng)用這三個過濾器時，大約 22% 的標記被去除。

這些過濾器使我們能夠進一步提升性能，并顯著超越了C4數(shù)據(jù)集的表現(xiàn)，同時提供了規(guī)模大得多的數(shù)據(jù)集。

2.5最終的FineWeb 數(shù)據(jù)集

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

1.基礎(chǔ)過濾。

2.對每個轉(zhuǎn)儲進行獨立的最小哈希去重。

3.選擇一些 C4 過濾器。

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

2.5.1與其他大規(guī)模網(wǎng)絡(luò)數(shù)據(jù)集的比較

我們將??FineWeb 與以下通常被認為是最高質(zhì)量的公開可用大規(guī)模網(wǎng)絡(luò)數(shù)據(jù)集進行了比較（我們還指出了每個數(shù)據(jù)集公開版本中大約的標記數(shù)量）：

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

你會發(fā)現(xiàn) 3500 億標記訓(xùn)練的消融模型是公開可用的，并收集在這個集合中。我們已經(jīng)上傳了每 1000 個訓(xùn)練步驟的檢查點。你也可以在這里找到我們的完整評估結(jié)果。

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

3 FineWeb-Edu

FineWeb-Edu 在我們的評估任務(wù)組上優(yōu)于 FineWeb 和所有其他公開的網(wǎng)絡(luò)數(shù)據(jù)集。

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

3.1大規(guī)模標注教育質(zhì)量

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

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

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

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

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

3.2訓(xùn)練分類器

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

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

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

3.3過濾和結(jié)果

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

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

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

Here are the key highlights of the ablation results above:

（1）FineWeb-Edu 在教育基準測試（如 MMLU、ARC 和 OpenBookQA）上超越了 FineWeb 和所有其他公開的網(wǎng)絡(luò)數(shù)據(jù)集。

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

（3）這證明了使用基于大語言模型標注訓(xùn)練的分類器進行大規(guī)模數(shù)據(jù)過濾的有效性。

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

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

4 額外內(nèi)容：隨時間變化的 CommonCrawl

就像優(yōu)質(zhì)葡萄酒一樣，并非所有的爬取數(shù)據(jù)都是一樣的。

在對過濾步驟進行消融時，我們注意到某些爬取數(shù)據(jù)的表現(xiàn)明顯優(yōu)于其他數(shù)據(jù)。我們決定研究這種現(xiàn)象。

4.1按爬取數(shù)據(jù)的基準性能

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

下面的圖表清楚地顯示，有些轉(zhuǎn)儲的表現(xiàn)比其他轉(zhuǎn)儲差得多。每年用不同的顏色表示，每年的爬取次數(shù)也不同。

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

4.2合成數(shù)據(jù)

我們想知道，最近幾次爬取數(shù)據(jù)的強大性能部分是否可歸因于大量合成數(shù)據(jù)（由大語言模型生成的數(shù)據(jù)）的存在?？紤]到最近大語言模型（尤其是 ChatGPT）的流行度增加，這樣的變化并不奇怪。

據(jù)我們所知，由于沒有萬無一失的方法來檢測合成數(shù)據(jù)，我們選擇使用一個替代指標：我們測量了每個爬取數(shù)據(jù)中以下單詞的頻率：“delve”、“as a large language model”、“it's important to note”、“rich tapestry”、“intertwined”、“certainly!”、“dive into”，這些都是 ChatGPT 常用的詞匯。

需要注意的是，并非所有包含這些短語的樣本都一定是由 ChatGPT 生成的（而且許多由 ChatGPT 生成的樣本也不包含這些短語），但假設(shè)合成數(shù)據(jù)的數(shù)量在各次爬取中保持不變，我們預(yù)期這些頻率會隨時間大致保持恒定。

結(jié)果顯示在下面的圖表中：

雖然頻率在 2023-14 之前大致保持恒定（ChatGPT 于 2022 年底發(fā)布），但我們發(fā)現(xiàn)最近的爬取數(shù)據(jù)中我們的替代指標急劇增加。雖然這個簡單的測試不足以得出 ChatGPT 的補全內(nèi)容和其他合成數(shù)據(jù)提高了最新爬取數(shù)據(jù)質(zhì)量的結(jié)論，但至少它似乎不會對其造成嚴重損害。

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

5 結(jié)論與展望

通過我們的開放科學(xué)努力，我們希望繼續(xù)揭示高性能大語言模型訓(xùn)練這個黑箱，同時讓每個模型訓(xùn)練者都有能力創(chuàng)建最先進的大語言模型。我們很高興繼續(xù)對 FineWeb 進行迭代，并以完全開放和可復(fù)現(xiàn)的方式發(fā)布質(zhì)量越來越好的網(wǎng)絡(luò)數(shù)據(jù)過濾子集。

在短期內(nèi)，我們期待將從（英語）FineWeb 中學(xué)到的經(jīng)驗應(yīng)用于其他語言。雖然目前英語在大語言模型領(lǐng)域占主導(dǎo)地位，但我們相信，使其他語言的高質(zhì)量網(wǎng)絡(luò)數(shù)據(jù)盡可能易于獲取將產(chǎn)生巨大影響。

簡而言之，大規(guī)模創(chuàng)建開放數(shù)據(jù)集的科學(xué)研究前景光明且令人興奮。

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

腳注：

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

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

（3）請注意，本報告專注于網(wǎng)絡(luò)規(guī)模數(shù)據(jù)集（“網(wǎng)絡(luò)規(guī)?！蓖ǔＶ笍木W(wǎng)絡(luò)中獲取的超過1000億個詞元）的特定領(lǐng)域，這些數(shù)據(jù)集用于預(yù)訓(xùn)練大型語言模型（我們所說的“預(yù)訓(xùn)練”是指模型訓(xùn)練的第一步，從隨機權(quán)重開始）。我們并不打算涵蓋數(shù)據(jù)集創(chuàng)建的其他領(lǐng)域，也不認為我們在本文中提出的觀點或假設(shè)可以擴展到除這一特定領(lǐng)域之外的任何其他領(lǐng)域。

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

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

（6）特別是我們懷疑它保留了過多的樣板內(nèi)容和導(dǎo)航菜單。

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

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

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

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

（11）盡管原始保留的數(shù)據(jù)中可能有與原始刪除的數(shù)據(jù)相似的文檔，但我們估計重疊部分很?。ù蠹s40億個詞元）。

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

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

本文轉(zhuǎn)載自??AIRoobt?? ，作者：HuggingFace