LLMデータ重複排除（エルエルエムデータチョウフクハイジョ）
大規模言語モデルの学習データから重複・類似コンテンツを検出・除去する技術。完全一致（Exact Dedup）と近似一致（Fuzzy Dedup）の2段階で実施し、MinHash LSHやSimHashが代表的なアルゴリズムである。
LLMデータ重複排除とは
LLMデータ重複排除（Deduplication）は、学習データ中の重複コンテンツを検出・除去するプロセスである。Webクロールデータには同一コンテンツのコピー、ミラーサイト、テンプレート生成ページなどが大量に含まれており、重複を放置するとモデルが特定のテキストを過学習（memorization）してしまう。Lee et al.（2022）の研究では、重複排除によりモデルの汎化性能が有意に向上し、学習効率も改善されることが実証されている。
重複の種類と影響
重複レベルの分類
| レベル | 定義 | 発生原因 | 影響 |
|---|---|---|---|
| 完全一致（Exact） | バイト列が完全に同一 | ミラーサイト、RSS配信、コピペ | 学習トークンの無駄消費 |
| 近似一致（Near-duplicate） | 90%以上の類似度 | テンプレート生成、軽微な編集 | 過学習リスク |
| 段落レベル重複 | 特定段落が複数文書に出現 | 引用、定型文、利用規約 | ボイラープレート学習 |
| n-gram重複 | 特定のn-gramが高頻度出現 | スパム、SEOテキスト | 品質低下 |
Common Crawl の1か月分のクロールデータでは、完全一致で約 30%、近似一致まで含めると約 50% のデータが重複しているとされる。
完全一致重複排除（Exact Dedup）
ハッシュベース手法
文書全体または行単位でハッシュ値を計算し、同一ハッシュの文書を除去する。
| 手法 | ハッシュ関数 | 粒度 | 処理速度 | メモリ使用量 |
|---|---|---|---|---|
| 文書レベルHash | SHA-256 / MD5 | 文書全体 | 非常に高速 | 低（ハッシュ表のみ） |
| 行レベルHash | SHA-256 | 1行単位 | 高速 | 中 |
| 段落レベルHash | SHA-256 | 段落単位 | 高速 | 中 |
| n-gram Hash | Rolling Hash | 連続n行 | 中速 | 高 |
文書レベルのExact Dedupは最も高速だが、1文字でも異なれば検出できないため、近似重複排除と組み合わせて使用する。RefinedWeb では文書レベル→URL正規化→近似重複排除の3段階で実施している。
近似重複排除（Fuzzy Dedup）
MinHash LSH（Locality-Sensitive Hashing）
MinHash LSH は近似重複検出の業界標準アルゴリズムである。
処理フロー:
- 文書をn-gram（通常5-gram）に分割
- 各n-gramに複数のハッシュ関数を適用し、各関数の最小値（MinHash）を取得
- MinHash署名をバンドに分割し、同一バンドに一致するペアを候補として抽出
- 候補ペア間のJaccard類似度を計算し、閾値以上のペアを重複と判定
パラメータ設定の目安:
- n-gram サイズ: 5（英語）、3〜4（日本語）
- ハッシュ関数数: 128〜256
- バンド数 × 行数: 20×5（閾値 ≈ 0.8）、14×8（閾値 ≈ 0.7）
- Jaccard類似度閾値: 0.8（FineWeb）、0.7（RefinedWeb）
SimHash
SimHash はGoogleが Web検索の重複検出に使用したアルゴリズムで、MinHash より省メモリ。
- 各文書を固定長ビットベクトル（64ビットまたは128ビット）に変換
- ハミング距離で類似度を計算（距離 ≤ 3 で重複と判定が一般的）
- メモリ効率が高く、数十億文書規模でも単一マシンで処理可能
- ただし MinHash と比較して偽陽性率がやや高い
Suffix Array ベースの手法
NeMo Curator が実装している手法で、テキスト全体のSuffix Arrayを構築し、長い共通部分文字列を持つ文書ペアを検出する。
- 段落レベル・文レベルの部分重複を高精度に検出可能
- 文書レベルのみの手法では見逃す「コピペ段落」を捉えられる
- 計算コストが高く、GPU加速（RAPIDS cuDF）の利用が推奨される
重複排除の効果
| データセット | Dedup前 | Dedup後 | 削減率 | 手法 |
|---|---|---|---|---|
| C4（Google） | 806GB | 305GB | 62% | Exact + MinHash |
| FineWeb | 〜100兆トークン | 15兆トークン | 85% | URL + Exact + MinHash |
| RefinedWeb | 〜50兆トークン | 5兆トークン | 90% | Macro + MinHash |
| The Pile | 1.6TB | 825GB | 48% | Exact + MinHash |
Lee et al.（2022）の実験では、C4 データセットの重複排除後にモデルを学習したところ、重複ありのベースラインと比較して perplexity が約 10% 改善し、下流タスクの精度も向上した。
スケーラブルな実装戦略
分散処理アーキテクチャ
数兆トークン規模のデータに対する重複排除は、単一マシンでは処理しきれない。
- MapReduce方式: ハッシュのPrefix（先頭バイト）でパーティショニングし、各ノードで局所的にデdup
- Spark + MinHash: PySpark の ML ライブラリに MinHash LSH が実装済み
- GPU加速: NeMo Curator の RAPIDS 統合により、MinHash 計算を GPU で並列化
- 段階的処理: まずExact Dedupで大量の完全一致を除去し、残りに対してFuzzy Dedupを適用
メモリ最適化
- ハッシュ値を64ビット整数に圧縮し、メモリ使用量を削減
- ブルームフィルタで候補ペアの事前スクリーニング
- ディスクベースのソートマージで大規模データに対応
よくある質問（FAQ）
Q1: 重複排除の閾値はどう決めるべきか？ A: Jaccard類似度 0.8 が標準的な閾値で、FineWeb でも採用されている。0.7 に下げると検出率は上がるが偽陽性も増える。実運用では、閾値を変えた場合のサンプル検証（1,000ペア程度を人手確認）で最適値を決定する。
Q2: 文書レベルと段落レベル、どちらで重複排除すべきか？ A: 両方実施するのがベストプラクティス。まず文書レベルで大量の完全コピーを除去し、次に段落レベルで「一部だけコピペ」されたコンテンツを処理する。ただし段落レベルの処理は計算コストが高いため、GPU 加速や Suffix Array の利用を推奨する。
Q3: 重複排除はクロスデータセットでも行うべきか？ A: はい。複数ソースを混合する場合、ソース間の重複も除去すべきである。例えば Common Crawl と Wikipedia を混合する際、Wikipedia のコンテンツが Common Crawl にも含まれている可能性が高い。データソースごとに ID 空間を分離し、クロスソースの MinHash を計算する。
まとめ
- 重複排除は LLM データパイプラインの最重要ステップの一つ
- 完全一致（ハッシュ）+ 近似一致（MinHash LSH）の2段階が標準
- Common Crawl データの約 50% は何らかの重複を含む
- 重複排除により perplexity が約 10% 改善し、汎化性能が向上
- 大規模データでは分散処理・GPU加速が必須