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 に最初に表示されました。

ほとんどの企業は、最初に取り組むユースケースが予想以上に難しいことに気づきます。そして、疑問は山積みになっていきます。

ムーンショットプロジェクト（ハイリスク・ハイリターンのプロジェクト）を目指すべきか、それとも小さくとも着実に価値を創出できるように務めるべきか、あるいはその両方をミックスすべきか？どのように規模を拡大するのか？次に何をすべきなのか？悩みはつきないでしょう。

ChatGPTを筆頭とするGenerative modelsは、AIが活躍できるシチュエーションを完全に変え、組織にまったく新しい問いを投げかけました。予測AIから得られた価値を作るためのノウハウのうち、どのノウハウを生成AIに適用すればよいのでしょうか？

予測AIで価値を得るためにやるべきこと

予測AIから価値を生み出す企業は、最初のユースケースを積極的に提供する傾向があります。

彼らが実践している取り組むべきポイントは以下の通りです。 

・適切なプロジェクトを選択し、それらのプロジェクトを総合的に評価する

プロジェクトの技術的実現可能性に多くの時間を費やすという罠に陥りがちだが、成功しているチームは、組織の複数のレベルから適切なスポンサーシップと賛同を得ることも考えています。

・適切なステークホルダーをプロジェクトの早期から参加させる

最も成功しているチームは、結果に投資し、さらなるAIプロジェクトを依頼するビジネスユーザーを関係しています。

・成功の炎をあおる

プロジェクトの成功を祝い、鼓舞し、惰性を克服し、緊急性を生み出すことが大事です。ここでも、エグゼクティブ・スポンサーシップが大いに役立ちます。次なる野心的なプロジェクトの基盤を築くことに貢献します。

そして、私たちがお客様からよく言われる「やってはいけないこと」は以下の通りです。 

・最も困難で最も価値の高い問題から始めること

多くのリスクが生じるため、その問題から着手しないことをお勧めしています。

・データが完璧になるまでモデリングを延期すること

この考え方は、不必要に価値創出を先送りすることになりかねません。

・組織設計、オペレーティング・モデル、戦略を完璧にすることに集中すること

これによって、AIプロジェクトをスケールさせることが非常に困難になります。

生成AIの新たな技術的課題とは？

・計算要件の増加

生成AIのモデルを学習・実行するには、高性能の計算とハードウェアが必要になります。企業はこのハードウェアを所有するか、クラウドを利用する必要があります。

・モデルの評価

本来、生成AIモデルは新しいコンテンツを生み出します。予測モデルは、精度やAUCのような非常に明確な指標を使用します。生成AIでは、より主観的で複雑な評価指標が必要となり、実装が難しくなります。

人間が出力結果を評価するのではなく、体系的に評価することは、これらのモデルすべてに適用する公正な評価基準を決定することを意味しており、それは予測モデルを評価することに比べて難しい作業です。生成AIモデルを使い始めるのは簡単かもしれませんが、意味のある優れたモデルを生成させるのは難しいでしょう。

・倫理的なAI

企業は、生成AIのアウトプットが、成熟し、責任あるものであり、社会や組織にとって有害でないことを確認する必要があります。

生成AIの主な差別化要因と課題とは？

・正しい問題から始める

間違った問題を追及する組織は、価値を迅速に得ることに苦労します。例えば、費用対効果ではなく、生産性に焦点を当てる方が、はるかに成功しやすいと言えます。動きが遅すぎることも問題です。

・生成AIのユースケースのラストワンマイルは、予測的AIとは異なる

予測AIでは、ダッシュボードや利害関係者のフィードバックループといった消費メカニズムに多くの時間を費やします。生成AIのアウトプットは言語の形をとっているため、これらの価値提案に到達するのがより速くなります。人間の言語が持つ双方向性によって、より速く進むことが容易になるかもしれません。

・データは異なるものになるだろう

データに関連する課題の性質は異なるでしょう。生成AIモデルは、乱雑でマルチモーダルなデータを扱うのが得意なので、データの準備や変換に費やす時間が少し減るかもしれません。

生成AIでデータサイエンティスト（DS）は何が変わるのか？

・スキルセットの変化

生成的AIモデルがどのように機能するかを理解する必要があります。どのように出力を生成するのか？その欠点は何か？私たちが使う可能性のあるプロンプト戦略は何か？私たちデータサイエンティスト全員がもっと学ぶべき新しいパラダイムです。

・計算量の増加

これらのモデルを自分でホストしたい場合、より複雑なハードウェアを扱う必要があります。

・モデル出力の評価

さまざまな戦略を使ってさまざまなタイプのモデルを実験し、どの組み合わせが最も効果的かを学ばなければいけません。これは、異なるプロンプトやデータチャンキング戦略、モデルの埋め込みを試すことを意味します。異なる種類の実験を実行し、それらを効率的かつ体系的に評価したい。どの組み合わせが最良の結果をもたらすのか？

・モニタリング

このようなモデルは倫理的、法的な問題を引き起こす可能性があるため、より綿密なモニタリングが必要となる。より厳密に監視するシステムが必要である。

・新しいユーザー体験

人間をループに入れ、モデリングのワークフローにどのような新しいユーザー・エクスペリエンスを取り入れたいかを考える必要があるかもしれません。生成AIソリューションの構築に関わる主なペルソナは誰になるのか。予測AIとの対比について考える必要があります。

組織が直面する人材ニーズは、生成AIであっても変わらないでしょう。依然としてモデルのニュアンスを理解し、新しいテクノロジーを研究できる人材は必要です。機械学習エンジニア、データエンジニア、ドメインの専門家、AI倫理の専門家など、すべてが生成AIを成功させるために必要であることに変わりはないのです。

生成AIに期待できること、どのユースケースから始めるべきかについて興味のある方はwebinar「予測AIと生成AIの融合で新たなバリューの創出 ~生成AIブームで浮かび上がる現場のニーズと課題」をご覧ください。

※本Blogは、Value-Driven AI: Applying Lessons Learned from Predictive AI to Generative AIの抄訳版です。詳細については、原文をご覧ください。

投稿 バリュー・ドリブンAI：予測AIから学んだ教訓を生成AIに応用する は 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 の MLOps をお使いの方もいらっしゃれば、独自の方法で行っている方もいらっしゃるでしょう。また、これらのモデルを監視してサービスの状態や精度などを把握しているとします。

まずは、おめでとうございます。あなたは、実際にここまでたどり着けたエリート組織10%の中に入っています。残りの90%の方々は、まだ最初のモデルをどうやって運用化するかを考えていて、監視方法については考え始めてもいません。

10%のエリートの方々に質問です。モデルの精度や性能が1～2か月後に劣化しそうなことが監視システムからわかった場合は、どうしますか？

お使いのモデルがこのような状況になった場合、いくつかの選択肢があります。

1. 劣化するモデルを新しいモデルと交換
2. 劣化するモデルを再トレーニング
3. 以前のバージョンのモデルにロールバック

どの選択肢においても、現在運用中のモデルを別のモデルやバージョンに単純に置き換えることにはリスクが伴うため、良いことではありません。

それはなぜでしょうか？

基本的に、試験環境でどれだけモデルのトレーニングやテストをしても、その結果は、実際の本番環境へ移行した際のモデル動作の推定に過ぎません。

モデルの劣化に対処する最善の方法とは？

こうした重要なモデル管理作業を正しく実施するには、いくつかの方法があります。そのほとんどは、「チャンピオン/チャレンジャー」という言葉でその特徴を表すことができます。

チャンピオン/チャレンジャーにより、本番環境においてさまざまなアプローチで予測モデルをテストすることが可能です。このコンセプトは、マーケティングの観点から見ると A/B テストと似ています。チャンピオン/チャレンジャーでは、ある意思決定ロジックに関する予測をいろいろなパターンで実行し、それを監視、評価することができます。最終的な目標は、どのパターンが最も成功しているかを見極めることです。

簡単に言うと、現行のモデル（チャンピオン）に対して、新しいモデルや再トレーニングされたモデルをチャレンジャーとして設定することができます。チャレンジャーはチャンピオンをシャドーイング、つまりチャンピオンと同じ予測を実行します。チャレンジャー達は、新チャンピオンになるチャンスを求めて精度などを競い合うことになります。その後 MLOps のエンジニアは、この本番の予測ベースの競争の結果を検討し、勝者となったモデル（つまり、既存のチャンピオンまたはチャレンジャーの1つ）を推薦することができます。

もしガバナンスのプロセスがある場合は、このタイミングで指定された承認者が新しい標準（つまり、新しいチャンピオン）となるモデルを最終的に決定します

チャンピオン/チャレンジャーの仕組みだけではなく、これが循環型プロセスであることを理解しておくことも重要です。つまり、このプロセスのアクティビティは、実行中のすべての実稼働モデルでほぼ常に発生しています（発生していなければなりません）これにより、質問への回答やテストの完了を待つことなく、モデルの「ホットスワップ」がいつでも可能です。

チャンピオン/チャレンジャーは MLOps 6.1の新機能です

DataRobot のリリース6.1では、MLOps にチャンピオン/チャレンジャーのフレームワークを追加しました。この新しい機能により、DataRobot のお客様は、管理されたフレームワークの中で、現在最高のパフォーマンスを発揮しているモデルと並行して、チャレンジャーモデルをシャドーモードで実行できます。

さらに、DataRobot の Automated Machine Learning を使用することで、潜在的なチャレンジャーとしての高品質な代替モデルをいつでも簡単に構築できます。DataRobot のモデルまたはカスタムモデルをチャンピオンとして選択し、最大3つのチャレンジャーモデル （DataRobot AutoML で自動生成したり、DataRobot の外で作成したりすることも可能)を選んで、チャンピオンをシャドーイングすることができます。

DataRobot の MLOps プラットフォームでのチャンピオン/チャレンジャーの主な特徴は、ライブで予測を行えるのはある一時点において1つだけであることです。予測リクエストはすべて、現在のチャンピオンモデルが対応します。その後、分析用に同じ予測リクエストがチャレンジャーに対して再生されます。

これが A/B テストや多腕バンディットとの重要な違いです。これらのアプローチでは、実際にモデル間でトラフィックを分割しています（つまり、一方のモデルに対して50%、もう一方のモデルに対しても50%とし、両方のモデルがリクエスト元のアプリケーションに対して予測を返します）。A/B テストでは、新しいモデルを段階的にテストでき、各モデルの KPI への影響について、より良い実験結果を得ることができます。しかし、このアプローチでは、アプリケーションがさまざまなモデルからランダムに予測を得るため、多くの組織において重大な欠点とされています。

つまり、テストするモデルのバリエーションは、（特徴量の使い方や精度などの点で）本番環境に適したものでなければなりません。A/B テストでは、最も精度が良い保険料率算出モデルと比較することはできません。このようなチャレンジャーモデルについては、本番環境への投入が禁止されていることが多いためです。また、ベースライン参照モデルを本番環境で実行するのは、精度に関する対処ができないため、やめたほうがいいかもしれません。

DataRobot のシャドーイング方式では、安全に予測をミラーリングすることができ、ビジネスや顧客に影響を与えるアプローチを取る必要がありません。このセーフティネットによって、比較したいモデルをより詳しく調べることができます。

MLOps において、Python で作成されたチャンピオンモデルが、3つのチャレンジャーを相手にどのようなパフォーマンスを発揮しているのかを時間を追って示した例

チャンピオンモデルと同じ本番環境データを提供することで、チャレンジャーモデルも同時にアクティブ化され、実際に本番環境のビジネスプロセスで使用されたチャンピオンの予測とチャレンジャーモデルの予測を比較できます。その後、さらに予測の内容、精度、データの誤差を継続的に分析し、過去の任意の期間に的を絞ることができます。

MLOps による厳格な管理の下で、このプロセスには承認ワークフローと監査証跡が提供されており、権限を与えられたユーザーのみがチャレンジャーモデルの提案・分析や現チャンピオンの交換を行えるようになっています。また、提案された交換を行う前に「シャドーモード」で実行することは、モデルの交換処理の安定性を向上させることにもつながります。

新しいチャレンジャーモデルを追加して、新しい予測と過去の予測をテストし、チャレンジャーとチャンピオンをホットスワップする

MLOps のチャンピオン/チャレンジャー機能では、本番運用のためのモデルとしてほかにどのような選択肢があるかを可視化できます。また、常に代替モデルが用意されているということになります。これにより、常に変化するビジネス状況に対応し、可能な限り最高のモデル品質を長期的に維持できます。

MLOps のチャンピオン/チャレンジャーモデルについてもっと知りたいですか？

DataRobot MLOps をすでにお使いの場合は、お持ちのライセンスでこの重要な新機能をご利用いただけます。また、DataRobotコミュニティでは、チャンピオン/チャレンジャーモデルについて詳しくご紹介し、初めてチャレンジャーモデルを構築する際に役立つビデオをご覧いただけます。MLOps のチャンピオン/チャレンジャーモデルは、リリース6.1の一般提供機能です。

投稿 MLOpsのチャンピオンモデルとチャレンジャーモデルのご紹介 は DataRobot に最初に表示されました。

AI の業務利用の拡大と DWH の進化

まずは現在の代表的な DWH の選択肢についてそれらのソリューションが登場した順に見ていきましょう。

2000年代前半- DWH 専用リレーショナルデータベース

DWH と通常のデータベースとの違いは、DWH でははじめからデータ分析を目的としてデータが蓄積されるため、膨大な過去データを時系列に保持する必要があり、従来の SQL を使用した操作で大量データを複数サーバでの分散処理により高速に処理する DWH 専用の RDBMS が登場しました。TeraData は1980年代から並列処理の製品をリリースしていましたが Netezza、OracleExaData、Vertica などが代表的な製品が出揃ったのは2000年代の中頃から後半にかけてです。扱えるデータは数字や文字列といった構造化データが中心ですが、これらの製品は SQL を習得すれば操作可能であることから利用経験のあるデータサイエンティストも多く、当初は BI 用途での大規模データに対する分析クエリやバッチ処理によるデータ加工の高速化が主要な利用形態でしたが、分析サーバで作成したモデルを SQL 関数として実装することでデータの移動なしに DWH 内で予測処理を行う In-database アナリティクス（In-DB Analytics）の手法が登場してから AI での活用も進みました。現在でも AI 製品との連携機能などのエンハンスをしながら多くの環境で利用されています。

 2010年代前半 – Hadoop/Spark

JSON 形式の半構造化/データ非構造化データやさらには IoT などのリアルタイムデータへの対応など、従来の事前定義された表形式のフォーマットでの対応が難しい場合など、Hadoop（Diskベース）や Spark（メモリベース）に代表される分散プラットフォームの採用をする企業も多く現れるようになり、ビッグデータやデータレイクというキーワードもこの頃から使われ始めたのも2010年代前半頃からように思います。DWH としての利用では SQL でのデータ操作も可能であるものの、Hadoop エコシステムと呼ばれるオープンソース由来のソフトウェアの種類も多く、その複雑さから運用管理スキルを持つエンジニアもそれほど多くはないのが現状です。RDBMS をベースとした DWH 製品と比較すると Hadoop/Spark を自社運用するしている企業もそれほど多くはないでしょう。しかし様々なデータフォーマットの大量データを分散コンピューティングで処理することが可能であるため、SaaS 型のデータプラットフォームやサードパーティ製品のバックエンドのデータ処理エンジンとして現在でも広く利用されているテクノロジーとなっています。

2010年代中頃 -SaaS 型 DWH

登場したのは Hadoop がメジャーになり始めた2010年前半ごろですが、一般的に認知され企業での活用が進んだのは2010年の中頃かと思います。上の2つの技術と比較するとクラウド環境のアドバンテージを取り入れた比較的新しい技術ですが、現在では BigQuery/Redshift/Snowflake/Treasure Data など様々なメジャーなサービスが存在しており、市場は急速に拡大しました。クラウド上の各種アプリケーションとの連携により、ほとんどのユースケースにおいてデータ収集からデータ加工まで AI に必要なデータ準備プロセスをクラウド上で完結することができます。従来の SQL でデータ操作もサポートしており、JSON など半構造化データを SQL で操作するスキーマレス DB としての機能を備えた製品もあるため活用の範囲も広く、クラウド環境の特性を生かしたリソースコントールや自動バックアップなどの運用工数の削減も可能です。後発であることから技術的に従来の DWH よりも機能面や運用面において先行している部分もあります。

AI 活用での DWH 選択のポイント

データの収集からデータ準備、予測の実行後の結果の格納までを行う AI ライフサイクルにおける DWH の製品選定では、AI 活用を前提とした機能要件/非機能要件を十分に検討をしていく必要があります。先ほど上でご紹介した DWH はいづれも多くの機能要件をカバーできていますが、サポートしている機能のレベルは製品それぞれに異なります。特に以下のような機能要件の充実度については実際のユースケースに照らし合わせて検討しておくと良いでしょう。

非構造化/準構造化データの格納

従来のデータ型が固定のテーブル形式で表現する構造化データを高速処理できるだけでははなく、AI 活用においても数値や文字以外の音声、画像データなど、収集できるデータも多種多様になってきています。AI で使用する DWH はこれらの非構造化/準構造化データを格納できる「スキーマレス」をサポートする DWH を選択すると変化に強い分析環境を構築可能です。これは分散ファイルシステムをベースに構成される Hadoop/Spark が最も得意とする分野です。

スナップショット機能

テーブルデータのコピーでは DWH のストレージ領域を大量に消費する可能性があるため、データの変更部分のみを差分で保持しながら過去時点のデータを参照可能なスナップショットを取得できる製品を検討すると良いです。スナップショットによりモデルを作成した時点のデータを効率的に保存することが可能です。複数の断面でのデータを使用した検証も可能ですのでスナップショットをうまく利用すると AI 活用において大きなアドバンテージとなります。こちらはストレージの機能でスナップショットを取得するか Snowflake や Hadoop エコシステムの一部の NoSQL など任意の時点のデータにアクセスする機能をもつ DB を検討すると良いでしょう。

ユーザ定義関数（UDF）

DWH 内のデータに対してデータの移動なしに予測処理を行う In-database 分析（In-DB analytics）を実装できると大量データのスコアリング処理の時間を大幅に削減できる可能性があります。SQL 関数で予測結果が取得できるようになると、BI ツールから任意の SQL を使ってのスコアリングが可能になるなど適用範囲が広がります。例えば DataRobot との連携では Prime モデルで外部出力した Python/Java のソースコードやスコアリングコードを UDF で SQL 関数として実装することが可能です。ほぼ全ての DWH がこの機能をサポートしますが利用可能な言語には注意が必要です。

リソース管理/構成変更機能

データ準備のプロセスでは負荷の高い非定型クエリが多数実行されることもあります。スケールアップ/スケールアウトのしやすさとデータ準備/加工処理のリソース要求に柔軟に対応できる構成が取れ、特に異なるワークロードの同時実行が想定される場合にはリソース競合を完全に排除可能なマルチテナント構成が取れると良いでしょう。SaaS 型 DWH では処理のピーク時とオフピーク時に柔軟に構成変更を実施しコストを軽減するなどの運用が容易な製品も登場しています。こちらは SaaS 型 DWH の得意とするところです。

AI の時代に選択すべき DWH は？

どの DWH が AI 活用において最も優れているか？という明確な回答は様々なユースケースに依存するため一概には答えられません。どのようなデータをどの場所に格納し、どのように活用するかにより最適な DWH を選択していただく必要があります。たとえば、セキュリティ上の理由からクラウド環境にデータを保存できない場合には、構造化データのみの分析であればオンプレ環境に DWH 専用リレーショナルデータベースで構築するのが良いでしょう。また、文章や画像データなどを分析する場合には分散ファイルシステムベースの Hadoop/Spark によるデータ管理が適しています。

一方で近年では、高度なスキルをもつ一部のデータ・サイエンティストだけでなく、DataRobot のような 自動化ツールの登場により幅広いユーザーがデータ活用に取り組んでいます。今後もこのような傾向は更に加速するでしょう。シチズンデータサイエンティスト、ビジネスアナリスト、AI エンジニア、データサイエンティスト、などなど、今後様々なデータ活用の担当者が生産性を向上させるためには、それぞれが必要とする種類のデータに随時、簡単で迅速にアクセスすることができる環境が必要とされます。環境構築と構成変更を柔軟に実行することができるだけでなく、製品の開発サイクルが速く技術的に先行しているSaaS 型の DWH をうまく活用していくことが AI 活用を成功させるポイントとなるでしょう。

大手企業が次々にクラウド基盤の採用を打ち出していることもあり、今後 SaaS 型 DWH がパッケージ型（オンプレ）の選択肢を遥かに凌駕していくトレンドは下記の市場レポートにも如実に現れています。

今後 DWH に求めれる要件は？

今後予想される DWH に対する先端的な要件についてもいくつかご紹介させていただきたいと思います。

リアルタイム・ストリーミングデータのロードと分析

定期なバッチで CSV ファイルをロードするのでなく、Kafka などのメッセージキューを連携し、リアルタイムにデータを取り込む機能です。リアルタイムで変動する株価データや10分前のデータではデータの価値が落ちてしまうといったような IoT データ分析やデータの鮮度が重要な場合には必須の機能ですが、 これまでは１秒間に数千万レコードというようなデータボリュームに対しては DWH へのリアルタイムでの取り込みは実現できませんでした。多くの場合、定期実行のバッチ処理で DWH にロードするか、NoSQL-DB のようなリアルタイム取り込みができるソリューションで代替することがありましたが、NoSQL-DB では大量データの加工や分析処理に不向きであり、結果、リアルタイム性が失われ、多くのユースケースにおいてこのソリューション構築は課題となっておりました。

地理空間データのサポート

地理空間情報のデータを使った分析も処方分析には重要な機能です。地理空間特徴量の生成を行うために特定の手法（ある地点や道路または特定の地域などの緯度/経度の情報をジオコーデディングと呼ばれる手法を使い、1つのオブジェクトとして表現する）でデータをストアする必要があるため、一般に Geospatial 機能ともいわれている地理空間情報データを処理する関数をサポートする DWH を選定する必要があります。地理空間データを活用したリアルタイム処方分析の例ではシンプルなものでは現時点の交通量や道路での工事や事故の情報を考慮しながら、最も効果的な配送ルートを提供するといったものがありますし、携帯の GPS 情報から現在の混雑状況を把握し基地局のアンテナをチューニングするといった事例もあります。また地理空間情報の計算は CPU リソースを消費するため、コンピューティング性能と拡張性の高いプラットフォームを検討する必要があります。

これらは既存の DWH 製品やツールを組み合わせることでも実現は可能ですが、現時点では複数の異なるプラットフォームの管理が必要になることが多く、管理の複雑さ、コスト、データ移動などのシステムのサイロ化の課題がありました。近年ではこのような課題を解決し、より高度な分析をリアルタイムに行うためにインメモリ+コンピューティングリソースに GPU を使用した AI との親和性の高い新しいタイプの DWH も登場し始めています。

最後に

いかがでしたでしょうか。AI 活用の視点で DWH 選定のポイントと今後の動向についてお話をさせていただきました。本ブログでご紹介した以外にも DataRobot では様々なデータベースに対応しており、データベースでのみ利用可能な連携機能もございます。これらの機能については次の機会にご紹介させていただければと思います。

投稿 DWH 最新動向 は DataRobot に最初に表示されました。

DataRobotの小島繁樹です。

Part 1 にて、機械学習モデルをビジネスに適用した場合に考慮しておくべきこと、その際に発生する可能性がある多くの課題 – チャレンジ – についてご紹介をいたしました。

一方、機械学習モデルをビジネスに適用した際の効果、そのビジネスインパクトは凄まじく、利用における課題 – チャレンジをうまく管理し、機械学習モデルをうまく運用していこうという思想、技術も広がってきていています。

一般的にそれら思想、技術はMLOps (Machine Learning Operations) と呼称されており、DataRobotとしてもこれら思想、技術を実現する DataRobot MLOps製品をご提供してきています。

これは2019年、この分野のリーディングプレイヤーであったParallelM社を買収し、その技術を洗練した形でDataRobotプラットフォームに融合したものとなっています。

本ブログでは、このDataRobot MLOpsによってどのような事を実現できるのかご紹介していきますが、急速な発展を遂げていくこのMLOpsについての発信の場となるコミュニティについても併せてご紹介をしていきます。

MLOps コミュニティ

Datarobotでは現在、弊社のMLOps製品を広めること以上にMLOpsの概念がより深く理解・議論されなくてはならないと考えており、MLOpsコミュニティを運営しています。 2020年2月28日、第一回コミュニティイベントを JapanTaxi様、Smart Analytics様の先進事例紹介を柱に開催を企画いたしました。

その結果、何とイベント公開から半日たらずで募集定員を大幅に突破、その後、数日間で募集50人に対し2倍近くにも及ぶご登録を頂くに至りました。

イベントは大変残念ながらコロナウイルス感染症への配慮から、募集期間も半ばにて延期を決定いたしましたが、実際に機械学習モデルの運用に立ち向かわれている皆様が、強くMLOpsという技術を必要とされている事、そしてこの分野に対する皆様の興味、関心の強さを示す出来事となりました。

本イベントについては時期をみて必ず開催いたします。是非とも本日コミュニティにご登録いただき、お待ちいただければと思います。

機械学習モデルのビジネス適用

Part 1 にてご紹介しました通り、機械学習モデルを実ビジネスで利用するのであれば、場当たり的なものであってはなりません。つまり、成果を出すために開発されたモデルは、その役目を終え、次のモデルに引き継がれるまでのライフサイクルで管理する必要があります。そしてまた、その管理は組織で運用中の全てのモデルに対して行う必要があります。

下記の図はPart 1 からの再掲ですが、機械学習モデルがビジネス環境で普遍的に利用されるにつれ、その管理、つまり正常に稼働しているか、そして性能が落ちていないか、モデルについての変更が適切に関係者に通達されているか、等について組織横断の視点から確認し続ける必要が出てきます。

DataRobot MLOps

組織横断での機械学習モデル管理の実現

Datarobotは先進的な機械学習自動化プラットフォームとして開発されてきました。DataRobotにデータを投入すると、モデル開発に必要な多くの工程が自動的に実行され、またビジネスで利用するためのデプロイまでもがボタン一つで完了します。

しかしながら、様々な理由により、実際のビジネス環境下ではDataRobotで開発されたモデル以外の運用を行う必要がある状況が出てくることがあります。例えば特別なライブラリを使わなければ扱えないモデルを開発する必要がある、等がこれに当たります。

DataRobot MLOps は、こういったDataRobotプラットフォームで開発されていないモデルに対しても、MLOpsの統一的なインタフェースを適用したモデルの利用 (他システムとのインテグレーション)や、運用管理ができるように設計されています。

ユーザ作成モデルの登録

DataRobot MLOps では、DataRobot開発モデル以外のモデルも登録が可能、しかも、特別なライブラリや独自のコーディングを利用したモデルについても同じプラットフォーム上で利用が可能となると、技術的にどのように実現しているのか、ご興味を持たれる方も多いかと思います。

DataRobot MLOpsはコンテナ型アーキテクチャを採用する事によりこの難題を実現しています。

ユーザは自身で作成したモデルと、そのモデルを動かすための実行環境をそれぞれパッケージ化し、DataRobot MLOps上に登録します。これらパッケージをDataRobot MLOpsではコンテナ化して扱うことにより、様々な環境で動作するユーザモデルを単一プラットフォーム上で稼働させる事を実現しています。

モデル開発者の目線ではこの作業が少し難しそうに見えてしまうかもしれませんが、実際にはDataRobot MLOpsの画面上にテンプレートに沿って作成したモデル関連ファイルをドラッグ＆ドロップするのみで簡単に利用することができます。ここにも、機械学習モデルの実装を極力、シンプルにかつ自動化して実現しようとするDataRobotの設計思想が生きています。

続いて、こうしてDataRobot MLOps上で稼働しているモデルについて、どのような運用を行う事ができるのかについて見ていきます。

DataRobot MLOpsがモデルの運用において常に重要であると考えているのは、「現時点の状況だけではなく、過去にさかのぼった任意の期間の確認をすることが出来る」という事です。そのモデル利用における過去の時間軸、またモデルのバージョンを切り替えた場合は、切り替え前後についての比較確認が出来るという事も重要です。

システム正常性

では、具体的にDataRobot MLOpsでの運用ポイントを見ていきましょう。１つ目は、デプロイされたモデルが正常に稼働しているか。つまり、エラーなく応答し、またそのレイテイシに問題がないか、いった視点で確認を行うことです。また、想定通りの利用状況となっているか、といった点についても確認する事ができます。

上記スクリーンショットの例では、ウェブサイトでの訪問者に対するコンテンツ切り替えを行う機械学習モデルの利用状況を示しています。サイトメンテナンスを実施した休業日に利用がなくなっている事、また来訪者に応じた利用状況となっていること、エラーが出ていない事、想定した速度で応答し続けている等、等々が確認できます。

また中段のスケールバーを操作することにより、任意の時間軸についての確認を行う事ができるインタフェースとなっています。

一見、当たり前の確認項目のようですが、こういった確認を行うことは非常に重要です。例えば、サイトメンテナンス時にも利用が継続されているとしたら、それはモデル開発者が意図しないビジネス用途に流用されている事が原因かもしれません。そういった状況を放置すればビジネス上の損失に繋がりかねません。しかしながら、開発された機械学習モデルそのものは、通常こういった確認を行う機能は持っていません。MLOps基盤を利用する事で可能となる運用の一例であり、重要性がわかりやすい物となっています。

精度

精度についても同様に、過去の任意の時間軸にさかのぼって確認を行うことができます。モデルのバージョンを切り替えた後や、実際のビジネス環境の変化等、精度に影響を及ぼしうるイベントがあった場合にはその前後について、モデルの精度への影響を確認することができます。

しかし、予測を行うMLOpsという基盤において、どうして予測値と実際の値 = 予測時点からみて未来の値 との比較である「精度」を算出することができているのでしょうか？

実はDataRobot MLOpsでは、予測結果に対して1意となる識別IDをモデルの予測時に付与し、後からその識別ID毎の実績値をフィードバックすることにより、この精度計算を実現しています。

こちらについても機械学習モデルが単体では持ち得ない管理機能を、実行基盤であるMLOpsが補っているということになります。

データドリフト

Part1ブログでもご紹介しましたが、機械学習モデルをトレーニングした時のデータ、と予測が行われたときのデータ、つまりビジネス上の現実がずれていく = ドリフトする、漂流する事を、データドリフトと呼称しています。

データドリフトは精度に大きな影響を及ぼすこともある、機械学習モデルの運用において監視を行うことが非常に重要な項目です。

DataRobot MLOpsでは、ある対象期間について２つの画面でデータドリフトを表現し、直感的な理解が出来るようになっています。

左側の画面では、予測したいターゲットに対しての特徴量の有用性とそのドリフトの度合いを表しており、右側の画面では選択した一つの特徴量について、どのようなドリフトが発生しているのかを表示しています。

ドリフトの検知はモデルの運用上非常に重要ですが、単に「発生した」事を検知するのみではその有効性は薄くなります。「いつの期間に」「どの特徴量で」「どのようなドリフトが発生したのか」までを特定できる事ではじめて、実際のビジネスで発生していた事象との突き合わせが可能となり、モデルの再構築への重要なインサイトとなりうるのです。

指標による通知設定 等

DataRobot MLOpsではこれら監視項目を、DataRobotで作成したモデル、ユーザが独自の環境で作成した独自のモデルを分け隔てせずに統一的に管理することができます。

しかし、数百にも及ぶモデルが存在する組織においては、一つ一つを毎日確認することは現実的ではありません。そのため、これら監視項目にそれぞれのモデルでしきい値を設定し、それを逸脱した場合に管理者がメール通知で受け取る機能も実装されています。機械学習モデルの運用の現場で求められている概念 = MLOpsを達成するためのツールであり、こういった運用についてもよく考え抜かれたものとなっています。

まとめ

Datarobot は MLOps製品により、機械学習の開発を自動化するのみならず、ビジネス適用の視点からみて理想的なモデル運用までを実現できる事をご紹介いたしました。DataRobot MLOpsは皆様のビジネスに役に立つモデル運用環境の実現のため、今後も継続的な製品開発が続いていきます。DataRobot MLOps製品にご興味を持たれた方は、ぜひこちら info-jp@datarobot.com までご連絡ください。

また、MLOpsコミュニティではDataRobot MLOpsにこだわらず、MLOpsという思想、技術に関連する最新情報について広く取り扱ってまいります。「モデルの実運用にてこのような課題があった」「このようにして克服した」「この点はモデル開発フローに組み込むべきであった」、等の貴重な経験談を共有し、議論し、また情報発信をする場としていきます。これを機会に、是非ともコミュニティへご登録ください。会場にてお会いし、MLOpsについて皆様と議論出来る事を楽しみにしております！

投稿 MLOps – 機械学習モデルの活用、その先にあるチャレンジ Part 2 は DataRobot に最初に表示されました。

DataRobotの小島繁樹です。ビジネスへのAI、機械学習の活用は日々喧伝され、既にバズワードと疑われるフェーズを遥かに超えています。日本でも多くのお客様がその効果を認め、巨大なビジネス効果創出にも成功しています。

こういった背景の中、「多くの機械学習モデルの威力を維持するための統合管理」といった、これまで存在すらしていなかったあらたな課題が先進的な企業においてその姿を表しつつあります。今回ご紹介するMLOpsという考え方、技術は、まさにこうした背景から生み出されたものです。

機械学習モデルライフサイクル

機械学習プロジェクトにより生み出されるモデルのライフサイクルとして、一般的に

課題の創出(発見) → データ準備→ モデル作成→ モデル理解 → 効果検証→ デプロイ→  ビジネス上での利用

という文脈が語られます。ビジネス上で利用するためのデプロイが一つの大きなゴールというわけです。しかし、実際のプロジェクトはここで完了する事はありません。

→ モデルの運用監視  → モデルの更新

という段階を経る事で、作成されたモデルの威力を落とさない運用を実現し、またモデルの精度等をよりビジネス課題に即した物へと進化させていくサイクルを実現することができます。

では、機械学習モデルの運用で何が必要とされるのか、また効果的であるのかについて見ていきます。

機械学習モデル運用時のチャレンジ

機械学習モデルの「運用」における具体的なチャンレンジとしては、下記が代表的なものとして存在します。

システム運用：

システム視点から「モデルがうまく動いているか」を定常監視する必要があります。予測実行時においてエラーがでていないか、といった確認はもちろん、処理スループットの低下、モデル切り替え時にはそのモデルを利用しているアプリケーション側の対応に問題がないか、といった点を観測していきます。

モデル性能監視：

機械学習モデルの視点から「うまく動いているか」を確認します。一般的なITシステムと異なった視点を持つ必要があり、代表的なものとしては、モデルを開発し、効果検証した時点から大きく予測性能が落ちていないか、その原因はなにかを観測していきます。

性能に問題が発生する代表的な要因としては、ビジネス状況の変化によるデータの変化、つまり、特徴量やターゲットの分布が、モデル作成時と比較して変化していく、といった現象があります。これを、まるで「データが流れ漂うよう」である事からデータドリフトと呼称します。

データドリフトの発生は、「いつごろから、どの程度、どの特徴量で発生していたのか」を時系列に沿った形で記録して置く事が重要です。それにより、ビジネス上での変化と付き合わせることができ、モデルをよりビジネスに沿ったものとして進化させていく上で非常に重要なインサイトとなっていきます。

ガバナンス：

ガバナンスは「統治」と和訳される事もあるように、「現在いくつのモデルが組織において稼働しているのか」「数多く予測に利用されている重要なモデルはどれなのか」といった稼働状況の把握から、「モデルは適切な利用者に限定されて利用されているか」「モデルが更新された場合、関係者へ適切な通知がなされているか」等を、組織横断的に把握する必要があります。また、監査証跡の観点からは変更前のモデルがどのようなものであったのか、といったモデルの世代管理についても、統合的に管理できる必要があります。

一元管理：

機械学習モデルが多く生成されていく過程の中で、個々のデータサイエンティストの得意とする技術(Python/R 等)や、目的に応じたライブラリの利用等で、単一のアーキテクチャではない技術を用いたモデルが増えていきます。しかし、そういった状況の中でも利用者に対しては同一のインタフェースで機械学習モデルへのアクセスを提供し、また上記に列挙したようなモデル運用監視を行う必要性には変わりありません。

また、非常に気密性が高いセキュリテイエリア等、モデルが配置される場所のネットワーク状況等も多様性に富んだものとなっていき、それらについての管理についても検討しておく必要があります。

MLOpsとは？

そこで、DevOpsの機械学習への発展という文脈で生まれたMLOpsという考え方が注目されています。

機械学習モデルの作成とデプロイを継続的・高速に行う仕組みと方法論を指しており、データサイエンティストの視点とIT運用者の視点を融合し実現する物となっています。モデルの構築を迅速かつ効率的に実現するのみならず、難易度が高くなり続ける高度なモデル運用の実現を目指す考え方です。

米国では昨年、MLOpsにフォーカスしたカンファレンスも実施されています。

DevOpsがそうであったように、現状MLOpsもその前段に過ぎない機械学習モデルの開発の自動化への注目度が高いのが現状ですが、その後段として避けることができない、様々なアーキテクチャにより作成された機械学習モデルをどのように運用すべきか、という視点こそが重要です。

そこには前述したように多くのチャレンジが存在しますが、変わり続けるビジネス環境に適合し続ける機械学習モデルを実現するためには欠かせないプロセスとなります。このプロセス無しには、ビジネスに価値をもたらすはずの機械学習モデルが逆効果となってしまうことすら考えられます。

DataRobot が実現するMLOps

DataRobotはこれまで、機械学習モデル開発の自動化を業界最高のレベルで実現して来ました。

ユーザは分類、回帰、時系列、と様々な分析機能をそのビジネス課題に対し、単一のインタフェースで容易かつ迅速に実現し、ビジネスへのデプロイまでを統合的に実現する事ができます。

そしてDataRobotは2019年、ビジネスへの機械学習モデル適用におけるMLOpsの重要性から、この分野の先駆者であったParallelM社を買収し、その技術を機械学習モデルの自動開発プラットフォームに融合する事を開始しました。

これにより2020年、いよいよDataRobotは機械学習モデルの開発から運用までを統合的に管理するDataRobot MLOpsをリリースします。PythonやR等の個々の技術で作成されたモデル等も、実装アーキテクチャを吸収し組織横断の機械学習モデルの運用管理を実現していきます。

DataRobotの機械学習プラットフォームは、モデル生成の自動化、どれだけ高精度のモデルを生成できるか・・・といったレベルを超越し、真にビジネス環境で役に立つ統合環境を実現していきます。

DataRobot MLOpsの詳細については ブログPart 2 にてご紹介を進めてまいります！

また、今後このMLOpsについて先端事例から学ぶ勉強会をコミュニティで広げていきます。ぜひともこちらからご登録ください。イベントでお会いできる事を楽しみにしております！

MLOpsコミュニティ

DataRobotでは、製品に依存しないMLOpsコミュニティを運営しています。

活気のあるイベントを続々と企画していきます。どうぞこちらからご登録ください。

投稿 MLOps – 機械学習モデルの活用、その先にあるチャレンジ Part 1 は DataRobot に最初に表示されました。

DataRobotの予測エンジン 3種

機械学習モデルの利用 (DataRobot の実装)

1. 共有予測エンジン　(通称：V2エンジン)

機械学習モデルの利用 (DataRobot の実装)

2.  専有予測エンジン　(通称：V1エンジン)

DataRobotをご利用であれば、作成したモデルのメニュー画面から “予測” -> “デプロイAPI” と選択し、”モデルをデプロイ” というボタンを押下するだけで、このモデルが全自動でV1エンジンにデプロイされ、ユーザから利用できるようになります。

デプロイを行うときにはモデルの管理のため、「何のために作ったモデルなのか」「想定している利用者は誰か」といったコメントをモデル毎に自由に残すこともできるようになっています。

これによりDataRobotで作成したモデルが、多くの端末からAPI経由で利用できるようになります。また、このV1エンジンは予測処理専用に設計されており、その処理性能にも優れています。

V1エンジンはhttp REST 型のAPIで構成されており、端末側には接続ツール等を導入する必要がありません。デプロイ後、直ちに予測処理を開始する事ができます。

加えて、DataRobotはユーザがすぐにコピー＆ペーストで実行可能な予測処理のためのPythonのコードを出力することもできます。　　　　　　　　　　　　　　　

（予測デプロイのコードについては こちら の記事もあわせてご参照ください）

またDataRobotでは、こういった不特定多数のユーザがモデルを利用する際に重要となる、

・どのモデルがどれくらい利用されているのか / 利用されなくなっているのか

・予測精度が落ちてきているモデルはどれなのか

・更新すべきモデルはどれなのか

といった管理もダッシュボードで集中的に管理ができる機能が実装されています。

このV1エンジンはhttp REST 型のAPIであり、数GBといった大きさのファイルの予測については予測性能の確保、転送エラーの抑止等のため実行できない仕様となっておりますが、そういった大きなファイルでの予測実行が必要なケースのため、DataRobotはバッチスコアリングというツールをご提供しています。

このツールは、大きなファイルをV1エンジンが処理できる大きさに分割、並列で予測処理を実行、結果をマージしユーザに提供するといった一連の処理を全自動で実行する事ができます。

DataRobotではモデルデプロイについての専用トレーニングである、DRU Model Deploy Trainingを開催しておりますが、ご参加いただいた皆様から「とても便利なものだと理解できた」「今後は積極的に利用したい」というフィードバックを最もいただくのがこのV1エンジンです。

機械学習モデルによる予測の実装、管理を行う時に必要となる機能について、データサイエンティストの経験に基づいてよく考えられた実装となっています。DataRobotをご利用であれば是非とも利用について検討いただきたいと思います。

機械学習モデルの利用 (DataRobot の実装)

3.  DataRobot Primeエンジン　(通称：Primeエンジン)

DataRobotはネットワーク経由で利用する製品ですが、モデルによる予測処理はネットワークに接続されていない / 接続が断続的にしかできない端末でも実行する必要がある場合があります。DataRobotではこういったご要望についても対応する事が可能です。

DataRobot Prime エンジンはDataRobotで作成されたモデルを、PythonもしくはJavaの実行形式でダウンロードし、各端末上で実行できる機能オプションです。 

例えば製造現場で稼働するロボットのような機械を始め、あらゆる Python、もしくはJavaが動作する環境上での予測処理を実現する事ができます。

DataRobot上でPrimeエンジン機能が有効となっていれば、それぞれのモデルから”予測” -> “DataRobot Prime”と選択する事で、このモデルをダウンロードする機能にアクセスする事ができます。

利用モデルはDataRobotで「即・実行可能」な形式にまとめられてダウンロードされます。そのため「端末側でモデルを利用して予測処理を行う仕組み」について別途用意する必要はなく、すぐに端末上での予測処理を稼働させることができます。

 

また、多数の端末でモデルを利用する、モデルの更新を頻繁に行う、といった場合においても、PythonもしくはRのSDKによりモデルのダウンロードを行うSDKが用意されているため、新たなモデルを端末にダウンロードするといった運用タスクの自動化にも対応できるよう考慮されています。

 

データをネットワーク経由で転送する必要がなく、実行基盤の性能にもよりますが、予測処理を高速に実行する事ができるのも、このPrimeエンジンの特徴です。一方で、前述のモデルマネジメント機能の利用はできませんし、モデルリフレッシュ時にはモデル置き換えのための開発工数が生じることなどから、V1/V2 APIをおすすめするケースが多いのも事実です。

機械学習モデルの利用 (DataRobot の実装)　まとめ

 

— — —

すでに機械学習モデルのデプロイ、活用に成功している多くの成功企業がご登壇！

DataRobot最大のカンファレンス、DataRobot AI Experience Tokyo 2018 を 11月27日に開催します！

お申込みは下記バナーリンクから、是非お早めにお願いします。

投稿 機械学習モデルのデプロイ 後編 は DataRobot に最初に表示されました。

一般的な機械学習モデルの実装

(1)分析環境で予測処理までを行う

一般的な機械学習モデルの実装

(2) モデルによる予測を行う中央集中型のサーバを構築する

予測処理を実行するための「予測処理の専用サーバ」を構築し、予測処理を必要とする端末からネットワーク経由でアクセスさせる形で共同利用するという実装です。

データサイエンティストが生成した機械学習モデルをこの予測専用サーバで稼働させます。

予測処理を必要とする端末は、この予測専用サーバにネットワーク経由でアクセスし、予測が必要なデータの投入と、予測結果の取得を行います。

システム構築の世界で一般的にC/S(クライアント・サーバ型) と呼ばれる形をイメージするとわかりやすいかも知れません。

近年、こういった予測専用サーバは端末側に専用の接続ソフト等を必要としない、REST型のAPIエンドポイントで構成される場合が一般的となってきました。

こういった構成である場合、接続する端末の種別を選ばないため接続性に優れています。

利点：

・端末側はモデルを利用した予測処理をサーバに「任せる」事ができる。そのためモデルの管理、

　予測処理の実行といった処理についてはサーバ側にまかせ、APIへの接続のみを考慮すれば良い。

・機械学習モデルの更新がサーバに対して一回で済むため運用管理面が容易。

考慮点：

・予測サーバ上では、２つの仕組みを構築する必要があります。

　「生成されたモデルを導入し、予測処理を実行する」「APIを起動し、予測データの授受を行う」

　  そしてこれらを維持、運用していく必要もあります。

・端末と予測サーバに何ら問題がなくとも、その間をつなぐネットワーク上に

　問題が発生すると、一切の予測処理を行うことができなくなります。

　堅牢なネットワーク設計、もしくは接続できなかった場合の代替案を考慮しておく事が必要です。

・大量の端末から多くの予測処理が投入された場合を想定し、予測サーバ側の

　コンピュータは性能を適切に設計しておく必要があります。

・対応できるREST処理には上限がある事が一般的です。数GBといった大容量ファイルについて

　の対応について考慮しておく事が必要です。

また、非常に重要な点としてこの予測専用サーバ上で予測処理に使われているモデルが、過去どれくらい利用されているか、利用者は誰か、更新が必要なモデルがどれか、という事もあわせて管理していく必要があります。

一般的な機械学習モデルの実装

(3) 利用する端末個別にモデルを「インストール」する

 

機械学習モデルの利用 / まとめ

投稿 機械学習モデルのデプロイ 前編 は DataRobot に最初に表示されました。