新しいモデルが発表されるたび、ベンチマークのスコアが並んだ比較表を見かけます。
その数字だけを根拠に「こちらのモデルのほうが賢い」と決めてよいのか、前から引っかかっていました。
引っかかりの正体がベンチマーク汚染（benchmark contamination）と呼ばれる現象でした。
テストとして使うはずの問題が、学習データの中に混ざってしまうことを指しています。
スコアが高いのは賢いからではなく、答えを見たことがあるから、という可能性が残るわけです。
私自身もモデル選定でスコア表を眺める機会が増えたので、一次情報をたどって整理しておきました。
ベンチマークは「答えが公開されているテスト」
ベンチマークとは、モデルの能力を同じ物差しで測るための問題集です。
学校の試験と同じで、受験者が事前に答えを知っていれば点数は意味を失うという前提があります。
ところが大規模言語モデルの学習データは、Web 上の膨大なテキストをかき集めて作られました。
ベンチマークの問題と正解も、多くは GitHub や論文サイトで公開されています。
その結果、試験問題が学習データの中に最初から置かれている状態になりやすくなります。
この現象はデータ汚染（data contamination）やテストセット漏洩（test set leakage）とも呼ばれ、資料によって呼び名が揺れます。
2025年に公開された調査論文 A Survey on Data Contamination for Large Language Models では、汚染の検出手法と緩和策が体系的に並べられました。
汚染は「不正」ではなく事故として起きる
汚染と聞くと、開発者がわざとテスト問題を混ぜた不正を想像するかもしれません。
実際には意図しない事故として混入するケースのほうが多いとされています。
学習データは数兆トークン規模になるため、中身を人間が一件ずつ確認できません。
ベンチマークの問題文は、解説ブログ・技術記事・Q&A サイトに形を変えて何度も転載されます。
元データを除外しても、言い換えられた派生物まで消すのは現実的に難しいところです。
さらに、モデルの学習データが公開されていない場合、外部からは混入の有無を確かめる手段がありません。
だからこそ汚染は「あるかないか」ではなく「どれくらいありそうか」で見る性質の問題になります。
同じ難易度の新問題で測り直した GSM1k
汚染の影響を測った研究として、よく参照されるのが GSM1k です。
小学校レベルの算数の推論力を測る GSM8k というベンチマークがあり、これは以前から広く使われてきました。
研究チームは GSM8k と同じ様式・同じ難易度の問題を人手で新しく作り、GSM1k と名付けています。
学習データに絶対に含まれていない問題で測り直せば、暗記と推論を切り分けられるという発想でした。
論文 A Careful Examination of Large Language Model Performance on Grade School Arithmetic によれば、GSM1k での精度は最大で 8% 下がりました。
いくつかのモデル系列では、ほぼすべてのサイズで組織的な過学習の兆候が見つかっています。
さらに、GSM8k の問題文をそのまま吐き出しやすいモデルほど、2つのベンチマークの差が大きいという相関（スピアマンの順位相関にもとづく決定係数で 0.36）も報告されました。
一方で最先端モデルは過学習の兆候がほとんど見られず、すべてのモデルが未知の問題にも一定の汎化を示したという結果も同時に示されています（論文 A Careful Examination of Large Language Model Performance on Grade School Arithmetic）。
汚染に強いベンチマークはどう作られているか
対策の方向はいくつかあり、実際に運用されている手法も出てきました。
ひとつは、問題を定期的に差し替え続ける方式です。
LiveBench は新しい問題を定期的に追加し、出題元を最近の論文やニュース記事などに置くことで、過去の学習データとの重なりを避けようとしています。
README は「毎月」の追加をうたっていますが、公開されている changelog の最新の項目は 2026年1月8日で、2026年9月時点ではそれ以降の追加がありません。
LiveCodeBench も同じ発想で、公開日が分かるコンテスト問題を使い、モデルの学習データ締め切り以降の問題だけを取り出して評価できる作りです。
もうひとつは、問題と正解をそもそも公開しない非公開ホールドアウト方式になります。
ただし非公開にすると、第三者が結果を再現できなくなるという別の問題が出てきます。
再現性と汚染耐性はトレードオフの関係にあるため、どちらを取るかは評価の目的しだいです。
自分の業務データで測る独自評価を併用するのも、現実的な逃げ道になります。
ただ、手元のデータで測るときも、正例と負例を別々の時期に集めていると、分類器が中身ではなく集めた時期の違いを覚えて、点数が高く出ることがあります。
画像の好みを学ぶ分類器で AUC 0.99 が出て、その正体が時代差のリークだった例を、別の記事にまとめました。
スコアを読むときに確認したい3点
比較表を渡されたとき、私が見るようにしている観点は3つあります。
1つ目はそのベンチマークがいつ公開されたかの確認です。
公開から年数が経った有名ベンチマークほど、解説記事や再掲によって汚染の機会が積み上がっています。
2つ目は、複数のベンチマークで順位が揃っているかどうかです。
1つのベンチマークだけ突出して高い場合、その問題集に最適化された可能性を疑う余地があります。
3つ目は、自分の使い方に近いタスクで小さく試すことです。
汎用ベンチマークの順位と、自社データでの使い勝手は一致しないことがあるからです。
AI に AI を採点させる評価方法も広がってきたので、そちらの仕組みも合わせて押さえておくと判断の幅が広がります。
検索と生成を分けて測る RAG の評価についても、別の記事で扱いました。
最後に
ベンチマーク汚染は、テスト問題が学習データに紛れ込んでスコアが実力より高く出る現象です。
不正よりも事故として起きることが多く、学習データが非公開なら外部から検証もできません。
だからスコアは絶対値ではなく、条件つきの参考値として読むことが大切です。
新しい問題で測り直す取り組みは進んでいるので、ベンチマークの公開日と更新方針を見る習慣をつけておくとよいでしょう。
以上です。
コメントを残す