30秒で分かる今回の変更
Revenue First側のcanonical DBを15テーブル・106カラムまで棚卸ししました。
その結果、今回の初期分類では、
- 相手との相対的な強さ：0項目
- レース難易度：0項目
- 展開・位置取り：0項目
でした。
一方で、能力情報は4項目、条件適性情報は3項目確認できました。
さらに、着順・払戻・オッズ関連など9カラムをリーク危険列として分離しました。
結論は単純です。
**モデルを変える前に、そもそも必要な情報をAIへ渡せているかを確認する必要がある。**
最初の新特徴量候補は「相対的な強さ」の1 familyだけに事前固定しています。まだ実行・評価はしていません。
なぜモデルより先に入力情報を疑ったのか
入力に存在しない情報は、どのモデルでも使えません。
そこで今回はモデル比較ではなく、現在のDBにどの情報軸が存在し、どの情報軸が欠けているかを先に整理しました。
監査結果
対象は15テーブル・106カラムです。
主な分類結果は、
- ABILITY：4項目
- CONDITION_FIT：3項目
- RELATIVE_STRENGTH：0項目
- RACE_DIFFICULTY：0項目
- PACE_POSITION：0項目
- LEAKAGE_RISK：9項目
でした。
不足軸として判定されたのはRELATIVE_STRENGTH、RACE_DIFFICULTY、PACE_POSITIONの3つです。
最初の追加候補
最初に試す候補はRELATIVE_STRENGTHです。
候補familyは RACE_RELATIVE_ABILITY_CONTEXT_V1。
意味としては「馬単体の能力」ではなく、「今回の相手関係の中での能力」を表現する情報群です。
結果を見てから候補を切り替えないよう、最初のfamilyは1件だけ事前固定しました。
安全面
レース後にしか得られない着順・払戻や、選定時に使うべきではないオッズ関連など、9カラムをリーク危険列として分離しています。
新特徴量は、出馬表時点で再現できる情報だけを使う方針です。
この監査の限界
今回の初期分類は、列名やschema情報を含む機械的分類です。
そのため transform_version などが意味上不適切なカテゴリに入る誤分類や、多くのカラムがOTHER_OR_UNCLASSIFIEDとして残る問題を確認しています。
また、このタスクでは新特徴量の効果、Pairwise / Ranking、収益性はまだ評価していません。
次の工程
次はRevenue First専用のFeature Governanceを構築します。
特徴量ごとに意味、producer、利用可能時点、True Forward再現性、モデル利用範囲を正本化し、**出馬表時点で再現できるTrue Forward Feature Universe**を作ります。
その後、Gap Matrixを正本Registryベースで再監査し、最初に固定した相対強さの特徴量familyへ進みます。