ADR 0004: best.yaml の確定を確認ラン (top-K 再評価) に基づかせる¶

背景¶

Optuna TPE (ADR 0003) による tuning では、50〜100 trial の中から objective 最大の config を best.yaml として書き出し、 tuning apply で params.yaml に反映していた。

この「探索の argmax をそのまま採用する」設計には統計的な欠陥がある:

Winner's curse (選択バイアス): 勝率 200 games の標準誤差は ±3〜4%。真の実力が同等の config が 50 個あれば、argmax はほぼ確実に「測定が上振れた config」になる。tuning で +4% に見えた改善が本番で消える、が構造的に起きる
分散削減の限界: seed 固定 (T2) を入れても、ゲーム内シャッフルが libcg.so 内部 RNG で seed 不可のため、trial 間の共通乱数は部分的にしか効かない。「探索時の測定をそのまま信じる」以外の防御が必要
baseline 比較の欠如: 探索が現行 params.yaml を上回れなかった場合にそれを検出する仕組みがなく、悪化 params を apply しうる

--confirm-top-k K を導入し、best.yaml は探索 argmax ではなく「top-K + baseline を高 games 数・別 seed で再評価した確認ランの winner」から確定する。

構成:

候補 = 探索 top-K (overrides で重複除去) + baseline (現行 params.yaml の探索空間への射影)。baseline は champion/challenger 比較のため必ず入る
確認ラン games = 探索の 3 倍 (default)、seed = 探索 seed + 100,000 (別系列)。全候補は同一 confirm seed で評価
出力: confirmed.csv (search rank と confirm rank の対応を記録)、manifest に confirmation メタ
winner が baseline の場合は stdout に WARNING (apply は no-op なので空間拡大 / games 増を促す)
実装は stage 非依存の後段処理 (tuning/confirm.py) で、grid / optuna 両方で使える。default は無効 (--confirm-top-k 0) で後方互換

運用推奨: --confirm-top-k 3 --confirm-games-per-config <探索の3倍>。

探索の games_per_config を単純に増やす — 全 trial のコストが均等に増える。上位候補だけ精査する確認ランの方がサンプル効率が良い
統計的再ランク (Bonferroni / bootstrap CI で argmax 補正) —実装が重く、測定の追加なしには上振れそのものは消えない
multi-fidelity (games 段階評価 + 早期打ち切り) — 有望だが Evaluator protocol の変更が必要。確認ランで先に信頼性を確保し、こちらは future work とする (rule-agent-tuning.md の今後の拡張)

best.yaml の意味が「探索 top-1」から「確認ラン winner」に変わる (確認ラン無効時は従来通り)。history.csv / top_k.yaml は探索の記録のまま
apply 前の人間確認は confirmed.csv (search rank vs confirm rank のズレ、winner_source) を見る運用に変わる
tuning の総実行時間が K × confirm_games 分増える