この記事のトピックは次のとおりです。
すべての表形式データモデルのベスト プラクティス
以下のベスト プラクティスは、AutoML モデルまたは表形式データを使用するカスタム トレーニング モデルを作成する場合に適用されます。
データ漏洩を避ける
予測を求める際に利用できない予測情報がトレーニング データに含まれていると、データ漏洩が発生します。データ漏洩があると、モデルは優れた評価指標を示しますが、実際のデータではパフォーマンスが悪化します。
たとえば、明日どのくらいの量のアイスクリームが売れるか知りたいとします。ターゲットとする日の気温をトレーニング データに含めることはできません。未来の正確な気温は事前にはわからないからです。しかし、前日から予測した気温を予測リクエストに含めることができます。
複数のデータ分割で同じデータを使用した場合もデータ漏洩が発生する可能性があります。時系列データを使用している場合は、同じ日付のデータが 3 つのデータ分割のいずれかでのみ使用されるようにします。
トレーニング / サービング スキューを避ける
トレーニング / サービング スキューは、予測をリクエストするために使用するデータを作成するのと異なる方法でトレーニング データを作成すると起こります。
たとえば平均値を使用する場合で、トレーニングの際は 10 日間の平均を出し、予測をリクエストするときは過去 1 か月の平均を出すなどです。
一般に、トレーニング データを作成する方法とサービング データ（予測を生成するために使用するデータ）を作成する方法の間に違いがある場合は、トレーニング / サービング スキューを防ぐために確認する必要があります。
トレーニング / サービング スキューとデータ分布
トレーニング / サービング スキューは、トレーニング、検証、テストのデータ分割におけるデータ分布に基づいて発生することもあります。本番環境にデプロイされたときにモデルに示されるデータ分布と、モデルのトレーニングに使用されるデータセットのデータ分布には、多くの場合違いがあります。たとえば、本番環境では、モデルは、トレーニング中に見られるのとはまったく異なるユーザーの集団に適用されることがあります。また、最終的なトレーニング データが記録されてから 30 日後に予測に使用されることもあります。
最良の結果を得るには、モデルの作成に使用されるデータ分割の分布が、トレーニング データと本番環境で予測を行うデータの違いを正確に反映するようにします。Vertex AI は単調でない予測を生成する可能性があります。本番環境のデータがトレーニング データとは非常に異なる分布からサンプリングされる場合、単調でない予測はあまり信頼性がありません。
さらに、本番環境のデータとトレーニング データの違いは、検証データ分割とトレーニング データ分割の違い、およびテストデータ分割と検証データ分割の違いに反映される必要があります。
たとえば、今後 30 日間にわたってユーザー ライフタイム バリュー（LTV）の予測を行う場合は、検証データ分割のデータがトレーニング データ分割のデータの 30 日後のものであり、テストデータ分割のデータが検証データ分割の 30 日後のものであることを確認します。
同様に、モデルを調整して新しいユーザーに関する一般的な予測を行う場合は、特定のユーザーのデータがトレーニング データの 1 つの分割のみに含まれるようにします。たとえば、user1 に関連するすべての行はトレーニング データ分割に含まれ、user2 に関連するすべての行は検証データ分割に含まれ、user3 に関連するすべての行はテストデータ分割に含まれるようにします。
タイムシグナルを提供する
分類モデルと回帰モデルで、データの基礎となるパターンが時間の経過とともに変化する可能性がある場合（時間内でランダムに分布していない場合）、その情報を Vertex AI に確実に提供するようにください。タイムシグナルは、次のような方法で提供できます。
データの各行にタイムスタンプがある場合は、その列を含めるようにし、変換型が
Timestampであり、モデルをトレーニングするときに、[時間] 列として設定されるようにします。この順序付けは、データを分割して、最新のデータをテストデータにし、最古のデータをトレーニング データとするために使用されます。詳細[時間] 列にある個別の値が多くない場合は、[時間] 列を使用するのではなく、手動分割を使用してデータを分割する必要があります。そうしないと、各データセットで十分な行が得られず、トレーニングが失敗する可能性があります。
時刻情報が単一の列に含まれていない場合は、手動データ分割を使用して最新のデータをテストデータとして使用し、最も古いデータをトレーニング データとして使用できます。
情報を必要に応じて明確化する
一部のデータ プリミティブでは、特徴を設計することによってモデルの品質を向上させることができます。
たとえば、データに経度と緯度が含まれている場合、これらの列は数値として扱われ、特別な計算は行われません。場所や距離が問題のシグナルを出す場合は、その情報を明示的に提供する特徴を設計する必要があります。
特徴エンジニアリングが必要になることがある一部のデータ型を次に示します。
- 経度 / 緯度
- URL
- IP アドレス
- メールアドレス
- 電話番号
- その他の地理コード（郵便番号など）
計算データまたは集計データを行に含める
Vertex AI は、1 行の入力データのみを使用して、その行のターゲット値を予測します。行の予測値の決定に役立つ他の行やソースの計算データまたは集計データがある場合は、そのデータをソース行に含めます。新しい列でデータ漏洩やトレーニング / サービング スキューが発生しないように注意してください。
たとえば、商品の翌週の需要を予測する場合、次の値を持つ列を含めることで予測の品質を改善できます。
- 商品と同じカテゴリの在庫品目の合計数。
- 商品と同じカテゴリの在庫品目の平均価格。
- 予測がリクエストされたときから既知の休日までの日数。
- その他
別の例では、特定のユーザーが商品を購入するかどうかを予測する場合、次の値を持つ列を含めることで予測の品質を改善できます。
- 特定のユーザーの過去の平均コンバージョン率またはクリック率。
- 現在ユーザーのショッピング カートにある商品の数。
偏りを避ける
トレーニング データは、予測の対象となる潜在的データの全領域を表すものになるようにしてください。たとえば、顧客が世界中にいる場合は、1 つの国だけのトレーニング データを使用すべきではありません。
表形式の AutoML モデルのベスト プラクティス
AutoML 表形式のモデル用に表形式のトレーニング データを作成するのがベスト プラクティスです。
null 値を適切に表す
CSV からインポートする場合、null 値は空の文字列で表してください。BigQuery からインポートする場合は、NULL 値を使用してください。
データで特殊文字または数字を使用して null 値（ゼロを含む）を表すと、これらの値が誤って解釈され、モデルの品質が低下します。
可能であれば欠損値を避ける
データに欠損値がないか確認し、可能であれば修正します。それ以外の場合は、値を空白のままにして null 値として扱うことができます。
スペースを使ってテキストを区切る
Vertex AI はテキスト文字列をトークン化して、個々の単語からトレーニング シグナルを導き出すことができます。単語はスペースで区切られるため、他の文字で区切られている単語は 1 つのエンティティとして扱われます。
たとえば、テキスト「red/green/blue」を指定した場合、「red」、「green」、「blue」にトークン化されません。これらの個々の単語がモデルのトレーニングで重要になるかもしれない場合は、このテキストを「red green blue」に変換してからトレーニング データに含めてください。
カテゴリ型の特徴を正確かつクリーンにする
データの不整合が原因でカテゴリが誤って分割される可能性があります。たとえば、データに「Brown」と「brown」が含まれている場合、この値を同じカテゴリと考えていた場合でも、Vertex AI は別のカテゴリとして使用します。スペルミスも同様の結果になります。トレーニング データを作成する前に、こうした種類の不整合をカテゴリデータから削除しておいてください。
分類モデルのクラスの不均衡に十分に注意する
クラスが不均衡（めったに見られない、1 つ以上の結果に関連する分類上の問題）である場合は、次のヒントをご覧ください。
少数派のクラスに十分なトレーニング データを用意する
1 つのクラスでデータが数行しかないと、モデルの質が低下します。可能であれば、すべてのクラスに 100 行以上のデータを用意してください。
手動分割の使用を検討する
Vertex AI は、テスト データセットの行をランダムに（しかし確定的に）選択します。クラスが不均衡である場合、テスト データセットに少数派のクラスがごくわずかしか、あるいはまったく含まれず、トレーニングが失敗することがあります。
クラスが不均衡である場合は、手動分割を割り当てて、少数派の結果を含む十分な行数をすべての分割に含めることができます。
十分なトレーニング データを用意する
十分なトレーニング データを提供しない場合、結果として得られるモデルのパフォーマンスが悪くなる場合があります。モデルのトレーニングに使用する列が多いほど、提供する必要があるデータは多くなります。
データセットは必ず 1,000 行以上にしなければなりません。
次の表は、目的に応じて、用意するトレーニング データ量に関するヒューリスティクスを示したものです。
| 目的 | 推奨されるトレーニング データの最小量 |
|---|---|
| 分類 | 列数の 10 倍以上の行数。 |
| 予測 | モデルのトレーニングに使用する列ごとに 10 以上の時系列。 |
| 回帰 | 列数の 50 倍以上の行数。 |
他のすべての前処理と変換を Vertex AI に残す
特に断りのない限り、AutoML モデルをトレーニングするときに、Vertex AI に特徴量エンジニアリングを委ねます。AutoML は、基になるデータにアクセスできる場合に最良の性能を発揮します。AutoML が変換タイプで行うすべての変換については、Vertex AI の変換をご覧ください。
表形式の予測モデルのベスト プラクティス
予測モデル用のトレーニング データには、特別な考慮事項があります。
データの粒度を選択する際の考慮事項
予測モデルをトレーニングする場合は、データの粒度、つまりトレーニング データ行の間の時間間隔を指定します。時間間隔は、時間、日、週、月、年の単位で指定できます。また、1 分ごと、5 分ごと、10 分ごと、15 分ごと、30 分ごとの単位でも指定できます。
データの粒度は、トレーニング データとすべてのバッチ予測データとの間で一貫している必要があります。1 日単位の粒度を指定し、2 つのトレーニング データ行の間に 2 日ある場合、Vertex AI は中間の日を欠落データとして扱い、モデルのパフォーマンスを低下させる可能性があります。同じタイプスタンプを持つ同じ時系列内の複数の行（粒度によって決定される）は、トレーニング時に検証エラーとみなされます。
通常は、データ収集方法によってデータの粒度を決定します。
コンテキスト ウィンドウに適切な値を見つける方法
過去には拡張しない予測データ（コールド スタート）が大量に発生すると予想される場合は、まずコンテキスト ウィンドウを 0 に設定します。それ以外の場合は、予測ホライズンのサイズと予測ホライズンのサイズの 10 倍の間にコンテキスト ウィンドウを設定すると、正常に機能します。
データに合った値を見つけるには、以下の手順をお試しください。
最初のトレーニング イテレーションで、コンテキスト ウィンドウと予測ホライズンに同じ値を設定し、トレーニング予算を 6 時間以上に設定します。
同じトレーニング予算を設定して再度モデルをトレーニングしますが、コンテキスト ウィンドウのサイズを、予測ホライズンの 2 倍まで倍増させます。
2 回目のモデルの評価指標が大幅に改善された場合は、コンテキスト ウィンドウを予測ホライズンのサイズの 5 倍に増やして、モデルを再度トレーニングします。トレーニング予算も比例して増加させることを検討してください（最初の手順で 10 時間トレーニングした場合は、トレーニング予算を 50 時間に増やします）。
評価指標の改善が見られなくなるか、結果に満足するまで、コンテキスト ウィンドウを増やしてください。許容される結果をもたらしたコンテキスト ウィンドウの最小値まで戻してください。
コンテキスト ウィンドウを増やすと、次のような影響があります。
トレーニング時間が長くなる
コンテキスト ウィンドウを増やすと、モデルはより多くのデータポイントを使用するため、トレーニング時間が長くなります。
必要な予測データの履歴の量が増加する
予測データは、コンテキスト ウィンドウの値と同程度の数の履歴データポイントを提供する必要があります。
データ形式のベスト プラクティス
トレーニング データは、ワイド形式またはナロー形式のどちらでも作成できます。回帰モデルと分類モデルでは、ワイド形式が広く使用され、構築と確認をより簡単に行えます。予測モデルでは、ナロー形式を使用すると、データとターゲット（データ漏洩）との間の意図しない接続の設定を回避できます。
予測モデルをトレーニングするためのトレーニング データを作成する場合、各行は 1 つの時系列で 1 つの観測値を表す必要があります。時系列識別子（時系列を他の時系列と区別する方法）を表す列と、予測する値（ターゲット）を表す列が必要です。次に、ターゲットの予測をリクエストするとき、モデルのトレーニングに使用される行に、他のすべての値が存在している必要があります。
以下の（簡略化され省略された）サンプル トレーニング データを考えてみましょう。
| 日付 | ウィジェット_1_需要 | ウィジェット_2_需要 | ウィジェット_3_需要 | 割引 | 地域 |
|---|---|---|---|---|---|
| 01/01/2019 | 112 | 241 | 0 | 0 | CA |
| 01/02/2019 | 141 | 219 | 0 | 1 | CA |
| 01/03/2019 | 149 | 244 | 0 | 0 | CA |
| 01/01/2019 | 52 | 0 | 43 | 0 | IL |
| 01/02/2019 | 81 | 0 | 26 | 1 | IL |
| 01/03/2019 | 89 | 0 | 86 | 0 | IL |
この表はワイド形式で、ビジネスデータが日付ごとに表示されていますが、現在の形式では予測モデルでは使用できません。ターゲット列が 1 つではなく、時系列 ID 列もありません。また、特定の日付では、予測時の他のウィジェットの需要は把握できません。
このテーブルは次の形式に変換できます。
| 日付 | 商品 | 地域_CA_需要 | 地域_IL_需要 | 割引 |
|---|---|---|---|---|
| 01/01/2019 | ウィジェット_1 | 112 | 52 | 0 |
| 01/02/2019 | ウィジェット_1 | 141 | 81 | 1 |
| 01/03/2019 | ウィジェット_1 | 149 | 89 | 0 |
| 01/01/2019 | ウィジェット_2 | 241 | 0 | 0 |
| 01/02/2019 | ウィジェット_2 | 219 | 0 | 1 |
| 01/03/2019 | ウィジェット_2 | 244 | 0 | 0 |
| 01/01/2019 | ウィジェット_3 | 0 | 43 | 0 |
| 01/02/2019 | ウィジェット_3 | 0 | 26 | 1 |
| 01/03/2019 | ウィジェット_3 | 0 | 86 | 0 |
時系列 ID として使用できる「商品」列を作成しました。ただし、この形式は一方の地域の予測にのみ使用できます。もう一方の地域のデータは、予測時には把握している必要があります。
解決方法は、各行が 1 つの観測値を表すように、この表をナロー形式に変換することです。時系列に依存しないデータは、各行で繰り返されます。
| 日付 | 需要 | ID | 割引 |
|---|---|---|---|
| 01/01/2019 | 112 | ウィジェット_1_CA | 0 |
| 01/02/2019 | 141 | ウィジェット_1_CA | 1 |
| 01/03/2019 | 149 | ウィジェット_1_CA | 0 |
| 01/01/2019 | 52 | ウィジェット_1_IL | 0 |
| 01/02/2019 | 81 | ウィジェット_1_IL | 1 |
| 01/03/2019 | 89 | ウィジェット_1_IL | 0 |
| 01/01/2019 | 241 | ウィジェット_2_CA | 0 |
| 01/02/2019 | 219 | ウィジェット_2_CA | 1 |
| 01/03/2019 | 244 | ウィジェット_2_CA | 0 |
| 01/01/2019 | 0 | ウィジェット_2_IL | 0 |
| 01/02/2019 | 0 | ウィジェット_2_IL | 1 |
| 01/03/2019 | 0 | ウィジェット_2_IL | 0 |
| 01/01/2019 | 0 | ウィジェット_3_CA | 0 |
| 01/02/2019 | 0 | ウィジェット_3_CA | 1 |
| 01/03/2019 | 0 | ウィジェット_3_CA | 0 |
| 01/01/2019 | 43 | ウィジェット_3_IL | 0 |
| 01/02/2019 | 26 | ウィジェット_3_IL | 1 |
| 01/03/2019 | 86 | ウィジェット_3_IL | 0 |
これで、時系列識別子（ID）、ターゲット列（需要）、時間列（日付）の列が作成されました。また、各行は 1 つの観測値に基づいており、これを使用してターゲット値を予測できます。割引列は、モデルをトレーニングするための特徴として使用されます。
実際には、この例よりも多くの行と列が必要になります。ただし、データ漏洩を防ぐためには、ここで説明したガイドラインに沿ってデータを構造化する必要があります。