モデルの準備の概要

このページでは、AML AI モデルを準備する手順を説明します。インスタンスがすでに設定され、必要なデータセットが準備されていることを前提としています。

ステージの概要

モデルを準備するプロセスは、次の 3 つのステージで行われます。

• ステージ 1: エンジンを構成します。たとえば、ハイパーパラメータのソースを選択します。

  • 調整: ハイパーパラメータの自動調整
  • 継承: 同じ調整バージョン内の以前のエンジン バージョンを使用して作成された以前のエンジン構成から、ハイパーパラメータを継承します。 この設定により、新しいモデルエンジン バージョンを採用するたびに再調整を行う必要がなくなります。

  エンジン構成を作成すると、調整または継承の結果が EngineConfig リソースに保存されます。

• ステージ 2: モデルの生成

  モデルの作成によってトレーニングがトリガーされ、その結果がモデルリソースとして保存されます。

• ステージ 3: モデルの評価

  バックテスト結果の作成では、指定された月のセットでモデルのパフォーマンスを評価し、サマリー結果を BacktestResult リソースに保存します。 必要に応じて、予測結果を作成すると、モデルの当事者ごとの出力を評価できます。

前のステージを完了し、モデルのパフォーマンスがニーズを満たしている場合は、リスクスコアと説明可能性の生成とモデルとリスク ガバナンスの準備のセクションのガイダンスをご覧ください。

始める前に

始める前に、次のものが必要になります。

• 1 つ以上のデータセット
• 使用する、選択したエンジン バージョン

データセットの要件

データモデルとスキーマの詳細なガイダンスについては、AML AI 用にデータを準備するのページをご覧ください。このセクションでは、エンジンの調整、トレーニング、評価で使用されるデータセットが連携して機能することを確認する方法について説明します。

注: ほとんどのモデル ガバナンス ポリシーでは、エンジン構成、トレーニング、評価のすべての ML オペレーションで使用されるデータリネージを追跡するための要件が定義されています。データが変更されないようにするため、データ検証に合格した後に BigQuery テーブルの BigQuery テーブル スナップショットを作成し、AML AI データセットでスナップショットを参照することをおすすめします。定期的に更新されるテーブルを参照する場合、AML AI オペレーションは、オペレーションで AML AI データセットを使用するたびに BigQuery テーブルを読み取ります。そのため、基盤となる BigQuery テーブルを変更すると、チューニング、トレーニング、バックテスト、予測に影響する可能性があります。

データセットの期間

各オペレーションにおけるデータセットの最小期間については、データ スコープと期間についてをご覧ください。 まとめると、テーブルに応じて、同じデータセットでのすべてのオペレーションをカバーするには、少なくとも 18 か月のコア時間枠に加えて、0 から 24 か月のルックバック ウィンドウが必要です。個々のオペレーションには、より短いデータセットを使用できます（たとえば、エンジン構成を再利用し、新しい調整を行う必要がない場合など）。

たとえば、エンジンの調整の場合、Transaction テーブルは少なくとも 42 か月（18 か月のコア時間枠および 24 か月のルックバック ウィンドウ）をカバーする必要があります。

エンジン、トレーニング、評価（バックテスト）の構成は、1 つのデータセットで完了できます。次の図をご覧ください。過学習を回避することで本番環境のパフォーマンスを維持するために、評価のコア時間枠（つまり、バックテスト結果の作成）を使用する必要があります。これは、分離され、トレーニングのコア時間枠よりも最新の（つまり、モデルの作成）のものです。

データセットの整合性

エンジンの調整、トレーニング、評価の各ステージで異なるデータセットを使用する場合は、各フィールドでデータの入力方法に一貫性を持たせてください。これは、AML モデルの安定性とパフォーマンスにとって重要です。

同様に、高品質のリスクスコアの場合、モデルを使用して予測結果を作成するために使用するデータセットは、そのモデルのトレーニングに使用するデータセットと一致する必要があります。

特に、次の点を確認してください。

• 各フィールドの入力にも、同じロジックが使用されます。フィールドに入力するためのロジックを変更すると、モデルのトレーニングと予測や評価との間に特徴の偏りが生じる可能性があります。
• 同じ RECOMMENDED フィールドの選択が入力されます。たとえば、モデルのトレーニング中に入力されたフィールドを削除すると、モデルが依存している特徴が評価時または予測時に偏ったり、欠落したりする可能性があります。

• 同じロジックを使用して値が提供されます。PartySupplementaryData テーブルでは、同じロジックを使用して各 party_supplementary_data_id フィールドの値を指定しています。

  • 同じデータを使用していて、party_supplementary_data_id 値が異なる場合、モデルがデータを正しく使用しません。たとえば、特定のフィールドで、1 つのデータ・セットの PartySupplementaryData テーブルで ID 5 を使用し、他のデータセットで ID 7 を使用します。
  • モデルが依存している party_supplementary_data_id 値を削除すると、予期しない結果が生じる可能性があります。たとえば、ID 3 は、1 つのデータセットの PartySupplementaryData テーブルでは使用されていますが、別のデータセットでは省略されています。

これで、エンジンの調整、トレーニング、評価に使用するデータセットの準備が整いました。モデルのオペレーションには数十時間かかることがあります。オペレーションがまだ実行中であるか、完了（失敗または成功）したかどうかを確認する方法については、長時間実行オペレーションの管理をご覧ください。