AI > 評価・実験設計 on M1KE BL0G

フリガナデータをクレンジングする時に直した項目のメモ

Fri, 18 Sep 2026 22:00:00 +0900

背景

日本語のフリガナ（読み）予測モデルを作る過程で、訓練データのバグを数え切れないほど直してきた
感覚としては百回近く直している気がするが、量が多すぎて自分でも何が起こって何を直したのかを把握しきれなくなっていた
そこで、実際に手を動かしたプロジェクトの記録を洗い出し、遭遇した問題を体系的に整理し直した

データの問題

遭遇した問題は、大きく「データそのものの中身の問題」と「それを扱う仕組み側の問題」に分けられる。まずは前者から整理する。

文字・表記レベル

これらは比較的機械的に検出・修正できる問題が多い。

全角/半角の不統一

数字・記号・英字が全角と半角で混在して記録され、同じ内容が別表記として扱われてしまう
特に電話番号や日付のような定型的な文字列で起こりやすい

1
2


０３－１２３４－５６７８
03-1234-5678

異体字・旧字体/新字体の不統一

同じ文字が複数の字体で記録され、見た目は近くても別のUnicodeコードポイントとして扱われる
姓名や地名に多く、機械的な正規化だけでは対応しきれないことがある

1
2
3
4


高　（通常の「高」）
髙　（はしごだかの異体字）
辺　（新字体）
邊　（旧字体）

旧仮名遣い/現代仮名遣いの混在

歴史的仮名遣いが現代仮名遣いに正規化されないまま残っている
古い文献由来のデータで特に目立つ

1
2


てふてふ　（歴史的仮名遣い）
ちょうちょう　（現代仮名遣い）

Unicode正規化の不備

見た目は同じ文字でも、結合文字と合字などUnicode上の内部表現が異なる場合がある
文字列としての一致判定が正しく行われず、同じ語が別物として扱われる

1
2


ガ　（単一の合字、U+30AC）
ガ　（「カ」＋結合濁点、U+30AB U+3099）

大字（旧漢数字）の扱い漏れ

壱・弐・参のような大字（旧漢数字）が、通常の漢数字と別表記として扱われ、正規化から漏れる
契約書や領収書のような改竄防止目的の文書に多い

1
2


壱萬円
一万円

英字・頭字語の表記統一の限界

頭字語の大文字/小文字やハイフンの有無が統一されていない
アルファベット部分の読み方自体も語ごとに慣用が異なり、一般化できない
実世界の使用自体が割れているケースを無理に一つの正解に決めてしまうと、それ自体が新たなノイズになる

1
2


K-POP → ケーポップ
J-WAVE → ジェイウェーブ

読み表記レベル

カタカナ/ひらがな表記の不統一

読みをカタカナで統一するかひらがなで統一するかが、データソースによって異なる

1
2


ワタシ
わたし

促音・拗音の表記ゆれ

特にOCR由来のデータで、小書きの「っ」「ゃ」などが通常サイズの文字として誤認識されることがある

1
2


きゃく　（正）
きやく　（誤認識）

長音符の表記ゆれ

長音符の表記が二重・三重に壊れて記録されることがある

1
2


経営 → ケイエイ　（正）
経営 → ケーエイ／ケイエー　（表記ゆれ）

濁点・半濁点の脱落

OCR由来のデータで、濁点・半濁点が読み取れず脱落することがある

1
2


がっこう　（正）
かつこう　（濁点脱落）

意味・文脈レベル

多義語・同綴異訓語の曖昧性

同じ表記でも文脈によって読みが変わる語が数多く存在する

1
2
3


方 → カタ（読み方）／ホウ（方法）
何時 → ナンジ（何時に行く）／ナンドキ（何時だと思ってる）
家 → イエ（家を建てる）／ウチ（家に帰る）

熟字訓と通常の音訓読みの混同

熟語全体で一つの読みが決まる熟字訓が、文字単位の音訓読みと混同され、誤って分解されることがある

1
2


今日 → キョウ　（熟字訓、正）
今日 → コン＋ジツ　（文字単位に誤分解）

固有名詞の読み

人名・地名は、そもそも一意に決まらないことが珍しくない

1
2


東 → アズマ
東 → ヒガシ

機械的なルールで決まる読みと、判断が必要な読みの混同

音韻規則として機械的に決まる読みと、単なる固有名詞混入による統計的パターンを混同すると、誤ったルール化をしてしまう
頻度だけを根拠に一般化すると、後者を誤ってルール化してしまう

1
2


◯分間 → 直前の数字に応じて機械的に決まる音韻規則
右衛門 → 「良右衛門」という一人の人名が繰り返し出現しているだけの統計的パターン

曖昧性そのものの種類分け

曖昧に見える語でも原因は一様ではなく、少なくとも3種類に分けて考える必要がある
この3つを区別しないと、本質的多義型の語に対して「もっとデータを増やせば解決する」という誤った対処をしてしまう

1
2
3


候補漏れ型: 正解の読みがそもそも候補集合に含まれていない
本質的多義型: 文脈をいくら与えても読みが一意に定まらない（英字読みの慣用差を含む）
文脈依存型: 「市場」のように、文脈さえ与えられれば一意に定まる

分割・アライメントレベル

形態素解析の構造的な分割・融合ミス

辞書の語彙不足とは別種の、境界（トークン分割）の問題であり、頻繁に発生した

1
2


何時 → 何 + 時　（意図しない分割）
二十 → 二 + 十　（複数桁数詞の結合失敗）

ラベル位置のアライメントの甘さ

正解の読みを部分文字列の一致だけで判定すると、対応箇所を取り違えることがある
「読みそのものが間違っている」バグとは別軸の、「読みは合っているが対応箇所がズレている」バグ

1
2
3


今日は今日で忙しい
^^^^ 1回目（正解ラベルの本来の対象）
 ^^^^ 2回目（部分文字列一致で誤って紐付けられる）

ソース・アノテーション品質レベル

複数の辞書・コーパス間での読みの不一致

辞書やコーパスによって、同じ語に対して異なる読みが採用されていることがある

1
2


私 → ワタシ　（辞書A）
私 → ワタシ／ワタクシ　（辞書B）

人手アノテーションの入力ミス

単純なタイプミスや読み間違いが、そのままラベルとして記録されてしまう

1
2


よむ　（正）
よぬ　（入力ミス）

ソースの信頼度によるGold/Silverの区別漏れ

単純な二値の区分だけでは不十分で、実際には信頼度を段階的なティアに分けて管理する方が扱いやすい
機械的なクロスチェックを先に流し、意見が割れたものを優先的に人手レビューに回す、という段階的な運用と組み合わせる

1
2
3


gold_verified 読みが一意で人手検証済み
gold_free_variation 本質的に複数の読みがありうる
silver_ambiguous まだ判断がついていない

自動ラベリングツールのバイアスの向きが語や構文によって不規則

ツール全体に対する一般的な補正ルールを当てはめるのではなく、語ごとに確認する必要がある

1
2


語A: 文語的な読みに寄る
語B: 特定の言い回しへの過学習で逆方向に寄る

ルビと原文の対応のズレ

ルビの範囲が実際の熟語の境界とズレて記録されることがある

1
2
3


原文: 山田太郎
ルビ範囲（誤）: 山田太[ろう]
ルビ範囲（正）: 山田[たろう]

分布・統計レベル

クラス不均衡・ロングテール分布による少数派読みの学習バイアス

出現頻度の差が大きいと、少数派の読みが十分に学習されなくなる

1
2


方 → ホウ（多数派）
方 → カタ（少数派、学習不足）

「候補生成漏れ」と「ランカーの多数派バイアス」の混同

前者は辞書へのエントリ追加で解決できるが、後者は正解が候補集合に含まれているにもかかわらず、学習不足な文脈で統計的に優勢な読みへ倒れてしまう問題で、辞書追加だけでは解決しない

1
2


候補生成漏れ: candidates = [ホウ] → 辞書にカタを追加すれば直る
ランカーのバイアス: candidates = [ホウ, カタ] → 追加しても依然ホウを選んでしまう

候補の並び順が暗黙の既定値として使われてしまう問題

呼び出し側が判断に迷った際に先頭の候補へフォールバックする実装は多いが、候補の並び順が実際の多数派の読みと系統的に食い違っていることがある
フォールバック処理そのものを直すより、候補テーブルの並び順自体を実際の頻度に合わせて直す方が、影響範囲が広く効果的

1
2


candidates[0] = ホウ　（テーブル上の並び順）
実際の多数派 = カタ

診断データセットの設計・重複データの扱い

ランダムサンプリングだけでは、少数派の意味的カテゴリを十分にカバーできないため、意図的にカテゴリを設計した診断データセットが必要になる

1
2
3


diagnostic_set:
 熟字訓カテゴリ: 意図的に一定数を含める
 固有名詞カテゴリ: 意図的に一定数を含める

実装・インフラレベル

実装ドリフト

同じ正規化ロジックが複数箇所に個別実装され、一方だけ修正されてもう一方が取り残され、時間とともに挙動が乖離していく
いわば「データのバグ」ではなく「バグを生み出す仕組み側のバグ」

1
2


normalize_choon() # モジュールAで修正済み
normalize_choon() # モジュールBは未修正のまま残存

派生データの陳腐化

「コードを直した」ことと「データが直った」ことは別で、複数の修正が反映されないまま蓄積すると、影響範囲の把握そのものが難しくなる

1

生成元コード修正 → train.jsonl は自動更新されない → 再生成するまで古いラベルのまま

評価インフラ自体のバグ・母集団ドリフト

訓練データだけでなく、物差しである評価パイプライン自体が壊れていないかも確認が必要
意外に大きい数字を見たときほど、まず測定方法自体を疑うべき

1
2
3


「候補に正解が見当たらない」という見た目の大きな問題
 → 実際の原因のほとんどは、評価セットとモデル出力の間の長音符表記のズレ
 → 実質的な問題はごく一部にすぎなかった

カンニング防止の射程

評価データそのものを学習に混入させない、という原則は当然守るべきだが、その射程は評価ファイル本体だけにとどまらない

1
2


eval_set.jsonl 直接の混入対象
tool_docs/schema.md 具体例が埋め込まれた、見落としやすい混入経路

データを直す方法論

個別のバグの分類以上に汎用性が高いと感じたのは、バグをどう見つけてどう直すかという方法論そのもの。

盲検サンプリングとWilson信頼区間

少数のサンプルを見て「綺麗そう」と判断するのは危険で、区間推定をせずに小さいnの結果を信用しないようにする

1

n=100, 誤り=0件 → 「誤り率0%」ではなく、信頼区間の上限を踏まえて判断する

ソース別の層化監査

複数のソースを混ぜてランダムサンプリングすると、量の多いソースに埋もれて、量の少ないソースの汚染を見落とす
ソースごとに独立したサンプルと信頼区間を持つことで、健全に見える全体平均の中に汚染された一つのソースが隠れているケースを検出できる

1
2


ソースA（大量）: n=500, エラー率 0.5%
ソースB（少量）: n=20, エラー率 15% ← 混ぜた平均では見えない

層化サンプリングとランダムサンプリングの往復

既知のリスクがある語を狙い撃ちする層化サンプリングは、既知パターンの再発を効率よく見つけられるが、想定していなかった問題は見つけられない
純粋なランダムサンプリングと交互に行い、両方の死角を補い合う

1
2


層化サンプリング: 過去に問題のあった語を優先的に再チェック
ランダムサンプリング: 誰も疑っていない箇所を無作為にチェック

修正のたびに監査をやり直す

一度きりの監査ではなく、何かを見つけて直すたびに、ゼロからサンプルを取り直して確認する
修正が実際に効いたか、そして新たな問題を持ち込んでいないかを、この再監査で確かめる

「検証済み」も定期的に再監査する

一度「検証済み」に分類したデータも、時間をおいて再度サンプル監査する
「検証済み」は保証ではなく、あくまである時点での確信度に過ぎない

何もなくても定期的に健全性を確認する

既知の問題が特に見つかっていない期間でも、一定のペースでサンプル監査を続ける
何かのトリガーに反応するだけでなく、確信度を維持するための定期点検として運用する

網羅的なシグネチャスキャンとランダムサンプリングの併用

既知のパターンに一致するものを網羅的に検出する方法と、未知のパターンを見つけるためのランダムサンプリングは、どちらか一方では不十分で、両方を使い分ける

1
2


既知パターン（濁点脱落など） → 全件シグネチャスキャン
未知パターン → ランダムサンプリング

独立したクロスチェックソースの利用

単一の辞書・コーパスだけを信頼せず、複数の独立したソースを突き合わせる

1

辞書A + 辞書B + コーパス頻度 → 一致しないものだけを優先的にレビュー

自分自身のノイズフロアを測る

何かを変更してスコアが動いたとき、それが本当に変更の効果なのか、単なる実行間のばらつき（ノイズ）なのかを、同一設定での再実行によって確認する
この確認を怠ると、ノイズを実質的な改善・劣化と誤認し、的外れな判断を積み重ねてしまう

1
2
3


変更あり: score = 0.893
変更なし（再実行1）: score = 0.891
変更なし（再実行2）: score = 0.895

内部矛盾スキャン

同じ表記に対して複数の異なる読みが記録されているケースだけを機械的に抽出し、その組だけをレビューする
全体をランダムサンプリングするより、ずっと高い効率で誤りを見つけられる

1

surface="方" → readings={ホウ, カタ} # レビュー対象として抽出

一括訂正の副作用に注意する

ある語の読みが間違っていたと分かったとき、その語の全出現箇所を一括で訂正すると効率は良いが、別の箇所では実は正しかった、という文脈依存のケースまで巻き込んで壊してしまうことがある
訂正自体が新しい誤りの発生源になりうる

1
2


「方」の誤ラベルを一括でカタ→ホウに訂正
→ 本来カタが正しかった別の出現箇所まで巻き込んで書き換えてしまう

検証ツール自体を疑う

検証ツールは「正しい前提」として扱いがちだが、それ自体もコードである以上、同じ種類のバグを持ちうる

1
2


cross_check_script.py に normalize_choon() と同じバグが混入
→ 大量の偽陽性を生成

表記のズレを見つけたら生データソースまで遡る

訓練データの中で表記が壊れているのを見つけたとき、それが下流の処理で壊れたのか、元の生データの時点でそう記録されていたのかを、まず切り分ける
話し言葉の書き起こしとして元々そう記録されていた場合、それは「バグ」ではなく、正しい実態を反映した表記ゆれということもある

1
2
3


raw_source → 正常
 ↓ 前処理
train.jsonl → 破損　→ 前処理側のバグと判明

コードが物語る大変さ

ここまではbacklog・docs・タスク記録という「言語化された記録」をもとに整理してきたが、実際のコードとテストを読むと、記録だけでは伝わらない大変さが見えてくる。

一つ一つが個別に勝ち取られた事実の集合

補正関数やルックアップテーブルの各エントリは、まとめて取り込んだものではなく、それぞれ個別の調査によって発見・検証された事実
過去の修正が広すぎた、あるいは狭すぎたと後から判明し、範囲を絞り直された跡も残っている

1
2


counter_word_sound_change_table:
 # エントリ1件ごとに、それを発見した具体的な調査の痕跡が残っている

正例と負例をペアにしたテスト

ほぼすべての修正に対して、狭いケースが正しく処理されることを確認するテストと、似ているが別のケースには意図的に手を付けていないことを確認するテストが、ペアで存在する
難しさの本質は「誤りを見つけること」ではなく「他を壊さないように修正の範囲を絞り込むこと」にあり、そのスコープの判断が回帰テストとして恒久的に固定化されている

1
2


test_counter_word_change_applies_to_specific_pattern()
test_counter_word_change_does_not_apply_to_similar_pattern()

先送りにされた妥協がない

TODO・HACK・FIXMEのようなショートカットの印が実質存在しない
見つかった問題は先送りにされず、スコープを絞った修正として実装まで持ち込まれている

モジュールのdocstringが実験ノートとして機能している

ドキュメントというより、試して失敗したアプローチの記録として機能している
複数の補正戦略が試され、悪化したために元に戻された、という記述も残っている

記録は「何を発見したか」を語るが、コード自体は「それぞれの発見を、他を壊さずに正しく直すことの方が、発見そのものよりはるかに労力のかかる半分の作業だった」ことを物語っている。

まとめ

日本語のフリガナデータで実際に遭遇した問題を整理すると、文字・表記、読み表記、意味・文脈、分割・アライメント、ソース・アノテーション品質、分布・統計、実装・インフラという複数のレベルにまたがっていた
特に、形態素解析の分割・融合ミスや、実装ドリフト、評価インフラ自体のバグは、訓練データそのものの中身の問題とは異なる、仕組み側の問題として区別して扱う必要がある
個別のバグより汎用性が高いのは、盲検サンプリング・ソース別の層化監査・Wilson信頼区間・独立クロスチェック・ノイズフロアの計測といった、データを直す際の方法論そのものだった
コードとテストを読むと、誤りを見つけることより、他を壊さずに正しく直すことの方がはるかに労力のかかる作業だったことが分かる
「データが完璧なら性能が出る」という単純な話ではなく、どのレベルで何が壊れているかを見極める継続的な作業そのものが、データを正しくするということの実態だと感じている

参考文献

Binomial proportion confidence interval - Wikipedia

安定化モードとseedの検定方法

Sat, 05 Sep 2026 13:08:25 +0900

背景

毎回このコードを最初に貼り付けるが、いつも見失う
なのでgistとしてここに残す
機械学習で毎回seedを固定するためのもの
非決定的にせずに実験をスムーズにするための設定

課題

機械学習での実験の課題はモデルの評価
新しいネットワーク構造にしても差が数ポイントだったりする
そうすると、ノイズフロアによる誤差なのかがわからない
そこで、学習や推論をできるだけ決定的（deterministic）にして再現性を高める

非決定的

非決定的とランダムの違い

非決定的と似た概念としてランダムがあるが、同じではない。

$$ 非決定的 \neq ランダム $$

ランダム化アルゴリズム
- 実際に乱数を使って1つの経路を選ぶ
非決定的アルゴリズム
- 理論上、複数の選択肢から「正解につながる選択ができる」と考える計算モデル

NOTE: ただしPyTorchのバージョン・プラットフォーム・CPU/GPUをまたいだ完全な再現性までは保証されない。

非決定的という言葉について

計算量理論でいう非決定的アルゴリズムと、PyTorchでいうnondeterministic operationは意味が異なる。

計算量理論の non-deterministic
- 複数の計算経路の中から正解につながる経路を選べると仮定する理論上の計算モデル
PyTorchやGPU計算のnon-deterministic
- 並列計算や演算順序などにより、同じ入力でも実行ごとに数値結果がわずかに変わることがある

seed固定と deterministic algorithmの利用は、後者を抑えて実験の再現性を高めるために行う。

安定化モード

安定化モードのコード

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


def set_seed(seed: int):
 random.seed(seed)
 np.random.seed(seed)
 torch.manual_seed(seed)
 torch.cuda.manual_seed_all(seed)


def enable_determinism(strict: bool = True):
 torch.backends.cudnn.deterministic = True
 torch.backends.cudnn.benchmark = False
 torch.backends.cuda.matmul.allow_tf32 = False
 torch.backends.cudnn.allow_tf32 = False

 torch.use_deterministic_algorithms(
 True,
 warn_only=not strict,
 )

 print(
 f'use_deterministic_algorithms(True, warn_only={not strict}) '
 f'+ TF32 無効化 + cudnn.deterministic=True'
 )

# 実行
seed = 42
set_seed(seed)
enable_determinism(True)
print('set_seed / enable_determinism 定義完了')

安定化モードの注意点

たとえ、あるseedに固定して決定的にして実験して精度が出せても、それが完全に優れているとは限らない
なぜなら、ある条件A（仮にseed=42）の時の複数の実験結果の精度比較に過ぎないから
つまり、複数seedでの平均・標準偏差などを見て最終的には評価する必要がある

たとえば、以下の結果だったとする。

1
2


モデルA seed=42 → 90.2%
モデルB seed=42 → 90.8%

しかし、seedを変えたら、以下になったら、Bが良いとは言い難い。

1
2
3
4
5
6


seed A B
1 90.5 90.0
2 89.8 90.3
3 90.4 90.1
4 89.9 90.5
5 90.2 90.0

統計的に評価する

複数seedで実験した結果、その差が統計的に意味のあるものかを確認する方法がいくつか提案されている。

検定の分類

良い図があったので、これを載せる。

t検定（平均とSDから直接比較する）

最もシンプルな方法は、平均と標準偏差からそのままt検定を行うこと。

$$ t = \frac{\bar{x}_A - \bar{x}_B}{\sqrt{\dfrac{s_A^2}{n_A} + \dfrac{s_B^2}{n_B}}} $$

$\bar{x}_A, \bar{x}_B$: それぞれのモデルの複数seedでの平均
$s_A, s_B$: それぞれのSD
$n_A, n_B$: seed数

$t$の絶対値が大きいほど、平均の差がSD（ばらつき）に対して十分大きい、つまり偶然とは考えにくいと判断できる。

分布を仮定しない方法

t検定は、データが正規分布に近いという前提を置いている。seed数が5個などと少ない場合、この前提が怪しくなる。

Kolmogorov-Smirnov検定やブートストラップ法は、分布の形を仮定しない、より頑健な代替手段になる
Henderson et al.は、強化学習分野でseedによる結果のばらつきが無視できないほど大きいことを指摘し、2標本t検定・Kolmogorov-Smirnov検定・ブートストラップ法による有意性検定を推奨している

必要なseed数を見積もる

「優劣を出す」話とは別に、「そもそも何seed回せば信頼できる結論が出せるか」という、実験を始める前の設計の問題もある。

検定力分析（power analysis）で、必要なseed数を統計的に見積もることができる
Colas et al.は強化学習実験を例に、この考え方を具体的に示している

探索コストの公平性

比較する2つのモデルが、同じ探索コストをかけて選ばれたかという、また別の前提条件もある。

Dodge et al.は、単一のtest scoreだけでなく、ハイパーパラメータ探索にかけた計算量（試行回数）に応じた期待検証性能を報告することを提案している
探索に使った計算量が違うモデル同士を比較すると、優劣の判定自体が公平でなくなる

実用ツール

深層学習向けにこうした検定を簡単に行うためのdeep-significanceというPythonライブラリも公開されている
有意検定（Significance Testing）によって、調査結果の有意性に関してある仮説をたてて、それが成り立つか否かを現実のデータでもって判断することが可能
単純に複数seedの平均を比べるだけでなく、その差が統計的に有意かどうかまで確認するのが望ましい。

その他

ちなみに、seedで42がよく使われるのは、銀河ヒッチハイクガイドからのオマージュ
その小説の中の「生命、宇宙、そして万物についての究極の疑問の答え」= 42という答えから引用している
- see 生命、宇宙、そして万物についての究極の疑問の答え - Wikipedia
個人的には、最高の答えが42だとしたら、最高の質問は存在の質問「Why is there something rather than nothing?」だと思う
- see なぜ何もないのではなく、何かがあるのか - Wikipedia
それらを組み合わせると、なぜなぜ究極の答えは、42だったと
ただ、個人的には、モンスター群の196883の方が真理に近い気がして好きな数字
- see モンスター群 - Wikipedia

まとめ

モデル変更による数pointの差を比較するときは、seedや演算を固定して実験を決定的にすることで、ばらつきを抑えられる
これは開発中のデバッグやablationでは非常に便利で、変更前後を同条件で比較しやすくなる
一方、最終的にモデル性能の改善を主張する場合は、単一seedでの結果だけでは不十分
つまり、複数seedで実験して平均や分散を見る必要がある
determinismは統計評価の代替ではなく、実験条件を揃えるための手段ということ
統計的保証に関しては、個人的にはt検定をすれば十分だと思っている

参考文献

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

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分割を、Diagと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, val, testの違い

train data：重み更新に使う
validation data：学習中のモデル選択、early stopping、ハイパーパラメータ調整に使う
test data：最後の最終評価に使う

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は、実質的に開発用データセットになってしまう

Target側にもDiagを作る

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

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

という構造になる。

diagとtestの違い

Diag

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

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

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

Test

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

Diagだけでも足りない理由

もう一つ問題がある。平均的なDiag 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
Diag	Error Analysis	Yes	Yes
Challenge	Failure-mode / Capability Evaluation	Yes	Yes
Test	Final Generalization Estimate	No	No

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

ValとDiagの違い

一見するとValとDiagは同じものに見え、実際に多くの文献ではValidation Setと開発用データセットがほぼ同義語として使われる。ここではあえて分離して考える。

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

例:

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

ChallengeとDiagの違い

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

例えば本番データで、通常画像98%・夜間1%・豪雨0.5%・逆光0.5%だったとする
Diagではこの比率をある程度維持する
しかし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だけではなく、その構造を見ながら評価する」という、Diag的な発想に近い
分布シフトに対する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からサンプリング
Diag・Test:
- Target distributionからサンプリング（Diagは見てよい、Testは見てはいけない）
Challenge:
- Target（デプロイ環境）に関連するが、意図的に分布を歪めて集める
- 「独立」というより「Target寄りだが非代表的」という位置づけ

本質はInformation Boundary

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

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

まとめ

機械学習ではTrain・Val・Testの3分割が基本とされているが、実運用では学習分布と本番分布が一致しないことが珍しくない
Testで性能が低下した理由を知るにはTarget側のデータを観察する必要があるが、Testを観察して改善に利用すると、そのTestはもはや完全なTestではなくなる
そこでTrain・Val・Diag・Challenge・Testという役割分離を考える
- Train: モデルを学習する
- Val: モデルを選択する
- Diag: 本番分布での失敗を理解する診断データセット
- Challenge: 重要なFailure Modeを集中的に診断する
- Test: 最後までBlindにして最終性能を測る
Source側からTrainとVal、TargetからTest、それと独立したDiagと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）

Conformal Predictionによるしきい値調整

Mon, 24 Aug 2026 12:00:00 +0900

背景

しきい値は、多くの場合「なんとなく良さそう」という経験的な決め方になりがち
- 0.9以上ならpositiveと判定する、など
Conformal Predictionを使うと、しきい値の決め方に統計的な保証を持たせられる
しきい値調整という実務に絞って、Conformal Predictionの考え方を整理する

しきい値をどう決めるか、という問題

経験的なしきい値選定（パーセンタイル法）

よくあるやり方は、キャリブレーション用データ（学習には使っていないホールドアウトデータ）に対してモデルのスコアを計算し、その分布から「これくらいなら安全」というパーセンタイル点をしきい値にする方法
例えば、negativeサンプルのスコアを集めて、その99パーセンタイル点をしきい値にする、というやり方
直感的で実装も簡単だが、以下のような弱点がある
- そのパーセンタイル値が、本番データでも本当に同じ意味を持つのか（同じ誤り率になるのか）の保証がない
- キャリブレーションデータの件数が少ないと、パーセンタイル自体の推定がぶれる

経験的な方法の弱点

「99パーセンタイル」という言葉は、キャリブレーションデータの中では正確でも、未来の新しいデータに対して「エラー率が1%以下になる」ことを保証しない
特にサンプル数が少ない場合、単純な分位点の推定には誤差が乗る
この誤差を統計的に補正し、有限サンプルでも成り立つ保証を与えるのがConformal Prediction

Conformal Predictionとは

モデルの中身に依存しない（モデルフリーな）枠組みで、予測に対して統計的に妥当な保証を与える手法
「分布によらない（distribution-free）」という特徴があり、スコアの分布がどんな形であっても、同じ手順で保証が成り立つ
唯一の前提は、キャリブレーションデータと将来のテストデータが交換可能（exchangeable、i.i.d.なデータもこれに含まれる）であること

交換可能性（exchangeability）とは

i.i.d.（独立同分布）は、交換可能性の一種
i.i.d.なら必ず交換可能だが、逆は成り立たない（交換可能でも、i.i.d.とは限らない）
交換可能性とは、$n$個のデータ$(x_1, \ldots, x_n)$の同時分布が、順番を入れ替えても変わらないという性質のこと

$$ P(x_1, \ldots, x_n) = P(x_{\pi(1)}, \ldots, x_{\pi(n)}) $$

$\pi$は、$1, \ldots, n$のどんな並べ替え（順列）でもよい
i.i.d.より緩い条件なので、データ同士に依存があっても交換可能性は満たされる場合がある

以下は、独立ではないが交換可能な例である。

非復元抽出（sampling without replacement）: 母集団からデータを1件ずつ取り出すとき、取り出したデータを母集団に戻さずに、次の抽出を行う方法
- 例: トランプ52枚から1枚引いて、それを戻さずに次の1枚を引く
- 対義語は復元抽出（sampling with replacement）で、こちらは毎回母集団に戻してから次を引く（同じデータが何度でも選ばれうる）
- 非復元抽出では、各データの抽出結果はお互いに影響し合う（1枚目でハートのAを引いたら、2枚目でハートのAが出る確率は0になる）ため、独立ではない
- しかし、母集団自体は変わらないので、どの順番で引いても「その$n$枚の組み合わせが出る確率」は同じになる。これが「独立ではないが交換可能」という状態

Conformal Predictionの証明で重要なのは、「キャリブレーションデータ$n$件＋テストデータ1件」を合わせた$n+1$件が交換可能でありさえすればよい、という点である。i.i.d.である必要はなく、より緩い条件で足りるというのが、この手法の強みの1つ。

Nonconformity score（非適合度スコア）

Conformal Predictionでは、まずモデルの出力を「どれだけ普通と違うか（適合していないか）」を表すスコアに変換する
分類の場合、以下のようなスコアがよく使われる

$$ s(x, y) = 1 - \hat{p}(y \mid x) $$

$\hat{p}(y \mid x)$は、モデルが出力する「入力$x$に対してラベル$y$である確率」
正解ラベルの予測確率が低いほど、このスコアは大きくなる（＝モデルの予測と実際のラベルが「適合していない」）

Conformal Predictionによるしきい値の求め方

キャリブレーションデータでのスコア計算

キャリブレーションデータ$n$件それぞれについて、正解ラベルに対するnonconformity score $s_1, \ldots, s_n$を計算する

有限サンプル補正つき分位点

以下は、目標エラー率$\alpha$（例えば5%）に対応する分位点$\hat{q}$の求め方である。

$$ \hat{q} = \text{Quantile}\left(\{s_1, \ldots, s_n\}; \ \frac{\lceil (n+1)(1-\alpha) \rceil}{n}\right) $$

単純に$(1-\alpha)$分位点を取るのではなく、$\frac{\lceil (n+1)(1-\alpha) \rceil}{n}$という、少しだけ大きい分位点を取っているのがポイント
この補正が、サンプル数$n$が有限であっても保証が成り立つようにするための調整になっている
$n$が大きくなるほど、この補正値は$(1-\alpha)$に近づいていく
同じことだが、$\hat{q}$は「$s_1, \ldots, s_n$を小さい順に並べたとき、$k = \lceil (n+1)(1-\alpha) \rceil$番目に小さい値」と言い換えられる
次の具体例では、この言い換えの方で計算する
注意点として、この分位点は一般的な補間つきの分位点（線形補間など）とは一致しない。値と値の間を補間せず、$k$番目の値をそのまま使う（段階的な）分位点である点がポイント

しきい値としての解釈

新しい入力$x$に対して、nonconformity scoreが$\hat{q}$以下となるラベルだけを予測集合に含める、というのが本来のConformal Predictionの出力（予測集合）
二値分類でFA（誤検知）を抑えたい、という文脈に絞ると、これは「予測確率が、ある値以上ならpositiveとする」という単一のしきい値の形に単純化できる
つまり、経験的なパーセンタイル法とほぼ同じ計算をしているが、分位点の取り方に前述の有限サンプル補正が入っている点が異なる

具体例：二値分類でのしきい値計算

迷惑メール判定（positive = 迷惑メール）を例に、実際に手で計算してみる
目標: 本当は迷惑メールではない（negative）メールを誤って迷惑メール判定してしまう率を、20%以下に抑えたい（$\alpha = 0.2$）
キャリブレーションデータとして、本当はnegativeだと分かっている9件のメールを用意し、それぞれモデルが出す「迷惑メールである確率」を集める

以下は、9件のキャリブレーションデータのスコア（迷惑メール確率）を小さい順に並べたものである。

$$ 0.02,\ 0.05,\ 0.05,\ 0.08,\ 0.10,\ 0.12,\ 0.15,\ 0.22,\ 0.31 $$

$n = 9$、$\alpha = 0.2$なので、$k = \lceil (n+1)(1-\alpha) \rceil = \lceil 10 \times 0.8 \rceil = \lceil 8 \rceil = 8$
つまり、9件のスコアのうち小さい方から8番目の値を$\hat{q}$として使う
8番目の値は$0.22$なので、$\hat{q} = 0.22$

これで、しきい値が$0.22$と決まった。新しく届いた3通のメールに対して、モデルが出す迷惑メール確率がそれぞれ$0.10$・$0.25$・$0.40$だったとすると、以下のように判定する。

$0.10 \leq 0.22$ → negativeと判定（受信）
$0.25 > 0.22$ → positiveと判定（迷惑メール扱い）
$0.40 > 0.22$ → positiveと判定（迷惑メール扱い）

補正の効果を確認するために、同じ9件のスコアに対して、補正なしの単純な80パーセンタイル（線形補間）を計算すると、以下のようになる。

$$ \text{Quantile}_{0.8}^{\text{naive}} = 0.178 $$

補正なしだと$0.178$、Conformal Predictionの補正ありだと$0.22$と、後者の方が少し大きい（＝positive判定に慎重になる）しきい値になる
サンプル数$n=9$が少ないため、この差が目立って出ている。$n$が大きくなるほど、この2つの値は近づいていく
この差こそが、有限サンプルでも「$\alpha=0.2$以下」という保証を成り立たせるための補正分

FARとFRRを両方Conformal Predictionで保証する

ここまではFA（誤って受理してしまう率、FAR）だけを抑える例だったが、逆側のエラーであるFRR（本来positiveなのに誤って拒否してしまう率）も同時に考えたいことがある
経験的な方法では、FARとFRRの曲線が交わる点（Equal Error Rate、EER）をしきい値にすることが多いが、これは統計的な保証を持たない、単なる経験的な交点にすぎない
Conformal Predictionなら、FARとFRRの両方を、それぞれ統計的な保証つきで同時に満たすしきい値を求められる

2つのしきい値を別々に求める

negative側のキャリブレーションデータから、$\hat{q}_{\text{FAR}}$を求める（$p(x) > \hat{q}_{\text{FAR}}$ならpositive、というルールで$\text{FAR} \leq \alpha_{\text{FA}}$を保証するしきい値）
positive側のキャリブレーションデータから、$\hat{q}_{\text{FRR}}$を求める（$p(x) \leq \hat{q}_{\text{FRR}}$ならnegative、というルールで$\text{FRR} \leq \alpha_{\text{FR}}$を保証するしきい値）
どちらも、前述の「有限サンプル補正つき分位点」の手順をそのまま使うが、キャリブレーションに使うデータのクラスが逆になる

両立できる条件

以下が成り立てば、この2つの間のどの$t$を選んでも、両方の保証が同時に成り立つ。

$$ \hat{q}_{\text{FAR}} \leq \hat{q}_{\text{FRR}} $$

理由は、それぞれの保証が単調な集合の包含関係でできているため
$\text{FAR}(t)$は$t$を上げるほど単調に下がり、$\text{FRR}(t)$は$t$を上げるほど単調に上がる
$t \geq \hat{q}_{\text{FAR}}$なら、$\{p(x) > t\}$は$\{p(x) > \hat{q}_{\text{FAR}}\}$の部分集合になるので、$\text{FAR}(t) \leq \alpha_{\text{FA}}$がそのまま保たれる
同様に$t \leq \hat{q}_{\text{FRR}}$なら、$\text{FRR}(t) \leq \alpha_{\text{FR}}$がそのまま保たれる
つまり、区間$[\hat{q}_{\text{FAR}}, \hat{q}_{\text{FRR}}]$の中でどこに$t$を置いても、どちらの保証も壊れない。むしろ境界から離れるほど、両方に余裕（マージン）が乗る方向に働く
中間点$t = (\hat{q}_{\text{FAR}} + \hat{q}_{\text{FRR}})/2$を使うのが分かりやすいが、区間内であればどこでもよい

両立できない場合

$\hat{q}_{\text{FAR}} > \hat{q}_{\text{FRR}}$（区間が空）の場合は、$\alpha_{\text{FA}}$と$\alpha_{\text{FR}}$を同時に満たすしきい値が存在しないことを意味する
この場合、中間を取っても意味がない
目標のどちらか（あるいは両方）を緩めるか、モデル自体の性能を上げる必要がある、という診断に使える

保証されること・されないこと

marginal coverageの保証

以下は、Conformal Predictionが与える保証である。

$$ P\left(y_{\text{test}} \in C(x_{\text{test}})\right) \geq 1 - \alpha $$

$C(x_{\text{test}})$は、テスト入力に対する予測集合（しきい値の文脈では「positiveと判定される領域」）
キャリブレーションデータとテストデータが交換可能であれば、サンプル数に関わらずこの不等式が成り立つ
「marginal」は、「キャリブレーションデータの取り方（乱数）ごと平均すると」という意味
- 1回のキャリブレーションで固定された$\hat{q}$に対して、個々の入力$x$ごとに条件づけて成り立つ保証（conditional coverage）ではない
- キャリブレーションをやり直すたびに変わる$\hat{q}$も含めて、全体として平均するとこの不等式が成り立つ、という意味

なぜ成り立つのか（交換可能性と順位の対称性）

この保証は近似ではなく、交換可能性（exchangeability）だけから導ける、組み合わせ論的な事実
キャリブレーションの$n$個のスコア$s_1, \ldots, s_n$と、テストデータのスコア$s_{n+1}$を合わせた$n+1$個が交換可能（どの並び順も同じ確率で起こる）だとする
このとき、$s_{n+1}$が全体の中で何番目に大きいかは、対称性からどの順位も等確率になる
したがって、$s_{n+1}$が上位$k$番目以内に入る確率は、ちょうど$\frac{k}{n+1}$になる

以下のように$k$を選んでおくと、この確率が目標の$1-\alpha$以上になることが保証される。

$$ k = \lceil (n+1)(1-\alpha) \rceil \implies \frac{k}{n+1} \geq 1 - \alpha $$

この議論は、モデルの中身にも、スコアの分布の形にも一切依存していない
モデルの性能が悪くても、この保証自体は定理として成り立つ（ただし、モデルが悪いとしきい値が緩くなりすぎて、実用上は使い物にならなくなる、という形で影響が出る）
つまり、保証の強さは丸ごと「交換可能性」という前提に懸かっている。分布シフトなどでこの前提が崩れると、証明も成り立たなくなる

条件付きカバレッジは保証されない

marginal coverageは、データ全体で平均した保証であって、クラスやサブグループ単位では保証されない
例えば、あるサブクラスだけエラー率が目標を大きく超えていても、別のサブクラスでエラー率が低ければ、全体の平均としては目標を満たしてしまうことがある
対策として、クラスごとに別々にキャリブレーションを行うclass-conditional conformal predictionという拡張がある
- クラスごとにキャリブレーションデータを分けて、それぞれ別の$\hat{q}$を求める

分布シフトで保証が崩れる

交換可能性の前提が崩れると（キャリブレーション時と本番運用時でデータの分布が変わると）、保証は成り立たなくなる
これは、以前書いた分布シフトの問題そのもの
運用中にデータの性質が変わっていないか、定期的に確認する必要がある

実際に必要なサンプル数

キャリブレーションデータの件数$n$は、大きく2段階で考える。

最低限必要な件数（有限であるための下限）

$k = \lceil (n+1)(1-\alpha) \rceil$が$n$を超えると、$\hat{q}$が存在しなくなる（＝しきい値が無限大になり、全部positive扱いになってしまう）
この条件から、保証が成り立つための絶対的な下限が以下のように求まる

$$ n \geq \frac{1}{\alpha} - 1 $$

例えば$\alpha = 0.05$（目標エラー率5%）なら、最低でも$n \geq 19$必要
これはあくまで「保証が数学的に成立するための下限」であって、「実用に足る精度」とは別の話
境界を$\alpha$側から見ると、$\alpha \geq \frac{1}{n+1}$であれば成立し、$\alpha < \frac{1}{n+1}$（厳密に小さい）だと成立しない、という条件になる
- ちょうど$\alpha = \frac{1}{n+1}$の場合はギリギリ成立し、その場合$k=n$になるので、$\hat{q}$はキャリブレーションデータ中の最大値そのものになる（マージンがない、際どいケース）
- 例えば$n=9$なら$\frac{1}{n+1}=0.1$なので、$\alpha=0.1$は成立するが$\alpha=0.09$は不足する

実用上必要な件数（保証のブレを抑える）

marginal coverageの保証は、どんな$n$でも「平均すれば」成り立つが、1回のキャリブレーションで得られる$\hat{q}$の実際のカバレッジは、$n$が小さいとブレる
このブレの標準偏差は、キャリブレーションデータの取り方に関するBeta分布の性質から、おおよそ以下のように近似できる

$$ \text{std}(\text{実際のカバレッジ}) \approx \sqrt{\frac{\alpha(1-\alpha)}{n}} $$

具体的な数字を入れると、以下のようになる
- $\alpha=0.2$、$n=9$（前述の具体例と同じ条件）: std $\approx 13\%$。目標20%に対して、実際は大きくブレうる。手計算で仕組みを説明するには良いが、実用には足りない件数
- $\alpha=0.05$、$n=100$: std $\approx 2.2\%$
- $\alpha=0.05$、$n=1000$: std $\approx 0.7\%$
経験則として、$n$が数百〜1000以上あると、実運用で許容できる程度までブレが小さくなることが多い

実務上の注意点

前述の実装イメージではnegative_scoresだけを使ってキャリブレーションするので、「全サンプル数」ではなく「negativeクラスの件数」がこの$n$に当たる
class-conditional conformal predictionのように、クラスごとに較正を分ける場合は、クラスごとにこの$n$の条件を満たす必要がある
- 件数が少ないクラス・サブクラスがあると、そこだけ保証が緩くなったり、$\hat{q}$が求まらなくなったりするので注意が必要

実装イメージ

以下は、二値分類でのしきい値調整をConformal Predictionで行う場合の実装イメージである。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


import numpy as np

# calib_scores: キャリブレーションデータに対する、モデルのpositive確率
# calib_labels: キャリブレーションデータの正解ラベル（0 or 1）
# negativeサンプルだけを使って、FA率を抑えるしきい値を求める
negative_scores = calib_scores[calib_labels == 0]

n = len(negative_scores)
alpha = 0.01 # 目標エラー率（この場合はFA率）1%

q_level = np.ceil((n + 1) * (1 - alpha)) / n
threshold = np.quantile(negative_scores, min(q_level, 1.0), method="inverted_cdf")

# 本番では、モデルのpositive確率がこのthresholdを超えたらpositiveと判定する

q_levelが1を超える場合（サンプル数が少なすぎる場合）は、保証を与えられないケースなので、サンプル数を増やす必要がある
method="inverted_cdf"を指定しているのは、これが前述の「小さい方から$k$番目の値」という定義と厳密に一致する分位点の取り方だから
- method="higher"など、他の補間方法を指定すると、$k$番目の値より大きい値になり、具体例で計算した$\hat{q}$とは異なる結果になってしまう

運用での使い方

キャリブレーションデータは、本番データの分布とずれないよう、定期的に更新して再計算する
目標エラー率$\alpha$を明示的なパラメータとして持てるため、「FA/hourをこの値以下に抑えたい」といった運用要件に、しきい値選定の手順を直接結びつけやすい
ただし、marginal coverageの保証はクラス・サブクラス単位では成り立たないため、サブクラスごとに運用上重要な誤り率がある場合は、class-conditionalな較正も検討する

まとめ

しきい値の経験的な決め方（パーセンタイル法）は、直感的だが将来のデータに対する統計的な保証がない
Conformal Predictionは、nonconformity scoreの分位点を有限サンプル補正つきで求めることで、分布によらない統計的保証（marginal coverage）を与える
保証されるのはデータ全体で平均したエラー率であり、クラス・サブグループ単位の保証や、分布シフトへの耐性は別途考える必要がある
経験的なパーセンタイル法とほぼ同じ手順で計算できるため、既存のしきい値調整の運用に組み込みやすい
FARとFRRをそれぞれConformal Predictionで較正し、2つのしきい値の間を使えば、EERのような経験的な交点ではなく、両方とも統計的に保証された区間を作れる

参考文献

機械学習の実験管理の為の設計

Fri, 14 Aug 2026 16:28:00 +0900

背景

あるプロジェクトで検知モデルを作っていて色々な課題が出てきた
- 「このrunはどのデータで学習したんだっけ」
- 「このmanifestの数字は本当に実行時の設定と一致しているんだっけ」
一度、実験管理そのものを設計し直すことにした
ディレクトリ構成そのものより、そこに至った判断基準の方が汎用的で使い回せる
考え方の部分だけを抜き出してまとめる

全体像

まず、最終的にどう分割したかを先に示す。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


xxx-project/
├── scripts/
│ ├── scaffold/ 番号採番・テンプレコピーを自動化するスクリプト
│ ├── pipeline/ データ生成/加工の実処理コード（共有、experimentごとにコピーしない）
│ ├── demo/ 実際に動かして触ってみるためのデモスクリプト
│ └── tools/ 分析・調査に使う単発ツール
├── templates/ コピーして使う雛形（notes/manifests/code/docs）
├── checklist/ templates/を指すpointer + 評価チェック項目（eval_checks/）の本体
├── data/
│ ├── specs/<id>/ グレード定義・単語/フレーズリスト、シードやレシピみたいなもの
│ ├── raw/<id>/ 生の長尺音声（未クリップ・未分類、collectionsの入力元の1つ）
│ ├── collections/<id>/ specs（またはraw）から生成/収集した実データ
│ ├── splits/<id>/ train/val/test等のロールへの分割
│ ├── aug/<id>/ splitでtrain判定されたクリップへのaug結果
│ ├── cache/<id>/ 埋め込み抽出のキャッシュ
│ └── err/<id>/ 評価runでFAしたクリップのエラー分析専用データ（学習には使わない）
├── backlog/<id>/ 今すぐ手を付けない課題・気づきを残す場所
├── leaderboard.md experiment/run横断の指標一覧（退行チェック用）
└── experiments/<id>/
 ├── README.md 仮説・作成理由・配下runの一覧
 ├── manifest.yaml parent_experiment・デフォルト設定
 └── runs/<id>/
 ├── manifest.yaml 実際に何を実行したか（cache/splits/hyperparams/seed/git commit）
 ├── output/ 学習済みモデル等
 └── README.md run単体の「論文」（背景・手法・結果・考察）

scripts/・templates/・checklist/
- 実験を作るための土台
- 採番の自動化・雛形・チェックリスト
data/
- 学習データの生成・収集パイプライン
- specs → [raw] → collections → splits → aug → cacheの順に積み上がる
experiments/
- 実際の実験本体と、その配下の個々のrun

以下の各節で、この形に至った判断理由を掘り下げる。

横断設計

IDの命名規則

番号付きフォルダ/ファイルは {ゼロパディング数字}_{slug} の形式
- 例: 01_front_prefix
番号は、同じ階層・同じネームスペース内で独立の通番
- 例: checklist/eval_checks/内の01〜17と、data/specs/内の01〜は無関係
番号を振るもの
- data/specs/・data/collections/・experiments/・runs/のように、実際に複数作られていくもの
番号を振らないもの
- templates/notes|manifests|code|docs/
- 種類ごとに1つずつしかない固定スロットなので、増えていく連番ではない
checklist/配下は番号を振る
- eval_checks/（相互参照・随時追加のリスト）はもちろん
- notes|manifests|code|docs/（templates/を指すpointer）も含めて番号を振る

IDの引用表記（namespace#id）

IDを文章中で引用する表記は、以下の2通りにした。

namespace#id
- 例: specs#01_xxx・experiments#01_baseline
- #の左がnamespace（data/specsのようなフォルダの種類）、右が番号付きslug
- 単体で番号が一意に決まるnamespaceに使う
namespace#id@parent_namespace#id
- 例: run#01_xxx@experiment#01_xxx
- runのように、親のIDに属する形でしか存在しないnamespaceに使う
- 理由は、同じrun#01_xxxでもどのexperiment配下かで別物になり、親を省略すると取り違えが起きるため

番号はnamespaceごとに独立の通番なので、01とだけ書くと文章中ではどのnamespaceの01か分からなくなる。この表記はディレクトリパスの代わりではなく、あくまで文章中で手短に引用するための省略記法で、実際のパス（data/specs/01_xxx/等）はコードやmanifestではそのまま使う。この表記があるだけで、読み手が都度パスから逆算しなくて済む。

「なぜ」と「何を」を分離する

実験・run・データの各段階（specs/collections/splits/aug）、それぞれに2つのファイルを持たせる。

README.md — 仮説・理由・考察など人間が読む文章
manifest.yaml — 構造化データ（参照するデータのID・ハイパーパラメータ・git commit等）だけ

分離しないとどうなるか？

理由をmanifestの1行コメントに押し込むと、後から読んでも意図が分からなくなる
逆に理由の文章に構造化データを混ぜると、スクリプトから機械的に読み取れなくなる

rulesとchecklist

プロジェクトの「決め事」を書く場所を、抽象度で2つに分けている。

rules.md — 憲法のような、全体を貫く設計方針そのもの
- なぜこの構造にしたか、判断の理由・トレードオフを文章で説明する
- 新しい仕組みを追加する時にまず参照する、判断基準の源
checklist/ — 法律のような、個別具体的なチェック項目
- 1項目1ファイルで、都度確認する具体的なルール
- rules.mdの方針を踏まえた上での、実務レベルの確認事項
- 理由は、個別に追加・削除・改訂できるようにするため

理由は、両方を1つのファイルに混ぜると、「そもそもなぜこの設計なのか」という背景と、「今回この項目を確認したか」という実務チェックが同じ場所に混在し、読みたい情報にたどり着きにくくなるため。方針を理解したい時と、作業中に確認したい時とでは、必要な粒度も読むタイミングも違う。

これは、前述の「README.mdとmanifest.yaml」の分離と同じ「なぜ」と「何を」の軸を、個々のデータ段階だけでなくプロジェクト全体のルールにも適用したものになっている。

データの設計

メタデータ

データのすべてのアイテムにはdata_item_idが振られ、role（train/val/test/calibration）というメタデータで管理される。

各stageの参照関係

データの生成は基本的にspecs → [raw] → collections → splits → aug → cacheの順で積み上がるが、各段階が参照するものは以下の通りで、親を全部知っているわけではない（例: cacheはsplitを知らない、splitsはroleをつけるだけでaugやcacheのことは知らない）。

stage	参照するもの
specs	-
raw	specs
collections	specs（またはraw）
splits	collection
aug	collection + split（roleでtrainだけ抜き出すため）
cache	collection + aug（roleは無視、全部埋め込む）
run	cache（複数可）+ split（複数可）——ここで初めてロールと埋め込みが突き合わされる

生データのための中間ステージ（raw）

素材によっては、TTS生成や直接録音のように「そのまま1件のクリップになる」形では手に入らないことがある（例: 動画から音声を集める場合、1本が数十分規模の生の長尺音声で、そこから後で複数のクリップを切り出す必要がある）。

specs → collectionsの間にrawという中間ステージを挟めるようにした（specs → raw → collections）
- rawの責務は「未クリップ・未分類の生の長尺音声を保持すること」だけ
- クリップ化やクラス分類は一切行わない、それは引き続きcollectionsの責務
rawを経由するかどうかは素材次第
- TTS生成・直接録音のような、そのままクリップになる通常の素材はこれまで通りrawを経由しない
rawもspecsやcollectionsと同様にimmutable必須
- 理由は、下流のcollectionsが参照するため

こうして「集めた素材の形（そのままクリップか、切り出しが必要な生データか）」による違いを、collectionsの責務を汚さずに吸収できるようにしている。

splitの決め方

splitは、位置（[::2]のようなスライス）ではなく、元のdata_item_idに対する決定的ハッシュで分割する。

同じdata_item_idなら、何度計算しても同じロールに落ちる
- 理由は、再現性を保つため
stratify_by_class（推奨true）
- collectionのクラスごとに層化してから、roles比率を適用するオプション
- falseだと全data_item_idを一律にハッシュするだけなので、小さいクラスが特定のロールに偏ってしまうことがある（最悪、あるクラスがtrainに0件になる等）
- 層化はロールという概念自体を持たないcollectionではなく、splits側の責務

train/val/testの役割

splitのロールは単に3分割すればよいわけではなく、それぞれ異なる役割を持たせている。

train — 実際に勾配を流して学習に使う
val — collectionと同じ生成過程から抜いた、学習には使わない検証用
- 安く頻繁にチェックできる一方、生成過程に共通する癖への過学習を検知できない
test — 理想的には生成過程そのものが異なる、独立した「本当の物差し」
- 理由は、同じ生成過程から均等に分けただけだと、trainとtestが同じ癖を共有してしまい、過学習していても高得点が出てしまうため
- 別collectionを丸ごとtestにする（roles: {test: 1.0}）ことでも表現できる
必要ならcalibrationなど、任意のロール名を追加できる

valで良い数字が出たからといって、testでの確認を省略しない。

独立した`data/eval/`ステージを作らなかった理由

当初はテスト専用データに独立したステージを設ける案もあったが、結局作らなかった。

テスト専用データのmanifestは、通常のcollectionとスキーマがほぼ同じで、違いは「学習に使ってよいか」という用途ラベルだけだった
- 独立ステージにすると、ほぼ同じスキーマが2つに分かれてしまう
代わりに、splitのrolesを任意個数・任意名に一般化し、roles: {test: 1.0}という1ロールだけのsplitとして表現することにした
- 理由は、同じcollectionからtrain/val/test/calibrationを1回のsplit定義で切り出す場合と、別の生成過程のcollectionを丸ごとテスト専用にする場合を、同じ仕組みで表現できるため
代わりに失うものもある
- 独立フォルダという物理的な安全装置（「学習に使うな」を構造で強制する）がなくなるため、命名やレビューといった運用上の注意でカバーする必要がある

スキーマを1つ増やす前に、既存の仕組み（この場合はsplitのロール）を一般化できないか考える、という判断の実例になっている。

処理単位（item/chunk/batch）

データの最小の処理単位は、大きく3つある。

item: データのアイテムのファイルの単位（例えば、画像なら1枚の画像）
chunk: itemをまとめた単位
batch: itemをまとめた単位

chunkはitemをまとめた単位になるため、batch_sizeで割り切れない場合は決定的な結果にならない可能性があるので注意が必要（例えば、BatchNormをかけていたりGPUの丸め誤差など）。

stage	単位
specs	item
collections	item
splits	item
aug	item
cache	chunk（`.pt`）
run	batch

大きい配列のコピーはメモリ量を見積もってチャンク分割する

array[mask]やtensor[keep_idx]のようなfancy indexing（リスト/bool配列でのインデックス参照）は、参照ではなく新しい配列を丸ごと確保してコピーする。

元データが数万件×埋め込み次元のような大きさの場合、「元の全件」「コピー後の配列」「その後の結合処理の結果」が一時的に同時にメモリへ乗る
- 理由は、fancy indexingが毎回新規確保のコピーを作るため、ピーク時のメモリ使用量が実質2〜3倍になってしまうため
対策は、一定件数（例: 2万件）ごとのチャンクに分けて、対象範囲へ書き込む形にすること
- 理由は、一時コピーのサイズを小さく抑えられ、ピークメモリを大幅に下げられるため

大きい配列に対して新しくコピー処理を書くときは、件数×要素サイズがどれくらいのメモリになるか見積もり、必要ならチャンク分割する。

コピーと参照、ミュータブルとイミュータブルの関係

templates/とdata/は、どちらも「他から使われる元」だが、扱いが正反対になっている。

テンプレート
- 毎回コピーして使う（experiment/runを作る時点で複製し、そこから先はコピー先が実体になる）
- 自由に改訂してよい
  - 理由は、コピーした瞬間に元とは切り離され、改訂は過去の実験に影響しないため
データ（specs・collections・splits・aug）
- 毎回コピーせず、IDによる参照で使う
- 新しいバージョンが必要でも上書きせず、番号をincrementした新しいフォルダを切る
- イミュータブルにする
  - 理由は、参照元が同じ実体を指し続けるため、元データを書き換えると参照している全experiment/runの再現性が同時に壊れるため

「コピーか参照か」を分けている基準はコピーのコストで、テンプレートはコストがほぼゼロ、データは数百MB〜数十GBになりうるのでコストが高い。整理すると、コピーは可変でよい、参照は不変でなければならない、という原則になる。

例外: cache（埋め込み抽出のキャッシュ）
- 参照される対象だがイミュータブル必須ではない
- 理由は、「collection + aug + 特徴抽出器のバージョン」から機械的に再生成できる純粋な派生物で、壊れても再現でき、失われるのは計算時間だけのため

immutabilityを物理的に強制する（chmod）

「一度作ったら書き換えない」は、最初はドキュメントに書くだけの運用上の約束事だった。

約束事だけだと、うっかり上書きしてしまう事故を防げない
そこで、各IDフォルダを、下流から参照され始める時点で読み取り専用にする（chmod -R a-w）
- ロックのタイミングは生成した直後ではない
  - 理由は、生成〜確定までの間は決定性の検証等で何度も再実行したいことがあるため
- 「下流が参照し始める（＝事実上確定する）タイミング」でロックする
読み取り専用にしても「削除して作り直す」操作は妨げられない
- 削除はフォルダ側の権限で決まるため、通常の更新フロー（新しいIDを切る）には影響しない
data/cache/は対象に含めない
- 理由は、再生成のたびに書き込む必要があるため
ハードリンク（cp -al）で実体を共有している場合、read-only化は特に重要
- 上書き編集による意図しない連鎖破損を物理的に防げる
- 削除の方向は安全（ハードリンクは参照カウント方式なので、他の参照が残っていれば実データは消えない）

実データはDVCで管理し、gitはmanifestだけ追跡する

data/配下の実データ・埋め込みそのものは大容量になりうるため、gitではなくDVCで管理する。

gitは各段階のmanifest.yaml（とsplitsの割り当てcsv）のような軽量なテキストだけを追跡する
- 理由は、実データ自体は数百MB〜数十GBになりうるため、そのままgit管理するとリポジトリが肥大化するため
実データそのものはDVCでバージョン管理し、manifestが参照するIDとひも付ける
- 理由は、バイナリの実体を専用のデータバージョン管理ツールに任せることで、gitはコードと設定の差分管理に専念できるため

大きいバイナリと軽量な設定・コードを、同じgit管理の仕組みに混ぜないという判断になっている。

トップレベルに独立させる理由

data/をexperimentの配下ではなく、リポジトリのトップレベルに独立させている。

理由は、データと実験の関係が1:Nだから
- 1つのcollectionは複数のexperimentから参照されうる
- 例: 同じデータで別のモデル構造を試す、同じデータで別のハイパラを試す
もしデータをexperiment配下に置くと、実質的に1:1の所有関係になってしまう
- 別のexperimentから使い回すには、コピーするかシンボリックリンクのような回避策が必要になる

1:Nの関係を素直に表現するには、データを共有可能な場所（トップレベル）に独立させ、各experimentのmanifest.yamlから「どのdata/collections/<id>を使うか」をIDで参照する形にすればよい。

specsは目的ごとに分ける

specsは「何を集めるか」を定義するtaxonomyだが、同じspecsを複数の目的で兼用しない。

評価用（実運用に近い性能を測るための物差し）と学習用（モデルの弱点を補強するための素材）のtaxonomyは、扱う現象やカテゴリ名が似ていても、必ず別のspecsとして新設する
- 理由は、評価用specs由来のデータを学習にも使うと、「評価に使うのと同じデータで学習する」ことになり、データリークが起きるため
- 評価用taxonomyは学習側から一切参照できないことが前提
- カテゴリの定義が似ていても、収集元（動画・音源）は目的ごとに必ず別に収集し直す

判断基準はシンプルで、新しいspecsを作る前に「このtaxonomyは評価用か学習用か」を自問し、両方に使いたくなった場合は1つを共用せず、目的ごとに別のspecsを新設する。

新しいデータソースはパイロットで検証してから本格展開する

新しいデータソースを追加するときは、本格規模で収集する前に必ず少量のパイロットを作り、実際に効果があるか確認してから本格展開する。

数本〜数十本規模の小さいパイロットをまず収集する
既存の最良のcache/splitと組み合わせて、ミニマルに再学習・評価する
- 理由は、大きいcollectionを毎回丸ごと作り直さなくても効果検証ができるため
効果が確認できてから、本格規模の収集を依頼する
- 理由は、パイロットで見えた効果が、規模を変えても同じ方向に働くとは限らないため
本格展開後も同じ評価をやり直し、効果が維持・拡大しているか確認する
- 理由は、規模を変えると逆効果になるケースがあるため（次項参照）

小さく検証してから広げるという当たり前の流れだが、パイロットの成功だけで本格投資を決めると、規模を変えたときに効果が消える・悪化するケースを見逃す。

class-balanced samplingではグループを分離する

class単位で重みを正規化するsamplingに新しいデータソースを混ぜる場合、既存の大きいグループにそのまま混ぜず、専用グループに分離するかを検討する。

既存グループに混ぜると、追加したデータ自身の学習頻度が意図と逆に下がることがある
- 理由は、重みがグループ全体の件数で正規化されるため、グループが大きくなるほど新しく足した分の1件あたりの重みも薄まるため
- 結果として、対策のつもりで追加したデータの絶対件数は増えても、実際に学習で使われる頻度はむしろ下がる
対策は、追加したデータソースを示すタグを検出し、既存の{class}_{source}のようなグループとは独立した専用グループとして扱う
- 理由は、他のソースの件数に関係なく、追加分自身の学習頻度を保つため

新しいデータを追加するときは、「専用グループにするか、既存グループに混ぜるか」を最初に決めておく。既存グループへの混入は、追加する件数が既存グループに対して相対的に大きいほど効果を弱めるため、後から気づきにくい。

複数ソースをマージする時はコンテンツ重複に注意する

複数のソースからデータをマージしてcollectionを作る場合、パスが違うだけで中身が同一のファイルが紛れ込むことがある。

本体の一部を間引いた「サブセットビュー」を、別ソースとして安易にマージしない
- 理由は、間引いたものは本体に対して新しい情報を追加しないため、別枠として件数に加算すると二重カウントになるため
データ移行やマージにはcp -alのようなハードリンクを使う
- 理由は、cp -rのような複製だと、後から見て「独立ファイルか、元々同じものか」が分からなくなるため
- ハードリンクなら、同一内容が複数箇所にできてしまってもinode照合で低コストに検出できる
マージ後は必ずコンテンツ重複の自動チェックを実行する
- 理由は、splitsはdata_item_id単位でハッシュ分割するため、同一データが別IDとして存在すると、同じ内容がtrain/val/testの異なるロールに分裂してしまうため

複製の混入は気づきにくいが、split後のtrain/testリークという実害につながるため、マージのたびに機械的にチェックする。

自動抽出のデータには再検証ステップを設計する

精度優先の自動抽出（字幕マッチング等）でデータを収集する場合、抽出されなかった残りを別のクラス（例: negative）と決めつけない。

自動抽出は網羅的ではなく、精度を優先した手法ほど取りこぼしが多い
- 理由は、ヒットしなかったからといって、対象が実際に含まれていないとは限らないため
「マッチしなかった残りは全部negative」のような推論をする場合は、別途再検証ステップを設計する
- 例: より網羅的な別手法で、対象が本当に含まれていないかを再確認する

自動化した抽出パイプラインほど、取りこぼしがそのままラベル誤りとしてデータに混入するリスクがあることを前提にする。

エラー分析専用のステージ（err）

評価runで誤発火（FA: False Alarm）したクリップを実際に聴いて原因を調べるため、data/err/<id>/（manifest.yaml+README.md+clips/）という専用のステージを追加した。

err由来のクリップは、学習には絶対に使わない
- 理由は、評価専用collectionから切り出したものなので、学習データに混ぜると評価データそのものが学習に漏れてしまうため
- collections・splits・aug・cacheのいずれにもerr由来のクリップを取り込まない
分析で見つかったパターンを対策データとして使いたい場合、そのクリップ自体は再利用しない
- 同じパターンの素材を別途独立に収集し直す

これも、前述の「評価用と学習用を混同しない」という原則の一種になっている。

生成順序でバグを消す（splitをaugより先に）

データ生成のパイプラインをspecs → [raw] → collections → splits → aug → cacheの順に固定した。

ポイントは「splitをaugより先に行う」こと
- 先にtrain/val/testに分割する
- train判定されたクリップにだけdata augmentationをかける
こうすると、val/testロールのクリップには最初からaugが一切かからなくなる
- 学習コード側に「val/testはaugを除外する」という特別な条件分岐を書く必要がなくなる

「気をつけて実装する」ではなく「その状態しか作れないようにする」ことでバグの芽を摘む、という考え方になっている。

experimentとrunの設計

分ける理由

experiment
- 実験単位。「何を検証したいか」という仮説・方針のレベル
run
- そのexperimentの中で実際に回した1回1回の試行。ハイパーパラメータ・seed・参照するsplit等の条件を変える
1つのexperimentの配下に複数のrunがぶら下がる（experiment:run = 1:N）
2階層に分ける
- 理由は、「大きな方針転換」と「同じ方針内の細かい調整」を同じ粒度で並べると、後から見てどちらの変化か読み取れなくなるため
系譜のリンクもparent_experiment（方針の系譜）とparent_run（試行の系譜）で軸を分けている

experimentの種類

「experiment」と一口に言っても、目的によって性質がかなり異なる。

精度向上のための実験 — 実際にモデルを学習し、指標そのものを改善することが目的
ベースライン実験 — 比較の基準点そのものを作る
比較実験 — 複数のモデル/手法/設定を同じ条件で横並びに比較する
アブレーション — ある要素（データソース・機構・ハイパーパラメータ）を1つだけ足し引きし、その要素単体の寄与を切り分ける
ハイパーパラメータ探索 — 学習率・バッチサイズ等の設定を振って良い設定を探す
診断的実験 — 「なぜこの現象が起きるか」という原因の特定そのものが目的で、精度向上を直接の目的としない
エラー分析 — 誤検知したデータを実際に調べて原因を特定する（前述のerrステージ参照）
決定性・再現性の検証 — モデルの学習は行わず、パイプラインが決定的かどうかだけを確認する
汎化性・頑健性の検証 — 生成過程が異なるデータやドメインシフトに対して頑健かを確認する
評価専用の実験 — 学習は行わず、既存モデルに対して評価パイプラインだけを繰り返し実行する

このうち診断的実験・決定性検証・評価専用は、モデルを学習しない点で「精度向上のための実験」とは性質が異なるが、同じexperiment/runという構造の中にそのまま収まる。仮説・手法・結果・考察という同じ形式で記録できれば十分で、種類ごとに別の入れ物を用意する必要はない。

コピーで固定化する範囲と、共有する範囲を分ける

前述の「コピーのコストで決める」とは別の軸で、コードにも同じコピー/共有の判断が出てくる。

experimentのコード
- テンプレートからコピーして各experimentフォルダに複製する（共有importにしない）
データ生成のパイプラインコード（collection.py・splits.py・aug.py・cache.py）
- コピーせず、リポジトリ全体で共有する
判断基準は「それ自体が実験対象かどうか」
- モデルのコードは実験そのものなので、後からリファクタリングして過去のexperimentの再現性を壊すわけにいかない
- データ生成コードは実験対象ではなく、変わるのは主に引数（単語リストやseed）の方なので共有コードにして育てる
- どのコード状態で生成したかは、各段階のmanifestにgit_commitを自動記録して担保する

系譜を2つの軸に分けて追う

parent_experimentとparent_runという、別々の系譜リンクを持たせている
- parent_experiment — 研究アイデア・実験方針の系譜（前のexperimentから何を変えたか）
- parent_run — 同じexperiment内での具体的な試行の系譜（ハイパラを変えた、seedを変えた等）
最初から軸を分けている
- 理由は、「大きな方針転換」と「同じ方針内の細かい試行錯誤」を1本の履歴に混ぜると、後から辿るときにどちらの変化か分からなくなるため

運用の自動化

手作業を自動化して、記録と実行のズレを防ぐ

新しいspecs・collection・experiment・runを作るときは、必ず採番用のシェルスクリプト（scaffold_*.sh）を使う
- 理由は、手でフォルダをコピーして番号を振ると、ID重複やgit_commit書き忘れのようなミスが起きるため
manifest.yamlは「事後にまとめたメモ」ではなく、学習・評価スクリプトが実際に読み込む設定そのものとして扱う

この2つを徹底すると、「記録されている内容」と「実際に実行された内容」が原理的にズレなくなる。

チェックリストをフェーズで分ける（データ作成時 / 評価後）

チェック観点をまとめるchecklist/は、確認するタイミングによって2つのネームスペースに分けている。

eval_checks/ — 評価runを実行した後に確認する観点
- クラスバランス・信頼区間・データの不整合・splitのリークなど
data_checks/ — データを作る/追加する時に確認する観点
- パイロット先行・グループ分離・コンテンツ重複・immutabilityなど（前述の各項目）
- 理由は、評価後に気づくのでは手遅れな観点（データ収集方針そのものの間違い等）を、作る段階でチェックできるようにするため

どちらも1項目1ファイルで管理し、個別に追加・削除・改訂できるようにしている。

評価は自動化と人の考察を分ける

評価観点はchecklist/に1項目1ファイルで管理し、随時追加・改訂できるようにしている。

客観的に判定できるもの（クラスバランス・サンプル数・信頼区間・データの不整合・splitのリーク）
- 自動テスト化し、runのたびに機械的に実行する
解釈が必要なもの（サブクラス間の相関、仮説との差異、汎化の妥当性）
- 自動化せず、run単体のREADME.mdに人が文章で書く
横断的な良化/悪化の比較はleaderboard.mdに1行ずつ追記していく
- 理由は、退行に気づけるようにするため

何でも自動化しようとせず、「機械的に白黒つけられるか」で線引きする。

対策より先に、原因を特定する（エラー分析のワークフロー）

指標が悪化した/改善しないと分かった時点で、いきなり「データを増やす」対策に飛びつかず、まず原因を特定するところまでを標準の手順にした。

誤検知したデータを専用ステージ（err）に抽出する
- 学習には混ぜない（前述の通り）
聴く・見る・文字起こしするなどして、内容面での共通点を探す
テキストだけで説明できない場合、モデルの特徴量空間でnearest neighbor分析を行う
- 理由は、声質やチャンネルの偏りのような、言語化しにくい非言語的な要因を検出するため
原因に対してピンポイントな対策データを設計し、同じ評価データで効果を検証する
改善しなければ、同じ手順を繰り返す
- 理由は、原因の特定が不十分なまま対策を打っても、的外れな対策になるか、既存の仕組み（class-balanced samplingのグループ分け等）との相互作用で意図しない逆効果になりうるため

反復的な調査記録は、モデル学習を行わない検証専用のexperimentとして残す。

理由は、通常のexperimentと同じ形式（README・manifest）で調査の系譜を追えるようにするため

数値の良化/悪化だけを見て次のパラメータを試すやり方では、ラベル誤りや学習データの偏りに起因するショートカット学習のような根本原因までは見つからない。

backlog（課題を残す場所）

作業中に気づいた課題や違和感を、その場で対応するかどうか判断せずに、まずbacklog/<id>/README.mdとして残す。

IDの命名規則は他の番号付きnamespaceと同じ（{ゼロパディング数字}_{slug}）
- 引用表記もbacklog#01_xxxのように使える
目的は「今すぐ着手しない」と「忘れる」を分けること
- 逐一対応すると本来の作業が進まない、その場限りのメモだと後で誰も覚えていない
README.mdだけの軽量な形
- 理由は、data/やexperiments/のように厳密なmanifestやimmutabilityを必要としないため

あくまで「後で読み返して着手判断する」ためのメモであり、何かを参照される実体ではない。

決定性・再現性の検証

安定化モードの例

以下が安定化コードの例で、runのmanifest.yamlなどにseed: 42のような値を埋めて使う。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


"""experimentを作るときにコピーして使う「安定化コード」(安定化モード)——学習の再現性
(reproducibility)を保証するための決定論設定。共有importにせず、experimentごとにコピーして
始める(過去のexperimentの再現性を守るため。詳細はrules.mdの`code/`節参照)。
"""

import random

import numpy as np
import torch


def set_seed(seed: int):
 random.seed(seed)
 np.random.seed(seed)
 torch.manual_seed(seed)
 torch.cuda.manual_seed_all(seed)


def enable_determinism(strict: bool):
 """runの再現性を検証するための厳格決定論モード。TF32・cudnn自動チューニング・
 非決定的なCUDA kernelを全て無効化する(有効なままだとhardwareや実行順で結果が
 僅かに揺れ、seed固定だけでは同一runの再現性を保証できない)。strict=Trueだと
 決定論的実装が無いopが例外で落ちる(warn_only=False)。"""
 torch.backends.cudnn.deterministic = True
 torch.backends.cudnn.benchmark = False
 torch.backends.cuda.matmul.allow_tf32 = False
 torch.backends.cudnn.allow_tf32 = False
 torch.use_deterministic_algorithms(strict, warn_only=not strict)
 print(f"use_deterministic_algorithms(strict={strict}, warn_only={not strict}) "
 f"+ TF32 無効化 + cudnn.deterministic=True")

非決定性は下流に伝播するため、パイプラインの全段階を検証する

specs → [raw] → collections → splits → aug → cacheのどこか1段階でも非決定的な処理が混ざると、それ以降の段階は全て非決定的になる。

各段階を個別に複数回re-runし、byte-for-byteで同一の結果になるか確認する
- 理由は、後段（例: cache）だけを確認しても、非決定性がどの段階で混入したかは特定できないため
自前のコードだけでなく、使っている外部ライブラリ（音声処理・特徴抽出器等）が内部で非決定的な処理（並列化・GPU上の演算順序等）を行っていないかも確認する
処理順序を変えて確認する（元の順・逆順・並列実行）
- 理由は、浮動小数点演算は結合則が成り立たないため、足し合わせる順序やバッチの構成が変わるだけで結果がわずかにブレることがあり、順序を変えて初めて顕在化するため

1段階でも見落とすと、その後どれだけ丁寧に決定性を検証しても意味がなくなる。

最初にやるべき実験

最初にやるべきなのは、確実に決定的になるかの試験と信頼区間を出すこと。実験の全ての前提は、データと実験の安定性にかかっている。

データのsplitが決定的になるかを確認する
cacheを作る時にcacheが決定的になるかを確認する
- 特に高速化のために並列処理を入れると、決定的にならないことがある
安定化コードを入れて、同じデータで学習を複数回行い、byte-for-byteレベルで決定的な結果になるかを確認する
それらを複数回評価して、評価コード自体が決定的かどうかを確認する
seedを変えたときのばらつき、dropoutを入れたときのばらつきを見る
決定的にならなかった場合は、クラス・サブクラス・グレードなどの区分でどれくらい信頼区間があるかを確認する
ソートも一意になるように第二・第三ソートキーまで指定する

結局のところ、seed値・データ・キャッシュ・学習・評価のどこから不確実性が入り、再現性が取れなくなるのかを明らかにする必要がある。CUDAの設定を決定論的にしていても、キャッシュレベルで不確実性が入っていることがあるので注意が必要。

実例：cacheの決定性チェックで見つかったバグ

実際に決定性チェック用の実験（experiments/02_cache_determinism）を作って検証したところ、2つのバグが見つかった。

fit_windowのjitterが共有rng依存になっていて、非決定的だった
GPU上でのバッチ構成に依存して、浮動小数点の計算結果がブレていた

対策として、cacheのmanifest.yamlに以下を明示的に持たせて固定・記録するようにした。

seed（ハッシュ導出の種）
chunk_size（チェックポイント区切り）
batch_size（特徴抽出器へ一度に渡す件数。バッチ構成がGPUの計算順序に影響するため、固定・記録が必要）

「関数呼び出し時の引数では気軽に変えられないようにする」ことで、後から知らないうちに条件が変わってしまうのを防いでいる。この実例が示すのは、決定性は「CUDAの設定を決定論的にすれば十分」ではなく、キャッシュ生成のような一見地味な処理にも不確実性が紛れ込みうるということ。

並列処理でも決定的にする（共有RNGを使わない）

同じseedを使っていても、並列処理のworker数や処理順序が変わると結果がズレることがある。

原因は、複数のworkerが1つの共有RNG（乱数生成器）を順番に消費する実装になっていると、どのアイテムがどのタイミングで乱数を引くかがworker数やスケジューリングに依存してしまうため
対策は、各アイテムに固有の決定的なseedを、そのアイテムのIDから導出すること
- 例: hash(seed, data_item_id)のように、グローバルなseedとアイテムのIDを合わせてハッシュ化し、そのアイテム専用のseedとして使う
- 理由は、この方式ならどのworkerがいつそのアイテムを処理しても、同じアイテムには常に同じ乱数列が使われるため
jitter付与・ランダムクロップなど、並列実行の順序やworker数に依存しうる処理はこの方式に置き換えて検証する
外部ライブラリを使う場合も、呼び出し直前にアイテム固有のseedでローカルにreseedすれば、ライブラリ内部の実装に関わらず同じ決定性を確保できる
- 理由は、ライブラリ側の乱数状態を外から一時的に固定してしまえば、そのライブラリ自体が共有RNGを使っていても影響を受けないため

「seedを固定する」だけでは不十分で、「どこからその都度の乱数を引いているか」まで見ないと、並列化した瞬間に再現性が崩れる。これは特定のライブラリの機能ではなく、状態を持たない乱数の一般的な作法で、JAXのPRNGKey（内部にグローバルな状態を持たず、明示的に受け渡す純粋関数型の乱数生成）・NumPyのSeedSequence.spawn()・PyTorch DataLoaderのworkerごとのseedingも、同じ発想の実装になっている。

実験のCheckability

作業は、特に中間生成物を残させるようにしなければならない。例えばWhisperで作業を数時間かけてもらう時は、必ず次の3つのことをやる。

小さなセットで事前にdry-run
中間生成物（Whisperの結果）はファイルに逐次保存
他のAgentにDouble Checkしてもらう

Whisperの処理には時間がたくさんかかり、数時間も待つ羽目になるため、中間生成物は必ずファイルに保存しておく。こうすることで、リトライや再検証などができるようになる。

まとめ

実験管理を設計し直す中で、ディレクトリ構成そのものより「なぜそう分けたか」という判断基準の方が、他のプロジェクトにも使い回せると感じた。挙げた基準は、次の通り。

方針転換（experiment）と細かい試行（run）を別の粒度として分ける
理由（文章）と構造化データを別ファイルに分ける
コピーは可変でよく、参照は不変でなければならない、という原則でミュータブル/イミュータブルを線引きする
コピーか参照かは、コピーのコストで決める（安ければコピー、高ければ参照）
「書き換えない」という約束事は、ドキュメントに書くだけでなくchmodで物理的に強制する
1:Nで参照される対象は、所有関係を1:1にしないようトップレベルの共有領域に独立させる
気をつけて実装するのではなく、間違った状態そのものを作れなくする（splitをaugより先に等）
スキーマを増やす前に、既存の仕組みを一般化できないか考える
実験対象のコードは複製して固定化し、実験対象でないコードは共有して育てる
手作業を自動化し、記録と実行がズレない構造にする
自動化できる評価と、人が書くべき考察を最初から切り分ける
新しいデータは小さく検証してから広げ、指標が悪化したら原因の特定まで追う
「気をつけて運用する」のではなく、間違いにくい状態しか作れないようにする（scaffoldスクリプト・chmod等）
特に全てのコードをCheckするのは無理なので、道を外さず、方向性を間違わないようにガードレースを作っていくイメージ

どれも当たり前に見えるが、後から気づいて直すのは大変。次に新しいプロジェクトを始めるときも、同じ基準で最初から作っていきたい。また、もっとやる場合は、そもそもxxx-project-dataとxxx-project-trainとかに分けてもいいのかもしれない。

分布外データを含む分類でFalse Positiveを抑える方法

Wed, 22 Jul 2026 10:52:57 +0900

背景

機械学習モデルを利用したシステムの開発で、precisionを高める必要があった
特に、対象ではないデータをpositiveと誤判定するFalse Positive（FP）のコストが高かったた
そのため、評価データ上でFPを発生させず、可能な限り高いrecallやcoverageを維持することを目標にした
しかし、本番環境では入力がフリーフォームに近く、事前にすべての入力パターンを列挙したり、完全に制限したりすることは難しい
なので、学習時に想定していなかった未知のデータ、すなわち分布外データに対する対策が必要になった
ここでは、そのときに実施した対策と、それぞれの限界についての備忘録をまとめる
なお、有限の評価データでFPが0件だったとしても、将来のあらゆる入力に対してFPが発生しないことを保証できるわけではない点に注意
ここでの「FPを抑える」とは、モデルとシステムの両面から誤判定のリスクを下げることを意味する

用語

ラベル

positive
- 判定対象であるデータに付ける正例ラベル
negative
- 判定対象ではないデータに付ける負例ラベル

IDとOOD

ID（In-Distribution）
- 学習時および運用時に想定している分布に属するデータ
OOD（Out-of-Distribution）
- 学習時に想定した分布から外れるデータ
疑似OOD
- 外部データやデータ加工によって作成した、OODを模したデータ

NOTE:

ID/OODとpositive/negativeは別の概念
ID/OODは「想定した分布に属するか」を表し、positive/negativeは「判定対象であるか」を表す
したがって、IDのnegativeやOODのpositiveが存在する可能性もある
実装上、OODをnegativeまたはNoneとして扱う場合があるが、概念として同一ではない

対象と想定の4象限

-	対象（Positive）	非対象（Negative／None）
想定内（ID）	① ID-Positive	② ID-Negative
想定外（OOD）	③ OOD-Positive	④ OOD-Negative

None：ラベル上、対象クラスではない
OOD：学習・想定分布から外れている
ID-Posivtive：想定範囲内の対象
ID-Negative：想定範囲内の非対象
OOD-Negative：想定範囲外の非対象
OOD-Positive：分布外だが、本当は対象に該当する

Mining

mining
- 大量の候補から、学習に役立つデータを発掘すること
hard negative mining
- 現在のモデルがpositiveと誤判定しやすい負例を優先的に発掘すること

OOD検出

入力が学習時に想定した分布の範囲内か、それとも分布外かを判定すること
一般には、モデルや特徴量からOODスコアを算出し、しきい値を超えた入力をOODとして扱う
ただし、IDとOODの境界は絶対的なものではなく、「何を想定範囲とするか」というタスクの定義にも依存する

i.i.d.（独立同分布）

データが互いに独立であり、同じ確率分布に従うという仮定のこと
機械学習では、学習データと評価・運用データが同じ分布から生成されるという仮定を置くことが多い
現実の運用環境では、時間、ユーザー、センサー、入力方法などの変化によって、この仮定が崩れることがある

内挿と外挿

内挿（interpolation）
- 学習データが十分に存在する領域における予測
外挿（extrapolation）
- 学習データがほとんど存在しない領域における予測
学習域
- 学習データが分布している領域を指す非形式的な表現

多次元データでは、各特徴量が単独では学習時の範囲内でも、特徴量の組み合わせとしては学習データから大きく外れていることがある。

なお、外挿とOODは関係が深いが、必ずしも同じ概念ではない。

バイアス

バイアスとは、調査や分析結果が、真の値や関係性から体系的にずれてしまうこと。

バイアスの種類	定義
交絡バイアス	第3の因子が介在し、見かけ上の因果関係を生む
選択バイアス	調査対象の選定に偏りがあり、標本が母集団を代表しない
情報バイアス	測定や回答、記録などの不正確さによってデータに偏りが生じる

因果関係と相関関係

ココらへんも頻出なので注意。

観点	相関関係	因果関係
意味	AとBが一緒に変化する	AがBを引き起こす
関係	「Aが増えるとBも増える／減る」	「Aを変えると、その結果Bが変わる」
原因・結果	わからない	原因と結果がある
方向性	基本的に方向は決まらない	A → Bという方向がある
第三の要因	影響している可能性がある	交絡などを排除する必要がある
データだけで判断できる？	比較的見つけやすい	相関だけでは証明できない
例	身長と体重には相関がある	喫煙は肺がんリスクを高める

欠落と交絡

早とちりの論理は多いので注意。

欠落
- 重要な第三の変数を落とした（欠落変数）上の結論
- 特に、その変数との交互作用を無視した結論
- 何を分析から落としたかという問題
- 例:
  - 「モデルのパラメーターを増やしたら=>前回より精度が落ちた」 ∴ 「モデルのパラメータを増やすと精度が落ちる」
  - でも実際はデータを増やしたら（第三の変数）、結果は良くなった
  - つまり「Bを固定したときのAの効果」を「Aの普遍的な効果」だと思ってしまった
交絡（こうらく）
- 第三の因子による見せかけ上の因果関係を出す事
- 欠落によって因果推定がどう歪んだかという構造
- 例:
  - 「アイスが売れると水難事故が増える」
  - 実際は気温が関係ある

タクソノミー（Taxonomy）

対象世界を、どんな粒度・軸・関係性で分類するかを体系立てて定義したもの
機械学習のデータ設計では、クラス・サブクラス・grade（難易度）などの階層構造として現れることが多い
タクソノミーを先に定義してからデータを集めることで、データセットの完全性・無矛盾性を担保しやすくなる（後述の「seedが実験の仮説」も参照）
タクソノミーに漏れがあると、学習・評価どちらでもカバーできない領域が生まれ、それがOODの一因にもなる

NOTE:

ただし、実験計画法の要因実験のように、軸・粒度をすべてマニュアルで組み合わせて定義しようとすると、組み合わせ爆発でパターン数が破綻しやすい
そのため、全パターンを人手で列挙するのではなく、実データから頻出パターンを抽出してタクソノミーを組み立てる方が現実的
例えば、ある言葉の使われ方の前後の文脈を助詞レベルで定義するのではなく、Wikiからデータを抽出してFSMを定義するなどのほうがいい

ゴールドラベルとシルバーラベル

ゴールド（Gold）
- 人の手で検証・確認されたラベル
- 品質は高いが、作成コストが高く量を確保しにくい
シルバー（Silver）
- モデルやルールベース処理などで自動生成されたラベル
- 量は確保しやすいが、ゴールドに比べてノイズが混ざりやすい
一般的に、シルバーで量を確保しつつ、一部をゴールドで検証・補強するという使い分けをする
ただし、シルバーは往々にして間違っている事が多いので、注意
評価データは特にゴールドで揃えることが望ましく、シルバーのまま評価に使うと、モデルの精度なのかラベルのノイズなのかが区別できなくなる

分布シフト

機械学習モデルの前提と問題

教師あり機械学習モデルは一般に、学習データから得た統計的な関係が評価時や運用時にも成立することを期待して学習される。

しかし、現実の運用環境では次のような理由でデータ分布が変化する。

データの収集方法が変わる
ユーザー層が変わる
撮影環境やセンサーが変わる
時間の経過によって対象の性質が変わる
学習データの選び方に偏りがある
データ生成メカニズムそのものが変わる

このような学習時と運用時の分布の違いを、分布シフトと呼ぶ。

主なデータセットシフト

シフト	変化するもの	不変と仮定するもの
Covariate Shift	$P(x)$	$P(y \mid x)$
Label Shift	$P(y)$	$P(x \mid y)$
Concept Shift	$P(y \mid x)$	一般には特に定まらない

他にも、次のような表現が使われる。

用語	内容
Domain Shift	撮影環境、計測方法、データセット、利用環境などのドメインが変化すること
Sample Selection Bias	データの選択方法や収集方法によって、観測された分布に偏りが生じること

例えば、道路画像が昼から夜に変化するケースはDomain Shiftに当たる
これによって$P(x)$が変化し、$P(y \mid x)$が変わらないと仮定できる場合はCovariate Shiftとしても扱える
実際のシステムでは、複数の種類のシフトが同時に発生することもある

評価指標

False Positiveを議論するときは、precisionとFalse Positive Rateを区別する必要がある。

$$ \mathrm{Precision} = \frac{TP}{TP + FP} $$$$ \mathrm{FPR} = \frac{FP}{FP + TN} $$

NOTE:

precisionは、モデルがpositiveと判定したもののうち、実際にpositiveだった割合を表す
FPRは、実際にはnegativeだったデータのうち、誤ってpositiveと判定された割合を表す

また、すべての入力をnegativeまたは棄却にすれば、FPを0件にすること自体はできる。そのため、安全性を評価する際にはFPだけでなく、recallやcoverageも同時に確認する必要がある。

recall
- 実際のpositiveをどの程度検出できたか
coverage
- 全入力のうち、棄却せず自動判定できた割合
selective risk
- 棄却せず受理した予測における誤り率

そもそもの前提

About Data

データが全て

結局はデータがあるかないかによって全てが決まると言っても過言ではない
特に評価では実データでやらないとドメインシフトが起きるので正当な評価ができない
データがあればほとんどの問題は解決するので、めんどくさくても先にデータを集めるべき
Data is the new oil

データ生成が最強

もし実際のinferenceデータを生成できるならそれが一番強い
データの分布の変更や、ハードネガティブにも逐次対応できるから
ドメインシフトが起きず、データ生成が適用可能な問題を解くのも大切
例えば、画像分類などで、データ生成による精度向上が良く使われがち

GIGO

garbage in, garbage out
モデルが弱く特徴が抽出できない事もある
また最新のモデルにすればいいと考える事もある
しかし、最新のモデルでも精度の差は数ポイントになることが多い
すなわちデータがほぼ全てと言っても過言ではない

データの特徴を消さない

音ではメルスペクトル特徴量や画像では圧縮などをやりがち
推論を高速化する上では重要だが精度を高める上では情報量が全て
最近ではメルスペクトル特徴量のような人の手によって作られた情報ではなく、wavを直接使う事も多い
また、図面などのデータでも、情報がスパースなので、圧縮すると消えてしまったりする
モデルの層に関しても同じでそもそも層に分解可能な情報が残っているのかも重要になる
もし転移学習などを刷る場合は、学習する前に、サブクラスレベルでDNNのレイヤーの分解能があるかを見極めるべき

データの分解

次のような基準でデータフォルダは分ける:

spec/seed（いわゆるデータを生成や収集する前提となるデータの設計書、taxonomyや例など）
self/others（selfは自分がリアルで作ったもの）
real/generated
third_party （他のデータセット用のフォルダ）
grade（難易度別）
class（ラベル別）
sampling_weight（学習時のsampleing weight別）
positive/negative（正負）
easy_positive/easy_negative/hard_positive/hard_negative（グレード別正負）
subclass（特定のサブクラス別、factorized taxonomyとしても有効）
case（特定のケース別）
pair（対照学習の為のデータペア）
test/train/test（holdout用）
calibration（確信度用）
generalization dataset （汎化評価用）

特に、generalization dataset（いわゆる ODD dataset）は用意しないと客観的な性能評価ができない。

seedが実験の仮説

seedはデータを収録、生成、収集する上で基本となるデータの設計書
Data-Centric AIでは、seedがデータ分解能の基本であり最も大切な学習の仮説となるから
例
- 文字レベルでやる場合は、先にTaxonomy（分類体系）を定義を行い分類する
- もし、音声データでやる場合は、音声学（Phonetics）のIPA（International Phonetic Alphabet）をベースにデータの定義を行う
- 難しい課題の場合は、失敗を考慮してgrade（難易度）の定義を行う
- クラスが二値分類ならあえてnegativeを他クラス分類にしてエラーパターン毎に学習させる
- 難しいクラスに関してはsubclassを定義してMECEに列挙する
- 精度が上がらないサブクラスは、対となるDyadのpair setを作って対象学習をする
基本的に、知識空間で論理的にパターンを列挙・網羅して論理的に学習可能なレベルまで落とす
これが仮説になりデータの分解能になり、人によるデータレベルのinductive biasになる
実験においてはここが最も大切な仮説になる
seedはLabel Ontologyと言ったほうが適切かもしれない
人間が対象世界をどの粒度・軸・関係性で分解するかという「データ仮説」を設計することが大切ということ
Knowledge Space → Data Spaceへの射影規則だろう

実験の前提の前提

安定化モード

seedは再現性確保で最も重要な話なので、必ず決定論的に実験ができるようにする
逆説的に、決定論的にしないと、そこが常に疑えるので、そもそもAIとdiscussionや検証しても意味がなくなる
処理速度を犠牲にしてでもやるべきであり、最初に安定化モードの試験を数回行うべき

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


def set_seed(seed: int):
 random.seed(seed)
 np.random.seed(seed)
 torch.manual_seed(seed)
 torch.cuda.manual_seed_all(seed)


def enable_determinism(strict: bool):
 torch.backends.cudnn.deterministic = True
 torch.backends.cudnn.benchmark = False
 torch.backends.cuda.matmul.allow_tf32 = False
 torch.backends.cudnn.allow_tf32 = False
 torch.use_deterministic_algorithms(strict, warn_only=not strict)
 print(f'use_deterministic_algorithms(strict={strict}, warn_only={not strict}) '
 f'+ TF32 無効化 + cudnn.deterministic=True')


# 実行
set_seed(seed)
enable_determinism(True)
print('set_seed / enable_determinism 定義完了')

seedキャリブレーション

seedを変えて結果がどのぐらい変わるのかをCheckする
もしseedを少し変えて結果が大きく変わる場合は、データのとり方などが一番大きなハイパラになる
基本的にそれだとモデルのアーキの向上による差が減るので、固定もするが、seedに依存しないようにするのも大事
例えば、ランダムサンプリングで抽出していたのを、固定分割でサンプリングするなど
ランダムサンプリングだとseedに依存するが、固定分割だったらepochに依存する
epochは往々にして変えないし、増やしても途中の結果が残るので、途中ので比較すればOK

クラス別信頼区間

最初に同じデータ、同じシードでべき等性テストをするべき
もし安定化モードが適用できないような確率的な結果になるときは特に重要
統計的に有意な回数分テストを回して点推定の信頼区間をクラス毎に取るべき
実験をするなかでクラスやグレードごとに分散は違うのが一因
これをしないと、いくら変化があっても原因がその変更によるものかはわからなくなる
これがFirst Stepとなる

対処方法

特徴抽出機の評価

線形Probeで特徴抽出できるのかを評価する

最近のAIの開発は強い特徴抽出機と分類Headを分離する事が多い
その時に、特徴抽出機は外部のものを使うことがあるが、その評価も刷る必要がある
例えば、Encoderを外部がら使ってEmbeddingするとする
AとBとCと複数のEncoderを評価する必要があり、かつそもそも特徴が埋め込まれていているのかも考慮刷る必要がある
例えば、線形プローブでEmbeddingからシンプルな線型回帰ができるか検査する
色々な層の出力に同じ種類の線形Probeを載せて、どの層で情報が最も読み出しやすいかを比較する
もしできないなら、そもそも前提の特徴抽出機やその特徴空間にその情報がないことになる
ただし、仮説の交絡に注意するべき
つまり、本当の原因ではないものを原因だと勘違いしてしまう事に注意
一言でいうと、「どの層で、どんな情報が立ち上がって、どこで消えるか」を見る検査

対照群付き埋め込み分析

一言でいうと、データをベクトル化し、注目するグループと比較対象のグループで、埋め込み空間の違いを調べる分析
例
- 対象群：AIを導入した店舗のレビュー
- 対照群：AIを導入していない似た店舗のレビュー
- この2つを比較して、「AI導入後、顧客レビューの内容が変化したか」を調べる
つまり、対象群は対照群に比べて、この方向にどれだけ特徴的にずれているかを見極める
もし、埋め込み後にデータとして特徴抽出の効果が出ているのか否かを調べる

データの集め方

posiとnegaの両方を集める

positiveだけでなく、negativeも意図して集める
negativeの収集を疎かにすると、実運用でどんな入力が来るか分からないままモデルを評価することになる
特にhard negativeやOODになりうる入力は、positiveと同じくらい丁寧に設計して集めるべき
さらなる理由として、positiveがa・b・cという特徴を持っていて本当はaだけを学習させたい場合、b・cは持つがaは持たないnegativeがないと、モデルが間違った特徴を学習してしまう
- 例: 音声からある単語を学習させたかったのに、negativeが不足していたため単語ではなく話者の喋り方を学習してしまった

中間データも保存する

最終的に使う加工済みデータだけでなく、加工前の中間データも保存しておく
理由は、後から加工方法自体を見直したくなった時に、収集からやり直さずに済むため
生の長尺音声やクリップ前の素材など、後段の処理を差し替えられる余地を残しておく

ダブルチェックをする

ラベル付けや収集作業は、1人だけでなく複数人でダブルチェックする
理由は、収集/ラベリングのミスがそのまま学習データの品質に直結するため
特にAIやクラウドソーシングで生成/収集したデータは、人の目でのダブルチェックが必須

あえて出来合いのデータセットのみでテストを作る

あえて自前データを一切混ぜず、出来合いの公開データセットのみ100%でテストセットを作る
理由は、生成過程が完全に独立したデータで評価できると、自前データの収集過程に共通する癖への過学習を検知できるため
精度を追求する本番用ではなく、評価のための物差しとして使う
特に、他人の作ったデータセットや手法を再現しようとすると、特徴量の計算方法など自分では気づかなかった変えられる点が色々見つかるため、学びや改善幅が大きい

データのクラス間の量

Class stratification（層化）

元データのクラス比率、つまり経験的な事前確率$P(Y)$をなるべく維持したままtrain/val/testに分割すること
例えば、元が A:70%, B:20%, C:10%だった場合は、train/val/testもそれぞれ概ね70/20/10とすること
一般的に、データをsplitする時に、stratified splitして行う

Class balancing（バランス化）

クラス間の影響の偏りを調整する、より広い概念
データ数そのものを変える場合もあれば、ロスのクラスウェイトのようにloss上の重みだけ変える場合もある
方法には以下がある
- oversampling：少数クラスのサンプルを増やす
- undersampling：多数クラスのサンプルを減らす
- サンプリング重み：データ数は変えず、抽選確率を変えてバッチに乗る頻度を調整する
- ロスのクラスウェイト：データ数は変えず、少数クラスのlossへの寄与を大きくする
- Focal Loss：簡単に正解できるサンプルのlossを弱め、難しいサンプルを相対的に重視する
また、balancingの一種で、よくやるのが、train splitで各クラスのサンプル数を、以下のABCのように均等にすること

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


元データ
 A 80 / B 15 / C 5
 ↓ stratified split

Train Validation Test
80 / 15 / 5 80 / 15 / 5 80 / 15 / 5
 ↓
必要ならtrainだけbalancingする。
 ↓
33 / 33 / 33

oversamplingとundersampling

どっちも不均衡データのクラス比率を、学習用データ側で調整する方法。

oversampling
- 少ない方を水増し
undersampling
- 多い方を間引く

サンプリング重み

oversamplingは、実際には各サンプルに重みをつけて、その重みに比例した確率で抽選する形で実装することが多い
ロスのクラスウェイトと違い、lossの計算自体は変えず、どのサンプルがバッチに乗るかの確率だけを変える
インバランスデータの学習に有効
重みは1/サンプル数（所属グループの件数の逆数）を使う
loss reweighting（ロスのクラスウェイト）と対になるやり方

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


group_counts = {
 "A": 1000,
 "B": 10,
}
# 各サンプルがどのグループに属するか
train_groups = [
 "A", "A", "A", # ...
 "B", "B", # ...
]

# ① 各サンプルに「所属グループ件数の逆数」を重みとして付ける
sample_weights = torch.tensor(
 [1.0 / group_counts[g] for g in train_groups],
 dtype=torch.float64,
)

# ② その重みに比例して、n_total個のサンプルindexを抽選する
# replacement=True なので、同じindexが何回選ばれてもOK
perm = torch.multinomial(
 sample_weights,
 n_total,
 replacement=True,
)

# ③ 抽選されたindexを使って、実際の学習データを取り出す
for i in range(0, n_total, batch_size):
 batch_idx = perm[i : i + batch_size]
 x_batch = train_x[batch_idx]
 y_batch = train_y[batch_idx]

 # 普通にlossを計算
 output = model(x_batch)
 loss = criterion(output, y_batch)
 optimizer.zero_grad()
 loss.backward()
 optimizer.step()

hard case

hard caseの注意

特徴の変化のかけ方で有益にも有害にもなるので注意
例えば、画像系だとFeatureに0でマスクをかけてわざと特徴を消して学習させることがある
しかし、これを同じように音のデータに適用するとうまくイカないことが多い
理由は音の場合は不自然さを学習してしまうから
ゆえに、単調にMaskをかけたりノイズでMaskをかけたり複数の手法を試す必要がある

shifted positive

例えば、「太郎」を取る時に、最低でも３つは作れる
「〜太郎」、「〜太郎〜」、「太郎〜」みたいな形
こちらもデータのかさ増しに使える
この場合は、時系列的なずらしによるpositiveケースを増やす例

adversarial negatives

いわゆるハードネガティブの一種
例えば、「太郎」を取る時に、音的ににているものをnegativeとして用意刷る手法
「tara」や「soro」みたいな形で一部分を変更した特徴量として作る
これは意図的に似た音のケースを増やす例

Truncated Negative

Trainデータの中でPositiveケースの一部を含むデータをNegativeとして用意する手法
例えば、「太郎」という名前を分類したい場合は、「〜太」と「郎〜」という２つの前後のTruncated Negativeを用意できる
全体を学習させたいが、部分で安易に分類させたくない場合に有効
部分切り出しによってトレインデータも増えるので、データかさ増しにも有効

Hidden Negative

画像などでもFine-grained Classificationなどでも特徴をMaskで隠して学習させる手法が有効とされている
Hard NegativeをPositiveケースの一部を隠して作る手法
特徴的なところをベースに学習が進むので、細かな特徴による違いを学習するにはあえて大局的な特徴を隠して、局所特徴を学習させる
こちらもデータかさ増しにも有効

combination

上述のpositive/negaitveのパターンは特徴量の要素によってさらにデータを増やせる
例えば、「たろう」を取りたく、精度を上げるために、hidden negativeを適用とする
「たろう」は3文字なので、3要素となり、この要素をABCとすると、正解はABCのみ
すると、hidden negativeだけでも次のケースが考えられる
$\binom{3}{2} + \binom{3}{1} + \binom{3}{0}$
2つ選ぶ：AB、AC、BC（3通り）
1つ選ぶ：A、B、C（3通り）
0個選ぶ：選ばない（1通り）
つまり、順番と要素が必須なので、7パターンのhidden negativeが作れるという事

Negation Class

Noneクラス（負例クラス）を追加する

低い確信度を単純に棄却するだけでなく、明示的なNoneまたはOtherクラスを追加した
これにより、モデルは既知のpositiveクラスだけでなく、学習時に与えた負例をNoneとして識別できるようになる
ただし、Noneクラスを追加しても、あらゆる未知入力を識別できるわけではない
学習に使用した負例や、それに近いOODには有効でも、まったく異なる未知入力に対して誤って高い確信度を出す可能性は残る
ただし、Noneは全体負例クラス用のメタクラスなため、実質Noneの1-Recallこそ本来的な全体のFRPになるので注意
この方法によってNoneのRecall（Noneを見逃さなかった）=>普通のクラスのPrecisionとなる
つまり、見逃さずに正確に処理できた普通のクラスの評価ができるようになる
Noneクラスの性能が下がると、当然普通クラスの性能にも影響がでる事になる

予め苦手なタスクを加味して対策する

例えば、NLPでは否定の表現が実は精度が下がりがちだったりする
それは特徴がにているにも関わらず、クラス領域外になるから
そういう既知の弱点に関しては予めデータ・セットのバランスを調整して対処が可能

Negationの明確化

特に、negationがある場合に有効
例えば、Moveクラスの反対はDon’t MoveだがStopクラスもあるとAIは迷う
その場合は、意味を明確化刷るために、MoveクラスのSlotにNegationを入れてMove(negated=True)のように対応する
するとメタクラスであるNone（負例クラス）以外は、否定クラスはNegationのスロットで対応ができる
結果、動かない!=Stopという事を学習しやくくなり精度が上がる
これはデータセットの無矛盾性とも関連する

Class Design

データセットの原則

データセットが間違えているとモデルも間違える。

では、ゲーテではないが、不完全性ではない完璧なデータセットを作れるのか？

それの暫定的な答えは以下になった:

完全性
- 不可能、なぜなら入力空間が無限だから（網羅は不可能）
- 故に、現実的なユースケースを定義して、目標をおさえるしかない
無矛盾
- 可能、なぜならタキソノミーを定義して、運用でカバーができる
- データをAIで作るとしても、細かなレシピがあれば無矛盾を回避可能

ただし、ソリテスパラドックスのように、境界を定義する問題は曖昧さがあるので注意。

サブデータセットを作って対処する

困難は分割せよではないが、サブデータセットを作るのも有効
サブデータセット = grade（難易度） x クラス数
そしてそれぞれにtaxonomyとdefinitinoを定義する
分割統治法のように小さなデータを無矛盾かつ完全に作るのが目的
大量の矛盾するデータよりも、少量の無矛盾のデータを作るイメージ
特にクラスの意味がにているinnner-class classificationなどには有効
結果、graddeでフォルダを切って、クラスでフォルダを切って、そこでさらにtaxonomyで分析してseedを生成するイメージ

小さな範囲で学習が可能かのテストをする

もしデータ・セットが無矛盾かつ完全だった場合は、作成したデータ・セットで学習してgradeの低いものは解けるはずだから
最初に作ったseedデータをベースにdata generationやaugumentationするまえに、素の状態でテストするのもあり
小さく試してどのgradeの学習ができるかのCkeckしてから拡張する方がベター
モデルの容量や学習データが難しいのではなく、学習データが矛盾していたり刷ることがよくあるから
ただし、小さな多様性のない小さな範囲での実験になるので汎化したまでとは言えない事が多い
基本をやってから応用を学習するべきという考え方

データセットの定義例

他クラス分類の例

まずdataについて、種となるデータと生成されたデータは分ける
data/{seeds, generated}のような形
そして、data/seeds/grade1/class_name/{positive,negative}/subclass_name/{def.md, seed.csv}みたいに切る
gradeは難易度の事でgrade1~6ぐらいまで定義する
gradeを定義刷る理由は、うまく行かなかった時にどこまでうまくいくのかを測る目的
そして、それぞれの$grade \times class \times subclass$について分割統治法のように解いていくイメージ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


 seed1/
 grade1/
 class1/
 positive/
 subclass1/
 subclass2/
 negative/
 subclass1/
 subclass2/
 class2/
 positive/
 subclass1/
 subclass2/
 negative/
 subclass1/
 subclass2/
 grade2/
 class2/
 positive/
 subclass1/
 subclass2/
 negative/
 subclass1/
 subclass2/

二値分類の例

xxxという名前を呼ぶ二値分類のクラス設計の例
グレードでトップで分けるのではなく、まずreal/syntheticというsourceの軸で分ける
その後に、grade分け（難易度分け）をあえてクラスに落として、クラス単位でグレードを教える
この例は単純な一つのクラスの二値分類の例だが、二値以外も入れて5クラス分類にしている
xxx_voiceフォルダ以外はネガティブケースとなっている
最後に、サブクラス単位で分割している

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


 synthetic/
 xxx_voice/
 easy_simple/
 hard_negative_voice/
 wrong_name_with_prefix/
 arbitrary_prefix/
 bare_other_name/
 real_word_fragment/
 invented_syllable/{nyao, yoon, sonorant_o, consonant_eo, second_mora_eo}/
 no_voice/
 synthetic_noise/
 real/
 xxx_voice/
 easy_simple/
 negative_voice/
 reazon/ vocal_bursts/ st_train_ja/ audioset_ns/
 no_voice/
 silence_clips/ demand_clips/ esc50/ musan_noise/ noise_only/

Geometric Class Design

クラスの定義を絞る

精度が低いものに対して、データ量を増やして曖昧な境界線を学習させるのではなく、クラス自体の範囲を狭める方法も有効
クラスの判定対象を狭め、クラス間の境界が太くなるようにモデルの設計をする
全体の土地を広げて（データを増やして）国境線の太さ（クラスの境界線の太さ）を広げるより、そもそも国土を小さくすれば境界線が太くなるという考え方
もちろん、モデルの性能が理由の場合もある

inner-classでのsubcatのサンプル傾向の割合を考える

例えば、そのクラスを決定する特徴的なものを属性1とする
それに対して、次点で優位な特徴を属性2とする
それらの軸をかけあわせてtaxinomyを作りデータをsubcat（サブカテゴリー）で分類する
クラス内の特徴を抽出してサンプルを生成するレシピで網羅する作戦

inter-classでラベル矛盾がないか

特に意味の近いクラスを分類する必要があるときは矛盾が発生しやすい
AというクラスとBというクラスでそれぞれのサンプルの中で一貫した教師信号がないなど
その場合はクラス間での矛盾がないかのCheckが必要
そうでもしないと、モデルが安い結論に陥りがち

クラスの領域空間をデザインする

分類する空間では基本的に2種類あると考えている
中心となるコアと、その界面であるサーフェス
例えば、文字ベースの分類だった場合
- コア
  - 意味軸
  - 人間製でseedで作成
  - もしくは実データをサンプリング
- サーフェス
  - 表現軸
  - AI製でseedからaugumentation
  - 例えばパラフレーズの生成など
こうすることでクラスの幾何学的な領域を作成することができるようになる

クラスの境界用のデータセットを作る

国土を狭めて国境線を太くしても間違える事はある
例えば、12クラス分類をしていたとする
その時に、ある3つのクラスは物理的に意味が近い事がある
そうすると、そこの境界は間違えやすい
そのため、クラス際のデータセットが作るのが有効
シンプルに12個のclassから2つ選ぶ組み合わせは66通り
そして、境界の際にそれぞれデータが必要なので、66x2=132通りになる（境界の両側にデータを用意する意味で）
つまり、距離に関わらないのであれば、原理的には132通りの境界クラス用のデータが必要となる

クラス境界のデータセットを作るためのクラスの選び方

先程の例だと、12クラス分類から2つの組み合わせなので66通り
ただしそれは大変なので、ターゲットを狙ってやったほうがいい
例えば、混同行列から66のランキングで誤爆ランキングを出して判断もできる
他にも何かの指標と相関性をとって判断するもいいかもしれない
ただし、同じデータを使った相関係数はトートロジーなので注意

Grade class

評価用のデータをgrade別に用意する

評価用のデータは難易度別に複数用意するべき
たとえデータを追加しても基礎能力に悪影響している可能性もある
そのため、小学校みたいに6段階でgrade別のholdoutのデータセットを用意し評価すると良い
grade1がいけるからその使い方をするみたいな逃げ道もできるから
例えば、paraphraseやreason付き、否定も入れるとgrade+1するとか

paraphraseの例:

同意語への置き換え
受動態と能動態の変換
品詞の変更
文の統合・分割

データセットの拡張

holdout/heldoutだけだと学習ができた事以外の証明にならない
そのため、difficultケースや全く別に作ってtestデータなどをベースに試験もするべき
つまり、複数種類のtestやevalのデータ・セットを用意するべき
また、特に1クラスのevalのサンプルサイズが経験則的には50以下でのholdoutは統計的に優位な数値がでない
特に、1教科で90点なのと、10教科で90点なのでは意味が全然違うので、分母は加味するべき
これはedge caseを除いたデータセットを作るなどのスコープの定義にも関わる

データの量

テストデータのサンプル数

仮にseedを固定していて実験がべき等に実行でき、２回同じ実験をしたら全く同じ結果が帰ってきてもサンプルサイズは必要
なぜなら、サンプル数が極端に少ないと、実験の比較では良くても、ドメインシフトが起こっている可能性があるから
また、テストデータは結局は注ぎ足し継ぎ足しで増やしていくので、結局は数が重要
また、学習時にはべき等であったとしても、評価時にべき等とは限らないので評価方法にも注意が必要

テストデータの相対的な量

テストデータの相対的な量も重要
例えば、AクラスとBクラスがあり、ある実験でBクラスのデータ（ホールドアウトも含めて）を増やすと、Bクラス過多になったしまった
ここで、Bクラスの精度の良し悪しは判断しやすいが、全体的な精度とAクラスの精度の見極めは難しい
当然、全体の精度（ミクロ指標）はBクラス過多になっているので、平等な精度の指標ではなくなる
そして、Aクラスは相対的に量が少なくなり、学習量もこのBクラスに大きく振っている事になる
つまり、もともと学習していたAクラスの特徴をモデルの容量不足で上書きした可能性もある
その場合は、モグラたたきではなく、モデル容量の不足が原因ということ（ASRのEncoderがわかりやすい例）
おうおうにして、データ量も増やしたらモデルのパラメータも一緒に増やす必要がある

Data Check

最小構成でのミニテスト（Overfit a single batch）

数百万パターンにもなるような大きな予測対象を扱う場合、いきなり全件で学習・評価するだけでなく、そのうち1件だけを使ってデータ生成・学習・テストを一通り試すのも有効
パイプライン全体（データ生成→学習→推論）を最小構成で一度通してみて、勘所を掴むのが目的
1件だけの学習すら成功しない（lossが下がりきらない）なら、パターン数を増やす前にやり方自体を疑うべき
逆に1件で学習できるなら、そのまま件数を横展開していけばいい
機械学習分野では一般に「overfit a single batch」と呼ばれる、学習パイプラインのsanity checkの定番手法

データビュアー

seedデータのデータビュアーは作るべき
大量データのCheckを高速化するのが目的
特にデータが多いとデータの品質Checkが大変になるため

そもそもデータセットの確認

ゴミを入れたらゴミがでるだけなので、そこのCheckを先にするべき
traindataが一部間違っていた結果精度が出ていない初歩ミスもある
それを完全に終わった後に、モデルのパラメーター増やすなどの改善フローに入れる
そもそも分母のデータは正常なのか、evalのサンプルサイズは足りているのか、エラーの例は妥当かのCheckになる
特にAIに生成されたデータは確実にCheckが必要

前提の制約を変える

可視化後、現実的に精度を高く分類することが厳しいなどがわかるようになることがある
その場合は、前提の制約を変えて境界線がはっきりでるようにそもそも要件とデータセットを変えるべき
モデルを大きくでもしない限り難しいこともあるため

結果の比較

追加したデータ量の確認

基本的に過去の実験と新しくした実験を比較するが、そもそも論データを増やしたら前提が変わる
例えば、Positive/Negativeの二値分類で、Positiveデータを増やしたとする
すると、それに引っ張られてモデルのPositiveの出しやすさも変わる
すなわち、何件そのカテゴリーで追加したのか、それは前回と比べて何％増えたのか、そして、クラス比はどう変わったのかを計算する必要がある
それらを元にデータ量や比率の違いによる影響のありなしを評価することができる

ホールドアウトかの確認

ある実験とある別の実験の比較で追加したデータによる精度の比較をする
つまり、新しく追加したデータがホールドアウトとして半分とか評価データに使われているなら疑うべき
特に新しいデータを大量に追加してその結果、評価データが増えて、指標が良くなっただけかもしれないから
基本的に評価データはホールドアウト以外に評価のみのデータセットを用意しておいてそれでもCheckするべき

アブレーション

もし追加したデータやモデルの差を見たいん場合はアブレーションをするべき
結局は安定化モードで決定論的な結果を出せても、複数の変更を含む実験だと原因が分からなくなる
機能であれば、XXXを消したバージョン、YYYを消したバージョンなどで追試をすることで何が寄与したのかを出せる

サブクラス間の相関

クラスのpositive/negativeの中のさらにsubclassを定義することで強みと弱みがわかる
特にデータ量の差よりもそのサブクラスの特性による得意不得意がわかるから
あえて弱みのサブクラスに対してはOut of Scope対応にしたりそれ専用の対策を入れる事も可能になる
それができるのも、クラスのさらに細かいSetのサブクラスを定義するから

総当りサブクラス

さらに、総当たり系のサブクラスはそもそも論、サブクラスの中の更に詳細なサブサブクラスも把握できる
例えば、あるクラスのネガティブのあるサブクラスについて、MECEに網羅できるならそれの中のサブサブクラスがモデルの性能を明らかにする
結局はデータの定義やTaxonomyをしっかりすれば、色々な考察が可能になる

Exposure

サブクラスカバー率とサブクラス学習効率

サブクラス毎に量の偏りがある場合は、サブクラスごとの選出率も関係ある
AとBというサブクラスがあり、Bクラスは量が多いが、AとBを同じ用にサンプリングしていたらカバー率が違う
仮に新しいBというサブクラスを追加しても精度が上がらない=難しいとはならない点に注意
また、統計的に仮にカバーを100%していても見ている回数が違う＝学習しやすさが違う場合がある
その場合は、カバー率だけではなく、学習効率（$sampleされた回数/データセットのサンプル数$）も出すべき
ステップ数におけるサンプリング数をだして、その上でサブクラスカバー率とサブクラス学習割合を出すべき
これとサブクラスごとの誤検知率とサブクラス学習割合の相関性をだすと学習が公平だったのかがわかる

サブクラスバリエーション効率

これはData Augumentaionする前提での話
subset毎にデータaugmentationを変えていた場合は、それもvariationという指標になる
単純な話サンプル数が多くてもvariationの少ないところからのsamplingか否かで大きく意味が異なる
そのため、精度との比較はサブクラスの学習効率とともに、variation数も比較する必要がある
バリエーション効率は$variation/samples$で求める
一般的に、量が多いデータセット程複雑なパターンがあるという前提で効率を求める

露出と表現の問題

仮にあるサブクラスの精度が低く、サブクラスのvariationとカバー率を上げたとする
その結果、サブクラスは相対的、絶対的に増えたにも関わらず精度が上がらなかったとする
この場合は、データの露出は増やしたのに、表現が上がらなかった事を意味する
すなわち、Exposureの問題ではなくExpressionの問題と判断する事ができる
Expressionとは、例えば分類問題などであった場合はHeadの話
特に、すでに線形Probeなどでモデルの層に線形分類するだけの特徴がある場合などは強くその仮説が支持される
例えば、分類層では、mean poolingをしていたがそれが特徴をけしていた、など

error analysis

データリーケージに注意する

データリーケージ（Data Leakage）とは、本来モデルが知り得ない情報が、学習や評価のプロセスに紛れ込んでしまうこと
エラーアナリシスにおいては、testデータを見て傾向をつかみ、その結果を元にモデルやデータを改善するというサイクルを繰り返すこと自体が、一種のデータリーケージになる
繰り返すうちにtestデータが実質的なvalidationデータ化してしまい、最終的な評価値が楽観的に偏る
これは後述のWinner’s Curseと同じ、同じデータで選択と評価を繰り返すことで生じるバイアスの一種
そのため、エラーアナリシスは基本的にvalidationデータで行い、testデータは最終確認のためだけに温存するべき

Winner’s Curse（勝者の呪い）に注意

複数のモデル、checkpoint、しきい値、ハイパーパラメータを同じ検証データで比較し、その中で一番良かったものを選ぶと、選ばれた候補の評価値は本来の実力より楽観的に偏る
理由は、比較対象の数が増えるほど、たまたま検証データとの相性が良かっただけの候補が選ばれやすくなるため
元はオークション理論の用語で、複数の入札者が同じ対象の価値を誤差込みで見積もったとき、最も高く見積もった入札者（勝者）の見積もりは実際の価値より高くなりがちという現象
意思決定論では同じ現象をoptimizer’s curseとも呼ぶ
データリーケージが「testデータを見て判断や改善を繰り返すこと」自体の問題なのに対し、Winner’s Curseは「パラメータや候補を最適化（比較・選択）した結果、選ばれたものの評価値が偏る」という、選択操作そのものに起因するバイアス
対処方法
- 選定に使ったのとは別のホールドアウトデータで、選ばれた候補を再評価する
- 比較する候補の数を絞る、または候補間の差が誤差の範囲内かを検定する
- checkpointの学習時evalを鵜呑みにしないという注意点（後述）も、この現象の一種

NOTE:

いわゆる「データ最適化バイアス」（同じデータに対して選択と評価を繰り返すことで生じる楽観バイアス）と、この現象は本質的に同じもの
しきい値選定、モデル選定、特徴量選定、ハイパーパラメータ探索など、何であれ「同じデータで何度も比較して一番良いものを選ぶ」という操作が入る限り発生する
呼び方が違うだけで、根っこにあるのは「選択に使ったデータで、選んだものをそのまま評価してはいけない」という同一の問題

エラーアナリシス

言わずもがなエラーアナリシスを行うのが一番大切
どこがエラーになり、なぜエラーになったのかの分析のこと
特にエラーの分類（Subcategorization）を行い、何が弱いのかを具体的に判断する
他には、一番重要なのはNoneクラスのRecall（全体見逃し）やその他のクラスのPrecisionなど
subcat毎に指標を置いて、エラーの傾向や割合をCheckする
別の言い方だと、Don’t boil the oceanという考え方に近い

データを可視化する

例えば、PCA、T-SNE、UMAPなどで次元を削減して可視化するのも一つの手
クラスタリングしてクラスごとの境界線を可視化するとどのぐらい分けれているのかがわかるため
そこで実際にコードを動かして結果を元にプロットするとどのクラスターに近いかがわかる
実際に手で動かすと、実はWhack-a-Moleパターンだとわかることもある
単に混同行列だけではなく、推論用にクラス境界マップを作るがおすすめ

確信度の高いfalseの境界ペアの可視化

確信度の高いfalseの境界ペアを明らかにするのが一番当たり前だが最も重要
確信度が90%以上で間違った例を確認して、どのクラスがどのクラスと間違えたのかという情報
例えば、AをBと間違えたなら、その分類の境界線が怪しいということ
それらのfalseの境界ペアに対して、境界線をはっきりさせる為のサンプルを追加すればいいという事
そして、Noneが全体を網羅する負例クラスとして存在するため、幾何学的にNoneはあらゆるクラスと接する
そのため、Noneに関してはepoch毎に入れ替えて多様性を加味して多角的に接点を学習させる必要がある
普通のクラス境界よりもNoneのクラス境界は多次元的に接していると考えられるため
別の言い方をすると、あるAクラスは狭いので他のクラスと距離がある、しかし、Noneは広いので他のクラスと距離が近いということ

信頼度をキャリブレーション

分類器が出力する信頼度 (confidence) が、分類結果が真に正しい可能性を表すように補正する
これを、信頼度キャリブレーション (confidence calibration) と呼ぶ
つまり、AIや自動化システムへの信頼を、そのシステムの実際の当たりやすさに近づけていく手法

エラーのクラス分類

特にしきい値が高いときのエラーの内訳が大切
その上で、genuine vs. quetionableなのかが最初のフィルターになる
つまり、評価データで正しくGTのラベルがついいているかいないかという事
さらに、それがグレード別にどうなのかの判断も大切
ODDだった場合はグレード外やtaxonomyのヌケモレだったということ
エラー内のクラス分類をして間違えたOODに対して、対策するのが正しい

Nearest Neighbor Analysis

学習して分析し、最もエラーが高かったものの一覧を出す
それをベースに、まずはどんな特徴があるのかをCheckする
さらに、そのエラーの特徴量一つ一つの特徴量と一番近い学習データの特徴量を出す
これによって、そのエラーが何のトレインによって学習されたのかがわかる
例えば、ある似たTrainの集合A, B, Cというデータがあり、それぞれ特徴量DとEを共有する
しかし、実際にDを学習させる目的で学習したらEも学習してしまったみたいな事もある
その場合は、Eを含むNear Negativeなデータを含めればいいとわかる

評価

かならず複数しきい値で評価する

しきい値を一つで評価するとモデルの評価はできない
AUCも複数種類でやるべきであり、かつclassやsubclassレベルでもやるべき
特に、モデルのアーキを良くしたのに精度を一つの指標で評価するのは危険
性能が上がっているのに、見落としている事が往々にしてあるから
最低でもROC-AUCとPR-ACU、pAUC（この場合は、FPRのpartial AUC=部分AUCなど）で評価するべき

不均衡データではAUC系より実運用の分母に寄り添った指標を使う

極端に不均衡なデータでは、AUC系の指標だけでは実運用の感覚とズレることがある
理由は、AUCは正例・負例のペアの順位関係を見る指標なので、負例が膨大にあっても比較的高い値が出やすいため
実運用の分母（1時間あたり・1日あたりの発話数など）に寄り添った指標を使うべき
- 例: FA/hour（1時間あたりの誤発火数）
こうすることで、「実際に運用したらどれくらいの頻度で誤動作するか」が直感的に分かる

マクロ指標とマイクロ指標でみる

全体としては性能が下がっていように見えても部分では性能が上がっている可能性がある
全サンプルを均等に評価するマイクロ指標サブクラスやクラス毎に出して評価するマクロ指標は分けるべき
特にある一部の問題を解決できるが全体の性能が下がるトレードオフがあるのが普通
全体評価と個別評価は分けて述べるべき

アップストリーム指標の注意

前提となるepoch選定には学習時のアップストリーム指標のみで測るとbestモデルを選べないことがある
故に、analysisの前提となるepochについては、ダウンストリーム指標で測るのがベター
すなわち、eval_lossとかだけではなく、この例で言うと、FPRやNone-Recall、クラスのPrecisionなどで総合的にクラスやサブクラスベースで測るべき
安易にeval_lossでbestを出さないべき

checkpointの学習時evalを鵜呑みにしない

学習中に自動で出るcheckpointごとのeval結果は、軽量・簡易な指標であることが多い
良さそうなcheckpointが見つかっても、その数値をそのまま信じてモデルを選定しない
後で改めて、ちゃんとした評価指標・評価データでそのcheckpointを洗い直すべき
学習時evalと本番想定の評価は、計算方法やデータの粒度が異なることが多く、乖離が起きうるため

Winner’s Curse（パラメータ最適化のバイアス）

Winner’s Curseについては、前述の「error analysis」内の同名セクションを参照。

足し算じゃない相互作用に注意

変更一つに対して精度が下がってもそれが必ずしも悪影響だったかというとそうでもないこともあるので注意
例えば、以下みたいなことがある
- Aという変更=>精度が下がった
- Bという変更=>精度が下がった
- しかしAとBを両方同時に入れた=>精度が上がった
故に、一般的に論理的に考えて有効な手法でも前提条件が揃わず下がる事があるので注意
自分の例では、multi-head attention pool x exposure設定の向上などであった
かっこよくいうと、non-additive interactionというらしい（マイナスかけてプラスだから？）

OOD対策の評価方法

OOD対策は、単一のテストデータだけで評価しないほうがよい。

例えば、次のように評価データを分ける。

IDのpositive
IDのnegative
IDに近いnear-OOD
IDから明確に離れたfar-OOD
実際の運用ログから作ったデータ
時期、ユーザー、環境などで分けたデータ

確認する指標には次のようなものがある。

対象	主な指標
通常の分類	Precision、Recall、FPR、F1
OOD検出	AUROC、AUPR、FPR@95TPR
棄却を含む分類	Coverage、Selective Risk
安全性	受理した予測におけるFP件数・FP率と信頼区間

しきい値は検証データで決定し、最終評価データを確認してから変更しないことも重要である。

評価データ上でFPが0件だった場合も、「観測されたFPが0件だった」と表現し、将来のFPが0であると断定しない。

model

学習率の選択

いろいろな手法を試していて、早いepochでlossが下がりすぎる傾向がある場合は、学習率が高すぎることを疑うべき
学習率の調整だけでも、スコアが良くなることが多い
迷ったら、その手法のベースになっている論文で使われている学習率を採用するのが安牌
桁を変えた複数の学習率（例: 1e-3、1e-4、1e-5）で実際にチェックして比較するべき

入力データを増やす

基本的に入力に対してモデルは学習する
もしどんなに頑張っても精度が上がらないときは、シンプルに入力データを増やすといい
あるEncoderをFreezeしたモデルで使ったクラス分類の時に、そのEncoderの中間データを使った
一般的にEncoderの最後の出力を使うと、既に丸められたデータだったから
このように、入力が抽象化されて弱いときはあえて、低次元のプリミティブな情報を取ってモデルを構築するのもあり

マルチエンコーダーを組み合わせる時の注意

複数のEncoderの出力をシンプルにconcatして学習に使ったが、精度が上がらなかった
原因は、Encoderごとに出力のスケールが違うものをそのままconcatしていたこと
スケールの大きいEncoder側の情報にモデルが引っ張られてしまい、スケールの小さい方の情報が実質的に無視されてしまう
対処方法はz値化
各Encoderの出力を平均0・分散1に標準化してからconcatすることで、スケールの違いによる偏りをなくす

モデルを厚くする

モデルのパラメータと学習量には相関性がある
ASRなどではEncoderの学習できる量はそのパラメーター数で決まる
例えば、大きな学習データを小さいEncoderで学習しようとしても忘却してしまう
もしくは、小さな学習データを大きなEncoderで学習しても過学習するだけ
モデルの容量とトレインデータのバランスが取れるモデルの厚みにするべき

残差とconcat

ResNetのような加算による残差を伝えたり、concatして長いベクトルにする方法もある
例えば、Conv層で情報を近傍の特徴を抽出しているが、それが原因だと判断した場合
その場合は、そのConv層で行う入力を残差ブロックやConcatで繋げて後ろに伝える方法

PE

TransformerではPositional Encodingを行う
それを応用してabsolute/relativeなPEを使って位置情報を明示的に特徴にする方法もある
Conv層の場合は、局所的な特徴をFilterするのでbiasとして織り込まれているが、明示的にPEをやるのもあり
ただし、絶対的なPEを使うと、その場所にその情報があることを過学習してしまう可能性もあるので注意

PoolingをAttentionに

poolingをAttentionするのも有効な手法
局所特徴をConvなどで抽出したとに、情報を抽象化する意味でPool層を入れる事はあるが、情報がぼやけてしまうことがある
例えば、mean poolなどでは、結局はpoolはそれぞれを重みをなく要約するので重要な情報が落ちる可能性がある
この場合は平均に要約されて、最大や最小の情報が消えてしまっている
そのため、Query attention poolingやmulti head attention poolingなどでどこのpoolを重要視するかを学習させるのもあり

ConvをAttentionに

ConvをAttention系にするのも有効な手法
Convだと近傍の特徴をまとめるinductive biasがかかっているが、全体をみたい時などにはself-attentionなどが有効
特に、multi-head self-attentionで複数のhead（見方）から高度なattentionをかけて特徴抽出を学習することができる

不均衡データの学習方法

None（負例）をepochごとに入れ替える

Noneクラスとして利用できる負例が大量にある場合、各epochで異なる負例をサンプリングした
これにより、Noneクラスの件数を極端に増やさずに、多様な負例をモデルへ提示できる
ただし、epochごとにランダムに入れ替えるだけではhard negative miningとは限らない
現在のモデルが高いpositiveスコアを出した負例を優先的に選ぶ場合に、hard negative miningと呼べる
また、学習時のクラス比率を変えること自体は禁止ではない
クラス比率、サンプリング方法、クラス重みは、precision、recall、確率校正に影響するため、目的に合わせて検証する必要がある

損失関数の重みで調整

epoch毎に入れ替えて調整する方法もあるが、損失関数側で重みで調整する方法もある
例えば、Positiveケースが少なく、Negativeケースが多い場合、あえてそのままで学習する
しかし、損失関数側でPositiveの重みを$\frac{neg}{pos}$倍に調整して、Positive側を大きく調整することとする
これによって、Positiveを学習しやすく、Negativeを学習しにくくし、影響をコントロールできる
少量のソースのサブクラスは普通にepochで全部学習さ、大量のソースのものはsamplingする形になる

ロスのクラスウェイト

ロスのクラスウェイトは「そのサンプルが何クラスか」で重みを決る
たとえば A:1%, B:99%なら、Aクラスはweight = 99、Bクラスはweight = 1
つまり、Aはサンプルが少ないので、Aのサンプルなら簡単なAでも難しいAでも全部重くするイメージ
データ数は変えず、少数クラス1件あたりのlossへの寄与を大きくする
ロスのクラスウェイトにはサンプル数の逆数が使える
- lossの計算時にクラスごとの重みを掛けて調整する

Focal Loss

クラス数そのものではなく、予測の難しさに応じて各サンプルのlossを調整する
ロスのクラスウェイトと違い、Focal Lossは「そのサンプルをモデルがどれくらい簡単に当てられているか」で重みを変える
例
- 正解を99%確信している → ほぼ無視
- 正解を60%くらい → そこそこ重視
- 正解を10%しか出せない → 強く重視
- つまり、クラスではなく難易度を見る
少数クラスは学習が浅い段階では確信度が低い（＝難しい）ことが多いため、Focal Lossはロスレベルで結果的にマイノリティクラスへ重みをかけることになる
- そのため、Focal Lossを使う場合はロスのクラスウェイトを併用してはいけない（重みが二重に乗ってしまうため）

ロスのクラスウェイトとFocal Lossの比較

-	ロスのクラスウェイト	Focal Loss
重みの基準	クラス	サンプルの難しさ
少数クラス	直接重くする	直接は関係ない
簡単なサンプル	少数クラスなら重いまま	軽くする
主な目的	クラス不均衡対策	Easy sample が大量にある問題への対策

まとめると、

ロスのクラスウェイト：「少数クラスだから重要視」
Focal Loss：「まだ上手く分類できないから重要視」

注意点として、不均衡データに対して既にロスのクラスウェイトで対応している場合、そこにFocal Lossを追加すると重みが二重に乗ってしまい逆効果になる。Focal Lossを使うなら、ロスのクラスウェイトは外す必要がある。

不揃いデータの学習方法

クラスごとの数が偏っている不均衡データとは別に、サンプルごとの難易度や質にばらつきがある不揃いなデータもある。この場合、いきなり全データを均等に学習させるより、まず粗く全体像を学習してから徐々に詳細や難しいケースに踏み込んでいく方が有効なことがある。

カリキュラム学習

人間が易しい問題から難しい問題へ順に学ぶのと同じように、モデルにも易しいサンプルから難しいサンプルへ順に学習させる手法
いきなり難しい・ノイズの多いサンプルを学習させると、学習が不安定になったり収束が遅くなったりすることがある
「易しい」の基準はタスクによって様々で、ラベルの確信度が高い、サンプルサイズが小さい、ノイズが少ない、などが使われる
学習が進むにつれて、徐々に難しい・不揃いなサンプルの比率を上げていく

破滅的忘却（Catastrophic Forgetting）

段階的に学習を進める際、新しい（後段の）データばかり学習させると、以前学習した内容を忘れてしまう現象
カリキュラム学習のように学習フェーズを分けたり、新しいドメインのデータを後から追加学習させたりする場合に起きやすい
対策
- 新しいデータだけでなく、古いデータも一定割合混ぜて学習を続ける（リハーサル）
- 学習率を下げて、既存の重みを大きく壊さないようにする
- 重要なパラメータの変化を抑制する正則化を加える

train

データを増量する時の注意

例えば、全体のデータ量を数倍にするのは一般的にやる方法
ただし、Train中にあるカテゴリーが弱いからとそこだけ増やすと問題が発生する事が多い
発生するのは「1カテゴリだけ拡張すると他が犠牲になる」問題
ある少量のサンプルを過度に拡張すると、過学習が起きる
つまり、データAugmentationなどをする場合は、もともとの多様性が重要ということ
言い換えると
- もともとのユニークなものが多い（多様性がある）=>増やしても偏らない=>全体的な底上げになる
- もともとのユニークなものが少ない=>増やすと偏り過学習になる=>り他のクラスも低下させる、もぐらたたきになる。
言い換えると、データ量とモデル容量の関係はもちろん容量の問題もあるが、データ量の多様性の問題もある

実験ログとdiscussionログを残す

実験に再現性と論理性、実論性、問題の真性を検証すためにいくつかの工夫が必要。

フォルダ分けする
- 再現性のためexperimentsフォルダを切ってそこで作業する
- 例えば、experiments/01_xxxみたいな形
- そこの中で完結するようにして、独立性を高める（例えば、過去の実験コードなどは使わない）
実行logなどは必ず全て保存する
- データドリブンでAIに開発させるのが目的
- データがあれば問題の再現性を検証できる
- AIにGuessさせない
mdベースでissueについてdiscussionする
- 理由は、課題が再現しても（原因がわかっても）解決するべき本物の課題かを議論する
- 前提が間違っていたり、インパクトが小さかったり、実現可能性が引くい可能性もある
- issueの真因究明と本物の課題かどうかをまずは見極める
mdベースでsolutionのdiscussionをする
- 解決策についてもmdでdiscussionする
- 特に課題の原因と価値が明らかになったら次は打ち手の検証が必要だから
- 打ち手についてもA vs Bのよう形で検証して結論を出してからsrcのコードに反映する

lossのトレンドの見方

train lossとvalid lossがどちらもまだ下がっている場合は、epoch数を増やした方がいい
- 収束しきっていないのに学習を打ち切ると、伸びしろを捨てることになる
wandbなどでlossを可視化して管理するべき
- 数値の羅列だけでは傾向がつかみにくく、グラフで見た方がトレンドが分かりやすい
プラトー（lossがほぼ横ばいになっている状態）にいるかどうかを確認する
- プラトーに入っているなら、そのままepochを増やしても伸びない可能性が高い

val_lossの設計

train lossだけを見ていると過学習に気づけないので、val lossが大切
val_lossの計算をやりすぎると重くなるので、毎epochではなく数epochに一度でもいい
最終的にはtestで使うような指標でval_lossを評価するべき
- valとtestで見ている指標がズレていると、valが良くてもtestで期待通りの結果にならないことがある

Dropout

trainで過学習を抑える目的で使う
非決定性の原因になりうるが、精度向上のためには入れるべき
スパイスのようなもの——少し入れるだけで効いてくる

Focal Loss

BCEだと、簡単な問題も難しい問題も同じように学習してしまう
Focal Lossを使うと、難しい問題（誤分類しやすい/確信度が低い例）により大きなウェイトを置いて学習できる
簡単な問題の勾配を抑えることで、モデルの学習を難しい問題に集中させる

ゲート処理

ブラックリスト方式ですべての不正入力を列挙するのではなく、条件を満たした入力だけを許可するホワイトリスト方式のゲートを設けた
ゲート処理によって、OODや不適合入力が分類モデルまで到達する可能性を減らせる。その結果、False Positiveを抑えやすくなる
一方で、本来はpositiveである入力まで棄却するとFalse Negativeが増える
そのため、ゲートの厳しさとcoverageのトレードオフを評価する必要がある

OODスコアを算出する

分類モデルのsoftmax確率だけでなく、入力が分布外である可能性を表すOODスコアを算出した。

OODスコアとしては、例えば次のようなものがある:

MSP（Maximum Softmax Probability）
- softmax出力の最大値（Top-1クラスの確率）を確信度スコアとして使う、最も単純な方法
- しかし、全クラスへの反応が弱い入力でも比率さえ偏っていれば高い値が出てしまう（相対的なため）
Energy Score
- softmaxを通す前のlogit（生の出力値）から計算するスコア
- logitの絶対的な大きさを反映して、「どのクラスにも強く反応していない入力」を検出しやすい
- IDならエネルギーが低く（負に大きく）、OODなら高くなる傾向
特徴空間における学習データからの距離
複数モデル間の予測の不一致
OOD検出専用モデルの出力

OODスコアにしきい値を設定し、しきい値を超えた入力をOut of Scopeとして棄却する。

ただし、OODスコアは必ずしもOODである確率ではない。また、学習分布から明確に離れたfar-OODは検出できても、IDに近いnear-OODは検出が難しい場合がある。

マルチタスクで学習をする

マルチタスク学習（Multi-task learning; MTL）が有効な場合もある
補タスク（auxiliary tasks）の学習から得た教師信号をもとに興味がある主タスクの性能を向上することができるから
あえて、gradeのheadもつけて学習させることによってauxiliary task learningができる

想定運用母集団に対する性能評価

固定データセットではなくリアルでどの程度使えるかを判断するため点推定ではなくCIで判断する
特に、固定済みモデルを、有限件のテスト標本で評価したことによる不確実性を測るのが目的
そのため、次の指標のCIを測る
- None Recallの片側下限
- 各TargetクラスPrecisionの片側下限
また、要求水準を「None Recall 99%以上」、信頼水準を95%として、二項CIで出した
ただし、CIが測るのは主に標本誤差で、分布シフトまではカバーしないので注意

自動学習

シンプルに精度が低いサブクラスは学習データを増やす方法
サブクラスのカバー率とサブクラス学習効率を求めて、それに対して精度を比較する
精度が低いなら、そのサブクラスの割合を想定的に他のクラスより増やす
これだけで自動学習が可能になる

対照学習

対照学習とは

教えるのが難しいものを、対照として用意して特別に学習させる方法
つまり、ほぼ同じ条件の正解と誤答”を直接並べて、正解のスコアを必ず上にしろTrainする方法
例えば、「たろう」を分類するために、「XXXたろう」と「XXXたらう」みたいなpositive/negativeのpairを用意して学習する
普通の学習では、そのペア比較するべきペアだとわからないため、対照学習という方法がある
そして、普通の学習とは別に、$score(Taro) > score(near-miss) + margin$というLossを入れる
実際は以下のような形
- $ReLU(2 - (logit_{pos}-logit_{neg}))$
- ちなみに、ReLUは、$ReLU(x) = max(0,x)$という関数
つまり、positiveのlogitをnegativeのlogitより2以上高くしてくださいという事
このPair Lossを使って学習をさせるイメージ

対照学習のPair Lossの具体例

差が1だとlossは罰になる:

1
2
3


positive logit = 3.0
negative logit = 2.0
loss = ReLU(2 -(3-2))= 1

差が2.5だとlossは0になる（罰なし）:

1
2
3


positive logit = 3.0
negative logit = 0.5
loss = ReLU(2 -(3-0.5)) = ReLU(2-2.5) = ReLU(-0.5) = 0

つまり、差が開くと、「もう十分離れてる=学習できた」となるということ（この2がmargin）。

BCEとPair Lossの違い

一般的に二値分類の損失関数はBCE（Binary Cross Entropy=二値交差エントロピー）を使う
positiveである確率は、$L=−[y log_p+(1−y)log(1−p)]$となる
つまりBCEは次の仕組み
- y=1
  - $-log_p$で、p=1なら0でlossなし
- y=0
  - $-log_(1-p)$で、p=0ならばlossなし
しかし、これは結局は、y=1のラベルならpは1に近づき、y=0のラベルならpは0に近づく事を学習するに過ぎない
言い換えると以下を学習している
- positiveには「1を出せ」
- negativeには「0を出せ」
他方、対照学習は場合分けせずに、統合して（2つを比較して距離を）学習している
故に、対照学習は、次の力学が働く:
- Positive logit ↑ 上げる
- near-miss logit ↓ 下げる
Binary Cross Entropyではなく、ReLUを使う理由がこれ

推論

Userの入力を狭める

任意の入力を完全に扱うという要件を見直し、システムが対応する入力の範囲を明確にした。

例えば、次のような条件を定義する。

対応するデータ形式
対応するクラス
必要な画像品質
許可するユーザーや利用環境
モデルが判定してよい状況

ユーザーごとに対象データを登録または学習し、その範囲だけを判定対象にする方法も考えられる。

機械学習モデルの改善だけで安全性を確保しようとせず、モデルが動作してよい範囲をシステム側で定義することが重要だった。

判定しきい値を上げる

positiveと判定するしきい値を上げる方法は、False Positiveを抑えるための単純で有効な方法である
一般には、しきい値を上げるとprecisionは上がりやすくなるが、recallとcoverageは下がる
また、DNNは未知入力に対しても高いsoftmaxスコアを出すことがある。そのため、分類確率のしきい値だけに依存せず、OODスコアやゲート処理と組み合わせる必要がある

相対的な確信度を利用する

一つのクラスの確信度だけでなく、複数クラス間のスコアを比較した。

例えば、次のような値を利用できる。

Top-1とTop-2の確率差
Top-1とTop-2のlogit差
予測分布のエントロピー
複数モデル間の予測のばらつき

同じTop-1確率でも、他のクラスと僅差の場合と、一つのクラスだけが突出している場合では意味が異なる。

ただし、相対的な確信度は主に既知クラス間の曖昧さを表す指標であり、それだけでOODを検出できるわけではない。OOD入力に対して一つのクラスが突出することもある。

アンサンブルで判定する

複数のモデルを利用し、予測結果やモデル間の不一致を判定材料にした。

例えば、次のような方法が考えられる。

複数モデルの平均確率を使う
すべてのモデルがpositiveと判定した場合だけ受理する
モデル間の予測分散が大きい場合は棄却する
異なる特徴や学習データを使ったモデルを組み合わせる

アンサンブルは予測性能や不確実性推定を改善する可能性がある。

ただし、複数モデルが同じ学習データや特徴に依存している場合、同じ入力に対して同時に誤る可能性がある。アンサンブルだけで安全性を保証できるわけではない。

Selective Classification

確信度が不十分な場合に、モデルが無理に分類せず棄却できる仕組みを追加した。

棄却された入力については、次のようなフローへ移す。

ユーザーに確認する
管理者によるレビューへ送る
より高精度なモデルで再判定する
安全側のデフォルト処理を実行する

これはSelective ClassificationまたはClassification with a Reject Optionと呼ばれる考え方に近い。

棄却を増やせば受理した予測の精度は高めやすいが、自動処理できるcoverageは下がる。そのため、誤り率とcoverageの両方を評価する必要がある。

また、ユーザーへの確認を追加しても、ユーザー自身が正解を判断できなければ安全性は保証されない。誰が何を根拠に確認するかまで設計する必要がある。

事前確率を考慮する

クラスの発生頻度が学習時と運用時で異なる場合、運用環境の事前確率を考慮する方法がある。

Label Shiftを仮定できる場合、推論結果は次のように補正できる。

$$ P_{\mathrm{test}}(y \mid x) \propto P_{\mathrm{train}}(y \mid x) \frac{P_{\mathrm{test}}(y)} {P_{\mathrm{train}}(y)} $$

ただし、この補正は主に次の仮定が成立する場合に利用できる。

$$ P_{\mathrm{test}}(x \mid y) = P_{\mathrm{train}}(x \mid y) $$

運用環境の事前確率を正しく推定できない場合や、Concept Shiftも発生している場合には、単純な補正が逆効果になる可能性がある。

また、False PositiveとFalse Negativeのコスト差を反映したい場合は、事前確率補正とは分けて、コストを考慮した判定しきい値を設計する。

Conformal Prediction

モデルフリーのConformal Predictionでしきい値や予測集合を統計的に較正し、自動判定、棄却を決めることも可能
各入力に対して予測集合を出し、長期的な誤り率が目標値以下になるよう較正する事が可能になる
普通の方法：「0.9なら十分自信が高そう」、Conformal：「過去のNegativeの99%を誤判定しなかった境界を使う」というイメージ
その前提として、キャリブレーションデータと本番データが同じような分布であることを前提にした長期的・集団的な保証ということ
UQ解析の一種

モデル選定

タスクに適したモデルへ変更する

分類対象同士の違いが細かい場合は、Fine-grained classificationに適したモデルや学習方法を採用する。

例えば、車とペットボトルのような上位カテゴリ間の分類に比べ、タカとワシのように同じ上位カテゴリ内の下位カテゴリを区別する分類では、細かな局所特徴が重要になる。

この場合、次のような方法が考えられる。

高解像度の入力を使う
局所特徴や部位に注目するモデルを使う
Metric LearningやContrastive Learningを使う
階層分類を行う
タスク専用の特徴抽出器を利用する

Fine-grained classificationへの対応は既知クラス間の識別性能を改善する方法であり、それ自体がOOD対策になるわけではない。

転移学習を利用する

大規模データで事前学習されたモデルを利用し、対象タスクへFine-tuningする
事前学習によって得られた汎用的な表現は、限られた学習データだけで一から学習する場合よりも、分類性能や分布シフトへの頑健性を改善する可能性がある
LLMにおけるLoRAは、事前学習済みモデルを少ない追加パラメータでFine-tuningするParameter-Efficient Fine-Tuningの一手法である。LoRA自体が転移学習と同義というわけではない
また、転移学習を行ってもOODを必ず検出できるわけではないため、OODスコアや棄却処理とは別に考える必要がある

feedback

運用中の監視と再学習

開発時に想定できなかった入力は、運用開始後にも発生する。

そのため、次の情報を継続的に収集する。

棄却された入力
高い確信度で誤判定した入力
モデル間で判定が分かれた入力
ユーザーが訂正した入力
時間経過による入力分布の変化

収集したデータからhard negativeを発掘し、評価データの追加や再学習に利用する。

ただし、同じデータをしきい値調整と最終評価の両方に使うと、性能を過大評価する可能性がある。学習用、検証用、最終評価用のデータは分ける必要がある。

Check項目まとめ

量が多いので、AIにSVGにしてもらった。

また、簡潔にいうとこれらは最低限でもやったほうがいい:

まず分母が同じ事
決定的なアルゴであること
非決定的なら信頼区間を出すこと
点推定ではなく信頼区間していること
それらを細かなデータ区分でやること
サンプル数があること
因果推論してること
統計的に有意なこと
論理的矛盾がないこと
証明されていること（truth and proof ）
事前の仮説との整合性があること
交差検証されてること
ホールドアウトで確認してること
未検証のデータセットを使ってること
ドメインシフトが起こってないこと
しきい値が一つじゃないこと（aucなどを使用）
seedを変えたときの再現性があること
欠陥変数がないこと

まとめ

ID/OODとpositive/negativeは別の概念として扱う必要がある
DNNは未知入力に対しても高い確信度を出すことがあるため、分類確率のしきい値だけでは十分ではない
False Positiveを抑えるには、入力ゲート、Noneクラス、疑似OOD、hard negative mining、OODスコア、アンサンブル、棄却などを組み合わせる必要がある
Noneクラスや転移学習は有効な場合があるが、単独で未知入力全般に対応できるわけではない
安全性が重要なシステムでは、確信度が不十分な入力を無理に分類せず、人間による確認や安全側の処理へ移す設計が重要である
有限の評価データから、将来のあらゆる入力に対するFP 0件を保証することはできない
FPだけを減らすとrecallやcoverageが低下するため、これらのトレードオフも評価する必要がある
OODへの対処は単一のモデルや手法で完結するものではなく、入力制約、モデル、棄却、監視、再学習を含むシステム全体で設計する必要がある

OOD対策の本質は、すべての入力を無理に分類することではなく、モデルが判断してよい範囲を定め、判断できない入力を安全に棄却すること。