開発ログ

Baseline比較と特徴量の採用・棄却指標を定義する

今回の変更を先に要約

特徴量候補をBaselineと比較し、事前に固定したMetric Contractに従ってPROMOTE / REJECTを決める仕組みを実装しました。

必須条件を満たさない候補はREJECTし、必要な比較指標が欠けている場合もFail Closedで拒否します。さらに、Evidenceに結びついた最終判断は後から別の判断へ書き換えられない形にしました。

Task Evidenceでは6件を確認し、6件すべて判定、未解決0件でした。

なぜ必要なのか

特徴量を追加したとき、「前より数字が良くなった」という理由だけで採用すると、候補ごとに判断基準が変わる可能性があります。

そこで、何をBaselineにするか、どの指標を必須とするか、どの方向を改善とみなすかを先に固定し、その契約に従って候補を評価する形にしました。

今回できるようにしたこと

  • Baseline比較ルールをdeterministicなContract identityとして固定
  • 必須比較条件を満たした候補だけPROMOTE
  • 必須条件を満たさない候補はREJECT
  • 必須指標が欠けている場合はFail Closed
  • Evidence付きの最終判断を後から別判断へ変更できない
  • 比較試行数、unique候補数、duplicate試行数を分離

具体例

Baselineモデルに新しい近走成績特徴量を追加した候補を比較するとします。

一部の数字だけ良くても、事前に固定した必須条件をすべて満たさなければPROMOTEしません。逆に、必須指標が欠けている場合も無視して先へ進めず、REJECT側へ倒します。

これにより「良い数字だけを見て採用する」余地を減らします。

検証結果

Task Evidence上では6件を実際に確認し、6件すべてを判定、未解決は0件でした。

確認対象には、Metric Contract identity、PROMOTE判定、REJECT判定、必須指標欠損時のFail Closed、判断の不変性、試行数の重複管理が含まれます。

現在の意味

この工程で予測精度や回収率が改善したと主張することはできません。

今回の成果は、今後の特徴量探索で「何をもって採用・棄却するか」を同じルールで判定できる土台を作ったことです。

次は、この基準を使って学習期間の長さと時系列重み付けを比較検証します。

全体ロードマップを見る →

← 開発ログへ戻る

掲載内容は、その時点の開発・検証記録です。将来の利益や的中を保証するものではありません。