目次
背景
- 機械学習では、データを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）