機械学習における評価指標の再考

Sat, 05 Sep 2026 12:00:00 +0900

背景

機械学習では、データをTrain・Validation・Testの3つに分けるのが定石とされている
Trainでモデルを学習し、ValidationでハイパーパラメータやEarly Stoppingを決め、最後にTestで未知データに対する性能を測るという構造
しかし実際にシステムを開発していると、この3分割だけでは説明できない問題にぶつかることがある
特に「Testで失敗している理由を知りたいが、Testを見て改善した瞬間、そのTestはもはやTestではなくなる」という問題がある
ここでは、Train・Val・Testという古典的な3分割を、DevとChallengeを加えた5つの役割に拡張して整理する

Train・Val・Testの役割

まず、通常の3分割それぞれの役割を整理する。

Train

モデルのパラメータを学習するためのデータ。以下の式で表される、学習データ上での損失を最小化するパラメータ$\theta^*$を求めるために使う。

$$ \theta^* = \arg\min_\theta \hat{R}_{\text{train}}(\theta) $$

Validation

モデルそのものではなく、学習方法を選択するためのデータ。

Learning Rate
モデルサイズ
正則化係数
Data Augmentation
Early Stopping
モデルアーキテクチャ

これらを選ぶために使う。つまりValidationも、広い意味では学習プロセスの一部といえる。

Test

最後までモデル開発から隔離し、最終的な汎化性能を測定するためのデータ。

Testを見て意思決定してはいけないという原則が重要
Testを見ながらモデルを改善すると、モデルの重みを直接学習していなくても、開発者自身がTestに適応してしまう
結果として、Testへの「開発プロセス全体の過学習」が起きる

Train分布と本番分布が違うという問題

古典的なTrain・Val・Testの説明には、以下のような暗黙の仮定がある。

$$ P_{\text{train}} \approx P_{\text{val}} \approx P_{\text{test}} \approx P_{\text{deployment}} $$

しかし、実運用ではこの仮定は頻繁に崩れる。

TrainはWeb画像だが、本番はスマートフォン画像
Trainは過去のユーザーだが、本番は将来のユーザー
Trainはある病院のデータだが、本番は別の病院
Trainはある国のデータだが、本番は別地域
Train時とDeployment時で商品の構成が変わる

WILDSベンチマークは、病院・撮影場所・時間・地域など、実世界で自然に発生するDistribution Shiftによって、In-distribution性能とOut-of-distribution性能の間に大きな差が生じることを示している。つまり、以下の不等式で表される状況は例外ではなく、実世界ではかなり普通に起きる。

$$ P_{\text{source}} \neq P_{\text{target}} $$

Testのパラドックス

例えば、最終Testで性能が大きく低下したとする。Val Accuracyが94%なのに、Test Accuracyが72%だったとすると、開発者は当然「なぜ22ポイントも落ちたのか」を知りたくなる。そこでTestデータを見ると、以下のようなことが分かる。

暗い画像で失敗している
特定の端末だけ性能が低い
特定カテゴリのRecallが悪い
Trainに存在しない背景が多い

これがError Analysis。この分析結果を元に、暗所画像をTrainに追加する、Augmentationを変更する、ラベル設計を変更する、モデル構造を変更する、といった改善を行う。

しかし、この瞬間に問題が起きる。

Testから得られた情報でモデルを改善した以上、そのTestはもう完全なBlind Testではない
形式的にモデルパラメータへTestを入力していなくても、Test→人間→モデル設計という情報経路が成立している
つまりTestは、実質的にDevelopment Setになってしまう

Target側にもDevを作る

ここで自然な解決策として、Source側だけでなくTarget側も分割するという発想が出てくる。

Source側: Train、Val
Target側: Dev、Test

という構造になる。

devとtestの違い

Dev

DevはTarget distributionを理解するためのデータで、開発者が見てよい。サンプルを直接確認し、以下のような分析をする。

Failure Mode
Slice別性能
分布差
ラベル問題
Spurious Correlation

Devから得られた知見は、Trainへ戻して改善に使う。

Test

Target distributionから採取するが、最後までBlindにする
最終的に、「Devを見ながら作った開発プロセスが、別のTargetサンプルにもGeneralizeしたか」を確認する
つまり、Train→Val→Dev→Error Analysis→Trainという改善ループと、Model→Blind Testという最終評価を分離する構造になる

Devだけでも足りない理由

もう一つ問題がある。平均的なDev performanceだけでは、モデルが持っている重要な弱点を発見できないことがある。

例えば自動運転モデルで、全体のAccuracyが99.5%だったとする
夜間・豪雨・逆光・工事現場・子どもの飛び出しといった状況だけで極端に性能が低ければ、実運用では重大な問題になる
しかし、これらが通常データの0.1%しか存在しなければ、平均Accuracyではほとんど見えない

そこで必要になるのがChallenge Set。

Challenge Setは分布を代表する必要がない

Challenge Setは、通常のTestとは目的が違う。Testは、以下のようにdeployment分布を代表することを目指す。

$$ P_{\text{test}} \approx P_{\text{deployment}} $$

一方Challengeは、必ずしもDeployment distributionを代表しなくてよい。むしろ意図的に難しいケースを集める。目的が違うため、以下のように分布が一致していなくても構わない。

$$ P_{\text{challenge}} \neq P_{\text{deployment}} $$

Challengeの目的は、平均性能を推定することではなく、特定の能力・弱点を診断すること。

ImageNet-Aのような研究はこの発想の典型例
通常のImageNetとは異なり、既存モデルが失敗しやすい自然画像を意図的に集めることで、平均的なテストセットでは見えにくいモデルの弱点を明らかにする
Challengeは1つである必要もなく、Failure Modeごとに複数持ってもよい
- Challenge（低照度）
- Challenge（レアクラス）
- Challenge（OOD）
- Challenge（ロングテール）

5つの役割

ここまで整理すると、評価データは以下のようになる。

Dataset	主目的	開発者が見るか	モデル改善に使用するか
Train	Parameter Learning	Yes	Yes
Val	Model Selection	Yes	Yes
Dev	Error Analysis	Yes	Yes
Challenge	Failure-mode / Capability Evaluation	Yes	Yes
Test	Final Generalization Estimate	No	No

つまり、Train・Val・Dev・Challenge・Blind Testという構造
ただし、これは「データを機械的に5分割せよ」という意味ではなく、重要なのはそれぞれの役割を分離すること

ValとDevの違い

一見するとValとDevは同じものに見え、実際に多くの文献ではValidation SetとDevelopment Setがほぼ同義語として使われる。ここではあえて分離して考える。

Val: どのモデルを選ぶかを決めるためのデータ
Dev: なぜ本番で失敗するのかを理解するためのデータ

例:

例えば、Val AccuracyでModel Aが91.2%、Model Bが92.1%ならModel Bを選ぶ
これがModel Selection
一方Devでは、「Model Bは平均では良いが、夜間画像ではModel Aより悪い」といった分析をする
これがError Analysis
つまり、ValとDevは役割が異なる

ChallengeとDevの違い

Devは、Target distributionをなるべく代表する。一方Challengeは、意図的に分布を歪める。

例えば本番データで、通常画像98%・夜間1%・豪雨0.5%・逆光0.5%だったとする
Devではこの比率をある程度維持する
しかしChallengeでは、夜間33%・豪雨33%・逆光34%のように歪めてもよい

なぜならChallengeはPopulation Performanceではなく、Capabilityを測っているため。

既存研究との関係

ここで整理した5つの役割そのものが、機械学習の標準規格として確立されているわけではなかった
むしろ、既存研究で別々に議論されてきた問題を、1つの開発フローとして整理したものと考える方が正確

先行研究のTopics:

分布シフト（WILDS）
- Koh et al.のWILDSは、現実世界ではTraining distributionとDeploymentに近いTest distributionが異なることを明示的に扱っている
- 病院、地域、時刻、カメラなどによる実世界のDistribution Shiftをベンチマーク化しており、Source/Targetを分けて考える必要性を示している
Target performanceの推定（Mandoline）
- Chen et al.のMandolineは、SourceとTargetの分布差を、実務者が定義したSliceを利用してTarget上の性能推定に利用する
- 「Target distributionを単一のAccuracyだけではなく、その構造を見ながら評価する」という、Dev的な発想に近い
分布シフトに対するStress Test
- Subbaswamy et al.は、単一の評価分布で平均性能を見るだけでなく、分布を変化させた際のモデルのRobustness・Stabilityを評価する枠組みを提案している
- Challenge SetやStress Testingの考え方と接続する
Challenge Set（ImageNet-A）
- Hendrycks et al.のImageNet-Aは、既存モデルが失敗しやすい自然画像を意図的に集めることで、通常のTest Accuracyでは見えにくい弱点を評価した、Challenge evaluationの分かりやすい例
Testから学習してしまう問題
- Hernández-Orallo et al.は、AI evaluationを単一のAggregate Metricに潰すことの問題を指摘している
- つまり、SystemとProblemの組み合わせに対するより詳細な評価情報を利用する考え方を議論している
- タイトル自体が「Training on the Test Set」であり、評価データからどこまで情報を抽出してよいかという問題を正面から扱っている

SourceとTargetによる分類

以下のような定義になる。

Train・Val:
- Source distributionからサンプリング
Dev・Test:
- Target distributionからサンプリング（Devは見てよい、Testは見てはいけない）
Challenge:
- Target（デプロイ環境）に関連するが、意図的に分布を歪めて集める
- 「独立」というより「Target寄りだが非代表的」という位置づけ

本質はInformation Boundary

ここで一番重要なのは、Train・Val・Dev・Challenge・Testという名前ではない。

本質は、どの評価情報を開発プロセスへフィードバックしてよいのかというInformation Boundary
モデル開発は、Data->Metric->Human->Decision->Modelというループで進む
そのため、「モデルのWeight Optimizerに渡していないからTest leakageではない」とは限らない
人間がTest結果を見てArchitectureを変更すれば、それも立派な情報伝達になる
したがって評価セットは、まずDevelopmentに利用してよいデータと、Developmentから完全に隔離するデータに分ける必要がある
その上でDevelopment側を、Parameter Learning・Model Selection・Error Analysis・Capability Analysisに分けると、Train・Val・Dev・Challengeが生まれ、最後にBlind Testを置く、という構造になる

まとめ

機械学習ではTrain・Val・Testの3分割が基本とされているが、実運用では学習分布と本番分布が一致しないことが珍しくない
Testで性能が低下した理由を知るにはTarget側のデータを観察する必要があるが、Testを観察して改善に利用すると、そのTestはもはや完全なTestではなくなる
そこでTrain・Val・Dev・Challenge・Testという役割分離を考える
- Train: モデルを学習する
- Val: モデルを選択する
- Dev: 本番分布での失敗を理解する
- Challenge: 重要なFailure Modeを集中的に診断する
- Test: 最後までBlindにして最終性能を測る
Source側からTrainとVal、TargetからTest、それと独立したDevとChallenge
これはデータ分割のテクニックというより、機械学習開発における情報の流れを設計する問題
本当に守りたいのは、モデル改善に使った情報と最終評価に使う情報を分離すること

参考文献

WILDS: A Benchmark of in-the-Wild Distribution Shifts（Koh et al., ICML 2021）
Mandoline: Model Evaluation under Distribution Shift（Chen et al., ICML 2021）
Evaluating Model Robustness and Stability to Dataset Shift（Subbaswamy et al., AISTATS 2021）
Natural Adversarial Examples（Hendrycks et al., CVPR 2021, ImageNet-A）
Training on the Test Set: Mapping the System-Problem Space in AI（Hernández-Orallo et al., AAAI 2022）
The Effect of Natural Distribution Shift on Question Answering Models（Miller et al., ICML 2020）

Evaluation on M1KE BL0G

機械学習における評価指標の再考

背景

Train・Val・Testの役割

Train

Validation

Test

Train分布と本番分布が違うという問題

Testのパラドックス

Target側にもDevを作る

devとtestの違い

Dev

Test

Devだけでも足りない理由

Challenge Setは分布を代表する必要がない

5つの役割

ValとDevの違い

ChallengeとDevの違い

既存研究との関係

SourceとTargetによる分類

本質はInformation Boundary

まとめ

参考文献