クレジットスコアリング:パート9 -スコアカードの実装:展開、稼働、観察

ブログ

Megaphone

投稿日

2017年11月15日

カテゴリー

データサイエンス

共有

筆者:英国 World Programming シニアデータサイエンティスト Natasha Mashanovich

Main image

「知識が力なのではない。知識を具体化することこそが力だ。」 - スコアカードもしくは信用手法の実際の利点は実装することでのみ証明できます。CRISP-DM フレームワークの最終段階である実装は、データサイエンスのドメインから情報技術ドメインへの移動を表しています。結果としてデータサイエンティストとビジネスアナリストからシステムとデータベース管理者、検証者へと責務が移行します。

スコアカードの実装の前に多くの技術的判断を下さなければなりません。この判断の範囲は、データの有効性やハードウェアとソフトウェアの選択、スコアカード実装の責任者、スコアカード管理の責任者、社内もしくは社外で稼働させるのかなどに及びます。

スコアカードの実装は継続的な処理であり、ビジネスによって承認された時点で開始されます。この処理はスコアカードのデプロイメントコードを生成することから始まり、前稼働、稼働、後稼働と続きます。

Part9 1.ja jp

図1。スコアカード実装段階

デプロイメントコード

デプロイメントコードは、モデルの式や表形式の スコアカードなど概念的なモデルを、それらモデルに相当したサーバー上で即実行可能なソフトウェアへと翻訳することで作成されます。モデルを実行する実装用プラットフォームは、例えば SAS 言語(図2)や SQL、PMML、C++などのデプロイメント言語を認識します。モデルのデプロイメントコード記述は、エラーが起こりがちであり、デプロイメントコードを作り出すにはコードの精製を何度も繰り返す必要があるため、ボトルネックの象徴となっています。いくつかの分析製品販売者は、自動コードデプロイメント機能をその販売ソフトウェアで提供していいます。それらはエラーの無いコードを生成し、デプロイメントとコードの検証サイクルを短縮する優れた機能です。

Part9 2

図2。World Programming ソフトウェア製品での SAS 言語のデプロイメントコードの自動生成

検証用の前稼働サーバーもしくはリアルタイムスコアリングの稼働サーバーでのスコアカードの実装は、モデルのデプロイメントコード周りでモデルスコアリングのリモート要求を取り扱うために API ラッパーが必要になります。内部や外部データソースから得るモデルのインプットは、内部か外部のスコアリングエンジンによって抽出されます。前者はスコアリングエンジンの外部で変数の抽出を行い、その変数を API リクエストのパラメータとして受け渡します。後者は図3で示されているようにスコアリングエンジン内で前処理コードを実行し、同じエンジン上で変数の抽出とモデルスコアリングを行います。

Part9 3.ja jp

図3。API コールを利用したリアルタイムスコアリング

前稼働と稼働

前稼働は、モデルを実際の稼働環境へ適用するために様々な検証を行うために使用する環境です。これらの検証は通常モデルの評価や有効性のテスト、予想される最大負荷の下でのシステムの要求と応答時間のテストであったり、インストールやシステム設定の検証になります。

徹底して検証され承認されたモデルは、最終目的地である稼働環境へアップロードされます。稼働サーバーで実行しているモデルは活動状態か受動状態になっています。活動的モデルは、リアルタイムにクレジットの承認や却下の判断を下す工程でそのスコアが使用されるチャンピオンモデルです。受動的モデルは通常、判断を下す工程ではまだ使用されていないモデルチャレンジですが、そのスコアは記録され活動的モデルになる前に事業価値を正当化するために長期間分析されています。

モニタリング

「計測できなければ改善することはできない。」(Lord Kelvin) – 新製品発売やマーケティングのインセンティブ、経済動向など様々な要因に影響を受けることによるモデルの自然な進展の結果、時間経過とともにどのようなモデルでも劣化していきます。

モデルのモニタリングは、モデルがまだ期待する精度を保っているかを判断するために使用する実装後の検証です。モニタリングを行うには、歴代のモデルレポートやレポートを格納するためのリポジトリ、モニタリングダッシュボードなどの利用を容易にすることで、 IT インフラを前もってセットアップしておく必要があります。

Part9 4.ja jp

図4。モデルのモニタリング処理

モデルレポートは例えば、新規申込者の特徴が時間経過とともに変化したかどうかを判定したり、承認率や債務不履行率を調整するためにスコアのカットオフ値を変更する必要があるかを確証したり、もしくは異なるリスクバンド全体でのモデリングの集団をランク付けしたのと同じ方法でスコアカードが顧客をランク付けするのかを決定したりするために使用されます。

スコアカードの劣化は通常、定義済みの閾値で捉えることができます。変化の度合いによって、適した行動の指針が採られます。例えば、スコアカードのパフォーマンス測定基準の小さな変化は無視することができるかもしれませんが、ほどほどの変化はより頻度の高いモニタリングやスコアカードの再調整が必要になるかもしれません。大きな変化はモデルの再構築を必要としたり、代わりに最もパフォーマンスの高いモデルと取り替える必要があります。

信用リスク部門は多様な動向レポートやパフォーマンスレポート、ポートフォリオレポート(表1)など広範囲のレポートを利用できます。最も一般的なレポートとしては集団安定性とパフォーマンス追跡の2つです。集団安定性は、時間経過とともに起こった集団のクレジットスコアの分布の変化を計測します。安定性レポートは集団の変化により顧客の振る舞いの変化の度合いを示す指標を生成します。著しい変化はモデルの再設計を求める警告を発します。パフォーマンス追跡レポートは、顧客の口座が成熟して顧客の動向を評価できるようになるまで長時間を要する最終段階のレポートです。この目的は2段階に分かれており、まずそのスコアカードがリスクによって顧客をまだランク付けできるかどうかを評価することでスコアカードの能力を検証し、その次に現在の債務不履行率とモデリングを行った時に予期した債務不履行率を比べて精度を検証します。

レポートの種類レポート名
動向レポート集団安定性
承認率分析
特徴分析
パフォーマンスレポートパフォーマンス追跡
ヴィンテージ分析
ポートフォリオ分析滞納分布
遷移行列

表1。スコアカードモニタリングレポート

モデルのモニタリングで難しい点は、変更の要求とその実装の間で長いタイムラグがあるところです。レポート生成のためのコードや各データソースへのアクセス、モデルの管理、レポートのスケジュール管理、モデル劣化の警告とレポートの視覚化などを含む実務環境(図1)で実行している各モデルのモニタリング処理を実現するための作業の複雑さが、処理をより手のかかる難しいものにしています。これは貸主にとってモデルのモニタリング作業を外注するのか、最小限の人件費でモデルのモニタリングを可能にする自動処理に投資するかの主な動機付けとなってきました。