DataRobot とは

DataRobotは、データ前処理からモデル構築、デプロイ、モデル運用までを自動化するエンタープライズ向けAIプラットフォームです。DataRobotは、多様なデータソースからデータを簡単に取り込み、さまざまな機械学習アルゴリズムを使用して、ビジネスニーズに合った高精度なモデルを迅速に構築します。さらに、モデルの稼働状況や精度・データドリフト・バイアスと公平性など様々な観点でモデルのパフォーマンスを監視し、持続可能なモデル運用を実現します。

Apache Airflow とは

Apache Airflowは、オープンソースのワークフローオーケストレーションツールです。データ取得、ETLジョブ、機械学習タスクなど、さまざまなタスクをスケジュールして実行するために使用できます。スケーラブルで信頼性の高いワークフローを構築するための強力なフレームワークを提供します。

Apache AirflowとDataRobotを連携するメリット

DataRobotとApache Airflowを連携するとMLOpsワークフローを強化できます。これにより次のようなメリットが享受できます。

メリット１：モデルトレーニングとデプロイの自動化

機械学習のビジネス利用ではモデルトレーニング、デプロイ、予測を定義したMLOpsワークフローが必要となるケースがあります。特に定期的にモデルを再トレーニングするケースや、頻繁にデータドリフトが起こりその都度再トレーニングが必要となるケースではMLOpsワークフローの構築は必須です。MLOpsワークフローを事前に作成することで、外部環境の変化に迅速に対応し、モデルの品質とパフォーマンスを維持できます。

DAG (Directed Acyclic Graph)構築

DataRobotとApache Airflowを連携することで、たとえば図1のようなMLOpsワークフローを構築できます。この例では、Apache Airflowを使用して、DataRobotのジョブ（モデルトレーニング、デプロイ、予測）をスケジュールして実行しています。

なおDataRobot単独でも再トレーニングの自動化機能があり、再トレーニングのスケジュール実行や異常時の実行が可能です。それに対し、DataRobotとApache Airflowを連携することのメリットは、データ取得、ETLジョブまで含めたパイプラインをより柔軟にカスタマイズできる点にあるといえます。

メリット２：MLOpsワークフローの可視化とデバッグ

図1のようにApache Airflowは、MLOpsワークフローの実行状況を可視化するための強力なダッシュボードを提供します。また、ワークフローの進行状況をリアルタイムに確認でき、問題が発生した場合にはログを解析できます（図2）。これにより、ワークフローを監視し、問題をデバッグします。

そして2020年7月からは、SHAP を用いた「特徴量のインパクト」および「予測の説明」が実装されました。この記事では SHAP の概念や計算原理、DataRobot での確認方法を解説するとともに、従来の Permutation Importance や XEMP との使い分けについて考察したいと思います。

メリット３：マルチクラウドへの対応

近年、企業におけるクラウド利用において、単一のクラウドベンダーに依存するのではなく、複数のクラウドサービスを組み合わせる「マルチクラウド」を採用するケースがあります。「マルチクラウド」には主に以下のようなメリットがあります。

• ベンダーロックインの回避
• 可用性の向上
• 柔軟性の向上

一方で、複数のクラウドに分散したデータやモデルを管理するためには、適切なガバナンス体制を構築したりスキル人材を獲得したりする必要があります。これは、特に大規模な組織においては大きな課題となります。

その課題に対して、Apache Airflowは各クラウドと接続することができるため、データが複数のクラウドに分散していてもワークフローを構築できます。

これはApache Airflowを利用すればデータのサイロ化を解決できると言っているわけではありません。マルチクラウド環境でも、機械学習に用いるデータは1つのデータウェアハウスやデータレイクに集約することがマルチクラウドの複雑さを解決する直接的な方法です。

1つのデータウェアハウスやデータレイクにデータを集約しておけば、データの管理コストを減らせるだけでなくチーム内外でのコラボレーションが加速するからです。

Apache AirflowとDataRobotを連携する方法

DataRobotとApache Airflowを連携するには、次の手順を実行します。詳細はApache Airflow用のDataRobot プロバイダーをご覧ください。

• Apache AirflowとDataRobotを連携する際の前提条件

DataRobotプロバイダーを使用するには、以下の依存関係をインストールした環境が必要です。

• Apache AirflowとDataRobotの連携手順

　（手順1） DataRobot APIキーを取得し、Apache Airflow上で接続設定を行います（図3）。

　（手順2）Apache Airflow環境にDataRobotプロバイダーをインストールします。Apache Airflow DAGページにインストールしたDataRobotプロバイダーが表示されます（図4）。

Apache Airflow用のDataRobotプロバイダーは、公開されているGitHubレポジトリからダウンロードできます。

DataRobotプロバイダーのモジュールには、DataRobot MLパイプラインのステップを自動化する複数のDataRobotオペレータとセンサーがあります。以下に代表的なオペレーターやセンサーを示します。各オペレータは特定のジョブを実行し、各センサーは事前に設定された動作が完了するのを待ちます。

オペレータ

• CreateProjectOperator: DataRobotプロジェクトを作成し、そのIDを返します。
• TrainModelsOperator: DataRobotのオートパイロットを実行し、モデルをトレーニングします。
• DeployModelOperator: 特定のモデルをデプロイし、デプロイIDを返します。
• DeployRecommendedModelOperator: 推奨モデルをデプロイし、デプロイIDを返します。
• ScorePredictionsOperator: デプロイしたモデルに対して予測を行い、バッチ予測ジョブ ID を返します。

センサー

• AutopilotCompleteSensor: Autopilotが完了したかどうかをチェックします。
• ScoringCompleteSensor: バッチスコアリングが完了したかどうかをチェックします。

　（手順3）Apache Airflow DAGを用いて、DataRobotジョブをスケジュールします。

Apache AirflowとDataRobotの連携でMLOpsワークフロー強化を実現

DataRobotとApache Airflowを連携することで、機械学習パイプラインを自動化しMLOpsワークフローを強化できます。これにより、データからより多くの価値を引き出すことができます。ぜひ、DataRobotとApache Airflowの組み合わせでMLOpsの可能性を広げてください。

機械学習プロジェクトの効率化を図るなら「DataRobot」

DataRobotでは、トライアル環境を提供しています。以下のURLから、アカウントを作成することができます。

https://www.datarobot.com/jp/trial/

トライアル環境では、DataRobotの主要な機能を使用することができます。機械学習モデルの開発や運用に興味がある方やすでに携わっている方も、ぜひこの機会にDataRobotを体験してみてください。

投稿 Apache AirflowとDataRobotを連携してMLOpsワークフローを強化する方法 は DataRobot に最初に表示されました。

AIプラットフォームでは機微なデータを扱うこともあるため、使いやすさとセキュリティのバランスは重要です。DataRobotではマネージドサービス(いわゆる「クラウド版」)とセルフマネージド型(いわゆる「オンプレミス版」)に加え、近年では専有環境のマネージドサービスであるシングルテナント版も提供しており、セキュリティ要件に応じて選ぶことができます。
[参考] DataRobot AI Platform のデプロイインフラストラクチャ

セルフマネージド型(「オンプレミス版」)をお使いで、なかなかバージョンアップの時間が取れない！という場合、二世代前のバージョン8(あるいはそれ以前)を使っているユーザーの方もいらっしゃるのではないでしょうか。

このブログではそうしたユーザーの方向けに最新世代のDataRobotをご紹介します。

「自分が使っているDataRobotのバージョンがわからない」という方は、ログイン画面などで確認することができます：

なおマネージドサービス(「クラウド版」)にはこうしたバージョン番号はなく、ほぼ毎週アップデートされています。

DataRobot AI Platform バージョン9、そして10へ

DataRobotバージョン9は2023年3月にリリースされました。AutoMLの「ツール」から、組織のAIニーズをトータルで支える「プラットフォーム」へと進化すべく、機能の大幅な拡充に加え製品アーキテクチャも大きく進化しました。バージョン10は2024年4月にリリースされ、生成AI関連開発機能のほか、それを支えるGPU対応、エコシステム連携の深化など、最新の変化を取り入れています。

[参考] バージョン10.0.xリリースノート

DataRobotの生成AIと予測AI

DataRobotは2012年の創業以来、機械学習の自動化を通じた予測型AIの開発、運用プラットフォームのリーダーであり続けていますが、近年では生成AIを利用したモデルの開発・運用機能も統合し、単一プラットフォームで生成AIと予測AIの両方に対応することができるようになっています。

[参考] RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術

コーディングベースの開発と運用

DataRobotは従来から、マウス操作だけで数多くの予測モデルを自動開発できる使いやすいGUIを提供してきました。しかしDataRobotの操作自体やDataRobot以外のエコシステムとの連携をAPIを使ってもっと自動化したい、といったニーズも高まっていました。そこでDataRobotにはノートブック機能が追加され、コーディングを通じた自動化ニーズにも対応できるプラットフォームとなっています。またDataRobot外でコーディングベースで開発されたモデル(カスタムモデル)の運用管理にも対応しています。

[参考] DataRobot Notebooks, デプロイ用のカスタムモデルの準備

新世代のUI

このように「生成AIと予測AI」、「GUI操作とコーディング」といった新たなAI開発・運用ニーズに対応するため、UIも一新されました。

これまでのUIは個人作業、1つのデータ、1つのプロジェクト(予測AI)を中心に設計されたものでしたが、新世代のUI「NextGen」では、チーム作業を通じたより大規模な開発、複数のデータやモデリング設定を使った試行錯誤の一元管理、生成AI開発と予測AI開発の統合、GUI開発とコーディングの統合、などを実現しています。

[参考] NextGenエクスペリエンス

モデルガバナンス

DataRobotはモデルの開発プラットフォームであるだけでなく、モデル運用プラットフォームでもあります。デプロイ、モニタリング、チャレンジャーモデルの分析、再トレーニングとモデル置換、といったライフサイクル管理のほか、DataRobot以外で開発したカスタムモデルの運用や、外部予測環境にホストされているモデルのリモート監視にも対応しています。カスタムモデルの開発自体はDataRobotのノートブック機能でも可能です。加えて生成AIの文脈では、ガードモデルを簡単に利用できるようにするなど、モデルガバナンスに力を入れています。

エコシステムインテグレーション

学習・予測データはどこに保存されていますか？SnowflakeやDatabricks、あるいはAWS、Azure、GCPなどのデータウェアハウスやデータレイクをご活用でしょうか？また、AWSやAzure、GCPにモデルをデプロイしていますか？DataRobotはこうしたデータやAIに関するクラウドのプレイヤーとの連携を深めており、データ準備やモデルデプロイ、運用などをシームレスに行えるようになっています。

(例：Snowflake連携の概要)

新しい利用形態 – 専有型のマネージドサービス

冒頭にも述べた通り、DataRobotはマネージドサービス(「クラウド」)とセルフマネージド型(「オンプレミス」)の両方を提供しており、今この記事をお読みの方はセキュリティ上の理由から自社の専用ネットワークにインストールできるセルフマネージド型をお使いなのではないでしょうか。

しかしセキュリティを確保したいからといって、必ずしもすべて自社で管理したいとは限りません。運用管理にはコストと時間がかかり、バージョンアップを通じて新機能を利用可能になるサイクルもどうしても遅くなりがちです。

DataRobotでは新しい利用形態として「DataRobotシングルテナント」という専有型のマネージドサービスを展開しています。お客様はプライベートなネットワークに自社専用のDataRobot環境を持つというセキュリティ上の特徴を維持しつつ、マネージドサービスによりインフラの運用管理から完全に解放されることができ、新機能もタイムリーに利用することができるようになります。

DataRobotシングルテナントの詳細については当社または各代理店様までお問い合わせください。

新アーキテクチャ – 進化し続けるAIワークロードをコスト効率よく実行

自社固有のDataRobot構成が必要、といった場合は引き続きDataRobotのセルフマネージド型を使い自社管理で運用することができます。この時やはり気になるのは運用に伴うコストでしょう。

AIは一般に計算量の大きいワークロードであるため、AI製品の進化にともないコンピュートリソースの使用量は増していきます。これは、従量課金が一般的であるクラウドサービス(AWS、Azure、GCPなど)でワークロードを実行する際には特に気をつけるべき点です。

DataRobotは2012年の創業時点でコンテナを利用したマイクロサービスアークテクチャを採用した先進的なプラットフォームでしたが、進化し続けるAIワークロードを支える上で限界を迎えていました。コンテナの動的配置にまでは対応しておらず、また使いたい機能を支えるための最大限のコンピュートリソースを起動し続けておく必要があったのです。コスト削減のために、特定の機能の使用をあきらめて構成を意図的に小さくしているケースもありました。

バージョン8.xまでのアーキテクチャーの主な課題

そこでDataRobotはバージョン9からアーキテクチャを変更し、 Kubernetesアプリケーション化されました。Kubernetesはコンテナの自動オーケストレーションのフレームワークです。これによりすべてのコンテナをどのサーバーにでも動的配置できるようになってコスト効率が上がり、さらにオートスケール機能を活用してワークロードに応じたスケールアップ、スケールダウンを自動化できるようになりました。「AI機能を使わなくてもコンピュートにコストがかかる」アーキテクチャから「AI機能を使ったぶんのみコンピュートリソースを使う」アーキテクチャになったのです。

Kubernetesアプリケーション化によるリソース自動制御

新アーキテクチャによるコスト最適化により、新たに利用が可能になったり、利用しやすくなった機能をいくつかご紹介します。

GPU利用の拡大

機械学習モデルにおけるディープラーニングアルゴリズムの活用のほか、生成AIの文脈ではGPUの利用がますます欠かせないものとなっています。DataRobotではGPUを利用して生成AI関連機能を加速しているほか、NVIDIA社との協業によりLLMのローカルホスティング、ガードレールモデルの利用など、生成AIを企業で本格的に利用するための能力を拡大しています(参考：DataRobot Spring ‘24 Launch Event)。DataRobotの新アーキテクチャは、プレミアムなハードウェアであるGPUをコスト効率よく利用することを可能にしています。

カスタムモデルの運用管理

DataRobotでは、カスタムPython環境で開発したモデルや他社製品で開発したモデルをデプロイし運用管理することも可能です。これにより開発環境に関わらずモデル運用の統合的なビューを持つことができます。これはインフラ観点ではモデルごとにランタイム環境とそれを動かすコンピュートリソースを用意することを意味します。

カスタムアプリケーション(ノーコード、ローコード)

DataRobotでは生成AIや予測AIを利用したアプリケーションを実行することもでき、GUI操作だけで利用可能なノーコードアプリや、Streamlitなどのローコードフレームワークを使ってモデルを利用するインターフェースをユーザーに提供できます。このような機能にも一時的なコンピュートリソースが必要であり、新世代のDataRobotではこうしたAI用アプリケーションを簡単にかつコスト効率よく提供することができます。

DataRobot Notebooks

ノートブック機能は、そのインスタンスごとに一時的なコンピュートリソースを必要とします。こうした機能は、動的なリソース割り当てができるインフラなしには極めてコストが高いものになります。バージョン9以降のアーキテクチャでは、DataRobot内でノートブック/コーディングのニーズにも応えつつ、そのリソース使用を最適化することができます。

学習に利用可能なデータサイズ

モデルの学習に大きなデータを使おうとするほど、それに対応したメモリを確保するためより大きなコンピュートインスタンスが必要になります。バージョン8までのアーキテクチャでもモデル作成用のコンテナ、ノードはオートスケールの構成が可能でしたが、それを選択しない場合は小さいインスタンスを選択してコスト削減するかわりに利用可能なデータサイズを制限(5GBなど)するケースがありました。

バージョン9以降ではこうしたことを検討する必要はなく、各DataRobot環境で利用可能な最大サイズを利用することができるようになります。

おわりに：DataRobot AI Platformとそれを支えるアーキテクチャ

DataRobotは「AutoMLツール」から「AIプラットフォーム」へと進化しました。つまり、生成AIと予測AI、GUI操作とコーディング、モデル開発とモデル運用、など組織のAIニーズをトータルで提供する共通基盤となっています。モデル開発をカスタムPythonコードや他社のMLツールで行っていたとしても、DataRobotはそれらと連携し、モデル運用などその先のニーズを幅広くカバーしていきます。

そして、そのようなプラットフォーム機能を実際にコスト効率よく実現するためのアーキテクチャを導入し、継続的に革新しています。これからの発展にもどうぞご注目ください。

5/15(水) 15:00〜開催！【オンプレミス版ご利用の方必見】DataRobot 最新バージョンで実現する生成AIほか最新機能とそれを支える新たなアーキテクチャ

本ウェビナーではDataRobotセルフマネージド版(“オンプレミス版”)をご利用中のユーザー様、運用管理している管理者様向けに、DataRobot最新バージョンのv9、そして発表されたばかりのv10のハイライトをご紹介するとともに、GPUなどを含む多様なAIニーズをコスト効率よく実行できる新たなアーキテクチャや、新しい利用形態である専有型のマネージドサービスなどを解説します。

参考

バージョン10.0.xリリースノート

RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術

DataRobot Notebooks

デプロイ用のカスタムモデルの準備

NextGenエクスペリエンス

DataRobot Spring ‘24 Launch Event

投稿 DataRobot 最新バージョンで実現する生成AIほか最新機能とそれを支える新たなアーキテクチャ は DataRobot に最初に表示されました。

今回は数ある機械学習のモデル精度の評価指標の中でも私のお気に入りであるにも関わらず前回の最適化指標ブログでは取り扱うことができなかったFVE  Binominalについて紹介したいと思います。分類モデルの精度を単一の指標で測る上ではトータルバランスで現時点最強の評価指標だと考えています。これまで分類問題ではとりあえずAUCを使っていた人もこのブログをきっかけにFVE  Binominalを利用いただければ幸いです。

機械学習モデル評価指標の重要性

機械学習モデルを構築する際にはモデルをどのようにフィッティングさせるかを基準に最適化指標および損失関数を決めていきます。多くの場合、その最適化指標を最も小さくしたモデルを選択することによって一番精度の良いモデルを選ぶというアプローチを行います。ただ、コンペティションのように争う指標が決まっているのであれば、その指標を基に判断するだけですが（実際には共通の目的で争うため、コンペは全く違う血肉を争う戦いがあります）、実務で機械学習を行う場合にはどの評価軸でモデルを比較するかの決定を下すことも重要となります。

評価軸が決まった後には、精度が最終的に合格かを判定する上では、きちんとした検証基準を置く必要があります。ただし、厳密な検証は手間もかかるので、実務者はとりあえず作成したモデルが「大体どれくらい精度がいいものか」知りたいということは多々あります。二値分類問題においては、多くの方がAUCをこの用途で利用しているかと思います。「AUCが0.5であれば完全にランダムなモデルと変わらない。AUCが0.8を超えていたら相当いいモデルとなっている。0.9を超えると精度が良すぎるのでリーケージを疑いたい」こういった話を聞いてモデルの評価基準にしている方は少なくありません。ただAUCには向いていないケースもあり、その評価指標の本質を理解していないとよもやの事故に遭う可能性もあります。

機械学習モデル評価指標「AUC(Area Under the Curve)」とは

AUCはArea Under the Curveを略したもので、一般的にはROC（Receiver  Operating Characteristic）曲線の下の面積（別のパターンとしてPR曲線の下の面積をとったものも存在しますが、本ブログではROC-AUCを以降AUCとして表記します）を表したものとなっています。

AUC(Area Under the Curve)の性質

ROC曲線はy軸をリコール、x軸を偽陽性率（フォールアウト）としたときに、モデルが取れる組み合わせをプロットしたときに描かれる曲線となっています。AUCの定義から完璧なモデルの場合にはリコールが1で偽陽性率が0となり、面積は1×1=1となります。逆にランダムなモデルを作るとROC曲線はリコール、偽陽性率（0,0）とリコール、偽陽性率（1,1）を結ぶ直線となり、AUCは三角形の面積の通り、1x1x0.5=0.5となります。この性質からAUCはプロジェクトが違ってもモデル精度をざっくりと比較でき、多くのプロジェクトにおいてモデルの精度を簡易的に測る上で頻繁に利用される指標となっています。ちなみに金融業界の与信モデルの評価指標としてよく使用されるAR値は2AUC-1と同義のため、AR値もAUCと同じ性質を持っています。

機械学習モデル評価指標「AUC(Area Under the Curve)」の欠点

では、機械学習モデル評価指標であるAUCの欠点について解説します。

AUCはリコールと偽陽性率（１）のみを見ていることから、結果として予測値順に並べた時の精度だけを見ていることになり、予測値と実測値の乖離をみていません。そしてターゲット比率が0.1%を切るようなプロジェクトにおいては、AUCが簡単に0.8を超えるなど高くなる傾向があります。AUCが高いのに実際に運用すると、思った以上にパフォーマンスが出ない（ビジネス指標における効果が出ない）ということがあります。

AUC(Area Under the Curve)活用時の失敗事例 

AUCが予測の順位しか見ないという特性を知らずに使用すると、思わぬ事故に遭遇する可能性があります。例えば、「正例が少ないためダウンサンプリングしたデータセットでモデリングを行い、高いAUCが得られた。しかし、本番での運用では予測値と実際の値に大きな乖離が生じた。予測の乖離があるにもかかわらず、AUCは悪化していなかったため、問題に気付くのに時間がかかった」という事例が挙げられます。

AUC(Area Under the Curve)失敗事例の検証

このような現象は簡単に試せるため、元のデータにダウンサンプリングを施し、AUCスコアの変化を観察してみましょう。

AUCがホールドアウトでも変化しないのがわかるかと思います。 ここで予測値と実測値の乖離も見れるリフトチャートを同じモデルで見て行きましょう。

学習データ（交差検定）では予測の青のラインと実測のオレンジのラインがうまくフィットしているのが分かります。ただ、ホールドアウトでは、予測の青のラインは正しく右肩上がりになっていることから傾向は捉えているように見えますが、予測値が大きく乖離しています。AUCはホールドアウトでも下がっていませんでしたが、これはAUCが順列を見ているという性質から説明でき、実はリフトチャートでも右肩上がりになっていたことからこのモデルは順列としては正しいものでした。

予測値は大幅に乖離しても順列だけはあっていれば問題ないAUCは、マーケティングのターゲティング分析のように上位1万件にDMを送付するという予測値そのものに注目しない分析では問題ありません。ただ、一件当たりのDMのコストを考えて予測CV率がx以上に送りたいなどを考えている、予測値に対して金利を設定するなどの場合には、全く役に立たないモデルになっているリスクを内包しています。

※ちなみにDataRobot内で実施するスマートダウンサンプリングは名前にスマートがついているように、ダウンサンプリングした比率のウェイトを入れることによって、上記の事象が発生するのを防ぐ仕組みが実装されております。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」とは

AUCの欠点についてここまで記載していきましたが、ここからはFVE  Binominalについて紹介していきます。

「FVE (Fraction of variance) Binominal」の特徴

以前のブログでも二値分類においては最適化指標はLoglossが最強と書かせていただきましたが、評価指標で使う上ではターゲットの比率によって値が変わることからモデルのざっくりとした当てはまりの良さを考える上では不向きでした。Loglossが1を下回っているから必ずしも当てはまりの良いモデルができたとは限りません。このLoglossの評価関数としての欠点を解消したのがFVE  Binominalとなります。

「FVE (Fraction of variance) Binominal」考え方と機械学習モデル指標として優れている点

FVE Binominalは以下の式で表現することができます。

FVE Binominal = 1 – Logloss(Model X)/Logloss(Majority Class Classifier)

考え方はシンプルで、ひたすらターゲットのクラス比率に合わせて予測値を出すモデル(Majority Class Classifier)と比較してどれだけそのモデルが改善できているかを表現しています。FVEは説明されたdeviance（尤離度）の割合と考えることができます。

仮に作成したモデルが単純にターゲット比率に合わせた予測値を出すだけのモデルと同様であれば、Logloss(Model X)/Logloss(Majority Class Classifier) = 1となり、FVE  Binominalは0となります。仮に完璧なモデルができた場合には、Loglossは0となるため、FVE  Binominalは1となります。よくAUCで完全ランダムなら0.5で完璧なモデルなら1という表現がありますが、FVE  Binominalでも同じようにランダムなら0で完璧なら1と考えることができます。また、Loglossをベースにすることによって、より予測値の期待値的にうまくいっているのかという部分にフォーカスした評価指標となっていますので、順列だけでなく予測値そのものにも注目するケース（貸し倒れ確率と合わせて金利テーブルを作成する場合など）ではとても有用な指標となります。

先ほどAUCではホールドアウトでも交差検定と比較してそこまで値の変化がしなかったものをFVE Binominalでみていくとホールドアウト部分がマイナス(-0.4361)になっているのが確認できます。ここから予測値と実測値がランダム以上に大きな乖離を持っていることがわかります。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」の精度

AUCだとみなさまの感覚として、0.75超えてきたならいいモデルで0.9超えたら怪しいという感覚（ここまでのブログからこの感覚が危険だということを理解した人も多いかと思いますが）を聞いたことがある人もいると思いますが、DataRobotのグローバルのデータサイエンティストの中で、FVE Binominalは以下のような基準で使われています。

———

プロジェクトが終了したら、最適なモデルをFVE Binomialで見てみましょう。

– FVE Binominal が0に近い＝機械学習には不向きなユースケース

– FVE Binominal > 0.25 = 良いユースケース

– FVE Binominal が1に近い = ターゲットリーケージを疑うべき状態

———

これは、DataRobotのグローバルで活躍するデータサイエンティストの経験則ですが、FVE Binominalが0.15など0から0.25の間の時はいくつかの解釈ができ、まだモデルの説明力をあげられる段階であり、チューニングやデータを追加すれば精度をあげられる可能性もありますし、ランダムよりは良いので、用途によっては問題ない精度ということもありえます。あくまでFVE Binominalもざっくりと当てはまり具合を見るものであって、犬と猫の分類のように簡単な問題であれば1に近づきますし、金融市場分析などで0.1を超えることも難しいということは覚えておいてください。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」の注意点

FVE Binominalの注意点をいくつかあげるとすると算出ロジックのベースがLoglossのため、Loglossと同じように誤ラベルの影響を大きく受けます。実際にはTrueのものがFalseとなっていた時にモデルが99%Trueと予測できていたにも関わらずデータ上はFalseのためLoglossが大きくなります。そのため、誤ラベルがある程度紛れてしまうような分析では、過小にモデルが評価される可能性があることには注意が必要です。またAUCでは順列を見ていて、FVE Binominalではスコアを見ているという性質からですが、仮にモデルの活用が予測値の上位x件を抽出した上でアクションを実行するという順列のみを見るケースではAUCを利用する場合もあります。FVE Binominalでは上位x件に含まれないデータに対するスコアのつき方も評価しているので、ビジネスアクションと関係ない部分が評価に含まれているためです。そして1番の欠点が知名度だと思います。このFVE Binominalは知名度がまだまだ低いため、初見の人には通じない可能性があります。ただAUC 0.8というのがデータサイエンティスト以外に正しく伝わるかというとそこに疑問は残りますので、みなさんがFVE Binominalの良さを広めて知名度拡充に努めていただけると助かります。

別のFVEシリーズ

今回、分類問題の鉄板損失関数Loglossを正規化したFVE Binominalを紹介させていただきましたが、連続値問題（回帰問題）においてはよいモデルを作るにはターゲット分布によって損失関数を選択する必要があります。そして損失関数でpoissonやganmaやtweedieを選んだ際にはLoglossと同じようにモデルの当てはまり具合がわからず、結局リフトチャートや残差チャートを見て視覚的に判断する必要があった経験をされた方も多いかと思います。実はFVEの考えは、poissonやganmaやtweedieにも応用でき、DataRobotではそれぞれFVE poisson、FVE ganma、FVE tweedieとして評価指標が用意されています。定義はいずれも、

1 – (error / baseline model error)となり、0だとベースラインモデルと同じで1だと完璧なモデルを意味します。0.25を超えれば良いモデルという感覚もそのまま利用できます。連続値問題ではR^2を利用する方が多いかと思いますが、FVEはR^2と非常に似た性質を持っています。ただ、logリンク関数を利用したモデル（DataRobotでは最適化指標にpoissonやganmaやtweedieが選択された際のモデル）にも対応できる点でも便利な評価指標となっています。

AUCより優れた機械学習モデル評価指標「FVE (Fraction of variance) Binominal」を有効活用するコツ

予測値へのアクションにおいて、予測確率が重要なウェイトを占めるテーマにおいては、ARスコアやAUCよりもはるかに有用なFVE Binominalをぜひ有効活用してみてください。

慣れてくるとFVE Binominalで大体の予測分布の形が想像できるようになり、AUCよりも鮮明にモデルの当てはまり度を単一の数字で想像できるようになります。またモデル運用において、AUCは変わってないが、FVE Binominalが悪化しているというケースに当たった際には、それぞれの性質を加味し、ターゲットの比率が変わっている可能性があるという部分に気づくきっかけにもなります。

出典

（１）The Relationship Between Precision-Recall and ROC Curves（Jesse Davis/Mark Goadrich）

投稿 分類プロジェクトの評価でAUCよりも便利なFVE Binominal｜DataRobot機械学習モデル評価指標解説 は DataRobot に最初に表示されました。

DataRobotで製造業/ヘルスケア業界のお客様を担当しているデータサイエンティストの長野です。技術的には生成AI領域を担当し、日本市場での生成AIプロダクトの導入と顧客支援を担当しています。

本記事では、生成AIの中でも特に注目を集めている技術領域の一つである「RAG（Retrieval-Augmented Generation）」に焦点を当てつつ、DataRobotで実現できる内容について解説させていただきます。

なお、本記事と関連するウェビナー「生成AI最前線：DataRobotを用いた実践RAG構築」では、実際のデモンストレーションを交えながらRAGに関して解説していますので、合わせてご確認いただければ幸いです。

LLMの活用パターンとRAG(Retrieval-Augumented Generation)の立ち位置

RAGについて踏み込む前に、ビジネスにおける大規模言語モデル（Large Language Model、以下LLM）の活用パターンを整理すると、大きく以下の3つに分けることができます。

活用パターン1. 事前学習済みLLM

このパターンでは、ChatGPTなどの既存の生成AIサービスやGPT3.5などのLLMをそのまま利用することを指します。導入コストが低いことがメリットとして挙げられます。執筆時点で多くの企業ではこのパターンでのLLM活用は進んでいると感じます。

活用パターン2. 検索拡張型LLM

検索拡張型LLMは、ユーザーからの入力に対して関連する情報を元に検索し、その結果をもとに回答を生成します。本記事の題材であるRAGがこのパターンに該当します。執筆時点でOpenAI社のgpt-4-turbo-previewは2023年12月、gpt-3.5 turboは2021年9月までの学習であり、最新の情報や社内文書も学習していません。そのため検索拡張型LLMが、社内文書や最新の情報を踏まえたLLMを構築する手法として注目を集めています。

活用パターン3. 追加学習/自作LLM

最後に、独自のニーズに合わせてLLMを追加学習させたり、オリジナルのLLMを開発するアプローチがあります。個々のユースケースに柔軟に対応させたLLMの開発ができる一方で、多くの企業にとってはまだまだ技術的ハードルの高い手段です。

この3パターンの中で、RAGが導入コストとユースケースとのマッチ度の観点で多くのユーザーが取り組まれている技術となります。

RAG(Retrieval-Augumented Generation)の課題

前章で解説したようにRAGの構築は比較的簡単に導入できる手法であると認識されていますが、弊社が実際にRAG開発に取り組まれている企業にヒアリングすると成果が出ていないケースも見受けられます。以下はその理由をまとめたものです。

課題1: テーマに対して技術的な課題を適切に捉えられていなかった

• 社内の文章を入れたら簡単にRAGが構築できると考え、あまり調査せずに中身がブラックボックスなツールを選定してしまう。
• Pythonライブラリを用いたRAG開発を試みるが、開発できるメンバーの不足や運用監視に苦労している。

課題2: RAGを構築できる人材が少なくスケールしない

• ユースケース毎に多くのRAGを開発する必要があるが、RAGの開発と運用監視の観点でプロジェクトが進んでいない。

課題3: 本番環境を想定した検証ができていなかった

• PoCを実施した結果、良さそうな結果は得られたが、本番導入を想定したハルシネーション対策や運用時の死活監視や精度監視までは確認できていない。

DataRobot生成AI機能を使うメリット

それでは、DataRobotの生成AI機能がこの問題に対してどのようにアプローチしているのかを以下の3つの視点からご紹介します。

DataRobot生成AI機能のメリット 1: RAGの開発

まず初めに、RAGが開発できないことには始まりません。DataRobotでは迅速なRAGの開発を実現できますが、この開発パートに関しては、後ほど詳しく解説します。

DataRobot生成AI機能のメリット2: API化/Webアプリ化

AIモデルを使って予測分析を行うユースケースでは予測結果のインサイトの取得も価値に繋がることが多く、実際に筆者が担当している製造業のお客様では要因分析のテーマでDataRobotをご活用されているケースも多くあります。要因分析のテーマでDataRobotをご活用されているお客様が非常に多くいます。一方で、生成AIのテーマでは、想定していた回答を返すだけではなく、実際にシステムへの組み込みやアプリケーションの開発まで求められるケースが非常に多いです。DataRobotではAPIによるシステム連携やStreamlitのDataRobotへのホスティング機能が充実しており、生成AI特有の課題に対しても十分にカバーできます。

DataRobot生成AI機能のメリット3: 運用監視とガードレール

予測AI/生成AIを問わず、あらゆるAIモデルはそのモデルを構築した時点から時間が経過すると精度パフォーマンスが劣化します。したがって、RAGを構築し生成AI機能を利用したアプリケーションを稼働させる際には、その精度パフォーマンスをはじめとする様々な品質指標を監視する仕組みも併せて稼働させることが必須です（予測AIモデルの運用を監視する仕組みはMLOpsと呼ばれていますが、生成AIシステムではLLMOpsと呼ばれています）。特に生成AIシステムでは、消費トークン数をトラッキングする、毒性のある単語/文章をガードレールにより弾くなど、様々な品質指標を設定してパフォーマンスを監視しながら、入力プロンプトの単位で適宜アクションをとる必要があります。DataRobotはこれらの要件に答えることができるAIライフサイクル・マネジメントプラットフォームです。

DataRobotを用いたRAG(Retrieval-Augumented Generation)構築

それでは、実際にDataRobotの画面を用いてRAGを構築してみます。NextGenインターフェイスでは予測AIと生成AIを同一のインターフェースから開発することができます。本ケースのようにRAGを構築する際は「データ」、「ベクターデータベース」、「プレイグラウンド」のタブを活用します。

データタブ：データの投入

RAGを構築する際に必要となるデータを投入します。2023年3月現在はtxtファイルとPDFファイルに対応しており、これらのファイルをZIPファイルにまとめて投入します。今回は、GPT3.5をそのまま使うと回答できないDataRobotの製品マニュアルをアップロードしてみました。

ベクターデータベースの構築

次にベクターデータベースを構築します。ベクターデータベースと聞くと構築が非常に困難に感じるかもしれませんが、DataRobotでは一つの画面上で簡単に設定することができます。主要なオプションを以下で解説します。

①埋め込みモデル

RAGに使用するデータを選択した後、「埋め込みモデル」タブをクリックし、今回使用する埋め込み（Embedding）モデルを選択します。Embeddingとは、後述するチャンクをベクトル情報に変換するモデルのことを指します。執筆時点では日本語も含む多言語対応モデルであるinfloat/multilingual-e5-baseなど、5種類のEmbeddingモデルから自由に選択することができます。埋め込み（Embedding）モデルの選択は回答の精度や出力のレスポンスに影響しますので、RAG開発フェーズで様々なモデルを試せることが重要です。infloat/multilingual-e5-baseのケースではチャンクを768次元のベクトル情報に展開します。これがベクターデータベースと呼ばれる理由です。

②チャンキング

チャンキングはテキストを分割する方法を指しており、一つ一つの固まりをチャンクと呼びます。一つ一つのチャンクをどのように分割するかによって同じデータでも得られる情報が変わります。極端な例ですが、文章を文単位の小さなチャンクに分割すると文脈の情報が欠落してしまいますし、反対に長文を一つのチャンクにすると本当に取得したい情報が得られないリスクがあります。チャンクを区切った際に、前後の文章も含める度合いをチャンクオーバーラップのパラメータで制御します。値を小さくしすぎると文脈が途切れてしまうリスクがありますが、大きくしすぎると、ベクターデータベースの容量が大きくなり、レスポンスタイムに影響します。

プレイグラウンドによる検証

ベクターデータベースの構築が完了したら、RAG構築の最後にプレイグラウンドを用いた実験を行います。プレイグラウンドは名前の通り、試行錯誤が非常にしやすい検証環境となっています。ここでは設定可能な主要パラメータについて解説します。

①LLM

LLMでは、DataRobotにプリセットされている多様なLLMの中から、自由に選択することができます。現在、選択肢としてGPT-3.5系、GPT-4系、AmazonTitan、Google Bisonの6種類が用意されています。さらに、皆様の会社で独自に契約されているLLMを、この選択肢に追加することも可能です（Bring-Your-Own LLM、以下BYOLLM）。

セキュリティポリシーの観点から、社内契約のLLMのみを使用可能な場合でも、BYOLLMのみをプレイグラウンド環境で利用する設定により、柔軟に対応することができます。これにより、各社のセキュリティ要件を満たしつつ、LLMの性能や特性を比較検討し、最適なモデルを選択することが可能になります。

②システムプロンプト

システムプロンプトは、通常のプロンプトとは異なる機能であり、RAGやLLMに対して、特定の役割や振る舞いを設定することができます。これにより、APIコストの最適化やエンドユーザーのニーズに合った回答の生成が可能になります。

ビジネスシーンにおいて、システムプロンプトを効果的に活用することで、例えば以下のようなメリットが期待できます。

トークン数の節約：「100文字以内で回答してください」といったプロンプトを設定することで、回答の文字数を制限し、トークン数を抑えることができます。

エンドユーザーのニーズに合った回答の提供：「箇条書きで答えてください」などのプロンプトを用いることで、情報を簡潔にまとめ、読みやすく構造化された回答を生成できます。

③ベクターデータベースを選択

こちらのタブを使用することで、RAGに用いるベクターデータベースを選択することができます。構築済みのベクターデータベースを選択することで、LLMに対して追加の文脈情報を提供し、より正確で関連性の高い回答を生成することが可能になります。もちろん、ベクターデータベースを選択しない場合は、素のLLMやシステムプロンプトのみを付与したLLMとして検証することも可能です。

RAGは一見すると複雑な技術に思えるかもしれませんが、DataRobotを使えば、実際の構築のプロセスは非常にシンプルになります。必要なデータを用意し、ボタンを数回クリックするだけで簡単にRAG用のベクターデータベースを作成することができますので、専門的な知識がなくても、誰でも手軽にRAGを活用することが可能となります。

RAGの設定が完了したので、実際の性能を確認してみましょう。画面の左側にはRAG（GPT3.5-Turbo + ベクターデータベース）の結果が、右側にはGPT-3.5 Turboのみの結果が表示されています。この比較機能を使うことで、データベースの有無による回答の違いを簡単に確認することができます。

DataRobotでは、最大3種類のブループリントを同時に比較することが可能です。これにより、異なるLLMやデータベースの組み合わせによる性能の違いを一目で把握することができます。

今回、「オートパイロットについて教えてください」というプロンプトを使って、素のGPT-3.5とRAGとの性能を比較してみました。その結果、両者の回答には明確な違いが見られました。

素のGPT-3.5では、ベクターデータベースを使用していないため、一般的な「オートパイロット」の概念について説明しています。つまり、自動運転技術や航空機の自動操縦システムなど、辞書的な定義に基づいた回答が生成されています。一方、RAGを構築したケースでは、DataRobotの文脈に基づいた回答が得られました(オートパイロットモードはDataRobotのモデリングモードの一つです)。

この比較結果から、RAGがタスクに関連する情報を適切に取り込み、文脈に沿った回答を生成できることが確認できました。データベースの選択と構築が適切に行われれば、RAGはビジネスにおける様々な場面で、より正確で有用な情報を提供できる可能性があります。

更に、RAGの場合は回答の生成に使った引用文を確認することができます。狙いたいドキュメントが正しく引用されているかなど、この画面を見ながらチェックします。

発展：RAG(Retrieval-Augumented Generation)のチューニングTips

最後に発展トピックスとしてRAGのチューニングのTipsについてご紹介します。RAGはデータの前処理やチャンキング戦略、プロンプトエンジニアリングと様々な改善ポイントがあるため、最初はどこから手をつけて良いのか分からないかもしれません。RAGは引用文を取得するまでの「検索パート」と引用文に含まれる情報から回答を生成する「生成パート」に分けることができます。大きな方針として、ドキュメントで狙いたい文章が引用文にない場合は、「生成パート」をいくら工夫しても精度を改善することは難しいので、まずは「検索パート」の工夫から考えてみるのが良いと思います。

「生成AI最前線：DataRobotを用いた実践RAG構築」Webinar無料視聴のご案内

本記事では、近年注目を集めているRetrieval-Augmented Generation（RAG）について、その基礎知識から実践的な活用方法までをDataRobotの生成AI機能にも触れながら包括的に解説いたしました。本記事が、RAGに関する理解を深め、皆様の生成AIプロジェクトの推進にお役立ていただければ幸いです。本記事と関連するウェビナー「生成AI最前線：DataRobotを用いた実践RAG構築」では、実際のデモンストレーションを交えながらRAGに関して解説しています。

投稿 RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術 は DataRobot に最初に表示されました。

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を使用して、機械学習の実験からアーティファクトを作成し、共同作業に必要な作業量を減らす方法
  • 利点：エラーを回避し、手動の作業量を減らすための実験の自動化が可能

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

4/26（金）15:00〜開催！DataRobot x Papermill x MLflowで機械学習プロジェクトを加速
本ウェビナーでは、DataRobot、Papermill、MLflowを組み合わせて使用することで、機械学習の効率化とログ管理を両立させる方法についてご紹介します。さらに、AIアクセラレーターが提供するサンプルコードを使って、実際のシナリオを通じてこれらのツールの活用方法を詳しくご紹介します。

投稿 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.analyze_and_model(
    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 に最初に表示されました。