なぜ汚染が起きるのか
LLM の事前学習コーパスは数兆トークン規模で、Common Crawl、GitHub、arXiv、Stack Exchange などを含む。公開ベンチマークはほぼ確実にこの中に混入している。GSM8K の問題文、MMLU の選択肢、HumanEval の関数シグネチャが学習データに含まれると、モデルは「解く」のではなく「思い出す」ことで高得点を出し得る。これを dataset contamination、または test set leakage と呼ぶ。
主要ベンチマークの汚染状況
- 年の複数の監査研究が、以下を報告している。GSM8K は問題文を逐語検索で容易に見つけられる。MMLU は問題・選択肢・正解の組がまとまって web 上に存在する。HumanEval は関数名と docstring が GitHub 上で露出している。SWE-Bench はリポジトリベースで issue/PR ごとまるごと学習される危険があり、「過去の自分の修正を思い出す」形での高スコアが懸念される。ベンダー側も対策を進めているが、完全な除去は事実上不可能だと報告される。
Canary String という古典的対策
BIG-bench が導入した canary string（「この UUID を含むテキストは評価用なので学習に入れないでください」）は、データ提供者側の対策として広く採用された。しかしこれは自己申告に近く、ベンダーが遵守するかは監査不能だ。さらに、ベンチマークが翻訳・改変されて再配布されると canary が剥がれる。必要条件ではあるが十分条件ではない。
LiveBench：時間軸で汚染を回避する
White、LeCun、Goldblum らが立ち上げた LiveBench は「毎月新しい問題を追加し、古い問題を徐々に引退させる」運用で汚染を構造的に避ける。ニュース記事からの要約、数学競技の新問題、最近公開された論文に基づく質問などを混ぜる。モデルが学習済みデータを持たない時期の問題で評価されるため、記憶での得点が難しい。欠点は問題の難易度・分布が月次で揺らぐことで、絶対スコアより同一月内の相対比較に向く。
自社ホールドアウトという最終防衛
本当に信頼できる評価は、社外に出していない私的データセットで測ることだ。実装ポイントは (1) 公開されない URL・S3 バケットに置く、(2) 評価 API は入出力をログせず即捨て、(3) スコアの数値のみを社内共有、(4) 問題文を含めた blog や slide を公開しない、の 4 点。さらに、同じデータを月次でローテーションし、特定のホールドアウトが長期的に「使い込まれる」ことも避ける。
実務的組み合わせ
- 年現在、以下の三段構えが現実解と報告される。第一段は公開ベンチマークをベースラインとして走らせる（汚染込みで相対傾向を見る）。第二段は LiveBench 等の時間軸ベンチで汚染フリーの目安を得る。第三段は自社ホールドアウトで本番想定タスクの精度を測る。どれか一つに依存するのではなく、差分と整合性を見ることで汚染のシグナルを検出する。