LLMデータ前処理（エルエルエムデータマエショリ）
大規模言語モデルの学習データに対して行うテキスト正規化・クリーニング・言語判定・エンコーディング修正などの初期処理工程。生データを後続の品質フィルタリングやトークン化に適した形式に変換する。
LLMデータ前処理とは
LLMデータ前処理は、Webクロールや書籍・論文などから収集した生テキストデータを、言語モデルの学習に適した形式に変換する初期処理工程である。HTMLタグの除去、文字エンコーディングの統一、言語の判定、不要な定型文（ボイラープレート）の除去などを行い、後続の重複排除や品質フィルタリングの精度を高める役割を担う。
前処理の主要タスク
テキスト抽出と正規化
Webページからの本文抽出は前処理の最初のステップである。
| 処理 | 内容 | 主要ツール |
|---|---|---|
| HTML→テキスト変換 | タグ除去、本文抽出 | Trafilatura, Resiliparse, jusText |
| エンコーディング修正 | UTF-8統一、文字化け修正 | ftfy, chardet |
| Unicode正規化 | NFC/NFKC正規化、制御文字除去 | unicodedata (Python) |
| 空白正規化 | 連続空白・改行の統一 | 正規表現 |
| URL/メール除去 | プライバシー保護とノイズ低減 | 正規表現 |
Trafilatura は Webページからの本文抽出において高い精度を持つライブラリで、FineWeb の構築にも使用された。HTML のナビゲーション、フッター、広告領域を自動判別し、本文のみを抽出する。
言語判定（Language Identification）
多言語コーパスを扱う場合、各文書の言語を正確に判定する必要がある。
| ツール | 開発元 | 対応言語数 | 精度（Top-1） | 速度 |
|---|---|---|---|---|
| fastText lid.176 | Meta | 176言語 | 約 97% | 非常に高速 |
| CLD3 | 107言語 | 約 95% | 高速 | |
| langdetect | Shuyo | 55言語 | 約 93% | 中速 |
| GlotLID | GlotScript | 2,000+言語 | 約 90% | 中速 |
fastText の lid.176.bin モデルが業界標準で、FineWeb・RefinedWeb・RedPajama のいずれでも採用されている。文書レベルと段落レベルの2段階で判定を行うのが精度向上のベストプラクティスである。
ボイラープレート除去
Webページに含まれるナビゲーション、Cookie同意バナー、著作権表示、広告テキストなどの定型文を除去する。
- ルールベース: 「Copyright ©」「All rights reserved」「Cookie Policy」など既知パターンのマッチング
- 統計ベース: 多くのページに共通するn-gramを検出し除去（CCNetの手法）
- 構造ベース: HTML DOM構造からメインコンテンツ領域を特定（Trafilatura）
- 行単位フィルタ: 短すぎる行（5単語未満）や記号比率が高い行を除去
文字レベルのクリーニング
ftfy による文字化け修正
ftfy（fixes text for you）は、エンコーディングの二重変換や不正な文字置換を修正するPythonライブラリである。
’→'（UTF-8をLatin-1として読んだ場合の典型的な文字化け）é→é（フランス語の文字化け）Ａ→Ａ（全角文字のエンコーディング問題）- 制御文字（
\x00〜\x1f）の除去 - BOM（Byte Order Mark）の統一的な除去
大規模コーパスでは、Webページの約 3〜5% に何らかのエンコーディング問題が存在するとされ、ftfy の適用は必須の前処理ステップとなっている。
数値・記号の正規化
- 全角数字→半角数字（日本語テキストで多発）
- 異体字セレクタの除去
- ゼロ幅スペース（U+200B）、ゼロ幅結合子（U+200D）の除去
- ハイフン・ダッシュ類の統一（U+2010, U+2011, U+2012, U+2013, U+2014 → U+002D）
前処理パイプラインの実装パターン
Datatrove での実装例
Datatrove では、各前処理ステップをブロック（Block）として定義し、パイプラインに組み込む。
- TextExtractor: HTML/PDF からテキストを抽出
- LanguageFilter: 指定言語以外のドキュメントを除外
- URLFilter: 特定ドメイン（アダルト、スパム）のURLをブラックリストで除外
- GopherQualityFilter: The Pile の品質基準に基づくフィルタ
- C4QualityFilter: C4 データセットの品質基準に基づくフィルタ
各ブロックは独立して動作するため、処理順序の変更や新しいフィルタの追加が容易である。
処理速度の目安
| データ規模 | CPU（64コア） | GPU（A100×8） |
|---|---|---|
| 1TB（圧縮） | 約 12時間 | 約 2時間 |
| 10TB（圧縮） | 約 5日 | 約 20時間 |
| 100TB（圧縮） | 約 50日 | 約 8日 |
GPU加速は主に言語判定やニューラルベースの品質分類で効果を発揮する。テキスト正規化などのルールベース処理はCPUで十分な速度が得られる。
日本語テキスト固有の前処理
日本語テキストには英語とは異なる前処理が必要となる。
- 文字種正規化: 全角英数→半角、半角カナ→全角カナ
- 表記揺れ統一: 「サーバー」「サーバ」の統一（ルールベースまたは辞書）
- ルビ除去: HTML
<ruby>タグ内のルビテキストの処理 - 顔文字・絵文字: 除去または特殊トークンへの置換
- 改行・空白: 日本語は分かち書きしないため、段落区切りの判定が英語より複雑
よくある質問（FAQ）
Q1: 前処理でデータ量はどれくらい減少するか？ A: 一般的にWebクロールデータの 30〜50% が前処理段階で除去される。HTMLタグ・ボイラープレートの除去で約 20〜30%、言語フィルタで約 5〜10%、文字クリーニングで約 2〜5% が削減される。FineWeb では Common Crawl の約 85% を最終的に除去しているが、これは品質フィルタリングまで含めた数値。
Q2: 前処理の品質をどう検証するか？ A: サンプリング検証が最も信頼性が高い。各処理段階で 1,000〜10,000 ドキュメントをランダム抽出し、人手で品質を確認する。さらに、前処理前後での平均文長、語彙サイズ、言語分布のメトリクスを比較し、異常な変動がないか監視する。
Q3: 前処理は毎回やり直す必要があるか？ A: データソースが同一であれば、前処理結果をキャッシュして再利用できる。ただし、フィルタルールを変更した場合や新しいクロールデータを追加した場合は再処理が必要。Datatrove はチェックポイント機能を提供しており、途中段階からの再開が可能。
まとめ
- 前処理はデータパイプラインの基盤であり、後続処理の品質を左右する
- Trafilatura + ftfy + fastText lid が標準的なツールセット
- 日本語は文字種正規化・表記揺れ統一など固有の処理が必要
- 処理結果のサンプリング検証でパイプライン品質を継続的に担保する
- 大規模データではGPU加速による言語判定の高速化が有効