30秒概要
生成対象183 Primaryを実際にBatch生成した結果、157 PrimaryをMaterializeできました。
一方、26 Primaryは元Source Tableが空だったため、0埋めせず明示的に保留しました。
PIT、Join、Schema / Fingerprintも監査し、次のIndividual / Family Ablation対象を157 Primaryに固定しました。
なぜ必要だったか
特徴量は定義できるだけでは不十分です。
元データが存在しない、Joinで行が落ちる、取得時点が不明、Schemaが変わる、といった状態のまま比較すると「特徴量の効果」と「データ不良」を区別できません。
何が変わったか
183 PrimaryをFamily × Source Table単位でBatch化し、成功済みBatchは再実行せず、Fingerprint完全一致時だけCache再利用する形にしました。
結果は157 Materialized、26 Source Empty Blockedです。Alias 187個はPrimary再利用とし再生成していません。
具体例：broodmare_sire_stats が0行
実際に止まったSourceの1つが broodmare_sire_stats です。
このテーブルは母父成績系の特徴量生成に使うSourceですが、監査時点で0行でした。
そのため、そのSourceに依存するBatchを0埋めして成功扱いにはせず、Source Emptyとして保留しました。
「実績0」と「データなし」を混同しないためです。
品質監査
Materialize済み157 Primaryについて確認した結果、
- Join loss：0
- PIT：PASS
- Schema / Fingerprint：PASS
- 1件以上NULLを含むFeature：61
- 全件NULL Feature：6
でした。
欠損は黙って除外せず、品質情報として保持します。
現在地
次のAblationへ正式に渡すのは157 Primaryです。
Source Empty 26 PrimaryとSource Fact待ち246 Primaryは未解決として別管理します。
Evidenceと限界
今回の結果は予測精度や回収率の改善を示すものではありません。
確認できたのは「何を実生成できたか」「どこでSourceが不足したか」「生成物の品質状態はどうか」です。
次
157 PrimaryをIndividual Ablation / Family Ablationへ渡し、どの特徴量が本当に予測へ寄与するかを比較します。