今回の変更をすぐ分かる形で
Baseline入力をモデルへ渡す前に、欠損・未知カテゴリ・不正値をどう扱うかを正式なPolicyとして固定しました。
今回の方針は、問題のある値を自動で補完して先へ進むのではなく、Baselineでは観測できたCanonical値をそのまま使い、条件を満たさない入力はFail Closedで扱うことです。
実Canonical DBに対する監査では、採用済みのBaseline特徴量について品質条件を確認し、未解決項目を残さずPoint-in-Timeデータセットへ進める状態まで確認しました。
なぜ必要なのか
Baselineは、最初から高性能を狙うためだけのモデルではありません。
後から特徴量や前処理を追加したときに、「何を変えた結果、何が変わったのか」を比較する基準点でもあります。
そのため、欠損補完や未知カテゴリ処理を暗黙に入れると、モデル差の原因を追いにくくなります。
今回は前処理の判断を先にPolicy化し、後続工程が同じ条件を再利用できるようにしました。
確認したこと
対象となるBaseline入力について、列の存在だけでなく、欠損、カテゴリ整合性、値域、不正値、Point-in-Timeデータセットへ渡せる品質を確認しました。
監査対象はすべて判定され、未解決は残っていません。
現在のルール
Baselineでは暗黙の欠損補完を行いません。
必要な値が欠けている、未知カテゴリが現れる、許容条件を外れるなどの問題があれば、正常データとして黙って通さずFail Closedで扱います。
将来補完処理を導入する場合は、それ自体を明示的な前処理変更としてBaselineとの差を検証できます。
現在地
Baseline特徴量の選定に続き、その入力品質と欠損値方針まで固定できました。
次は、予測時点より未来の情報が混ざらないPoint-in-Timeデータセットと時系列分割を構築します。
この工程ではモデル精度・回収率・収益性の改善はまだ主張しません。今回確認したのは、Baselineへ渡す入力品質とその扱いです。