開発ログ

Canonical DBの特徴量供給範囲を全テーブル・全カラム単位で棚卸しする

今回の成果

特徴量研究を始める前に、新しいCanonical DBの全テーブル・全カラムを棚卸ししました。

何が入っているか、どの期間まであるか、どこが空かを明確にし、特徴量候補を実データから選べる状態にしました。

何を確認したのか

Canonical DBに存在するテーブルとカラムを省略せず確認し、各項目の利用可能な期間と欠損状況も確認しました。

主要な時間軸については、途中の年が抜けている状態は今回の棚卸しでは確認されませんでした。

また、完全に空の項目として horse.normalized_name と horse.birth_date を特定しました。

なぜ重要なのか

特徴量の良し悪しを比較するには、元になるデータがどこまで揃っているかを先に把握する必要があります。

存在期間や欠損状態が不明なままでは、特徴量そのものの効果とデータ供給の差を切り分けられません。

今回の棚卸しによって、思いつきで特徴量を増やすのではなく、実際に存在するデータから候補を選べる土台ができました。

空の項目はどうするか

空だから自動的に埋めるのではなく、元データに存在するのか、Canonical供給経路で落ちているのか、派生生成すべきなのかを後続工程で切り分けます。

現在の位置

この工程では、予測精度や回収率の改善は主張しません。

今回確定したのは、Canonical DBを特徴量研究の供給元として棚卸しし、次のPoint-in-Time・Lineage・Leakage判定へ進める状態になったことです。

次は、前日時点で利用可能だった情報だけを特徴量候補として扱えるか、結果情報が混ざっていないか、値の出所を追跡できるかを確認します。

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

← 開発ログへ戻る

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