データ汚染検出とドメイン横断性能：ベンチマークを信じる前に確認すること

LLM の評価では、スコアが高いのに実運用では弱い、というズレが起きがちです。原因としてまず疑うべきなのが、学習データとテストデータの重複です。さらに、同じモデルでもドメインが変わると性能が落ちるため、汚染の有無とドメイン横断性能を分けて見る必要があります。

この記事では、データ汚染の見つけ方と、In-domain / Out-of-domain / ロバスト性の見方を整理します。評価指標そのものを作る話ではなく、すでにあるベンチマークをどう読み替えるかに絞ります。

実務で難しいのは、数字が出たあとに「そのスコアをどこまで信用してよいか」を判断することです。公開ベンチマークに学習データが混ざっていれば、見かけの性能は上がります。一方で、汎用モデルでもドメインが変わると急に弱くなることがあります。つまり、評価は単なる正答率ではなく、汚染と一般化の両方を確認して初めて意味を持ちます。

観点	見るもの	失敗しやすい点	主な対策
データ汚染	学習データとテストデータの重複	スコアの過大評価	N-gram、embedding、手動確認
In-domain 性能	同一ドメイン内での一般化	タスクが変わると落ちる	同ドメイン別タスクで比較
Out-of-domain 性能	ドメインをまたいだ一般化	実運用で急に弱くなる	別ドメインで再評価
ロバスト性	ノイズや入力揺れへの耐性	形式が少し変わるだけで崩れる	typo / OOD / adversarial テスト

この整理ができると、ベンチマークの数字をそのまま信じるのではなく、「何に対して強いのか」を見分けやすくなります。以下ではまず、なぜ汚染とドメイン横断性能を分けて考える必要があるのかを確認し、そのあとに検出方法と運用手順を見ていきます。

1. Why: なぜ汚染と一般化を分けて見るのか

1.1 ベンチマークが高いだけでは足りない

公開ベンチマークで高得点が出ても、それだけで真の性能とは言い切れません。学習時にテスト問題を見ていた場合、モデルは知識を理解したというより、答えを覚えていた可能性があるからです。

たとえば、MMLU や SQuAD の一部が事前学習データに含まれていたとすると、スコアは実力以上に見えます。これがデータ汚染です。汚染があると、比較の土台そのものが崩れるため、モデル選定や論文比較の前に確認しておく必要があります。

1.2 ドメインが変わると性能は落ちる

汚染がなくても、学習ドメインと評価ドメインが違えば性能は変わります。たとえば、一般ニュースで学習したモデルを医学や法律で評価すると、用語の使い方や推論の前提が変わるため、同じスコアは出にくくなります。

ここで大事なのは、低下そのものを失敗と決めつけないことです。むしろ、どの条件でどれだけ落ちるかを見れば、モデルの得意領域と弱点が分かります。

1.3 汚染とドメイン差は別の問題

この 2 つは似ていますが、意味は違います。汚染は「見てはいけないデータを見ていたか」、ドメイン差は「見たことのない条件でどれだけ耐えられるか」です。片方だけ見ても評価は不十分です。

問題	何が起きるか	典型的な症状
データ汚染	テストデータを事前に学習してしまう	スコアが不自然に高い
ドメイン差	学習時と評価時の分布が違う	別領域で性能が落ちる
ロバスト性不足	ノイズや形式差に弱い	軽い入力変化で崩れる

2. What: データ汚染とドメイン横断性能の見方

2.1 データ汚染とは

データ汚染（Data Contamination）とは、学習時に使ったデータと評価時に使うベンチマークデータが重複している状態です。完全一致だけでなく、言い換えや近い表現まで含めると、汚染の範囲は広くなります。

汚染の種類は、ざっくり次のように分けて考えられます。

種類	例	なぜ危険か	検出の考え方
完全一致	文章がそのまま含まれている	暗記と実力が区別できない	N-gram で照合する
近似重複	句読点や語順だけ違う	見た目は違っても実質同じ	長めの N-gram で比較する
意味的重複	言い換え・パラフレーズ	完全一致では見逃す	embedding 類似度を見る
時間的漏洩	公開前の答えを学習している	将来情報を先取りしてしまう	データ取得時点を確認する

2.2 汚染検出の主な方法

汚染検出は 1 つの方法だけでは不十分です。まず粗く絞り、そのあとで意味的な近さを確認する多段構えが現実的です。

方法	強み	弱み	向いている場面
N-gram 監査	速い、実装しやすい	言い換えに弱い	大規模コーパスの一次スクリーニング
長い N-gram	近似一致に強い	完全な言い換えは見逃す	ベンチマーク本文の重複確認
Embedding 類似度	意味的重複を拾いやすい	計算コストが高い	パラフレーズの検出
手動レビュー	最終確認として強い	時間がかかる	疑わしいケースの確定

実務では、まず N-gram で候補を絞り、そのあと embedding で意味的な重なりを見て、最後に人手で確認する流れが扱いやすいです。いきなり全件を人手で見ようとすると、コストのわりに再現性が落ちます。

2.3 ドメイン横断性能とは

ドメイン横断性能は、学習した条件と違う条件でも性能を保てるかを見る指標です。よく見るのは、In-domain、Out-of-domain、ロバスト性の 3 つです。

観点	意味	見るポイント
In-domain	学習時と近いドメインでの性能	その領域の基本性能を確認する
Out-of-domain	まったく別のドメインでの性能	汎用性がどれだけあるかを見る
ロバスト性	ノイズや揺れに対する強さ	形式変化への耐性を見る

In-domain が高くても Out-of-domain が弱いなら、特定領域に寄りすぎている可能性があります。逆に、Out-of-domain でも落ちにくいモデルは、運用先の変化に対応しやすいと考えられます。

2.4 低下率で見ると分かりやすい

一般化性能は、絶対値だけでなく低下率で見ると判断しやすくなります。

$$ \text{低下率} = \frac{\text{In-domain} – \text{Out-of-domain}}{\text{In-domain}} $$

低下率	受け取り方
15% 未満	汎用性が高い
15〜25%	中程度の汎用性
25% 超	ドメイン依存が強い可能性がある

この数値は絶対基準ではありませんが、比較の起点にはなります。重要なのは、ドメインが変わったときにどの程度崩れるかを、毎回同じ尺度で見られるようにすることです。

3. How: 実務での確認手順

3.1 まず評価条件を固定する

最初にやるべきなのは、ベンチマーク名ではなく評価条件を固定することです。データの取得時点、前処理、プロンプト、デコード設定が揃っていないと、汚染の有無も一般化性能も比較しにくくなります。

固定する項目	理由
データ取得時点	時間的漏洩を避けるため
前処理ルール	余計な差分を消すため
評価プロンプト	条件差でスコアが揺れないようにするため
デコード設定	生成のばらつきを抑えるため

3.2 汚染を先に疑う

スコアが高く出たときは、まず汚染を疑う方が安全です。とくに公開データセットで異常に高い点が出た場合は、単純にモデルが強いのではなく、評価データに似た例を学習していた可能性があります。

確認の順番は次の通りです。

完全一致の重複を確認する
長めの N-gram で近似一致を見る
embedding 類似度で言い換えを探す
疑わしい例を人手で確認する

3.3 ドメインをずらして再評価する

次に、同じモデルを別ドメインで再評価します。たとえば、ニュース中心のモデルを医学、法律、金融、サポートログなどで試すと、どの領域で落ちやすいかが見えてきます。

結果	読み方
In-domain は高いが Out-of-domain が低い	特化は強いが汎用性は弱い
両方高い	比較的バランスが良い
両方低い	基本性能が不足している
ノイズで大きく崩れる	ロバスト性が足りない

3.4 判定は 1 つの数字で決めない

汚染の有無、Out-of-domain の低下率、ノイズ耐性をまとめて見ると、モデルの性格が分かりやすくなります。単一のスコアだけで判断すると、強みと弱みを取り違えやすくなります。

状況	ありがちな解釈	実際に疑うこと
高スコアだが別ドメインで落ちる	強いモデルに見える	ドメイン依存が強い
高スコアだが汚染候補が多い	実力があるように見える	データ重複の可能性
ノイズで急に崩れる	たまたま良い結果に見える	ロバスト性不足
全体的に安定	実運用に向いていそう	追加の安全性確認を行う

3.5 リリース前の最低限チェック

実装や運用に入る前に、少なくとも次の 4 点は確認しておくと安全です。

評価データが学習データと重複していないか
同じモデルを別ドメインでも測っているか
ノイズ入力で極端に崩れないか
数字の比較条件がそろっているか

これらが抜けると、評価の解釈がぶれやすくなります。特に公開ベンチマークは、スコアの高さだけで判断すると過大評価につながりやすいです。

4. Next action: 次にやること

次にやることは、評価対象を 1 つ決めて、汚染チェックとドメイン横断テストを同時に回せる形にすることです。具体的には、同じモデルに対して、同一ドメイン、別ドメイン、ノイズ入力の 3 種類を並べて見ると判断しやすくなります。

もし最初の一歩で迷うなら、次の順序で十分です。

ベンチマークの取得時点と前処理を固定する
完全一致と近似一致で汚染候補を洗う
In-domain と Out-of-domain を並べて測る
ノイズ入力でも再確認する
低下率を見て、リリース可否を判断する

この記事で押さえたいのは、ベンチマークの数字をそのまま受け取らないことです。汚染と一般化を分けて確認すると、モデルが本当に強いのか、それとも条件に助けられているだけなのかが見えやすくなります。

次の記事では、Attention の可視化と解釈を通じて、モデルの内部で何が起きているかをさらに深く見ていきます。

参考文献

Raffel, C., et al. (2020): “Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer”, JMLR 2020
- https://arxiv.org/abs/1910.10683
Zhang, T., Kishore, V., Wu, F., Weinberger, K. Q., & Artzi, Y. (2020): “BERTScore: Evaluating Text Generation with BERT”, ICLR 2020
- https://arxiv.org/abs/1904.09675
Lin, C. Y. (2004): “ROUGE: A Package for Automatic Evaluation of Summaries”, ACL Workshop 2004
- https://aclanthology.org/W04-1013/

シリーズ案内

ブログD：詳細設計書編では、LLM の評価体系とベンチマーク管理を解説しています。

大規模言語モデル【事前学習：詳細設計書D-3】LLM評価で確認すべきこと