[基礎] Part 9. モデルはパイプラインの上でしか生きられません：データエンジニアリングとツール

Part 8まで九回にわたって、信用データサイエンスがなぜ違うのかを扱ってきました。選択バイアスと時間、非対称なコスト、因果、検証とガバナンス、解釈可能性と公平性。すべて概念の話でした。

ところが概念はひとりでに動いてはくれません。モデルはパイプラインの上でしか生きられません。データを集め、特徴量を作り、学習し、スコアを送り出す配管がなければ、どれほど良いモデルも紙の上のアイデアのまま残ります。

この回はその配管の話です。派手ではないのに、実務の時間のかなりの部分がここに入ります。そしてこの分野では、性能よりも整合性と再現性が先です。

いちばん長く触っている道具はSQLです

モデリングを学んで入ってくると、主にPythonを使うだろうと思いがちです。実際にはSQLのほうを長く使います。

特徴量の多くがSQLで作られるからです。直近3か月の平均利用額、6か月の延滞回数、残高のトレンドとボラティリティといったものは、すべて時間ウィンドウの集計です。数千万件の取引テーブルからこれを取り出す作業はBigQueryのような大規模データウェアハウスで行われ、ウィンドウ関数が主力の道具になります。

ここでクエリがうまいというのは、結果を当てることだけを意味しません。パーティショニングとクラスタリングをどう取るかで、同じ結果を返すクエリのコストが数十倍変わります。特徴量を一つ足すことが月額コストの問題になることもあります。

リークはたいてい結合で生まれます

ただ、SQLで本当に重要なのは性能ではありません。データリークを防ぐ最前線がクエリ設計だという点です。

Part 0で時間は一方向に流れると述べ、Part 3でだからOOT検証を使うと述べました。その原則がコードに降りてくると、こうなります。すべての結合と集計が意思決定時点を基準にだけ行われなければなりません。これを時点整合（ポイントインタイム）の結合と呼びます。

当たり前のようでいて、実際にはよく崩れます。いちばんよくある事故は、現在状態のテーブルをそのまま貼り付けることです。顧客マスタから限度額を取ってきたのに、それが申込時点の限度額ではなく今の限度額である場合です。延滞履歴を付けたら、申込より後に生じた延滞まで混ざっていた場合も同じです。

この事故が怖い理由は、検証で捕まらないからです。リークした特徴量は学習でも検証でも同じようによく当たります。OOTで分けても両方が汚染されていれば意味がありません。だから成績がやけに良く出たときは、喜ぶ前に結合を見直すのが正解です。現場でAUCが0.95を超えたら、たいていは祝うことではなく疑うことです。

Pythonはその次です

データがテーブルとして出てきてからがPythonの区間です。

処理にはpandasを使い、データが大きくなればpolarsに移ることもあります。モデルはscikit-learnとLightGBM、XGBoostが主力で、統計的な説明が必要ならstatsmodelsを使います。

信用の領域にはこの分野専用の道具があります。Part 4で見たWOE変換とビニング、スコアカードのスケーリングは、毎回自分で書くよりoptbinningやscorecardpyのようなライブラリを使うほうが速くて安全です。Part 6の因果推論にはDoWhyとEconML、CausalMLがあり、Part 8の解釈にはSHAPが事実上の標準です。

道具のリスト自体はすぐ変わります。大事なのは、どんな問題にどんな種類の道具が要るのかを知っているほうです。

学習とサービングがずれると

モデルを作り終えたら、スコアを実際に送り出さなければなりません。ところがここで静かな事故がよく起きます。

学習のときはバッチSQLで特徴量を作ったのに、サービングのときはリアルタイムAPIが同じ名前の特徴量を少し違う形で計算している場合です。直近3か月を90日と取るか直近の3か月分と取るか、欠損を0で埋めるか平均で埋めるかといった些細な違いです。名前は同じなのに値が違います。

これを学習とサービングのずれと呼びます。検証成績は問題ないのに運用でスコアがおかしく出て、原因を探すのに数週間かかることもあります。Part 7でリリース後にPSIでモニタリングすると述べましたが、PSIが跳ねる原因が顧客の変化ではなくこのずれである場合も少なくありません。

解き方は、定義を一か所に置くことです。フィーチャーストアは特徴量の計算ルールを一つに登録しておき、学習とサービングが同じ定義を取りに行くようにします。大げさなシステムを導入しなくても、せめて特徴量の定義をコードの一か所にまとめ、両方がそれを呼ぶようにするだけでも、かなりの部分は防げます。

再現性は検証の前提です

Part 7で、再現できないモデルは検証することも監査を受けることもできないと述べました。その再現性は、実際にはこうした道具で作られます。

コードは当然Gitで管理し、ライブラリのバージョンを固定して環境を再現できるようにします。どの実験でどの設定でどんな成績が出たのかは、MLflowのような実験追跡ツールに残します。そして金融でとくに重要なのが、データとモデルのバージョン管理です。半年前に承認を受けたモデルがどのデータで学習されたのかを、後から辿れなければならないからです。

モデルレジストリに、どのバージョンがいつ承認されて運用に乗ったのかを記録しておけば、Part 7で述べた監査証跡が自然についてきます。ガバナンス文書とエンジニアリングが同じものを指すようになるわけです。

データ品質がそのままモデル品質です

最後はデータ品質です。

欠損と外れ値、重複は基本で、実務でもっと怖いのは定義が静かに変わる場合です。上流でコード体系を変えたのに誰も知らせてくれず、ある日から特定の特徴量の分布がまるごと変わるといった具合です。モデルはそれを知らないままスコアを出し続けます。

だからスキーマと値の範囲を明示しておくデータ契約を結び、データが時間どおりに入ってきたかという鮮度を確認します。信用にはここにもう一つ加わります。信用情報機関から来る情報には報告の遅れがあります。昨日生じた延滞が今日のデータにはないかもしれない、という意味です。この遅れを知らずに特徴量を作ると、学習時に見えていた情報と実際の審査時に見える情報がまた違ってきます。

だから、性能より整合性です

この回は概念というより配管に近い話でした。ところがこの配管が、前の九回を支えています。時点整合が崩れればPart 3の検証が意味を失い、学習とサービングがずれればPart 7のモニタリングが見当違いの場所を指し、再現できなければPart 7の独立検証そのものが不可能になります。

だからこの分野では、モデルの性能を0.01引き上げるより、結合が時点整合かを確認し、特徴量の定義を一か所にまとめるほうが、たいてい得るものが大きいのです。

あと一回を残すのみになりました。どれほどうまく作り、うまく動かしても、モデルは誰かの決定に変わらなければ何も起きません。最後の回では、スコアを決定に変える仕事、そしてその結果を他の人に伝える仕事で締めくくります。