モデルのトレーニングとデプロイ

データをクレンジングして準備し、Object Storageに移動すると、モデルをトレーニングしてデプロイできます。

モデルの作成とトレーニング

モデルを作成する場合は、トレーニング・データ・アセットを指定し、いくつかのパラメータを設定します。モデルは、作成時に自動的にトレーニングされます。

次のダイアグラムに、プロセスを示します。

training-flow.pngの説明が続きます
図training-flow.pngの説明

モデルの作成およびトレーニングのプロセスは次のとおりです。

  1. プロジェクトを作成します。OCIのコンパートメントにプロジェクトを作成し、プロジェクトに名前を付けます。コンパートメントは、1つ以上の異常検出プロジェクトの保持専用です。
  2. オブジェクト・ストレージ内のファイルであるトレーニング・データ・アセットを指定します。ファイルはクリーンで、トレーニングの準備ができている必要があります。そうでない場合は、Data ScienceなどのOCIサービスを使用して、クリーニングと前処理を実行できます。ファイルはCSV形式またはJSON形式です。
  3. モデルを作成します。モデルを作成する場合は、トレーニング・データ・アセットを選択し、「False Alarm Probability」および「Training Fraction Ratio」を設定します。モデルは作成プロセスの一部としてトレーニングされます。

異常検出サービス・ドキュメントには、これを実行する方法の詳細な手順が記載されています。コンソールUIを使用するか、REST APIを使用できます。

誤アラーム確率と電車の分率を設定するガイダンスをいくつか示します。

False Alarmの確度
これは、検出された異常が実際に異常ではない可能性です。この値は、実際のビジネス・シナリオで見つかった異常の割合と同じレベルに近いレベルに設定します。値0.01 (1%)は、多くのシナリオに適しています。値が低いほど、モデルのトレーニングにかかる時間が長くなります。また、ターゲットの偽アラーム確率を低すぎると、モデルはターゲットを達成しない可能性があります。
トレインの分数比率
これは、研修に使用されるデータの量です。たとえば、値が0.7の場合、データの70%がトレーニングに使用され、モデルのパフォーマンスのテストと評価に30%が使用されます。

モデルのデプロイおよびテスト

モデルを作成した後は、それを使用する前にデプロイする必要があります。

モデルがデプロイされると、異常がないかテストするデータを受信できます。

コンソールUIを使用してモデルをデプロイすることも、REST APIを使用することもできます。モデルをデプロイするときは、名前を付けます。説明も入力できますが、これはオプションです。モデルは、複数のデプロイメントを持つことができます。

次のスクリーンショットは、コンソールUIのモデルの例を示しています。デプロイメントを追加するには、「デプロイメントの追加」ボタンをクリックします。

add-deployment.pngの説明が続きます
図add-deployment.pngの説明

異常の検出

バッチで異常検出のためにデータを発行することも、ストリーミング・データの異常を検出することもできます。

次の図は、バッチ処理のアーキテクチャを示しています。

forecast-batch-flow.pngの説明が続きます
図dictions-batch-flow.pngの説明

バッチは次のように処理されます。

  1. データは、ストリーミングまたは他のデータベースからOracle Data Integrationを介してObject Storageバケットに収集されます。
  2. Object Storageは、異常検出サービスによって処理されるバッチ・データのランディング・ゾーンです。
  3. データの前処理は、ホストされているアプリケーション、コンテナ、またはサーバーレス関数で実行できます。処理されたデータは異常検出サービスに送信されます。
  4. 異常検出サービスは、トレーニング・フェーズでトレーニングおよびデプロイされたモデルを使用して予測を行います。
  5. 異常検出サービスによって生成される会議は、REST経由でアプリケーションまたは通知プラットフォームに送信される即時アクションになります。
  6. 異常検出サービスの推論結果をオブジェクト・ストレージに格納して、後で分析、ロギングおよび通知サービスで使用できます。

ストリーミング・アーキテクチャはバッチ・アーキテクチャよりも複雑ですが、リアルタイムの異常検出やほぼリアルタイムで検出される場合は必要です。

次の図は、ストリーミング・アーキテクチャを示しています。

forecast-streaming-flow.pngの説明が続きます
図dictions-streaming-flow.pngの説明
  1. ストリーミング・サービスは、異なるストリーミング・データ・ソースからデータを取得します。
  2. データ前処理(必要な場合)は、ホストされるアプリケーション、コンテナまたはサーバーレス関数によって実行されます。処理されたデータは、異常検出サービス・ストリーム・インタフェースに送信されます。データがよく知られており、追加の処理が不要な場合、ストリームは異常検出サービスに直接接続できます。
  3. 異常検出サービスは、トレーニング・フェーズでトレーニングおよびデプロイされたモデルを使用して予測を行います。
  4. 異常検出サービスは、アクションの実行およびロギングのために出力ストリームに推論をポストします。
  5. 異常検出サービスによって生成される会議は、VMまたはコンテナ上のアプリケーションまたはサーバーレス関数を介してアプリケーションまたは通知プラットフォームに送信される即時アクションになります。
  6. 異常検出サービスからの出力ストリームは、ダウンストリーム工程および分析のパイプラインを移入できます。

異常検出サービスの推論結果をオブジェクト・ストレージに格納して、後で分析、ロギングおよび通知サービスで使用できます。