DataRobotは実務担当者がモデリングからモデル運用まで行うための機械学習・AIプラットフォームとして知られていますが、データサイエンティスト（DS）の業務を加速するためのエンジンにもなります。

今回は、DS向けにDataRobot×Papermill×MLflowを使うことで、どれくらい業務を加速し、チーム内のコラボレーションを高められるのかを紹介します。AIアクセラレーターにサンプルコードを公開していますので、実際にコードを動かしてもらえればその威力を感じていただけます。

機械学習モデル構築は実験の繰り返し

機械学習モデルのビジネス利用は、一回モデルを作成して終わりではありません。Kaggleなどのコンペティションでもトップクラスになるためには試行錯誤を自動化することが重要ですが、時間と共にデータが変わっていく実ビジネスでは、この試行錯誤を自動化することがより重要になってきます。データの変化に対応が遅れてしまうと、機械学習モデルのビジネス利用により得られるインパクトが消失してしまうからです。

試行錯誤の過程では、大量のコードとモデルとメトリクスが作成されます。これらのアセットの対応関係が明確にわかるように、実験ログを管理することもとても大切です。

試行錯誤の自動化とログ管理が成功への近道

試行錯誤の自動化や実験ログの管理ができていれば、データサイエンティスト（DS)が陥りがちな失敗を防ぐこともできます。

多くのデータサイエンティスト（DS）にとって、機械学習の実験はゲーム感覚で楽しい瞬間であり、精度が良いモデルを作るために時間を忘れてコーディングしたなんていう経験がある人も多いのではないでしょうか。しかし、機械学習に没頭しすぎて、もしくは1人のDSの力量に依存しすぎて、機械学習プロジェクトが失敗するケースが多々あります。以下の失敗例は、そんな失敗の一部を集めたものです。

機械学習の実験過程の失敗例その１：再現性

• 膨大な試行錯誤により、実験ログの管理が疎かになり、モデルや出力結果を再現できない問題が発生
• 担当者が変更した際にログが残っておらず異常時に対応できないような最悪のケースも

機械学習の実験過程の失敗例その２：ヒューマンエラー

• コーディングはデータサイエンティストの経験や能力に依存するため、担当者レベルによってコードに技術的な誤りが発生することがある
• 経験のあるデータサイエンティストでも作業量が増えるほどヒューマンエラーによるミスが増える

機械学習の実験過程の失敗例その３：コスト管理

• モデル構築に膨大なリソースが発生し、投資対効果が悪化する
• モデル構築にリソースが偏り、課題定義やモデル運用の設計に投入するリソースが薄くなる

DataRobot, Papermill, MLflowの連携による実験効率化とログ管理

それでは、本稿で紹介するDataRobot、 Papermill、MLflowがどのように上記課題を解決するか解説します。まず、それぞれの道具の概要です。

データサイエンティストの道具その１：DataRobot

• DataRobotは、データサイエンティスト（DS）や開発者が機械学習モデルを迅速に開発、デプロイ、管理できるように設計された包括的かつオープンなエンドツーエンドのAIライフサイクル・プラットフォームです。
• GUIベースの操作だけでなく、Pythonクライアントを使うことができます。したがって、コードベースで、データの準備からモデルのトレーニング、評価、デプロイメント、モニタリングに至るまでのプロセスを自動化し、機械学習プロジェクトの複雑さと時間を大幅に削減します。

データサイエンティストの道具その２：Papermill

• Papermillは、ノートブックをパラメータ化して実行するためのオープンソースのツールであり、データサイエンスや機械学習のワークフローを自動化するために広く使用されています。
• ノートブックを入力として受け取り、実行時にパラメータを渡すことで、ノートブック内のコードを動的に実行することができます。これにより、異なるデータセットやパラメータで同じ分析を繰り返し実行する際の効率が大幅に向上します。

データサイエンティストの道具その３：MLflow

• MLflowは機械学習のライフサイクルを管理するためのオープンソースプラットフォームです。
• 機械学習の実験管理、モデルのトラッキング、デプロイメント、およびワークフローの全体を通しての管理を簡素化することを目的としています。

DataRobot、Papermill、MLflowを使うメリット

この3つの道具を使うメリットは、実験効率化とログ管理です。DataRobotは、GUI操作だけではなく、コードベースでモデルのトレーニングを自動化することができます。モデルのトレーニングには特徴量やアルゴリズムの選定も含まれ、その機能だけでもDSにとって鬼に金棒です。

さらに、Papermillを使うことでノートブックをバッチ実行できるため、DataRobotを用いた実験を効率化できます。たとえば、需要予測などの時系列分析では、学習データの期間や検定期間や特徴量セットについてさまざまなパターンを試します。学習データの期間で3種類、検定期間で2種類、特徴量セットで3種類あるケースでは、合計で3×2×3の18回分の実験をする必要があり、DataRobotでは18のエクスペリメント（プロジェクト）を作成することに対応します。その都度、毎回ノートブックを手動で作成していては大変ですし、ヒューマンエラーも多くなります。そこで、Papermillを使うことで、18のノートブックを自動で作成し、バッチ実行することができます。

同時に、MLflowを使うことで、18の実験結果を1つのダッシュボードで表示できます。

AIアクセラレーターのサンプルコード

それでは、AIアクセラレーターに公開されているサンプルコードを紹介します。サンプルコードでは、時系列モデルの作成を効率化しています。

以下の内容がシナリオです。

 ——-シナリオ——-

時系列モデルの作成では、試みるべき多くの実験があります。最も基本的なものには、複数の特徴量派生ウィンドウ（fdws）を試すことや、事前に既知の特徴量（kias）を有効にすることが含まれます。

<用語説明>

• 特徴量派生ウィンドウ（fdws）：DataRobotの時系列モデリングにおいて、DataRobotが自動で派生する特徴量のローリングウィンドウ（fdws= -28 ~ 0 daysと指定すれば、過去28日間の移動平均、ラグ、差分などの特徴量が自動で生成される）
• 事前に既知の特徴量（kias）：DataRobotの時系列モデリングにおいて、予測時点で値がわかっている特徴量のこと（休日やキャンペーンなど）

サンプルコードでは、実験を効率化するために、Papermillを用いてパラメータ（fdwsとkias）を変更しノートブックをバッチ実行します。パラメータを設定し、バッチ実行を指示するノートブックがバッチ実行用ノートブック（orchestration_notebook.ipynb）であり、その指示により複数の実験用ノートブック（experiment_notebook.ipynb）が作成され、バッチ実行が走るという関係になっています。機械学習モデル作成のエンジンはDataRobotを利用しており、実験ログはMLflowで管理します。

DataRobot、Papermill、MLflow連携の流れ

以下、バッチ実行用ノートブック（orchestration_notebook.ipynb）のコードの中身を詳しく解説します。

①パラメータの設定

シナリオに沿って、特徴量派生ウィンドウ（fdws）と事前に既知の特徴量（kias）に異なるパラメーターを与えて実験します。以下のセルの例に示されているように、3(fdwsが35,70,14の3種類)×2(kiasがFalseとTrueの2種類) = 6の異なる実験を行います。

②ノートブックのバッチ実行

①で定義したパラメータを実験用ノートブック（experiment_notebook.ipynb）に与え、バッチ実行します。for文でループ実行しており、ここでは6回分ループ実行が行われます。pmはPapermillのことで、引数として、

• input_path: 実験用ノートブックのパス
• output_path: 実験実行後のノートブックのパス
• parameters: 実験用ノートブックに与えるパラメータ

を指定します。

以下のセルを実行すると、自動でノートブックが6つ作成されて、バッチ実行が動きます。

それでは、次に、実験用ノートブック（experiment_notebook.ipynb）の中身を見てみましょう。

①機械学習モデルの作成

機械学習モデルの作成にはDataRobotを用います。以下のセルは、検定スキー（time_partition）や特徴量セットの設定をしています。特徴量ウィンドウ（FDW）と事前に既知の特徴量（KIA）は、バッチ実行用ノートブック（orchestration_notebook.ipynb）から与えられたパラメータです。

以下のセルを実行すると、自動で複数のモデルが構築され、最も精度が良いモデルをDataRobotが選択してくれます。

②予測の実行

最も精度が良いモデルを使って予測を実行します。

③実験ログ管理

予測値と実測値を比較して、精度を算出し、MLflowを使って実験ログを記録します。ここでは、変更したパラメータと各種精度指標のスコアを記録しています。

サンプルコードを実行すると以下のようなアウトプットが得られます。アウトプットからわかるように、この3つの道具を使うことで、実験を効率化できるだけでなく、コードとモデルとメトリックスを実行後にアセットとしてそれぞれ残すことができ、後任者がコードとモデルの中身を再確認することもできます。

機械学習の実験効率化とログ管理を両立させる方法

今回は、実験効率化とログ管理のために、以下の方法をご紹介しました。

• DataRobotとMLflowを使用して、機械学習の実験を追跡およびログする方法
  • 利点：実験間での結果の一貫した比較が可能
• DataRobotとPapermillを使用して、機械学習の実験からアーティファクトを作成し、共同作業に必要な作業量を減らす方法
  • 利点：エラーを回避し、手動の作業量を減らすための実験の自動化が可能

ぜひサンプルコードを参考に、皆さまのプロジェクトにご活用ください。具体的な実装などでお困りの際は弊社までお問い合わせください。

投稿 DataRobot, Papermill, MLflowを活用した機械学習効率化とログ管理 | AIのプロが解説 は DataRobot に最初に表示されました。

　このパートナーシップでは、ミッションクリティカルなビジネスデータを含むSAPソフトウェアのデータをDataRobot AI Platformに接続する事で、AI利用の拡大を促進するだけでなく、SAPのビジネスアプリケーションの更なる有効活用に貢献する事が可能になります。

SAPユーザー企業のAI活用を拡大する

従来、SAPユーザー企業は、機械学習モデルを利用する際、SAPデータからSAP Datasphere（旧SAP HANA Cloud上）でモデルを構築し、SAP上のモデルを展開しビジネス活用を行っていました。今回のDataRobotとの戦略アライアンスによって、SAPデータだけでなく、SAP以外のデータを活用する事で、より高度な予測AIの利用が可能になるだけでなく、より高度なモデルの運用管理が可能です。また、従来よりも扱えるデータの種類が増える事で、より多くのAI課題を解決する事ができます。

• SAPのみで予測モデルを構築する従来の方式（パターン1）:
  SAP Datasphere（旧SAP HANA Cloud）において、SAP環境で予測モデルの構築からモデルの展開まで一元管理する事が可能です。
• SAP & DataRobot連携（パターン２）方式：
  DataRobotのJDBCコネクタを活用することで、SAPユーザーはDataRobotからSAP Datasphere（旧SAP HANA Cloud）に存在するデータを活用して機械学習モデルをトレーニングすることができます。

生成した機械学習モデルを、SAP AI Core およびSAP AI Launchpadを活用してデプロイすることができます。

SAPユーザー企業がDataRobotを利用する理由

それでは、SAPユーザー企業がDataRobotを活用するメリットについてご紹介します。

1. SAPデータ&サードパーティーデータの活用
   SAP Datasphereとそれ以外のデータソースをDataRobotに収集/統合してAIモデルを構築できるようになります。SAPデータ以外を活用した予測モデルの構築が可能になる事で、より多くのAI課題に取り組めるだけでなく、従来の予測モデルの精度向上にも期待できます。
2. AIモデル構築環境
   データサイエンティストだけでなく、非データサイエンティストでもDataRobotを活用する事で、様々なデータソースの統合と探索、自動化された特徴量エンジニアリング、複数のMLモデルのトレーニングと評価、要因分析などが可能になります。これにより高精度なモデル構築/検証を短期間に行う事が可能です。
3. AIモデル運用環境
   開発したモデルをSAP上にデプロイし、監視、管理までのプロセスを自動化、効率化する事が可能です。自動化されたワークフローやツールを活用し、またSAPのアプリケーション上で予測データを活用した意思決定が可能になる事で、より多くのユーザーに展開できるプラットフォームを提供します。

適用可能なSAPユーザー企業向けユースケース

SAPユーザー企業はDataRobotを活用する事により、様々な成功事例のあるAIユースケースに取り組む事が可能になります。製造業や小売業・流通業におけるSCM(調達、製造、物流、販売、需給、アフターマーケットサービス）といったプロセスにおいて、サプライチェーンの最適化、きめ細かな需要予測、価格の最適化、タイムリーな予知保全などの様々なユースケースでご利用いただけます。これらの課題は、日本国内でも様々なお客様で成功事例がございますので、詳細のユースケースを知りたい方はこちらのPath Finderにアクセスください。

どのように進めるべきか？

SAPをお使いの方で、DataRobotの利用について詳細を確認されたい場合は、こちらにアクセスください。また、実際にトライアルでの利用も可能ですので、SAPとの連携検証もご体験いただけます。

投稿 DataRobotとSAPの連携から創出されるビジネス価値 は DataRobot に最初に表示されました。

DataRobot で製造業のお客様を担当しているデータサイエンティストの長野将吾です。

直感的な UI で誰でも簡単に扱うことができる DataRobot ですが、実は Python や R を普段から扱うデータサイエンティストや R&D 部門の技術者の方々にもご活用いただいています。本稿では Python や R ユーザーの皆様の生産性をさらに高めるDataRobot の機能をユースケース（以下、事例）を交えながら解説します。

（注意：Python を例として説明しますが、R でも同様の操作が可能です。）

Python ユーザーのデータ分析業務に関する悩み

 Python で普段データ分析をされているユーザーの皆様からデータ分析に関する以下のお悩みを頂きます。

• コードを書くことはできるが、データ分析のあらゆる処理をコーディングしたいわけではない
• コードを書くことばかりに時間が取られてしまい、ビジネスや業務そのものに割く時間が削がれてしまう
• コーディングができる人に案件が集中し、全てを捌くことができず困っている

もしコードを書きたいところや書くべきところは引き続きコーディングをし、それ以外を DataRobot に任せることができたら、皆様はもっと本来のビジネスに集中することができるでしょう。また、もし皆様が書いたコードをコーディングできない人が簡単に利用することができれば、皆様の知見は社内で共有され、一層の価値を生み出すことでしょう。

これらを実現する DataRobot の「Python SDK」と「Composable ML」をそれぞれご紹介します。

Python SDK の概要

直感的な UI が持ち味である DataRobot ですが、普段からコーディングしている皆様からみるとクリック操作が少し煩わしく感じるかもしれません。実際にこのようなお客様からは、「DataRobot に慣れるまでは GUI で操作したいが、慣れてからは Python で操作してみたい」というご要望も頂きます。これらの声にお応えするのがPython SDK です。DataRobot を Python から操作するライブラリが完備されています。通常の Python ライブラリと同様に、以下のように pip コマンドでインストールすることが可能です。

pip install datarobot

あとは、DataRobot から APIキーを取得 するだけで準備完了です。以下の手順をコードで記載してみます。

1. DataRobot に学習用データの投入
2. プロジェクトの作成
3. ターゲットの指定
4. モデリングモードの指定
5. ワーカー数の指定
6. 開始ボタンのクリック

まずはじめに、APIキーとエンドポイントを設定し、学習用のデータを読み込みます。

#ライブラリのimport
import pandas as pd
import datarobot as dr
 
# DataRobotのAPIに接続
your_token = 'APIキー'
dr.Client(token = your_token, endpoint = 'エンドポイント')

#学習データの読み込み
df_train = pd.read_csv('学習用データ.csv')

次に、プロジェクトを作成します。学習用データとプロジェクト名を引数として指定しています。このコードは、DataRobot の GUI でデータ（今回は’学習用データ.csv’）をドラッグ＆ドロップしたことに相当し、このコードを実行するとデータのアップロードが始まります。

#プロジェクトの作成
project = dr.Project.create(
   sourcedata = df_train, #学習用データ
   project_name = 'プロジェクト名'
)

最後に、モデリングの条件に関する設定を行います。ここでは、ターゲット名、モデリングモードの指定、ワーカー数の指定をしました。オートパイロットモードを選択した場合、このコードを実行すると学習が開始します。

#ターゲットの設定
project.set_target(
    target = 'ターゲット名',
    mode = dr.AUTOPILOT_MODE.FULL_AUTO, #オートパイロットモードを選択
    worker_count = 20 #使用するワーカー数を20に設定
)

このように、非常にシンプルなコードで DataRobot が Python から操作できることを実感していただけたのではないでしょうか。もちろん、上記サンプルコード以外にも Python SDK を使えば DataRobot の GUI で実行可能な様々な操作が実装可能です。詳細はドキュメントをご覧ください。

Python SDK の活用事例

前章では、Python SDK の基本的なイメージをお伝えさせていただきました。この章では Python SDK の活用事例を3パターンご紹介させていただきます。

事例１：Python SDK と DataRobot で定型作業をまとめて処理する

Python SDK の威力を一番実感できるのは、同じ作業を何度も DataRobot で実行する場合であると考えます。例えば製造業ではセンサーデータ等の時系列データを様々なアイデアで加工し、その他のテーブルデータと結合することが多いのではないでしょうか？（この事例の詳細はこちら） PythonSDK を使えば、プロジェクト作成やモデリングは全部 DataRobot にまかせ、皆様は特徴量エンジニアリングやテーブル結合のアイデア等に集中することが可能です。

こちらの事例もサンプルコードを記載しました。先ほど解説したコードを少し書き換えるだけで、例えば30種類のプロジェクトを一気に実行することが可能です。

#ライブラリのimport
import pandas as pd
import datarobot as dr
 
# DataRobotのAPIに接続
your_token = 'APIキー'
dr.Client(token = your_token, endpoint = 'エンドポイント')

for i in range (30):

    #データの読み込み
    df_train = pd.read_csv(f'学習用データ_{i}.csv')

    #プロジェクトの作成
    pj_name = f'プロジェクト名_{i}'

    project = dr.Project.create(
        sourcedata = df_train,
        project_name = pj_name
        )

    #ターゲットの設定
    project.set_target(
        target = 'ターゲット名',
        mode = dr.AUTOPILOT_MODE.FULL_AUTO, #オートパイロットモードを選択
        worker_count = 20 #使用するワーカー数を20に設定
        )

事例２：使いたい機械学習モデルを自由に選択

ビジネス要件によって既に使いたいモデルの種類がある程度決まっていることはないでしょうか？ 例えば、製造業のお客様でよくある事例としては「Eureqa モデル等の数式が出力できるモデルが使いたい」等が挙げられます。その他にも、「勾配ブースティング系のモデルだけ使ってみたい」等の用途も考えられます。これらの要望も Python SDK を使うことで、使いたいモデルを細かく調整することが可能です。例えば、以下のサンプルコードでは、まずモデリングモードとしてマニュアルモードを選択することでブループリントの候補を取得しています。得られたブループリントの候補に対して簡単なテキスト処理を行うことで LightGBM、 RandomForest、 Elastic-Net を用いたブループリントのみを選択し、実行しています。

#ターゲットの設定
project.set_target(
    target = 'ターゲット名',
    mode = dr.AUTOPILOT_MODE.MANUAL, #マニュアルモードを選択
    worker_count = 20 #使用するワーカー数を20に設定
)

bps = project.get_blueprints() #ブループリントの候補を取得
 
#LightgbmとRandomForestとElastic-Netだけ選択
lgb = [bp for bp in project.get_blueprints() if 'Light'  in bp.model_type]
rf  = [bp for bp in project.get_blueprints() if 'Random' in bp.model_type]
els = [bp for bp in project.get_blueprints() if 'Elastic' in bp.model_type]
bps = lgb + rf + els
 
#選択したブループリントに絞って学習
for bp in bps:
    project.train(bp)

事例３：スモールデータの要因分析で頑健性を確保する

要因分析の際には Permutation Importance を用いて算出した特徴量のインパクトから要因を考察することがありますが、スモールデータを扱う場合には注意が必要です。パーティションの区切り方によって Permutation Importance の結果が変動するため、特にスモールデータにおいてはパーティションの条件をランダムシードを変更しながら複数回モデリングし、解析結果の頑健性（ロバストネス）を高めることを推奨しています。この事例も定型作業の繰り返しとなるため、Python SDK を用いることで素早く結果を確認することができます（詳細はこちらのブログやウェビナーをご覧ください）。

Composable ML の概要

DataRobot には、ブループリントと呼ばれる、データ前処理、特徴量エンジニアリング、機械学習アルゴリズムの組み合わせからなる設計図が何千通りも搭載されています。DataRobotの熟練のデータサイエンスチームが日々開発しているブループリントは非常に強力で、高い精度のモデルを短時間で作ることができます。そして、このブループリントにさらに皆様の知見やアイデアを追加することができる機能がComposable MLです。

こちらが DataRobot に元から搭載されているブループリントの一例です。データが前処理や特徴量エンジニアリングを経て XGBoost（図中では、eXtreme Gradient Boosted Trees Classifier と表記）に投入されている様子が確認できます。

次は、このブループリントの XGBoost を、Composable ML を用いて筆者が Python でコーディングした「ロジスティック回帰」に書き換えた例です。このように、Composable ML では皆様が Python や R で書いたオリジナルの処理をブループリントに実装し、DataRobot で実行することができます。もちろん、この皆様が実装した処理は社内に共有することが可能です。Composable ML に関する詳細は、ドキュメントやオンラインコースをご参照ください。

Composable ML の活用事例

では、DataRobot のブループリントに皆様が手を加えたいケースとはどのような場合でしょうか。DataRobot は予めデータ前処理や特徴量エンジニアリングのほとんどを自動化していますが、ドメイン知識が必要な処理は実装されていません。そのため、Composable ML は皆様のドメイン知識をモデルに組み込みたい時に最も有用であると言えるでしょう。この章では Composable ML の活用事例を3パターンご紹介させていただきます。

事例１: ベースラインモデルの実装

DataRobot が作成した機械学習モデルを採用するべきか判断する場合に、これまで業務に使用していたモデルと比較したいケースがあります。例えば、簡単なルールベースのモデルや、別ツールで作成した機械学習モデルなどとの比較です。この場合、そのモデルを Python や R で書き、Composable ML を用いて DataRobot で実行することにより、DataRobot が作ったモデルとこれまで使用していたモデルをリーダーボード上で比較することができるようになります。

以下のリーダーボード例では、DataRobot が作成した3つのモデル（2種類の Elastic-Net Classifier と Light Gradient Boosted Trees Classifier）の精度が、Composable ML で実行したこれまでのモデル（ベースラインモデル）の精度よりも高いことが確認できます。同じ条件で DataRobot のリーダーボード上で比較することにより、DataRobot が作成したモデルの業務実装可否を判断しやすくなることでしょう。

事例２: ドメイン知識を活用したモデルの精度向上

先述した通り、DataRobot はドメイン知識に基づく特徴量エンジニアリングを実施しません。例えば、DataRobot は外れ値があればデータ品質評価機能を用いて警告をしてくれますが、外れ値の除去を積極的に行うことはありません。これは、本当に取り除いて良いデータなのかはドメイン知識のある皆様しか分からないためです。そのため、皆様が普段扱うデータセットに十分詳しく、外れ値を除去しても問題ないと考えるのであれば、このドメイン知識を DataRobot のブループリントに反映することが可能です。例えば、数値データの±3 σの範囲外のデータを欠損値に置き換える処理は外れ値が多いデータセットでは有効な場合が多いです。他にも、SMILES という分子の化学構造を踏まえた前処理を Composable ML で実装することにより、予測精度が向上した事例があります。詳細はこちらをご参照ください。

事例３: 途中のデータ処理結果を出力し、モデルを更に理解する

機械学習モデルがブラックボックス化されていると人はモデルを理解・解釈することができず、業務適用しづらくなります。DataRobot ではこのブラックボックス化を避けるため、Permutation Importance、Partial Dependance、SHAP 等の豊富なアルゴリズムの実装により説明可能なAI を実現しています。さらに、Composable ML を用いることでブループリントの途中の処理結果を CSV ファイルとして出力することが可能となり、モデルの解釈性をさらに高めることができるようになります。

例えば、One-Hot Encoding の処理結果を取り出したい場合は、下記のように CSV ファイルとして簡単に取り出すことができます。

あるいは、学習器の直前までのデータ処理結果を CSV ファイルとして取り出せば、手元のローカル環境でデータ処理結果を学習させることが可能です。先ほどの事例２では、DataRobot 上で Python や R で実装したベースラインモデルを評価していましたが、このようにローカルの環境でモデルを評価することも可能です。この方法は、Python や R 以外のツールと DataRobot を同じ条件で比較したい場合にも有効です。

まとめ

本稿では、Python ユーザーの皆様に DataRobot をさらに活用していただけるように「Python SDK」及び「Composable ML」の機能を事例を交えながら解説しました。もちろん、R ユーザーの皆様も「R SDK」を用いることで同様のことが実行できます。皆様の機械学習プロジェクトの生産性向上の一助になれば幸いです。

参考

• DataRobot Python package documentation (Python SDK のドキュメント)
• ‘DataRobot’ Predictive Modeling API (R SDK のドキュメント)
• DataRobot Docs – Composable ML
• DataRobot Features – Composable ML

投稿 Python / R ユーザーのための Auto ML 活用法 は DataRobot に最初に表示されました。

原則１－ガバナンス：取締役会等及び上級管理職は、モデル・リスクを包括的に管理するための態勢を構築すべきである。

AI 推進のための組織構築は多くの企業が検討してきたが、管理運用のための組織構築はまだ未着手という企業がほとんどであろう。本原則によって指針は示されたものの、実際に具体への落とし込みをする際にその難しさが顕在化するであろう。特に Part 1で述べたことの再強調になるが、AI モデル・リスクの管理を特定の個人のみに依存するのは限界がある。膨大なデータを扱い、複雑な処理を実施する AI モデル全てを人の頭脳によって把握・記憶することは困難であり、また例えできたとしてもそれは個別の力量の高い者に頼った結果であり、それらの者のリテンション問題が不安定要素として常に付き纏う。運用するAIモデルが多ければ多いほど、その限界は顕在化し、ツールをも活用した管理態勢が検討の俎上に上がってくるであろう。

原則２－モデルの特定、インベントリー管理及びリスク格付：金融機関は、管理すべきモデルを特定し、モデル・インベントリーに記録した上で、各モデルに対してリスク格付を付与するべきである。

昨今の AI プロジェクトは複数メンバーが担う傾向が高く、また人材の流動性が高くなっている観点からインベントリー管理の重要性は以前より高まっている。
気をつけるべきことは AI モデルはデータとコードから生成されるバイナリファイルに過ぎない点である。手元の AI モデルがなんのために生成されたものなのか、どういったデータとコードから作成されたものなのか、を正しく記録しておかないと再現性を満たすことができない。さらにコードとデータだけでなく、リスク格付など作成手順には含まれない情報も管理することが AI モデルの構築・運用におけるリソースをどこに割くのか判断する上で重要となる。

DataRobot はユースケース（AI 活用プロジェクト情報）登録機能を有している。AI モデルを生成するために利用したデータ、AI モデル生成過程が記録された AI モデル構築プロジェクト、運用に利用している AI モデルと IT アセットを登録するだけでなく、AI モデルが何の業務のために利用したものなのかや、AI モデルのビジネスにおける重要性（リスク格付）などの情報を登録・保持することができる。またユースケース登録機能で作成された各ユースケースは他のユーザーやグループに共有することが可能である。第1線がAIモデル作成まで完了した上で、ユースケースを第2線に共有すれば、それに紐づくデータやAIモデル構築プロジェクト、AIモデルへの参照を一元的に渡すことができる。
また、ユースケースへの更新はアクティビティとして全て記録されているため、第2線はどのような手順で第1線が AI モデルを構築していったのかを辿ることができ、そしてそこにコメントを残して再度第1線に返すこともできる。

原則３－モデル開発：金融機関は、適切なモデル開発プロセスを整備すべきである。 モデル開発においては、モデル記述書を適切に作成し、モデル・テストを実施すべきである。

AI モデルは、入力に対して確率値を返す動作は誤った AI モデルでも同じであるため、従来の IT 的なテストだけでなく生成元のデータとコード自体をチェックする必要がある。特に AI モデル生成には乱数が利用されるものも多いため、その再現性が可能な形で開発プロセスを整備する必要がある。さらに特定のツールで作成された AI モデルにおいては、そのツールが仮に利用できない状態になった場合での AI モデルの利用や再現を考慮することも重要である。そして AI モデルの限界を把握するためには、AI モデルの性質を可視化できるようにしておくべきであり、具体的には学習時に存在しない値や欠損データに対してどのように振る舞うのかなどを把握しておく必要がある。
精度面での検証では、ホールドアウト（= 学習に利用していないデータ）を利用する。これは学習時のデータだけではなく、未知のデータに対してもパフォーマンスを発揮する（= 過学習していない）AI モデルになっているかを確かめるために重要である。そしてホールドアウトそのものに過学習した AI モデルとなる可能性を防ぐ上でも、第1線からはホールドアウトが閲覧できない形で AI モデル構築を行える仕組みがあることが望ましい。

DataRobot は、AI モデル構築ステージにおいて、ブループリントと呼ばれるデータ前処理とアルゴリズム、ハイパーパラメータのチューニングが組み合わさったテンプレートが自動的に多数実行され、精度順にリスト化される仕組みとなっている。その上で、AI モデルが構築する上での学習データと検証、ホールドアウトデータの分割や全ての AI モデルに共通なモデル可視化機能も自動で実行される。また AI モデルの差別も海外では頻繁に問題として取り沙汰されているが、DataRobot は AI モデルが差別的な判定をしていないか、様々な尺度から構築段階で検知する仕組みを有している。
またベンダーロックインを防ぐ上で、より包括的なモデル記述書として、SR11-7に対応したAI モデル構築に関するモデルコンプライアンスレポートを自動で生成することも可能である。

原則４－モデル承認：金融機関は、モデル・ライフサイクルのステージ（モデルの 使用開始時、重要な変更の発生時、再検証時等）に応じたモデルの内部承認プロセスを有するべきである。

シャドウ IT という言葉が一時期話題になったが、AI モデルが誰にでも手軽に作成できるようになった今、「シャドウ AI モデル」が社内に氾濫する可能性がある。そのため、AI モデルを安全に正しく使う上でも、第2線からの独立的なチェック体制及び、稼働開始フローをシステム的にも整備することが重要となる。また AI モデルは導入後にも時間とともに精度が劣化する性質から、定期的な再学習を必要とする。すなわち、AI モデルにおいては使用開始時のみに気を配るのではなく、再学習という変更の発生が従来の IT システムに比べて頻繁に起こることを考慮した内部承認プロセスを構築する必要がある。

DataRobot では AI モデル・ライフサイクルのステージに合わせたタスク、またそのタスクへの関わり方に応じて権限分掌を行うことができる。そして、権限分掌を行った上で、AI モデル・ライフサイクルのステージ変更及びその AI モデルの重要度に応じて、設定した承認ポリシーに従った承認ワークフローを設定することが可能である。これにより、第1線と第2線での内部承認プロセスをシステムとして構築することができるようになる。

原則５－継続モニタリング：モデルの使用開始後は、モデルが意図したとおりに機能していることを確認するために、第１線によって継続的にモニタリングされるべきである。

AI モデルは時間とともに当初想定していた性能を発揮しなくなる。また急激な市場の状況やその他の環境の変化等によって AI モデルの性能が大幅に劣化することは少なくない。実際、本稿執筆時（2022年3月）、新型コロナウイルスの蔓延に伴い、過去に作成された多くの AI モデルが再作成を余儀なくされている。このような AI モデルの性能変化を適切な間隔でモニタリングすることで、モデルを再作成するべきタイミングを適切に検知し、劣化したモデルの使用によってもたらされる経済的損失を未然に防ぐことができる。AI モデルにおけるモニタリングポイントは、従来のシステム的な「サービス正常性」と AI モデル特有の「データドリフト」と「精度変化」の三点となる。
「サービス正常性」とは、運用に利用している AI モデルがシステムとして正常に稼働しているかを確認するものである。未知の入力が来た場合のエラーハンドリングをできているかなども含まれている。また従来の統計モデルに対して複雑化した AI モデルは推論時においても処理時間がかかるものもあるため、想定時間内に計算が完了しているかなどもチェックは必須となる。
「データドリフト」とは、AI モデルの運用にとって非常に重要な概念となる。学習時と推論時の各特徴量（説明変数）の分布が変化したことを表現する言葉で、データドリフトが発生していると AI モデルが学習時と同等の性能を発揮しない可能性が高い。データドリフトが発生する要因はいくつかあるが、代表的なカテゴリとしては以下の2つとなる。

• 時間経過とともに全体のトレンドがドリフトするもの
• 学習時と推論時の条件違いによって発生するもの

「時間経過とともに発生するデータドリフト」も、緩やかに発生するものや急激に発生するもの、周期的に発生するものがあるため、データドリフトが発生するサイクルに合わせて AI モデルの再学習を計画することが重要である。これらのドリフトは世の中のトレンドに影響を受けて起こるため、AIモデル作成者自身もその発生タイミングで感覚的に気づける場合が多い。
もう一つの学習時と推論時の条件違いによるデータドリフトは、データ変換処理上の違いが原因で発生する。同一の変換処理を利用しない理由として、例えば”学習時にはバッチで学習データを準備したが、運用時はオンライン推論だったため、それぞれの処理で通るデータパイプラインが違った”などが存在する。
変換処理の違いで実際に起こりうるものには以下のようなものがある。

• 学習時にだけ表記ゆれを修正し、推論時には表記ゆれ修正を行っていない
• 学習時と推論時でエンコーディングが違い一部の値が別の値として認識されている
• SQL の処理系の中で学習と推論時で欠損値の扱い方が違う

これらはそもそもがミスが起点で発生しているため、AI モデル作成者が捉えることは難しい。ただし、データドリフト検知を実施することによってミスに気付くことができるため、中長期的な AI モデル運用だけでなく、短期的なモニタリングにおいてもデータドリフト検知は重要となる。
「精度変化」はそのまま AI モデルの最終パフォーマンスを見るものだが、注意すべきは、精度が変化したことに気づくまで推論時点からはラグがあるということである。仮に AI モデルが3ヶ月後のデフォルトを予測しているものだった場合、その正解データは3ヶ月後にならないと収集することができない。この点からも AI モデル運用では精度変化を検知することも重要だが、精度変化だけでなく、先に上げたデータドリフトをモニタリングし、未然にリスクを検知することが重要となる。

DataRobot 内で作成した AI モデル及び Python、R、SAS などで作成した AI モデルを DataRobot に取り込んだ場合には自動的に「サービス正常性」「データドリフト」「精度変化」を時間および特定のセグメントごとにモニタリングできる。また DataRobot から外部に書き出された AI モデルでも、エージェント機能によって「データドリフト」「精度劣化」を同様にモニタリングできる。そして、運用状況をデプロイレポートとしてスケジュールされたタイミングで自動発行する機能も有しているため、AI モデルが増えた場合においてもスケールする運用体制を構築することができる。

原則６－モデル検証：第２線が担う重要なけん制機能として、金融機関はモデルの独立検証を実施すべきである。独立検証には、モデルの正式な使用開始前の検証、重要な変更時の検証及びモデル使用開始後の再検証が含まれる。

第2線に関する議論、特に体制面での議論に落とし込むと、一つ大きな課題が見えて来る。本原則の3つの防衛線ルールでの第2線は、原則1.4においてそれが第1線から独立すべき監督部門となるべき、とされている。第3線が管理態勢全般への監督を役割とする以上、実質的な管理監督の要はこの第2線であるため、その役割は極めて重大だ。ただ、”この役割に付きたい人はいるのだろうか？”
AI モデル分析は現在最も先進性/将来性の高い領域の一つだ、データサイエンティストを志す者が、膨大な時間をかけてスキルを身につけてきたのも、その最前線で挑戦を続け、更なる高みとリターンを目指すためであり、「管理監督」という一歩引いた役割を望む者は少ないであろう。一方でAIモデルリスク発生時のインパクトを考えれば、企業としてはこの役割に最先端の知識を持つ者を配置したい。米国での AI 普及の初期を振り返ってみると、多くの企業でこのギャップが見落とされていた。例を挙げると第2線に引退間近の人員を配置し、管理態勢が形骸化し、リスクへの防衛が疎かになってしまった。この課題を解決し、強固な第2線体制を構築するには3つの方法があり得る

①    系列企業の第1線同士が検証し合う体制の構築
②    第2線ポジションの魅力向上
③    牽制役ではなく、第1線と共闘する第1.5線の設計

①   
ごく自然に思いつく打ち手だが、系列各社の第1線が他社の第1線の AI モデルを検証することができれば、上記の課題にはなりうる。金融庁の質疑回答を確認する限り、この対策は推奨されているとまでは言えないが、明確な否定もなく、その妥当性はどちらかと言うと、企業ごとの実務的な有効性次第であろう。系列企業とは言え、業務を異にする以上、他社の AI モデルをどれだけ理解し、有効な検証ができるかは各社が慎重に判断すべきであろう。

②     
上記の打ち手が現実的でない日本企業には、米国企業の反省を踏まえると、ぜひ第2線のポジションの強化、そしてそのための人材キャリアパス設計を進言したい。端的に言えば、第2線での役割でも十分な報酬を期待でき、社内的にも将来性のあるキャリアパスが見えれば、スキルの高い人材にも十分魅力的なポジションとなる。
このような管理監督ポジションはどうしても軽視されがちだが、今一度AIモデルリスクのインパクトを概算して頂きたい。その数字を見れば、このポジションにいくらのコストをかけるべきか、自ずと見えて来るはずだ。

③     
また、そもそもの役割として第2線を単なる第1線に対する牽制役とすべきではなく、もっと第1線と共闘する役割と考えても良いのではないか。第2線のポジションはある意味、ガードレール的な役割だが、現在 AI モデルリスク管理においては絶対的に正しいガードレールは存在しない。ならば、第2線は第1線がやろうとすることの本質を正確に捉え、リスクを抑止しつつ、その実現をサポートする、いわば「第1.5線」の役割である方がより現実的である。それにより第1線はより積極的に第2線の協力を仰ぐようになり、“守り”だけではなく、“攻め”をも兼ねた AI モデル検証体制が構築できるはずだ。

原則７－ベンダー・モデル及び外部リソースの活用：金融機関がベンダー・モデル等や外部リソースを活用する場合、それらのモデル等や外部リソースの活用に対して適切な統制を行うべきである。

ベンダー・モデルのデータやパラメーター等が不透明な場合に生じるリスクとしては、以下の2つが存在する。

• ベンダーがサービスを停止した際に再現性が保てなくなるリスク
• モデルの特性や限界を正しく把握できないリスク

1つ目のリスクはベンダー・サービスより API 経由で AI モデルを利用している場合などにおいて、その API が使えなくなることを意味する。このリスクを回避するためには、AI モデルをベンダー・サービスと切り離せる何らかの仕組みをそのベンダーが提示できるかどうか確認する必要がある。
2つ目のリスクはベンダー・サービスの AI モデルに予期しないバイアスが含まれていることやどのようなパターンで精度が劣化するか把握できていないことを意味する。リスク回避手段の一つは、AI モデルの性質を調べるためベンダーに学習用データとコードの開示を要求することだが、学習データやコードの開示はそのベンダーの知的財産にも関わるため現実的ではない。現実的には、AI モデルのリスク格付けが高いものに関しては、ベンダー・モデルの利用を停止するという手段も選択肢にいれるべきである。補足となるが、近年の AI モデルは複雑化しており、ベンダー・モデルが一部処理のみで使われている場合も存在し、一見手元のデータからゼロベースで学習させたと思っていても潜在的にベンダー・モデルが紛れている可能性もある。そのため、AI モデルの透明性を求めた上でその内容を注意深く確認する必要がある。

DataRobot は、基本的には企業内での AI モデルの内製化を目指したプラットフォームであり、ベンダー・モデルに該当するケースは多くはない。ただし、一部の高度な分析テンプレートにおいては、事前学習済みのモデル（高度な自然言語処理や画像データの前処理）を含んだものが存在する。DataRobot では、これらの処理が使われた AI モデルかどうかを確認することができるため、該当処理を含まない AI モデルを選択することもできる。また、他の処理は残したまま、該当処理だけを除きたいという要望に対しては、自動生成された分析テンプレートを編集する ComposableML 機能も備えている。
そして内製化を目的としてDataRobotを導入しても、その利用者をすべて外部リソースに頼っている場合には、活動の結果を理解し、適切に評価することは難しい。外部リソースの活用をリスク管理を実施した上で実現できるためにも、ツールの導入だけでなく、人材育成は重要なウェイトを占めることになる。

原則８－内部監査：内部監査部門は、第３線として、モデル・リスク管理態勢の全体的な有効性を評価すべきである。

第3線の論点も多々あるが、一つ絞るなら、“今ではなく、これから”を見据えた管理監督が求められる。監督対象として企業が“今”どんな AI モデル・リスク管理態勢にあるのか、は当たり前として、第3線は企業の AI 戦略、つまり“これから”やろうとすることまで、助言し監督すべきである。さらにその前提として、常に最新のトレンドと情報を踏まえたアドバイスを求められる。前述のように AI モデルリスクがどんどん進化する以上、管理監督の論点も変化し続けているため、それらをいち早くキャッチアップし、社内での検証・改善に落とし込める機能が第3線に求められる。しかし、そこまで行くとやはり管理監督体制は一朝一夕で構築できるものではない。したがって企業によっては一定の外部支援を初期は求めるのも一つの手であろう。

まとめ

本稿ではあくまで AI モデルに注視して記述したが、モデル・リスク管理の原則では、モデルの定義は統計モデルやルールベースモデルなど、様々な手法をカバーするものと回答されており、AI モデルに限定されるものではない点には注意が必要となる。
リスク管理では、組織的な体制、人材の育成、またそれらをサポートするシステムが重要となる。AI モデル活用が金融機関において拡大中のいま、本ブログ及び弊社ソリューションが参考になれば幸いである。

参照文献

金融庁：モデル・リスク管理に関する原則
金融庁：コメントの概要及びコメントに対する金融庁の考え方
COSO──ガバナンスと内部統制３つのディフェンスライン全体でのCOSOの活用
三つの防衛線（3つのディフェンスライン）によるリスクマネジメント
Machine Learning in Production: Why You Should Care About Data and Concept Drift

投稿 モデル・リスク管理の原則におけるAIモデルの対応について Part 2 は DataRobot に最初に表示されました。

本稿は二部構成をとっている。Part1 では金融庁の示すモデル・リスク管理における8原則への対処を思案する上での重要論点を整理し、Part2 では各原則について個別に DataRobot を利用した対処案を説明する。（AI モデル・リスク管理は金融業界だけでなく全ての業界で遅かれ早かれ具体的対処が必要になる重要項目であると考えられるため、金融業界とは直接関わりがなくてもDataRobot が提唱する対処法・機能についてご興味のある読者はぜひ Part2 だけでもお読みいただければ幸いである）

今回、本原則の発表は金融業界にとって青天の霹靂では無いはずだ。元々モデルの管理を規定する SR 11-7 は米国で早くから導入されており、日本にもいずれ類似の業界ルールが規定されることは予見できた。それでも、本原則の正式発表は、今まで各社が企業単位で独自努力と理解の範囲で行って来たモデルリスク管理がとうとう、業界単位でのルール規定の下に、チェックされることを意味している。それは、モデルリスク管理が金融機関にとって最重要アジェンダである時代の到来を告げている。

DataRobot は米国で、SR 11-7 が登場した黎明期から、AI モデルガバナンスの支援を AI 活用をリードする金融機関に対して実施して来た。その経験は本原則への対応でも参考価値があると考えられる。

本原則を議論する上での論点は下記のように大まかに整理できる：

①    本原則の対象となる企業はどれか？
②    管理対象となるモデルはどこまでか？
③    管理すべきリスクとは何か？
④    ガバナンス（管理体制・社内ルール）をどのように設計すべきか？

本稿は主に上記論点④の範疇にあるが、論点①、②、③における要点をまず述べさせて頂きたい。端的に要点をいうならば、

①　本原則対象は今後将来的に拡大する可能性は高い。
現状、G-SIBs、D-SIBs、FSB により選定された G-SIBs（本邦 G-SIBs を除く。）の本邦子会社であって、金融庁によるモデルの承認を受けている金融機関が対象となっているが、SR11-7 のトレンドを見ても、日本では今後対象範囲が拡大することは必至だ。
また、原則の対象外になっているからと言って、例えば現対象の子会社がモデルリスク管理をしていない訳ではない、子会社ごとに方向性の異なる管理アプローチが進むと、いざ対象範囲内に入った時に、親会社を含めたグループ全体の管理方針に齟齬が生まれてしまう。現時点から先取って、子会社をも検討の範囲内に含めることは長い目で見れば間違い無く多くのコストを節約することができる

②　本原則の発表により、管理すべき対象はより広義のものとなった。
恐らく、直近ではまずこれが各対象企業にとっての一番の頭痛であろう。本原則では、明確な線引きはされていないが、質疑応答などをも含めて読み解くならば、広義にモデルを解釈する方向性は確かだ。各業界/企業ごとの事情によるため、一概に論じることは難しいが、ガバナンス体制を検討する上でも影響は出てくる。
*本稿においては、より精緻な議論のため、広義のモデルの中でもあえて AI モデルに範囲を制限していきたい。AI は近年金融業界で業務利用が急拡大する一方で、運用管理について悩まれている企業がまだ大多数であり、議論の価値が高い領域と認識している。

③　AI モデルリスクは絶えず変化/進化しており、現状特定できていないリスクにも備える必要がある。
これは本原則というよりも、近年の AI モデルの進化とそれに伴う事件を見れば、AI モデルリスクというもの自体、まだ我々が把握しているのはほんのわずかであり、今後AIモデル活用が本格化するに連れて、どんどん新しいリスクも発生する。例えば、AI モデルのバイアスによる不公平性のリスクは、凡そ今まで予見が難しいリスクであった。そのような新しいリスクをいかに早くキャッチアップし、自社における対策を講じることができるのか、これもガバナンス体制に問われるポイントの一つとなりうる。

④　構成においては、他のリスク管理と同様に、実効的なけん制を確保する基本的な枠組みとして、「3つの防衛線（3線モデル）」の概念の下で整理する。
この中で、「第1の防衛線（第1線）は、モデルを所管する又はモデルの開発・使用に直接関係する部門・個人で構成される（モデル・オーナー、モデル開発者、モデル使用者等）。」を想定と書かれているので、実際に AI モデルを構築するデータサイエンティストが含まれることになる。そして「第2の防衛線（第2線）は、第2線に対するけん制を通じてモデル・リスクを管理する部門・個人で構成され、モデル・リスク管理態勢の維持、規程等の遵守状況及びモデル・リスク全体に対する独立した立場からの監視、モデルの独立検証等の役割を担う。」を想定と書かれていることから普段業務においては、AI モデル構築は行わないながらも、監視や独立検証ができるレベルということで、第1線以上のデータサイエンススキルを求められることになる。最後に、「第3の防衛線（第3線）は、内部監査部門で構成され、金融機関のモデル・リスク管理態勢の全体的な有効性を評価する。」となることから、単純なデータサイエンススキルだけでなく、企業の AI 戦略を見据えることができる人材を必要とする。これらの構成を満たした上で、さらに理想とするガバナンス体制は、透明性、継続性、効率性の3つのキーポイントを実現できるものであるべきである。

AI モデルリスク管理のガバナンスにおける絶対的な正解はまだ無いが、米国の金融機関の先端的な取り組みを支援して来た DataRobot の経験から見えてきたキーポイントの中で、特に重要な3つのキーポイントがあると考えている。そして、DataRobot は下記の3つを満たすガバナンス体制の構築には、人にだけ依存するのではなく、ツールをも活用することを提言している。

・    透明性
・    継続性
・    効率性

上記で論じたように、AI モデルリスクはまだ絶えず進化しているものである。世界中で膨大な数のAIモデルが運用されており、今まで想定していなかったリスクが突如現れる。ここ数年、これらのニュースは幾度も金融業界を騒がせてきた。新しいリスクの発現において、企業がまず実施すべきは、自社での類似の運用状況の把握である。そこにおいて、人に依存しない透明性が重要となる。”うちには優秀なデータサイエンティストがいて、その人に聞けば状況把握は全てわかる！”、と安心している企業は多いのかもしれない。ただ、それは盲信・過信の危険性があり、ガバナンスの思想ではない。どのようなデータを持ち、どのように分析し、どのように運用されているかの状況は理想として、人の頭にではなく、全てツールとして記録され、誰もがすぐに、明確に把握できるようにすべきだ。

継続性も上記議論から生じるものだ。人への依存には、転職・各種事由による勤務不能、パフォーマンスの不安定などのリスクが付き纏う。第1線、第2線のキーマンが離職したばかりの時期に、AI モデルリスク側が空気を読んで発生を控える、ということが望めない以上、ガバナンスの根幹として人への依存は可能な限り抑えるべきである。

最後に効率性も見落としてはならない重要なポイントである。ガバナンスの目指す姿を今一度お考え頂きたいが、リスク回避だけがガバナンスの目的では無いはずだ。”リスクを抑制しつつ、業務効率をも維持すること”が理想像のはずである。恐らく、AI モデルリスク管理を具体的に検討した企業はすぐにこの難題にぶつかるであろう。本原則1.3で求められる、”文書化”、は実務者から見れば、”言うは易し・・”の典型である。AI モデル活用は今最も進化が活発な技術領域であり、第1線のデータサイエンティストは日々トライアンドエラーを繰り返しており、また扱うデータの種類・量も膨大である。それらを管理監督の実効性を維持できるレベルで記録する手段は、具体的にどう設計すれば良いか？AI モデル構築・運用を行いつつ、横手で一つ一つのアクションをエクセルなどにでも記録するのか？それは現場を無視し、効率低下を招く非現実的な管理手法に他ならない。AI モデルの構築・運用、そして記録、それらが自動的に、シームレスに、一つのプラットフォーム上で行われるべきである。記録という行為で人への依存をできる限り抑止する、それは、効率性のみならず、正確性の観点からもガバナンスの理想像と言える。

”人への依存の抑止”、は DataRobot が提供する重要な付加価値の一つであり、それは Part2 でより具体的に、技術的に解説していく。その根幹をなす思想として、上記3つのキーポイントの観点があることを覚えて頂きたい。

各原則については、Part2 にて DataRobot としての対処案をより具体的に論じていくが、その概要を下記に提示する：

Part 2に続く。

投稿 モデル・リスク管理の原則におけるAIモデルの対応について Part 1 は DataRobot に最初に表示されました。

DataRobot では、機械学習（ML）を民主化して拡張知能につなげるためには、機械学習モデルを準備、作成、探索、デプロイ、監視、使用する方法などについて、シームレスに学習できる環境をあらゆるユーザーに提供しなければならないと考えてきました。
DataRobot を使い慣れている方は、アプリ内のドキュメントにも慣れ親しんでいるため、急成長を続ける製品を容易に使いこなすことができます。一方、DataRobot のプラットフォームについて、あるいはもっと一般的に機械学習について詳しく検討中の方にとっては、それらに関する情報が一般に公開されていると、それを大きな足がかりとして、理解や習得を深めることができます。しかし、多くの場合、操作方法を理解するだけでは不十分です。製品の可能性を見出せなければ、アイデアやビジョンはひらめきません。

ユーザーと一緒に仕事をしていると、「へえ、そんなことができるんですね」という声をよく聞きます。 

新しい公開ドキュメントサイトを利用すれば、自分ひとりで探索的な作業をしていても、思いがけなく素晴らしい発見ができます。

docs.datarobot.com のご紹介

Docs.datarobot.com はユーザーでなくても閲覧でき、DataRobot の全製品の情報を得ることができます。この新しいサイトで DataRobot の重要なプラットフォームドキュメント、API リファレンス、チュートリアルコンテンツを公開することで、私たちはデータサイエンスの民主化をさらに進めていきます。ドキュメントだけでなく、DataRobot University、コミュニティ、DataRobot のウェブサイトに誰でもアクセスできます。

各セクションの内容をご紹介します。

• プラットフォーム：データのインポートからモデルの使用まで、ワークフローに関する完全なドキュメント
• API：すべての API リファレンスガイドとクイックスタートへのリンク 
• チュートリアル：モデリングプロセスの各段階に関連したタスクの簡単な説明
• ノートブック： DataRobot ノートブックを活用したデータサイエンスの利用および管理方法
• 用語集： DataRobot を理解する上で特に重要な用語の定義

また、このサイトでは、自然言語による絞り込み検索を直感的な操作で行うことができます。疑問点の解決に役立つ情報が希望のフォーマットで表示されます。

既存のお客様向けのドキュメント

すでに DataRobot をお使いの場合は、この公開サイトの全コンテンツだけでなく、アプリ内限定のコンテンツも参照できます。たとえば、収益曲線のグラフを見ているときに、コストや利益が変化したときの影響を知りたいと思ったとします。アプリ内のヘルプをクリックすると、完全なドキュメントが表示されます。

しかし、docs.datarobot.com を利用すれば、すぐに回答が得られます。このサイトを通じて、ユーザーではない人に概念を説明したり（リンクを共有）、DataRobot の他のリソースに簡単にアクセスしたりすることもできます。たとえば、学生の中退予測において、適切な論文を書けないまま中退する学生がいるのはなぜなのか、大学の管理者に正確に説明する必要がありますか？そうであれば、SHAP のドキュメントのリンクを彼らに送りましょう。

私は 5 年前に DataRobot に入社してドキュメントの初版を担当しましたが、それ以前にお客様に提供されていたのは、多言語に対応した 6 ページの仕様書だけでした。寝る間も惜しんで作成された素晴らしい内容でしたが、私はすぐにそれをすべて捨て、最初から作り直しました。DataRobot のドキュメントは、執筆者、レビュアー、開発者、プロダクトマネージャー、翻訳者など、国際的な素晴らしいチームによる、真の意味での愛の結晶です。私がこれまでに執筆したものや学んだ技術（機械学習とコンテンツプラットフォームの両方）の中で、この新しいウェブサイトの結果ほど満足できたり、歓迎されたりしたものはありません。開発者やデータサイエンティストと一緒に仕事をしたことがある人、あるいは現在そうした状況にある人は、彼らが要求の多い厳しい人たちであることを知っているでしょう。DataRobot では、機械であれ人間であれ、学習のあらゆる面での民主化を信じています。この新しいサイトの最初の読者はもちろん DataRobot の従業員で、彼らは夢中になって使っています。私たちのドキュメントは、部門の垣根を越えた全員参加のコラボレーション、レビュー、そして絶え間ない修正の成果です。つまり、私たちのドキュメントは信頼できるということです。DataRobot のデータサイエンティストも信頼しています。   

次のステップ

今後も引き続きサイトの充実化を図っていきます。たとえば、お客様の DataRobot アカウントでログインすることで、完全なユーザードキュメントを参照できるようにする予定です。また、DataRobot の学習コンテンツのポートフォリオ全体での検索結果が表示されるようになります。そしてもちろん、機能に関するドキュメント、チュートリアル、API ツールも引き続き充実させていきます。

投稿 新しいオールインワンの公開ドキュメント<br>およびラーニングセンター は DataRobot に最初に表示されました。

化学・材料業界におけるマテリアルズインフォマティクスの重要性

近年、材料開発領域における情報技術の活用、いわゆるマテリアルズインフォマティクス (Materials Informatics: MI) の重要性はますます広く認識されるところとなっています。マテリアルズインフォマティクス自体は機械学習に限定されないより広い概念ですが、昨今の Deep Learning を始めとする機械学習技術の急速な発展に伴って特に機械学習・AI の活用が産業界において重要視されています。化学は摺り合わせ技術の最たるもので、日本の御家芸とも言える産業領域の一つですが、この領域にも技術革新の波は確実に迫っています。

AI の材料開発への活用はリサーチから実用の段階へ

日本国内の製造業における AI 導入に何十社と関わってきた筆者は、その段階がいよいよマテリアルズインフォマティクスそれ自身のリサーチから実用段階に入っていることを肌身で実感しています。概ね2~3年前くらいに”マテリアルズインフォマティクス研究所”のような組織を立ち上げて技術それ自身の研究と少数のテーマにおける検証を進めてきて、最近になって実用に当たっての生産性を求め始めたというお客様が多いのではないでしょうか？有機材料の処方開発、合金や半導体材料の組成と処理条件の検討などで様々な領域で活用が進んでおり、まさに機械学習・AI の材料開発への応用は、一般の実験化学者である現場の研究員が用いるツールとして実際に役立てるフェイズに到達しているというのが現状なのです。

製造業と逆問題解析

今回はその中でも、特に活用事例の多い材料の配合からの物性推算とその逆問題解析について紹介したいと思います。通常の教師あり機械学習では、下図の (a) ように材料の組成やプロセス条件などから性能となる材料物性を予測します。この物性予測自体も非常に有用なものですが、一方で材料開発の現場において本当に欲しい情報は物性の予測値というよりも、むしろ (b) のように最も望ましい材料物性を与える配合条件の候補という場合が多いでしょう。この物性推算モデルから逆に最適な配合の候補を求めるアプローチを逆問題解析と呼びます。

この構図は開発者目線では当たり前のニーズと言えますが、興味深いことにこのニーズは製造業において特に集中して耳にする要求で、この業界の特色の一つと言えます。その他にも逆問題解析は、配合の最適化以外にも材料の処理条件や製造工程における設備の運転条件の探索などに用いられており、製造業全体における活用の幅が広い技術です。おそらく特に製造業において逆問題解析が重要視される理由としては、製造業がそのデータの生成プロセスであるモノづくりの過程を自身で制御し、改善し得る立場にいるためではないでしょうか。まさにこの分野におけるデータサイエンスが一際面白い理由の一つでもあるかと思います。

DataRobot 最適化アプリ

この逆問題解析ですが、一般に解析的には解けないのでソルバーを使って解くことになります。DataRobot にはなんとこの逆問題解析のためのソルバー：DataRobot 最適化アプリが付属¹しており、データがあれば物性推算から配合検討までを一気通貫で行うことが可能です。これは材料開発の PDCA をスピードと質の両面で大幅に向上させる効果が期待されるパワフルな機能ですが、ある意味では従来の実験計画法の延長にあるものとも言えるため、製造業のお客様であれば大きな違和感を感じることなく便利なツールとしてご活用頂けると考えています。

実際の手順を見てみましょう。過去の配合データと工程条件から学習データを構築し、DataRobot で物性を予測するモデルを構築するところまでは、通常の予測モデリングと同じで学習データをドラッグ＆ドロップで読みこんて、予測ターゲットを指定したら開始ボタンを押すだけです。下図の例では鋼の熱処理条件や組成、その他条件から回転曲げ疲労強度を予測していますが、比較的良い精度のモデルができていることがわかります。

次に、DataRobot 最適化アプリではこのモデルを用いて仮想の実験を数百回と繰り返しながら最適な物性が得られる入力条件を見つけ出します。こちらも使い方は非常に簡単で、まずターゲットを最大化したいのか最小化したいのか（あるいはある規格値からの乖離幅を最小化するなども可能）、どの変数についてどの範囲を探索したいのかを元データの分布を見ながらグラフィカルに設定し、あとは初期値を入れて探索を開始するだけで最適な予測結果を与える入力条件を得ることができます。得られた候補点を参考にして次回実験の水準設計などに活用することで処方開発の質とスピードを数段レベルアップさせることができるでしょう。こうした水準設計とそれに基づいた実験は日々繰り返し行うものですから、こうしてついた差はいつの間にか積み重なって覆し難い大きな競争優位性となり得るのです。

予測の不確実性と活用シーン

さて、ここで得られた配合条件と対応する材料物性の予測値については不確実性が伴います。例えば、以下の二つの組成に対してあるモデルによって得られた reduced glass transition temperature² の点推定値はいずれも近しい値をとりますが、実は予測区間を見てみると大きく異なることがわかります。

一般に得られた候補点の近傍に過去の実績値が多数ある場合には予測の確信度は高くなり、逆に実績値から遠く離れている場合には予測の確信度は低く（＝不確実性が高く）なります。ただし、ここで不確実性が高いことは一概に悪いというわけではありません。不確実性が高いということは、現有モデルが自信を持てていない実績の薄い部分ということですから、逆にその候補点について実験を行って追加の実績値を獲得することができれば、その際に多くの情報を得られるということにもなるからです。これは探索、すなわち知見の獲得がより大きな価値を持つ R&D の初期〜中期で有効に活用することができるでしょう。仮に候補点に対する実験結果が予測と合致しなかったとしても、それは価値あるデータと見ることもできるのです。このように確信度の低い領域に対して選択的に実験を行い、実測値を得ることで効率的に学習データを収集するアプローチは Active Learning と呼ばれています。

一方で、不確実性の低い領域は収穫、すなわち良い製品性能そのものが大きな価値を持つ R&D の後期ないし実際の製造工程で有用でしょう。これらの両方のアプローチを開発のステージに合わせて適切に用いることが重要です。

不確実性の評価方法

予測値の不確実性の評価方法について見てみましょう。分類タスクの場合には比較的シンプルで、出力される確率値がいずれのクラスともつかない中途半端な領域であるほど不確実性が高いと見なすことができます。この中途半端さの定量化にはいくつかの定義がありますが、下図のようにいずれの場合でも各クラスの中間領域で不確実性が高いとされます³。

一方で回帰タスクの場合には、通常の機械学習モデルの出力は点推定値になっていることが多いために、そのままでは不確実性に関する情報を得ることができません。そこで工夫をする必要が出てきます。手法としては様々知られていますが、任意の回帰モデルに対して予測の不確かさ、すなわち予測区間を推定する方法としては例えば、ブートストラップ法が知られています。これは元データセットからランダムにサンプリングしたデータセットを用いてモデル作成と予測を繰り返し、その予測値のばらつきを評価するという手法です。ブートストラップ方によるアプローチは対象を問わずに汎用的に使えるというメリットがありますが、計算コストが非常に高いというデメリットがあります。その他にもGaussian Processによる方法やニューラルネットワークの Drop out を推論時にも有効にして予測分布を得るなどのアプローチ⁴なども知られています。

DataRobot を用いた不確実性の評価とその活用

予測区間をより簡便に推定する手法としては分位点回帰による方法が挙げられ、DataRobot でも利用することができます。分位点回帰で用いられる Quantile Loss は図のように MAE を非対称化した損失関数で、任意の分位点を回帰タスクとして直接学習します。例えば、50パーセンタイル (=MAE) に加えて10パーセンタイルと90パーセンタイルについてそれぞれ分位点回帰を行うことで対応する予測区間が得ることができます。この幅が広い場合には予測の不確実性が高く、反対に狭い場合には不確実性が低いと言えるでしょう。予測分布をまるごと推定するブートストラップ法などの方法と比較して単一の分位点のみに対する回帰ですので計算コストもそう高くなく、手軽に用いることができます。

全体のワークフローをまとめると以下のようになります。まず、材料の配合データや工程条件、それに予測ターゲットとなる材料物性などのデータを集めて学習データとします。これを用いて DataRobot で材料物性を予測するモデルを構築し、次いで DataRobot 最適化アプリで逆問題解析を行うことで最適な配合ないし工程条件の候補を求めます。この得られた候補データを別途 DataRobot で構築しておいた分位点回帰モデルに与えることで、対応する予測区間を得ることができます。予測区間からはその候補点の不確実性に関する情報を得ることができますから、開発の段階に応じて「多くの知見が得られる探索モード」と「手堅く結果を得る収穫モード」を使い分けていくことで、従来以上に深い業務活用を実現して頂くことができます。例えば、研究開発プロジェクトの初期では不確実性の高い箇所を集中的に実験することでどんどん新たな知見を得て現象理解を深めていき、製品化が近づいてきた段階で不確実性の低い領域から好適な配合や条件を作り込んでいくことができれば、研究開発のスピードと最終的な品質いずれをも両立させつつ現在より高い次元を目指すことができるでしょう。

今回ご紹介した DataRobot および DataRobot 最適化アプリはいずれも大好評の DataRobot AI Platform トライアル でご試用頂くことができます。是非、これらのパワフルなツールをご活用頂き、皆様が材料開発を次のステージに進められる際の一助として頂ければ幸いです。

参考文献

1. 2020年10月現在、SaaS版のみ対応（オンプレ対応については開発中）
2. Z.P. Lu, Y. Li, S.C. Ng, Reduced glass transition temperature and glass forming ability of bulk glass forming alloys, J. Non. Cryst. Solids. 270 (2000).
3. Burr Settles. Active Learning Literature Survey. Computer Sciences Technical Report 1648, University of Wisconsin–Madison. 2009.
4. Gal, Y. and Ghahramani, Z. (2015). Dropout as a Bayesian Approximation: Representing Model Uncertainty in Deep Learning. arXiv:1506.02142 [cs, stat]. arXiv: 1506.02142.

投稿 製造業：AIによる材料配合検討とその応用 は DataRobot に最初に表示されました。

今回はDataRobotの強力な機能の一つである特徴量ごとの作用についてご紹介したいと思います。DataRobotはモデルを解釈するための様々な機能を有していますが、特徴量ごとの作用を使うことでその名の通り、各特徴量がターゲットに対してどのような影響を及ぼしているか、そのモデルの予測値と実測値の関係がどうなっているのか、その中身を見通すことができます。

特徴量ごとの作用とは

特徴量のインパクトを見ることで、そのモデルにどの特徴量がよく効いているのかを知ることができます。しかし、どのように効いているのかを知ることはできません。そこでモデル特徴量ごとの作用の出番です。モデル特徴量ごとの作用を見ることで、その変数がプラスに効いているのかマイナスに効いているのか、どのように効いているのか依存性を定量的に理解することができます。さらにはどの領域でモデルの信頼性が高くて、どの領域では注意が必要なのかについてのインサイトを得ることも可能です。

まずはモデル特徴量ごとの作用を見てみましょう

モデル特徴量ごとの作用を見てみます。今回の題材はローンの申請データからの貸し倒れ予測で、年収入について見てみることにします。オレンジ色、青色、黄色の３つの折れ線グラフとその下にヒストグラムが表示されているのがわかります。このヒストグラムは年収入の分布を表すもので、データの画面で見ることができるものと同じものです。オレンジ色の折れ線はターゲットのそのビンにおける平均値の実測値を、青色の折れ線グラフは予想値を表しています。黄色の折れ線グラフは部分依存を表しますが、これについては後で説明することにします。

この折れ線グラフから例えば、「年収入が高い人ほど貸し倒れが少ない傾向がありそうだ」とか「年収入100k USDくらいまでは青色の予測とオレンジ色の実測の折れ線がほぼ一致しているので、この辺りまではモデルを信頼できそうだ」などのインサイトを得ることができます。さらには、「年収入100k USD以上では傾向が違うようだ。貸し倒れる要因が異なるのかもしれない。分けて別々のモデルを作ってみようか」などの考察も可能かもしれません。

部分依存はどのように計算されているのか？

特徴量ごとの作用の部分依存（Partial Dependence）とは何なのかについては、お客様から最も頻繁にご質問を頂くポイントの一つです。実際、部分依存とは何なのかについては直感的にはわかりづらいため、ここでは実際にローン申請のデータを用いて、その導出過程を追いかけながら中身を一緒に理解していければと思います。それでは、以下のデータの年収入について部分依存を求めていきましょう。

まずは、他の特徴量はそのままで、年収入だけが全員30,000ドルだったと仮定して、対象のモデルを用いて貸し倒れ確率を求めます。そして得られた確率の平均をとります。

同様に年収入を40000ドル、50000ドルと変化させていって貸し倒れの予測を行い、それぞれの場合における貸し倒れ確率の平均値を求めていきます。

最後に得られた貸し倒れ確率の各平均値を年収入に対してプロットすることで、目的の年収入の部分依存が得られます。

このように手動で計算すると手間と時間のかかる部分依存の計算ですが、DataRobotでは、特徴量ごとの作用のボタンを押すとすべての入力特徴量に対して部分依存を自動的に計算してくれます。

部分依存って何の役に立つの？

部分依存は、貸し倒れ確率が年収入の部分にどのように依存するかを他の特徴量の影響を平均化することで取り除いくれたものと言えます。そのため、その特徴量が単独でどのように予測結果に影響しているかをこのグラフから知ることができます。また、部分依存はこの特徴量を単独で変更した場合の効果と解釈することができ、例えば材料の開発における添加剤の効果やマーケティングにおけるターゲット層別の違いなどについて、単独の効果を把握して次のアクションに繋げることができるという点で実務において大変有用です。

実際に導出してみるとよくわかるのですが、部分依存の計算はモデルの部分はモデルの種類に依ることなく同様に行うことができることが出来る点で優れています。モデルの中身を詳しく知ることができる特徴量ごとの作用について、部分依存も含めてこれまで以上にDataRobotをご活用頂ければと思います。

投稿 特徴量ごとの作用を使ってモデルの中身を解釈する は DataRobot に最初に表示されました。

今回は、そのリフトチャートを更にもう一段深く分析するための、デュアルリフトチャート（Dual Lift Chart）について解説します。またの名をダブルリフトチャート（Double Lift Chart）と呼びますが、いずれにしてもあまりオンライン上に文献がありません（検索するとシワ伸ばしの美容外科クリニックに）

リフトチャートおさらい

リフトチャートは、モデルの出力する予測値がどれくらいの判別能力や予知能力を有しているのか、また複数のモデルを比較した時に、どちらのモデルの精度が良いのかを素早く視覚的に捉えることができます。具体的には、予測値が大きいときに実際の結果が大きくなり、小さいときには結果も小さくなるという、予測値の有用性をシンプルな曲線で表してくれます。

一般的には実測の曲線の角度が急であるほどよく、予測の曲線と近く交差していることが理想的なモデルです。

デュアルリフトは、2つのモデルを比べるためのもの

リフトチャートでは、一つのモデルを一つの線で表すことができるため、複数のモデルを簡単に比べることができます。しかし、2つのモデルが似ているときには比較がしにくくなる問題が有ります。例えばこの2つのモデルを比べてみましょう

AUCでも0.68と0.69の違いしかなく、非常に近い2つのモデルのため、ここから多くを語ることはあまりできません。「2つのモデルは似ている」くらいの結論でしょう。

デュアルリフトの作り方

ここで下記の手順でデュアルリフトチャートの作成を行います

1. 2つのモデルによって計算された予測値A（白い線のモデル）とB（青い線のモデル）があったとき、A/Bの値を計算する
2. リフトチャートを作るときと同様に、A/Bの値で全体を並べ替え、各ビンに同じレコード数が入るよう等分する
3. A/Bの小さいビンから並べ、ビンごとに、予測値Aの平均、予測値Bの平均及び実測値の平均を計算する

そうして完成したのがこのデュアルリフトチャートです。

チャートの真ん中付近においては2つのモデルの予測値がほぼ同じであるため、2つのモデルの曲線が交差します。左右の端においては、2つのモデルの予測結果の差が大きくなり、左側においては青のモデルのほうが高い予測値、右側では白のモデルが高い予測値を出しています。リフトチャートでは見えなかった2つのモデルの違いがよりはっきり見えます。そして、オレンジの線で表されているのが実測値です。

これにより、先程は見にくかった2つのモデルの違いを定量的に分析することができます。例えば、2つのモデルが一番ずれている右のビンにおいては、予測値が40%ほど（0.28と0.2）ずれていて、白い線のモデルのほうが実測に圧倒的に近いなどです。

新旧モデルの比較による、さらなるインサイト

デュアルリフトと、2つのリフチャートの比較との違いは、両方のモデルの結果を一つの指標で並び替えたため、各ビンにおいて計算される3つの値はすべて同じレコード群から計算されています。今回のデータでは、貸し倒れを予測していますが、例えば青い線のモデルが過去に使われていたモデル、白い線はこれから導入を検討しているモデルだとしたときに、

• 過去のモデルにおいては、貸し倒れ率を50%も低く見積もっていた領域がある（右のビン）
  • この領域のローンに対しては損害が出ていたと考えられる
• 過去のモデルにおいては、貸し倒れ率を20％も高く見積もっていた領域がある（左のビン）
  • この領域のローンに対しては利率を高く設定しすぎていた可能性がある
• いずれの場合も新しいモデルのほうが実測値（ホールド・アウトデータでの）に近づいている

といった新しいインサイトを得ることができるのです。

以上、簡単でしたがデュアルリフトチャートの作り方と使い方でした。実際には2つのモデルを比べるだけならば、検定値のAUCで十分ということもあるかもしれないですが、素早く上記のようなインサイトを得ることができるのは時として分析のサイクルをスピードアップしてくれるでしょう。

投稿 デュアルリフトチャートとは は DataRobot に最初に表示されました。