デプロイ¶

MLOpsの目標は、モデルデプロイを容易にすることです。 役割（ビジネスアナリスト、データサイエンティスト、データエンジニア、または運用チームのメンバー）に関係なく、MLOpsでデプロイを簡単に作成できます。 DataRobotで構築されたモデルと、PythonやRなどのさまざまなプログラミング言語で記述されたモデルをデプロイします。

以下のセクションでは、モデルを任意の本番環境にデプロイし、MLOpsを使用してそれらのモデルを監視および管理する方法について説明します。

その他の情報については、関連する デプロイと カスタムモデルデプロイの注意事項を参照してください。

機能に関する注意事項¶

外部ソースから予測リクエスト／応答データセットのキュレーションを行う場合：

• 有用性が最も高い25の特徴量を含みます。

• CSVのファイルサイズの要件に従ってください。

• 分類プロジェクトの場合、クラスに0または1の値があるか、クラスがテキスト文字列である必要があります。

加えて、以下の事項にも注意してください。

• Self-Managed AI Platform only: By default, the 25 most important features and the target are tracked for data drift.

• 予測の作成タブは、外部のデプロイでは使用できません。

• DataRobotデプロイでは、によって専用の予測サーバーに対して行われた予測のみが追跡されますdeployment_id。

  • モデルマネジメントで分析するには、その他の予測方法ではリクエストおよび予測をCSVファイルに記録する必要があります。 その後、外部デプロイとしてファイルをDataRobotにアップロードします。

  • バージョン7.0では、deployment_idの代わりにproject_idおよびmodel_idを使用する使用非推奨のエンドポイントはHTTP 404 Not foundを返します（DataRobotの担当者が別の設定をした場合を除く）。

• デプロイごとに1時間あたりの最初の100万の予測がデータドリフト分析のために追跡され、精度が計算されます。 この制限に達した場合、1時間以内の予測はどちらの指標に対しても処理されません。 ただし、一般に予測に対する制限はありません。

• より大きなデータセット（最大5GB）をスコアリングする場合、複数の予測ジョブを実行する必要があるため、予測が使用可能になるまでの待機時間が長くなります。 予測インターフェイスから移動した場合、ジョブは引き続き実行されます。

• 予測リクエストを作成した後、データドリフトと精度指標が更新されるには、30秒ほどかかることがあります。 指標の更新速度は、モデルの種類（時系列など）、デプロイ設定（セグメント属性、予測距離の数など）、システムの安定性に依存することに留意してください。

• DataRobotでは、同じ関連付けIDを使用する複数の予測行を送信しないことを推奨しています。関連付けIDは、予測行の一意の識別子です。 複数の予測行を送信する場合、最新の予測だけが関連する実測値を使用します。 以前のすべての予測リクエストは、事実上、その実測値と対になっていません。 さらに、対になっていない予測行も含めて、すべての予測がデータドリフト統計に含まれます。

• 予測をクラウドの場所またはデータベースに書き込む場合は、予測APIを使用する必要があります。

時系列デプロイ¶

• 時系列のデプロイで予測を行う場合、使用するモデルによって必要な履歴の量が異なります。

  • 従来の時系列 （ARIMAファミリー）モデルは、トレーニング時間と予測時間の間の完全な履歴を必要とします。 DataRobotは、これらのモデルのスコアリングを 予測APIで行うことをお勧めします。

  • 他のすべての時系列モデルは、プロジェクトによって異なりますが、特徴量派生ウィンドウを埋めるに十分な履歴のみを必要とします。 交差系列の場合、予測時刻にすべての系列が提供される必要があります。

  どちらのカテゴリーのモデルもリアルタイム予測をサポートしており、最大ペイロードサイズは50MBです。

• ARIMAファミリーと非ARIMA系列間モデルはバッチ予測をサポートしていません。

• 他のすべての時系列モデルはバッチ予測をサポートしています。 複数系列の場合、入力データはIDとタイムスタンプでソートする必要があります。

• サポートされているモデルの時系列バッチ予測については、単一系列で50 MBを超えられないこと以外にデータ制限はありません。

• 統合エンタープライズデータベースを使用して連続値時系列モデルをスコアリングする際、ターゲットデータベースに以下の列が含まれるはずだが見つからなかったという注意が受信されることがあります：DEPLOYMENT_APPROVAL_STATUS。 オプションである列は、デプロイされたモデルが管理者により承認されたかどうかを記録します。 組織でデプロイ承認ワークフローが設定されている場合、次のことができます。

  • ターゲットデータベースに列を追加します。

  • columnNamesRemappingパラメーターを使用して別の列にデータをリダイレクトします。

  上記のいずれかのアクションを行った後は、予測ジョブを再度実行すると、承認ステータスが予測結果に表示されます。 承認ステータスを記録していない場合は、メッセージを無視して予測ジョブが継続されます。

• DataRobotがデプロイ予測のために時系列データを処理できるようにするには、次の要件を満たすようにデータセットを設定します。

  • 予測行をタイムスタンプでソートします。最も古い行が最初に表示されます。

  • 複数系列では、予測行を系列IDでソートし、さらにタイムスタンプでソートします。

  • DataRobotがサポートする系列の数には制限はありません。 唯一の制限は、ジョブのタイムアウトです。 詳細については、バッチ予測の制限を参照してください。

  データセットの例については、スコアリングデータセットの要件をご覧ください。

多クラスデプロイ¶

• ターゲット、精度、およびデータドリフトが監視される多クラスデプロイで最大100クラスをサポートします。

• 再トレーニングされる多クラスデプロイで、最大100クラスをサポートします。

• 特徴量ドリフトを有効にしたバージョン7.0より前に作成された多クラスデプロイには、ターゲットの特徴量ドリフトの履歴データはありません。新しいデータのみが追跡されます。

• DataRobotは、ホールドアウトデータをターゲットドリフトのベースラインとして使用します。 特定のデータセットを使用する多クラスデプロイの場合、まれなクラス値がホールドアウトデータで欠損し、その結果、ドリフトのベースラインで欠損することがあります。 このシナリオでは、これらのまれな値は新しい値として扱われます。

チャレンジャー¶

• チャレンジャーを有効にし、それらに対する予測を再生するには、デプロイ済みモデルがターゲットドリフト追跡をサポートしている必要があり、また、 特徴量探索あるいは 非構造化カスタム推論 モデルではないことが条件です。

• チャレンジャーに対する予想を再生するには、デプロイに関連付けられている 組織に所属している必要があります。 この制限はデプロイ 所有者にも適用されます。

予測結果のクリーンアップ¶

DataRobotはデプロイごとにクリーンアップジョブを定期的に実行し、Postgresの対応する予測結果テーブルからデプロイの予測値と実測値を削除します。 この処理はテーブルのサイズを適切に保つために行われ、テーブルサイズの制限に達する危険を冒すことなく、すべてのデプロイの精度指標を一貫して生成し、チャレンジャーモデルの再生をスケジュールできます。

クリーンアップジョブによってデプロイが予測結果テーブルの「ハード」制限に達することが防止されます。テーブルがいっぱいになると、予測値と実測値は保存されなくなり、デプロイの追加の精度指標を生成できなくなります。 クリーンアップジョブは、デプロイが「ソフト」制限に達するとトリガーされ、デプロイが「ハード」制限に達するのを防ぐためのバッファーとして機能します。 クリーンアップでは、対応する実測値にすでに関連付けられている最も古い予測行から削除されます。 データドリフトおよび時系列の精度を向上させるために使用される集計データは影響を受けません。

マネージドAIプラットフォーム¶

マネージドAIプラットフォームユーザーには、1時間ごとに次の制限があります。 各デプロイが許可されます。

• データドリフト分析：100万の予測、または個々の予測インスタンスごとに合計100 MBの予測がリクエストされます。 いずれかの制限に達した場合、データドリフト分析はその1時間の残りの間停止します。

• 予測行ごとの履歴保存：個々の予測インスタンスのデプロイごとの合計予測リクエストの最初の100 MB。 制限に達した場合、その1時間の残りの時間の予測データは収集されません。