すぐ分かる今回の変更
最初のBaselineモデルに使う特徴量を、実データで確認できた4つに固定しました。
採用したのは venue_code、surface、race_distance、horse_number です。
現在のCanonical DBに存在する実列へ結び付け、現行データで欠損がないことを確認したものだけを採用しています。
なぜ最初から特徴量を増やさないのか
Baselineの目的は、最初から高性能を狙うことではありません。
後から特徴量を追加したときに、「何を足したことで結果が変わったのか」を比較できる基準点を作ることです。
そのため、最初の入力は意図的に小さく保ちます。
今回採用した特徴量
venue_code→race.venue_codesurface→race.surfacerace_distance→race.distance_mhorse_number→race_entry.horse_number
4特徴量はいずれも現行Canonical DBで nonnull_ratio=1.0 を確認しました。
あえて除外したもの
frame_number は実データに存在し欠損もありませんが、horse_number と同じく出走位置に関係するため、Minimal Baselineでは重ねず除外しました。
horse_age、horse_sex、race_class は、現在のMinimal Canonical DBで対応列を確認できなかったためV1には入れていません。
結果情報、払戻、オッズ、レース後タイムなどの未来・結果側情報もBaseline候補から明示的に除外しています。
現在の状態
Minimal Baseline Feature Set V1は4特徴量で正式に固定されました。
採用・除外理由、Canonical DB上のsource binding、利用可能時点の基準、禁止カテゴリはAuthorityとして機械可読化されています。
今回のEvidenceでは7件を確認し、未解決は0件です。
次の工程
次はPoint-in-Timeデータセットと時系列分割です。
今回固定したBaseline特徴量を使い、予測時点より未来の情報が混ざらない学習データへ進みます。