今回の変更
競馬AIの特徴量について、値だけでなく「何の情報か・どこから来たか・いつ使えるか」を追跡できるFeature Registry / Availability Manifestを実装しました。
各登録特徴量には一意の feature_id と source を持たせ、派生特徴量には formula と lineage を要求します。さらに、D-1 23:00 JSTを基準にavailabilityを記録し、null policy と leakage risk も特徴量ごとに管理できるようにしました。
なぜ必要か
過去検証では、予測時点では存在しなかった情報が混ざると結果が良く見えてしまう可能性があります。
そのため、特徴量の値そのものだけでなく、
- 何の特徴量か
- 元データはどこか
- 派生特徴量ならどう作られたか
- 予測時点で利用できる情報か
- 欠損をどう扱う前提か
- リーク危険性があるか
まで追跡できる必要があります。
今回変えたこと
Feature Identity / Source
各登録特徴量に一意の feature_id と source を要求するRegistryを実装しました。
Formula / Lineage
派生特徴量には formula と lineage を必須化しました。元データから派生特徴量までのつながりを追跡するためです。
Availability
D-1 23:00 JSTをprimary cutoff authorityとして、特徴量がその時点で利用可能かを記録できるManifestを実装しました。
Null Policy / Leakage Risk
欠損方針とリーク危険性を特徴量ごとに明示できるようにしました。
検証
Task Evidenceでは対象6件を確認し、6件すべてを判定、未解決は0件でした。全6件が VERIFIED と記録されています。
今回の公開内容は、Task EvidenceおよびObjective Completion Evidenceで確認できる範囲に限定しています。
現在の状態
Feature Registry / Availability Manifestの実装は完了しました。
次は RF_DEV_121_02_MINIMAL_BASELINE_FEATURE_SET_V1 で、このRegistryを前提にMinimal Baselineへ入れる特徴量セットを確定します。
制約
この工程ではモデル性能、収益性、予測精度の改善は主張しません。
また、実データの欠損補完・encoding・scaling・standardizationそのものを行う工程ではありません。今回の対象は、特徴量の身元・出所・利用可能時点・欠損方針・リーク危険性を追跡できる管理基盤です。