事前学習データの作り方 — Webから教科書品質へ
「大量のWebデータで学習した」の一行の裏には、本文抽出・品質フィルタ・重複除去・混合比という4つの工程がある。CommonCrawlという砂利の山から教科書品質の文章を選り分ける仕組みを、MinHashの式から現場で触るパラメータ名まで1から解説する。
要点
- 事前学習データの工程は、本文抽出、品質フィルタ、重複除去、混合比の4段です。
- Common Crawlの配布形式はWARC、WAT、WETの3つで、品質重視のデータセットはWETを捨ててWARCのHTMLから本文を抽出し直します。
- RefinedWebの報告では、複数の工程を通すと元の1割前後しか残らず、9割は捨てる前提で組みます。
- MinHashではハッシュの最小値が一致する確率がJaccard係数に等しく、LSHでバンド分割して候補だけを絞ります。
- GPT-3の配合ではCommonCrawlは410Bトークンで60%、Wikipediaは3Bで3%と、量に比例させず質の高い山を厚く読ませます。
The Pile: An 800GB Dataset of Diverse Text for Language Modeling
一次資料 — この記事の根拠
この解説の公開 2026-08-26
The Pile: An 800GB Dataset of Diverse Text for Language ModelingarXiv:2101.00027論文ページ·PDFDeduplicating Training Data Makes Language Models BetterarXiv:2107.06499論文ページ·PDF
The RefinedWeb Dataset for Falcon LLMarXiv:2306.01116論文ページ·PDF
Scaling Data-Constrained Language ModelsarXiv:2305.16264論文ページ·PDF
砂金採りの話から始める
モデルカードには「大量のWebデータで事前学習した」と一行あるだけです。その裏には、たいてい数ヶ月分の地味な選別工程が隠れています。
川で砂金を採る作業を思い浮かべてください。バケツ一杯の砂利を水に沈めて揺すり、軽い砂を流し、重い粒だけを残す。事前学習データのパイプラインがやっているのはこれで、違うのは砂利が数百テラバイトあることだけです。同じアーキテクチャ・同じ計算量でも、食べさせたデータが違えば出来上がるモデルは別物になります。
素材 — CommonCrawlという砂利の山
Web全体を自前でクロールできる組織は多くありません。多くのモデルの出発点は、非営利団体 Common Crawl が公開しているWebアーカイブです。おおむね毎月1回の巡回結果(snapshot)が公開され、1回あたり数十億ページ規模になります。
配布形式は3つ。WARC(HTTPのやり取りの生ログ。HTMLがそのまま入る)、WAT(メタデータだけ)、WET(タグを外した素朴なテキスト)です。
一番手軽なのはWETですが、ここが最初の分岐点になります。WETの抽出は、ナビゲーションメニューも著作権表示も広告も区別なくテキスト化します。本文が3行のページから200行のメニューが取れてしまう。だから品質にこだわるデータセット(FalconのRefinedWeb、HuggingFaceのFineWeb)はWETを捨て、WARCのHTMLから trafilatura のような本文抽出ツールでやり直します。上流の抽出品質が、全工程の天井になります。
桁を掴んでおく
必要なトークン量の目安はスケーリング則を1から解説のとおり、パラメータ1つあたり20トークン前後。一方RefinedWebの報告では、URLフィルタ→本文抽出→言語判定→品質フィルタ→重複除去を通すと元の1割前後しか残りません。9割は捨てる前提で組みます。
もう一つの壁が計算量です。10億文書を総当たりで比べれば比較回数は約5×1017回。1秒に10億回比較できても15年以上かかります。
O(n²)が無理だと分かった時点で方向は決まります。総当たりをやめ、似ている候補だけを先に絞る。
第1の関門: 品質フィルタ
本文を取り出したら、次は「読むに値する文章か」を判定します。下にいくほど賢く、そして重くなります。
(1) URLレベル — ドメインのブロックリストでアダルト・スパム・自動生成サイトを丸ごと落とす。1バイトも読まずに済む最安の工程です。
(2) 言語判定 — fastText の言語識別モデルでスコアを出し、閾値を超えたものだけ残す。RefinedWebは英語のスコア0.65以上が条件です。閾値を上げると純度は上がりますが、コード混じりの技術文書や多言語ページが落ちやすくなります。
(3) ルールベース — DeepMindのGopher論文が公開したフィルタ群が事実上の標準です。単語数が極端、平均単語長が3〜10文字を外れる、記号と単語の比率が高すぎる、行の大半が箇条書き記号で始まる、基本的なストップワード(the, be, to, of, and, that, have, with)が2語も含まれない、といった条件で落とします。
このルール群は、内容の良し悪しを判定していません。見ているのは「壊れた文書の形」です。キーワードを羅列したSEOページ、文字化け、商品リストだけのページは、読まなくても形で分かります。
(4) 統計・学習ベース — CCNetはWikipediaで訓練した5-gram言語モデル(KenLM)でパープレキシティを測り、文書を3層に振り分けました。さらに進むと分類器を使います。GPT-3は人手でキュレートされたテキストを正例、素のCommonCrawlを負例として分類器を訓練。FineWeb-EduはLLMに「教育的価値があるか」を採点させ、その採点で軽量な分類器を訓練して1.3Tトークンを抽出しました。副題の「教科書品質へ」はこの流れです。
ただし禁止語リストが特定の方言やコミュニティの文章を不均衡に落とす、という指摘もあります。フィルタの設計は、そのままモデルが見る世界の偏りになります。
第2の関門: 重複除去
Webには同じ文章が何度も現れます。同じ文書がn回現れればそこだけn回学習したのと同じで、Leeらは重複除去したデータで訓練したモデルは訓練文を逐語で吐く頻度が桁違いに減ったと報告しています。ベンチマークの問題文が転載されていれば評価が汚染されます。
完全一致は文書全体のハッシュなら簡単ですが、厄介なのは一部だけが共通なケースです。接尾辞配列で一定長(例: 50トークン)以上の共有部分文字列を検出して切り取ります。C4の中に61単語の同じ英文が6万回以上現れていた、という報告もあります。
近似重複は1語違い・広告の位置違いで、完全一致では捕まりません。ここでMinHashを使います。文書を、連続するn単語の組(shingle、5-gram程度)の集合に変換し、重なりで似ている度合いを測ります。
と は各文書のshingle集合、 はJaccard係数です。言い換えると「両方に出てくるかけら」÷「どちらかに出てくるかけら」。同一なら1、共通ゼロなら0です。
問題は全ペアで計算できないことでした。集合の全要素にハッシュ関数 をかけ、その最小値だけを取り出すと、次が成り立ちます。
つまり「最小値がたまたま一致する確率」がそのままJaccard係数になる。 の中で最小値を取る要素がどれかは等確率で、それが に属していれば両者の最小値は一致するからです。これで可変長の文書を短い署名に潰せます。
import numpy as np
def minhash_signature(text, num_perm=128, ngram=5, seed=0):
words = text.split()
shingles = {" ".join(words[i:i+ngram]) for i in range(len(words)-ngram+1)}
a, b = np.random.default_rng(seed).integers(1, 2**61-1, (2, num_perm))
sig = np.full(num_perm, 2**61-1, dtype=np.int64)
for s in shingles:
x = hash(s) & 0x7FFFFFFF
sig = np.minimum(sig, (a * x + b) % (2**61-1)) # 各ハッシュ関数の最小値
return sig
署名同士の総当たりも避けたいので、署名を 個のバンド(各 行)に分け、バンドごと完全一致したペアだけを候補にします(LSH)。候補になる確率 は に対してS字を描くので、 と が「どれくらい似ていたら重複か」の閾値になります。同じ土台の話はハッシュと近傍探索でも扱っています。
現場の知見も一つ。FineWebのチームは、全snapshotをまとめて除去するより、snapshotごとに個別に除去したほうが下流タスクの性能が良かったと報告しています。全体で除去すると、残るのが「誰も転載しなかった」文書に偏るためです。除去は強いほど良い、ではありません。
第3の関門: どう混ぜるか
最後は混合比です。The Pileが示したのは「Webだけでは足りない」という設計思想で、22種類のサブセット(学術論文、GitHub、特許、字幕、数学など)を意図的に混ぜています。
そして量が多いものに大きな重みを置くわけではありません。GPT-3の配合表では、フィルタ済みCommonCrawlは410Bトークンあるのに学習トークンの60%、Wikipediaは3Bしかないのに3%。結果としてCommonCrawlは0.44エポック(読み切らない)、Wikipediaは3.4エポック読まれます。小さくて質の高い山を、意図的に厚く読ませているわけです。
多言語データでは、この配分を式で決めるのが定番です。
は言語 のデータ量、 はサンプリング確率、 は0〜1の指数です。 なら量そのままの比率、 なら全言語を均等に扱う(mT5やXLM-Rでは0.3前後)。要するに、 を下げるほど少数言語がかさ増しされる。この「尖らせる/平らにする」感覚は、softmaxの温度とまったく同じです。
近年は学習の後半で高品質データの比率を上げる手法(アニーリング)も報告されています。受験直前に過去問だけをやるのと同じ発想です。
出荷前の2工程と、エポックの上限
評価用テストセットと一定長のn-gram(GPT-3では13-gram)が重なる学習文書を除く汚染除去と、メールアドレス・電話番号などを正規表現でマスクする個人情報除去は必須です。
そして「データが尽きたら何周させていいか」。Muennighoffらのデータ制約下のスケーリング則では、おおむね4エポックまでは新規データの追加とほぼ同等の効果があり、それを超えると急速に価値が落ちると報告されています。エポックを増やせばいい、は限度つきでしか成り立ちません。
現場ではこう使う
誰がやるか: 基盤モデルを作るチームのデータエンジニア、または特定ドメイン(医療・法務・社内文書)向けに継続事前学習を行う受託開発。後者は規模が小さいだけで工程は同じで、社内文書は重複だらけなので除去がよく効きます。
触るツール: trafilatura(本文抽出)、fastText の lid.176(言語判定)、KenLM(パープレキシティ)、datasketch や text-dedup(MinHash/LSH)、HuggingFaceの datatrove やAI2の dolma(パイプライン全体)。
触るパラメータ名: num_perm(ハッシュ本数、128前後)、threshold(Jaccard閾値、0.7〜0.85あたり)、ngram_size(shingle長、5前後)、min_doc_words / max_doc_words、言語判定の閾値、混合の alpha。
知らないと事故になる落とし穴:
- WETで済ませる — 上流の抽出品質が全工程の天井になる
- 工程の順序 — フィルタで落とす文書に重い重複除去を先にかけると、計算を丸ごと捨てる
- seedを記録しない — ハッシュのseedが変われば残る文書が変わる。データセットは再現できて初めて資産
- decontaminationの忘れ — 社内ベンチのスコアが不自然に跳ね、外部評価で必ず崩れる
- トークナイザの後差し替え — トークン数の見積もりがずれる。データ量の計算はトークナイザ確定後が原則
- 落とした側を人間が読まない — フィルタの偏りは、捨てたサンプルを目視しないと発見できない
設計問として問われる形: 「1兆トークンの重複除去をどう設計するか」。筋道は、shingle化 → MinHash署名 → LSHでバンド分割して候補を絞る → Union-Findで連結成分にまとめ各クラスタから1本残す、分散はバンドのハッシュ値をシャッフルキーにする、です。
まとめ
- 工程は 本文抽出 → 品質フィルタ → 重複除去 → 混合比 の4段。上流ほど安く、上流ほど効く
- 品質フィルタは「壊れた文書の形」を見るルールから始め、統計量、分類器へと段階的に賢くする
- 重複除去はMinHash+LSHで候補を絞る。ただし強ければ良いわけではない
- 混合比は量に比例させない。小さくて質の高い山を厚く読ませる
ここまでで「文章の続きを書ける」モデルはできますが、まだ指示には従いません。その先はInstruction Tuning と RLHFで扱っています。
コメント
コメントにはログインが必要です