簡短回答。 對原始Common Crawl數據應用完整的FineWeb-Edu風格管道，會過濾掉5到7%的輸入內容——100萬億原始令牌最終產生5到7萬億訓練令牌，僅語言識別這一環節就先丟棄了50到80%的內容，再進行任何質量篩選之前。八個生產階段依次為語言識別、精確去重、模糊去重、啟發式過濾、質量分類、個人身份信息（PII）移除、去汙染和格式化，其順序具有關鍵意義。重複內容值得測量而非假設：Lee等（2022年） 發現，在C4數據集中字節級重複率為6.7%，在RealNews數據集中為18.6%，在ROOTS數據集中為21.67%。
預訓練語料庫？
從貫穿一切的數字開始。
對原始Common Crawl數據應用完整的FineWeb-Edu風格的篩選管道，其綜合通過率為5到7%。
從100萬億原始令牌開始，最終得到5到7萬億訓練令牌。
輸入數據的93%到95%被丟棄。並非因為管道過於激進，而是因為原始網絡爬取數據的真實情況就是如此：語言錯誤、重複、模板化內容、機器生成內容，或者根本無法用於學習。
這個數字應當重新定義人們對‘我們擁有大量數據’這一說法的理解。在篩選前的數據量並不具有實際意義。真正重要的數字是最終存活下來的內容。
八個階段及其順序並非隨意安排
生產流程已確立，排序原則簡單：先運行低成本操作，以最小化昂貴操作所處理的數據量。
語言識別。剔除非目標語言內容，通常佔輸入數據的50%到80%。該步驟優先執行，因其成本低且能大幅減少數據體量。
精確去重。通過哈希計算去除字節完全相同的文檔。
模糊去重。利用MinHash LSH技術識別近似重複內容。
啟發式過濾。基於行統計、詞長分佈、標點符號比例等進行過濾。Gopher和MassiveText的啟發式方法仍作為參考集保留。
質量分類。模型對文檔進行打分，得分較低的文檔被剔除。
個人身份信息（PII）移除。電子郵件、電話號碼、政府識別碼和IP地址在原位置進行遮蔽，而非直接丟棄。
去汙染。移除評估集內容，以確保基準測試仍能衡量有效指標。
劃分為訓練可用的 Parquet 或 JSONL 文件。
每個階段都會縮減語料庫，將昂貴的階段置於便宜的階段之前，會在最終被丟棄的文檔上浪費計算資源。
關於這一排序的一個重要注意事項，來自 FineWeb2。由於去重計算開銷較大，通常會將其放在最後執行。FineWeb2 團隊特意先執行去重，這樣在進行過濾實驗時，他們可以直接觀察最終數據集的表現，而不會受到後續去重對結果的影響。
這是一個方法論決策，而非生產環境決策，瞭解這一區別非常重要。如果你正在進行實驗以決定過濾策略，應先去重，以確保結果清晰。如果你在大規模生產環境中運行，應將去重操作延遲到最後，以避免對本就會被丟棄的文檔進行去重。
實際上存在多少重複內容
這一基礎性測量來自 Lee 等人在 2022 年的研究，瞭解這一點有助於校準預期。
各語料庫的字節級完全重複率：C4 為 6.7%，RealNews 為 18.6%，ROOTS 為 21.67%。
這些僅是完全相同的重複內容。近似重複內容——即同一文檔以不同標題或更改日期的形式再現——更為普遍，這也是模糊去重技術存在的目的。
之所以重要，是因為記憶效應。Carlini及其同事刻畫了對數線性記憶效應與重複之間的關係：序列在訓練數據中出現的次數越多，模型越有可能原樣復現該序列。
這同時是一個隱私問題、一個版權問題和一個泛化問題。
而近似重複並不是這個問題的弱版本。Shilov及其同事在2026年發表於《Nature Communications》的研究表明，模糊重複對記憶效應的貢獻速率是精確重複的0.8倍。有80%的效應來自那些無法通過精確匹配捕捉到的文檔。這一發現證明了模糊去重必須是強制性的，而非可選的。
這些方法及其實際作用
MinHash LSH是核心方法。MinHash草圖上的局部敏感哈希，最初由Broder提出用於大規模網絡近似重複檢測，至今仍是預訓練語料庫去重的主流生產方案。
FineWeb的超參數已形成事實上的標準，值得記錄：共14個桶，每個桶大小為8，基於5-gram。文檔按簽名進行聚類，每個聚類保留一個代表文檔。
LSHBloom (Khan et al., 2及2024) 用Bloom過濾器替代了MinHash-LSH索引，報告在千萬級數據規模下實現了12倍的加速。
SemDeDup (Abbas et al., 2023) 基於語義而非詞元工作，通過嵌入識別並移除語義冗餘的文檔。一個典型的生產流程首先使用MinHash清除精確和近詞法重複，然後使用輕量級句子編碼器（如all-MiniLM-L6-v2）對剩餘文檔進行嵌入，對於超出編碼器輸入長度的文檔則進行分塊處理。
SoftDedup 採取了完全不同的方法，通過重新加權重複項而非直接刪除它們，從而保留了某內容頻繁出現的信號，同時降低了其主導地位。
存在 GPU 加速版本，因為否則計算開銷將不可承受。在 1000 億個標記上使用 MinHash LSH 需要在 96 核 CPU 集群上運行數週，這使得僅使用 CPU 的人工篩選在大規模預訓練場景下變得不切實際。
一個需要牢記的注意事項：所有這些近似方法本質上都是近似的。這在預訓練階段是可以接受的，因為目標是減少冗餘而非保證字節穩定性，但這意味著結果會隨實現方式和超參數的變化而變化，從而使得跨語料庫的比較變得不可靠。
局部與全局：真正重要的爭論
這個決策對最終語料庫的影響最大，且業界共識已經發生了轉變。
全局去重在全語料庫範圍內移除重複項：跨越所有爬取快照、所有語言、所有來源。
局部去重在分區內部進行操作，通常按爬取快照和語言劃分。
直覺認為全局去重更好，因為它移除了更多的重複內容。然而，證據表明情況恰恰相反。
OpenGPT-X團隊在經過廣泛測試後，對每個快照和每種語言進行了去重，並引用了最新研究證實，局部去重相較於全局方法，在保留數據多樣性的同時最小化冗餘方面更具優勢。
我此前在這一系列文章中提到過的機制，看似反直覺卻是一致的。激進的跨爬取去重會優先保留高熵頁面，因為真正有用的內容在多次爬取中會被去重掉，而噪聲、獨特且低質量的頁面則因獨特性而得以倖存。最終得到的語料庫反而冗餘更少且質量更差。
FineWeb項目在96個Common Crawl快照上分別運行每快照的MinHash，生成了15萬億個標記。FineWeb2則採用了全局語言層面的去重，這是一種中間方案：在語言內部全局去重，跨語言則分區處理。
不同項目落地方式各異，Zyda則採取了相反的策略，使用13-gram的LSH進行跨數據集高激進去重。誠實的總結是，這本質上是一個動態的設計決策，而非定論，而近期證據的趨勢更傾向於分區方法。
多語言問題，也就是大多數流水線悄然崩潰的地方
這裡有一個細節，幾乎在每一個流水線描述中都會被跳過，一旦遺漏，就會導致結果無效。
MinHash操作在n-gram shingles上，而n-gram需要分詞處理。空格分詞對英語來說效果尚可，但對於那些不以空格分隔詞、具有豐富形態變化或使用無詞邊界標記的書寫系統來說，效果極差甚至完全無效。
FineWeb2團隊對此進行了明確處理：他們為每種語言使用了詞級分詞器，以獲取詞級別的n-gram，而非在整個多語言語料庫上統一應用一種分詞方法。
在泰語、中文或日語文本上運行英文分詞，你的MinHash簽名將毫無意義。無法檢測到重複項，非重複項會被錯誤地聚類。整個流程運行，產生輸出，報告一個去重率，但這個數字是虛構的。
同樣的問題會貫穿整個流程的其餘部分。基於英文假設構建的啟發式過濾器，如平均詞長、標點比例、停用詞頻率，在具有不同形態結構的語言中會失效，會將有效文本誤判為低質量。語言識別在低資源語言和混合語言文本上表現更差，導致文檔被錯誤路由到錯誤的語言分區或被完全丟棄。基於英文教育內容訓練的質量分類器無法遷移。
實際後果是，一個經過英文設計流程處理的多語言語料庫在不同語言之間並未得到同等的整理。英文部分整理得很好，而其他語言部分的整理則不可預測，且整體統計數據無法揭示這一問題。
解決方案是按語言配置和按語言報告：分詞、過濾閾值、語言識別置信度、去重率和通過率，均按語言而非整體進行報告。這需要更多工作。這也是唯一能真正瞭解你實際擁有內容的方式。
去汙染，容易被低估
有一個階段值得單獨關注，因為如果處理錯誤，將使所有下游環節無效。
去汙染會從訓練語料庫中移除評估集內容。如果基準問題出現在預訓練數據中，那麼基準分數衡量的是記憶能力而非實際能力，這正是我在多語言基準測試中討論的問題——隨著模型被訓練以通過這些測試，這些基準測試變得不可靠。
兩個實際要點。
汙染是通過網絡上基準內容的重複傳播而來，而不是有人故意包含測試集。一個流行基準問題被一百篇博客文章引用，那麼在你的語料庫中它就會被重複一百次，而對原始基準文件的精確匹配將無法捕捉到同義改寫版本。
因此，去汙染必須針對你打算報告的每一個基準內容進行，這意味著基準列表必須在整理之前就確定，而不是在訓練之後才選定。
我們自身工作的相關部分
聲明利益：Lifewood 從事人工智能數據和多語言數據收集工作，雖然語料庫級別的去重是工程領域而非標註領域，但兩者在某個具體點上交匯，值得明確命名。
清洗告訴你應該刪除什麼，但它無法告訴你什麼內容是缺失的。
一個管道可以配置得完美無缺，但仍可能產生一個在你所需語言、領域和語體方面極為貧乏的語料庫，因為過濾操作僅作用於爬取到的內容。網絡爬取過度反映了網絡實際產出的內容，即以少數高資源語言為主、書面化、正式的英文文本。
我們此前在本系列中曾撰文分析了205個網絡爬取語言語料庫，發現其中至少有15個完全沒有可用文本，87個低於50%的可用內容。無論MinHash參數如何調整，都無法修復一個本就不可用的語料庫。當低於某個閾值時，委託生產並驗證數據的成本，反而低於清洗那些本就無法使用的爬取數據。
我們與客戶使用的實際框架：先運行管道，然後按語言逐個審計留存內容。英語的通過率為6%，斯里蘭卡語為0.4%，這並非一個管道運行得一致可靠，而是表明你的語料庫中低資源語言部分需要進行數據採集，而非僅靠過濾。
需要做什麼？報告每個階段和每種語言的通過率。聚合通過率會掩蓋一切重要信息。
進行模糊去重，而不僅僅是精確去重。模糊重複項的記憶率是精確匹配的0.8倍，而精確匹配會完全遺漏它們。
默認採用本地去重，按數據快照和按語言分別處理，除非你已經測量過全局去重在你的語料庫上表現更好。
在分塊處理時使用按語言的分詞方法。對非拉丁文字使用英文空格分詞會產生無意義的簽名，導致去重率虛假。
在生產環境中，將階段按成本從低到高排序，但在運行過濾實驗時，考慮先進行去重，以避免結果相互干擾。
在數據整理前，先確定基準列表，以便去汙染處理可以針對全部列表運行。
如果你的語料庫規模超過大約1000億個標記，應預留GPU加速預算，因為在此規模下，MinHash LSH在CPU上運行需要數週時間。
審計最終留存的內容，而不僅僅是被移除的內容。經過清洗後的語料庫是由最初爬取的語料庫定義的，而其中的空白在清洗統計中是不可見的。
關鍵要點
- 對原始 Common Crawl 數據應用完整的 FineWeb-Edu 式處理流程，整體通過率為 5% 至 7%。100 萬億個原始詞元最終可得到 5 萬億至 7 萬億個訓練詞元。
- 八個生產階段分別是語言識別、精確去重、模糊去重、啟發式過濾、質量分類、個人身份信息（PII）移除、去汙染和分片。成本較低的階段優先運行。
- 僅語言識別這一環節通常就會丟棄50%到80%的原始輸入。
- Lee等人（2022）在C4數據中測得字節級精確重複率為6.7%，在RealNews中為18.6%，在ROOTS中為21.67%。
- Carlini等人對重複內容與記憶擴展之間的對數線性關係進行了表徵，這使得去重問題同時成為隱私、版權和泛化能力方面的關鍵議題。
- Shilov等人（《Nature Communications》，2026）發現模糊重複內容的記憶率是精確重複內容的0.8倍，這使得模糊去重成為必要而非可選環節。
- MinHash LSH仍然是主流的生產方法。FineWeb事實上的標準超參數是使用5-gram，共14個桶，每個桶大小為8。
- LSHBloom通過用Bloom過濾器替代LSH索引，在千萬級規模下實現了十二倍的加速。SemDeDup基於嵌入向量進行處理，SoftDedup採用重新加權而非直接移除的方式。
- 在96核CPU集群上，對1000億個標記進行MinHash LSH操作需要數週時間，因此在大規模場景下僅使用CPU進行數據篩選是不現實的。
- 經過廣泛測試，OpenGPT-X發現，按單次導出數據和按語言進行本地去重，比全局方法更能保留數據多樣性。
- 激進的跨爬蟲去重會優先保留高熵噪聲，因為出現在多個爬蟲中的有用內容被移除，而獨特的低質量頁面得以留存。
- FineWeb2採用按語言進行全局去重，並使用每種語言的詞級分詞器生成n-gram。
- 將英文的空白字符分詞方式應用於沒有空格分隔詞的語言，會產生無意義的MinHash簽名，且去重率是虛假的。
- 基於英文假設構建的啟發式過濾器、語言ID和質量分類器在其他語言中表現都會退化，因此經過英文流程處理的多語言語料庫在篩選過程中存在不均衡現象，這些不均衡在聚合統計中被掩蓋。
- FineWeb2在執行去重操作時是先於過濾實驗，這樣可以在去重不干擾結果的前提下評估過濾效果。而在生產環境中，通常相反的順序才是正確的。
- 去汙染必須針對你計劃報告的每一個基準測試運行，並且該列表在數據篩選前必須固定。
- 清洗告訴你該移除什麼，卻從不告訴你缺失了什麼。當質量低於閾值時，驗證數據的交付成本低於清洗那些從未可用的爬取數據。
資料與進一步閱讀
- Spheron, "AI Pretraining Data Curation on GPU Cloud: NeMo Curator, Datatrove and FineWeb-Style Pipelines (2026 Guide)", 在八階段流程中，5到7%的綜合通過率，50到80%的語言ID下降率以及MinHash LSH的CPU計算需求
- "Byte-Exact Deduplication in Retrieval-Augmented Generation", arXiv, 關於Lee等人（2022）在C4、RealNews和ROOTS上的重複率，Carlini等人關於記憶擴展的分析，以及Shilov等人（Nature Communications 2026）關於模糊重複記憶率的研究
- "Merlin: Deterministic Byte-Exact Deduplication", arXiv, 關於MinHash LSH作為主流生產方案，LSHBloom的十二倍千萬級加速，以及SemDeDup、D4和SoftDedup
- "FineWeb2: One Pipeline to Scale Them All", arXiv, 關於每種語言的詞級分詞器，全局多語言去重，FineWeb超參數設置，以及先進行去重以確保實驗純淨度
- "Data Processing for the OpenGPT-X Model Family", arXiv, 關於局部與全局去重測試，發現局部方法在保留數據多樣性方面表現更優
- "ManufactuBERT: Efficient Continual Pretraining for Manufacturing", arXiv, 關於實際應用中MinHash後接SemDeDup的流程，以及編碼器的選擇
- Emergent Mind, "FineWeb-Edu-Dedup", 關於多階段去重，Jaccard閾值和語料庫規模，以及"RefinedWeb Dataset"在包括Zyda在內的多種流程對比分析
- Kreutzer等人，《質量一覽：對網絡爬取多語言數據集的審計》，TACL，此前系列中討論的語料庫中無可用文本的情況
- Lifewood，多語言數據採集與AI數據服務