モデルの準備の概要

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

ステージの概要

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

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

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

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

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

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

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

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

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

始める前に

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

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

データセットの要件

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

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

データセットの期間

チューニング、トレーニング、バックテスト、予測オペレーションに使用する各データセットには、API 呼び出しで指定された end_time より前の最後の暦月末までの期間の有効なデータが含まれている必要があります。この時間範囲の長さは、テーブル、エンジン バージョン、オペレーションによって異なります。最小期間については、データ スコープと期間を理解するで詳しく説明しています。

たとえば、v004.004 エンジン バージョンでのエンジン チューニングの場合、Transaction テーブルは少なくとも 30 か月をカバーする必要があります。

エンジン、トレーニング、評価（バックテスト）の構成は、単一のデータセットで完了できます。次の図をご覧ください。過学習を回避して本番環境のパフォーマンスを達成するには、評価に使用する期間（バックテスト結果の作成）が、トレーニングに使用する期間（モデルの作成）の後になるようにする必要があります。

たとえば、バックテストに 3 つの期間を使用し、トレーニングに 2024 年 2 月末までの期間（終了時間は 2024 年 3 月上旬）を使用する場合は、バックテストに 2024 年 5 月末までの期間（終了時間は 2024 年 6 月上旬）を使用できます。

データセットの整合性

エンジンの調整、トレーニング、評価の各ステージで異なるデータセットを使用する場合は、各フィールドでデータの入力方法に一貫性を持たせてください。これは、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 テーブルでは使用されていますが、別のデータセットでは省略されています。

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