大規模近重複刪除背後的 BigCode

Hugging Face 已實作一個大規模近重複刪除管線，使用 MinHash 與 Locality Sensitive Hashing（LSH）來提升 BigCode 計畫的訓練資料品質。此流程可減少基準測試的污染、降低隱私風險，並透過讓模型在較小的資料集上達到相似或更佳的效能，提升訓練效率。

在 LLM 訓練中去重複的重要性

在大型語言模型（LLM）訓練中，資料重複會導致多項關鍵問題，包括模型傾向逐字輸出訓練資料，以及提升對隱私攻擊的脆弱性。有效的去重複提供了三大主要優勢：

  • 訓練效率： 模型可以在較少的訓練步驟下達到相同或更優的效能。
  • 評估完整性： 移除重複資料可防止資料外洩與基準測試污染，確保效能提升是真實的，而非模型在訓練期間已見過測試資料所致。
  • 可及性： 縮減資料集的實體大小，使其更易於儲存、傳輸與協作。

技術實作：MinHash 與 LSH

BigCode 採用三步工作流程，以大規模辨識與移除近重複文件。

1. Shingling 與指紋化

此流程從將文字切割成 n-gram（shingle）開始。例如，使用字詞層級的三元組（tri-gram）來表示文件。每個 shingle 會被多次雜湊與排列。透過在文件的所有 shingle 上對每次排列取最小雜湊值，即可產生「MinHash」指紋。此操作的時間複雜度為 $\mathcal{O}(NM)$（其中 $N$ 為文件數量，$M$ 為文件長度），透過平行化可線性擴展。

2. Locality Sensitive Hashing（LSH）

為避免比較每一對文件的計算成本過高，LSH 會將 MinHash 指紋陣列切分為多個 band。於特定 band 中擁有相同雜湊值的文件會被分入同一 bucket，並標記為去重複的候選配對。

3. 重複移除與聚類

當候選配對被識別後，BigCode 採用圖形化方法將重複項目聚類為連通元件。雖然管線的早期版本會再次檢查 Jaccard 相似度以過濾偽陽性，但在「The Stack」資料集上的實驗顯示，將所有 LSH 候選視為真陽性往往能帶來最佳的下游模型效能。

使用 Spark 擴展管線

為處理 TB 級規模的資料，Hugging Face 從本地 Python 框架轉移至 Apache Spark。這使得分散式的 groupBy 操作與連通元件偵測演算法得以實作。利用 GCP DataProc，團隊在不到四小時內成功去除 1.4 TB 資料的重複，成本約為每小時 $15。

對模型效能的影響

近重複刪除對程式碼模型的品質有顯著影響。主要發現包括：

  • 資料集大小 vs. 效能： 近重複刪除使模型在較小的資料集上（例如 3 TB 與 6 TB）也能表現更佳。
  • 積極去重複： 透過降低相似度門檻並增大 shingle 大小（例如從 unigram 轉為 5-gram），可進一步提升效能，且可降低偽陽性的比例。
  • 召回率： 降低相似度門檻會提升高相似度配對的召回率，從而移除更多冗餘資料。

限制與未來方向

近重複刪除是基礎步驟，但仍無法取代對有毒性、偏見或個人可識別資訊（PII）等資料品質的過濾需求。此外，團隊指出基準測試的污染仍是一大挑戰；例如，MBPP 基準與 GitHub 上常見的 Leetcode 題目有高度相似性。

未來的研究方向包括探索程式碼的子字串去重複、偵測單一文件內重複段落，以及利用模型嵌入進行語意去重複，以在多樣性與冗餘之間取得平衡。

Sources