時系列プロジェクトのカスタマイズ¶

DataRobotはデフォルトのウィンドウ設定（特徴量派生 と 予測ウィンドウ）および時系列プロジェクトの パーティションサイズを指定します。 これらの設定はデータセットの特性に基づいているため、通常はそのままにしておくと、堅牢なモデルになります。

デフォルト設定を変更することを選択した場合、プロジェクトの設定時には、実際の予測リクエストを作業環境と一致させる必要があることに注意してください。 ユースケースとは無関係に高い精度を得るためにコンテキスト外でプロジェクト設定を変更すると、多くの場合、期待外れの結果となります。

次のリファレンスでは、DataRobotがデフォルト、要件、およびその他の設定の選択を決定する方法について説明します。

• ウィンドウ値の設定に関するガイダンス。

• 以下を含むバックテストの理解：

  • バックテストの設定。
  • バックテストの有用性。
  • トレーニングデータからの 行の選択と使用の背後にあるロジック。

• 期間と行数の理解。

• DataRobotによる トレーニングと検証フォールドの処理方法。

• トレーニング期間の変更方法。

さらに、デプロイ前に モデルの再トレーニングに関するガイダンスを参照してください。

ウィンドウ値の設定¶

特徴量派生ウィンドウを使用して、DataRobotがモデリングデータセットの 特徴量派生に使用するデータ期間を設定します。

左側の特徴量の派生ウィンドウ（1）で、特徴量の派生に使用する時間履歴に制約を加えます。 ここでは、予測を作成するために必要なデータの量を決定する値の数を決定します。 （トレーニングパーティションによって決定される、モデリングに使用される時間履歴を制約するものでは ありません 。） 上記の例では、最も最近の35日分のデータが使用されます。

DataRobotは、データセットの時間単位に基づいてウィンドウの値を自動推奨します。 たとえば、特徴量派生ウィンドウの一般的な期間は、およそ1か月の設定（ 「35～0日」）、または分ベースのデータの場合は1時間単位（60～0分）です。 これらの設定は、いくつかの重要なラグを表示するのに十分なカバレッジを提供しますが、無関係なラグ特徴量が派生するほどではありません。 特徴量削減プロセスは、良い情報を生成しないラグを取り除くため、幅が広すぎる特徴量派生ウィンドウを作成すると、必ずしも利点が追加されるわけではなく、構築時間が長くなります。 （DataRobotは、ローリング統計に使用するウィンドウの制限に、特徴量派生ウィンドウのサイズに関係なく、最大5つのラグを作成します。）

時間単位が年単位のデータを扱っている場合を除き、たとえば昨年の2月に起こったことと、今年の2月に起こることとが関連することはめったにありません。 過去の特定の日付が関連する場合があります。この場合、年間の有用性と年間の遅れを判断するには、カレンダーを使用するのが適切です。 日次データの場合、主な季節性は週単位である可能性が高いため、365日の特徴量派生ウィンドウは必要なく、結果が改善される可能性が低くなります。

右側の予測ウィンドウ（2）はモデル出力の予測の時間範囲を設定します。 この例では、予測ポイントの1～7日までの予測を作成するように設定しています。 表示される時間単位（この場合は日）は、時間/時刻の特徴量を選択したときに検出された単位に基づきます。

ウィンドウには検出された時間単位または行数を指定できます。 DataRobotでは、その選択（Price (7 days average)またはPrice (7 rows average)）を使用して移動統計量が計算されます。 時間ベースのオプションが利用可能な場合は、それを使用してください。 行ベースのウィンドウで設定した場合、共通のイベントパターンや季節性は検出されません。 しかし、DataRobotでは、不規則な日付/時刻特徴量を含むデータセットの特殊な方法で処理できます。 データセットが不規則な場合、ウィンドウ設定はデフォルトで行ベースになります。

これらの値は変更できます（変更を行うと表示も更新されます）。 たとえば、データにリアルタイムでアクセスできない場合や新しすぎるデータにモデルを依存させるべきでない場合があります。 その場合は、特徴量派生ウィンドウ（以下の計算ではFDW）を変更し、利用できる最新データの末尾に移動します。 行動を起こすための時間が足りないという理由で明日の予測が必要ない場合は、予測を開始する時点にFWを変更します。 その後、DataRobotでのモデルの最適化方法が変更され、設定された範囲に対する精度を比較する目的でモデルがリーダーボードで格付け（ランキング）されます。

ギャップを理解する¶

特徴量派生ウィンドウと予測ウィンドウを設定すると、期間のギャップが作成されます（ ギャップの長さ設定のギャップと混同しないでください）。

• ブラインド履歴 とは、実際にデータを取得/受信してから予測が実際に行われるまでの時間ウィンドウです。 具体的には、特徴量派生ウィンドウの最新の時刻から予測ポイントまでです。
• 運用不可 とは、短期的すぎて役に立たない期間を表します。 具体的には、予測ポイントの直後から予測ウィンドウの開始点までです。

ブラインド履歴の例¶

ブラインド履歴は、行っている予測が遅延のあるデータを使用しているという事実を説明します。 ブラインド履歴ギャップの設定は、主に _予測時_のデータの状態に関連しています。 データの取得元とそれに伴う遅延を誤解している場合、実際の予測はモデルが示唆するほど正確ではない可能性があります。

別の言い方をすれば、データを見て、「2年間の日次データがあります。私のデータセットには常に前日データがあるので、ギャップはありません」と言うことができます。 トレーニング の観点からは、これは事実です。 トレーニング データに関連する「現在」の観点からデータを表示している場合、データに目に見えるまたは明らかなギャップがある可能性はほとんどありません。

実際の予測データ元を理解することが重要です。 以下の点に注意してください。

• 企業では、週に1回実行される大規模なバッチジョブで利用可能なすべてのデータを処理します。
• 履歴データを収集してモデルをトレーニングしますが、この遅延を認識していません。
• 企業が取り組むための2週間の予測を作成するモデルを構築します。
• モデルは本番環境に入りますが、予測が「ずれている」理由がわかりません。

ここで理解しにくいのは次の点です。

いつでも、入手できる最も信頼できるデータが X 日前のものである場合、モデリングにそれより新しいデータを使用することを保証できません。

ブラインド履歴を使用して、短期的なバイアスをカットすることもできます。 たとえば、過去24時間のデータが非常に変動しやすい場合には、ブラインドギャップを使用してその入力を無視します。

運用不可の例¶

店舗にある在庫のパンの量を予測していて、短期的すぎて役に立たない期間があるとします。

• パンの注文を処理する（在庫が店舗に到着する）までに2日かかります。

• 1〜2日前の予測は役に立ちません。これらの予測に対してアクションを実行することはできません。

• 「運用不可」ギャップ = 2日間。

• この設定では、生成された予測の3日後に予測が行われるため、パンを注文して在庫を確保するのに十分な時間が確保されます。

バックテストの設定¶

バックテストは、モデルが経験する可能性のある実際の予測環境をシミュレートします。 ユースケースの制約事項を考慮して、バックテストを使用して精度を評価します。 精度は得られるが、現実的ではない方法でバックテストを作成しないように注意してください。 （設定の詳細については、 日付/時刻のパーティショニングの説明を参照してください。） 以下に、これらの設定を変更する際の考慮事項について説明します。

このセクションでは、以下の内容について説明します。

• 検証の長さの設定
• バックテスト数の設定
• ギャップの長さの設定
• バックテストの有用性

検定の長さ¶

検証の長さは、モデルを再トレーニングする頻度を表します。 デフォルト設定を変更する場合、考慮すべき最も重要な設定です。 たとえば、2週間ごとに再トレーニングする予定の場合は、検証期間を14日に設定します。四半期ごとに再トレーニングする場合は、3か月または90日に設定します。 検証の長さを再トレーニング計画と一致しない任意数に設定すると、モデルのパフォーマンスを理解するために必要な情報が得られません。

バックテストの数¶

バックテストの数を設定することは、「本能的直感」のようなものです。答えようとしている質問は、「再トレーニングスケジュールに基づいた予測に満足するには何が必要か」ということです。最終的には、検証の長さが少なくとも予測ウィンドウ全体をカバーする数のバックテストが必要です。 これ以上の回数は、モデルのパフォーマンスに慣れるために必要な期間に依存します。

バックテストを行うほどモデルの精度の高さを検証できますが、トレーニングに時間がかかり、保有する履歴データの量に応じて設定できるバックテストの数に制限がかかる可能性があります。 特定の検証期間では、バックテスト数を増やすとトレーニング期間が短縮され、ある時点でトレーニング期間が短くなりすぎることがあります。

再トレーニングスケジュールに基づいて検証期間を選択し、バックテストの数を選択します。トレーニング時間およびトレーニングデータの可用性に対して、モデルの信頼性のバランスを取り、より多くのバックテストをサポートします。

再トレーニングを頻繁に行う場合は、最新データでより頻繁に再トレーニングを行うことになるため、バックテストごとにモデルのパフォーマンスの違いを気にする必要はありません。 この場合、バックテスト1のバックテスト回数を減らすことができます。ただし、再トレーニングの頻度が減ると予想される場合は、バックテストのパフォーマンスの変動が本番環境でのモデル精度に影響を与える可能性があります。 この場合、より多くのバックテストを行って、時間の経過とともにより安定していることが検証されるモデルを取得する必要があります。 バックテストにより、履歴データのさまざまな期間にわたって適切な汎用モデルを選択できます。 再トレーニングする前に、モデルを本番環境に残す予定が長いほど、これは懸念事項になります。

また、予測距離が再トレーニング期間より短いか長いかによって、数値の設定が異なります。

• 例：1週間の予測ウィンドウがあり、毎月再トレーニングします。 過去の販売実績に基づいて、モデルが四半期にわたって安定していることを確認したいと考えています。 FW = [1,7]で、再トレーニング期間は1Mであるため、それに一致する検証期間を選択します。 3か月以上モデルの安定性を確認するには、3つのバックテストを選択します。

予測ウィンドウが再トレーニング期間よりも長い場合は、前の例を検討できます。ただし、予測ウィンドウ全体を説明するのに十分なバックテストがあることも確認する必要があります。

• 例：30日の予測ウィンドウがあり、15日ごとに再トレーニングします。 それを検証するには、最低2回のバックテストが必要です。 最後の例のように、四半期にわたってモデルの安定性を確認するには、6回のバックテストを行います。

最終的には、検証の長さが少なくとも予測ウィンドウ全体をカバーする数のバックテストが必要です。 これ以上の回数は、モデルのパフォーマンスに慣れるために必要な期間に依存します。

ギャップの長さ¶

日付/時刻パーティションの一部として設定されたギャップの長さ（ ブラインド履歴または「運用不可」期間と混同しないでください）は、モデルを本番環境に移行する際の遅延の問題に対処するのに役立ちます。 たとえば、モデルをトレーニングし、本番環境で実行するのに5日かかる場合、5日間のギャップが必要になります。 たとえば、金曜日から何日前までの直近のデータポイントが、 実際の 使用可能な データと等しいかを自問してみてください。本番環境ですぐにトレーニング、デプロイ、およびデプロイの使用を開始できる企業はほとんどありません。

バックテストの有用性¶

すべてのバックテストは同等ではありません。

バックテスト1が最も有用性が高くなります。なぜなら、プロジェクトの設定時、実環境をシミュレートしようとするからです。 バックテスト1は、利用可能な最新期間に実際に利用できるデータをトレーニングして検証するとどうなるかをシミュレートしています。 これは、トレーニングに使用する 最新 かつ 最も関連性の高い データであるため、バックテスト1の精度は非常に有用性が高くなります。

ホールドアウトは、モデルが本番環境に入ったときに何が起こるかをシミュレートします。つまり、再トレーニング中にモデルを使用している間何が起こるかを可能な限り「シミュレート」します。 精度は重要ですが、モデルから何を除外するかのガイドラインとして使用する必要があります。 ホールドアウトとバックテスト1のパフォーマンスに極端な違いがあるかどうかを判断します。これは、過剰適合または不足適合を示している可能性があります。

他のバックテストは、モデルが時間の経過とともに確実に機能できるように設計されています。 それは重要ですが、「すべてのバックテスト」で完璧なスコアを得ることは、バックテスト1とホールドアウトのスコアほど有用性が高くありません。 これらのテストは、時間の経過とともにパフォーマンスが変動するため、データの再トレーニングを要する頻度に関するガイダンスを提供します。 バックテスト1とホールドアウトの精度が良好または類似しているが、他のバックテストの精度が低いため、単にモデルをより頻繁に再トレーニングする必要があることを意味している可能性があります。 言い換えれば、バックテスト1で適切に機能するモデルを犠牲にして、すべてのバックテストで適切に機能するモデルを取得しようとしないでください。

有効なバックテストパーティション¶

時系列プロジェクトのバックテストを設定する場合、選択したバックテストの数は、 _バックテストごとに_次の最小行になる必要があります。

• トレーニングパーティションの最小20行。
• 検証パーティションとホールドアウトパーティションの最小4行。

パーティションを設定する場合：

• 予測の観点から境界を考慮し、適切な ギャップの長さを設定してください。

• 予測を行うためにリアルタイムでデータを収集している場合、0で終了する特徴量派生ウィンドウで十分です。 ただし、ほとんどのユーザーは、ブラインド履歴ギャップは実際には1～14日あることに気付きます。

詳細：デフォルトのパーティション¶

バックテストのパーティションを設定する前に、時系列モデリングの標準トレーニングパーティションの計算方法を理解することが重要です。 以下は、各バックテストのトレーニングパーティションで 行の最小要件を満たしていることを前提としています。

予測距離が10を超えるプロジェクトの場合、DataRobotは予測距離によって決定される行数をトレーニングパーティションには含めません。 その結果、データセットは指定最小値よりも多くの行を必要とし、追加の行数は予測距離の深さによって決定されます。

特定の予測距離へのバイアスを軽減し、検証、ホールドアウト、およびギャップの余地を残すために、DataRobotではバックテストトレーニング パーティションにすべてのデータセット行を含めません。 DataRobotがトレーニングパーティションに 含めない データセットの行数は、以下で説明する要素によって異なります。

以下の用語を使用して以下の計算を説明します。

以下は、トレーニングに含まれていない行数の計算です。

単一系列および10個未満のFD¶

予測距離が10以下の単一系列の場合、DataRobotは次のように除外された行を計算します。

FDW + 1 + BH + CO + 検定  + ホールドアウト

複数系列または10個を超えるFD¶

プロジェクトに予測距離> 10がある場合、DataRobotは、削除された行に予測ウィンドウの長さを追加します。 たとえば、あるプロジェクトに20の予測距離がある場合、DataRobotはトレーニングセットの考慮対象から20行を削除します。 つまり、予測距離の数が多いほど、トレーニングの考慮事項から削除される行が多くなります（したがって、最小20行を維持するためにプロジェクトに必要なデータが増えます）。

複数系列プロジェクト、または予測距離を超える単一系列の場合、DataRobotは次のように除外された行を計算します。

FDW + 1 + FW + BH + CO + 検定  + ホールドアウト

季節性のあるプロジェクト¶

季節性がある場合（つまり、 差分を適用する詳細オプションを選択した場合）、FDW + 1をFDW + Seasonal periodに置き換えます。 選択されていない場合、DataRobotはデフォルトで季節性を検出しようとします。 つまり、DataRobotは除外された行を次のように計算します。

• 単一系列および10個未満のFD：

  FDW + シーズン期間 + BH + CO + 検定 + ホールドアウト

• 複数系列または10個を超えるFD：

  FDW + シーズン期間 + FW + BH + CO + 検定 + ホールドアウト

期間と行数¶

データの間隔が均等である場合、期間と行数は同じです。 しかし、時間軸で認識されない不均等なギャップがあるデータを含む日付/時刻データセットの場合、データの間隔は均等ではありません。 これは期間と行数が各バックテストのトレーニングデータに与える影響に影響を与える可能性があります。 データにギャップがある場合：

• 行数は、バックテストごとの行数は偶数です（いくつかの行の時間間隔は長くなる可能性があります）。 特定の状況において、行数が同じ場合でも、行数モデルは期間モデルよりも多くのRAMを使用します。
• 期間は、バックテストごとに同じ長さの時間です（行数は異なる可能性があります）。

さらに、これらの値の意味は、トレーニングに適用するのか検定に適用するのかに応じて異なります。

_不規則_なデータセットの場合、トレーニングウィンドウ形式のデフォルト設定は行数です。 この設定は期間に変更できますが、予期されないトレーニングウィンドウまたはモデルエラーが生成されることがあるので、そのままにしておくことが推奨されます。

トレーニングフォールドと検証フォールドの処理¶

トレーニングデータの期間と行数は、時系列モデリング設定のトレーニングウィンドウの形式セクションで設定します。

期間を選択した場合、トレーニングデータのデュレーションに基づいて、モデルのトレーニングのデフォルトの分割サイズ（特定の期間）が選択されます。 たとえば、「常に3か月分のデータを使用」するように設定できます。行数を選択した場合は、モデルでは特定の行数（常に1000行など）がモデルのトレーニングに使用されます。 トレーニングデータの行数は、ここで指定した行数になります。

たとえば、詐欺と通常のトランザクションを含み、トランザクションの頻度が時間の経過と共に増加する（期間あたりのトランザクション数が増加する）データセットを考えてみます。 トレーニングデータのバックテストでトレーニングサンプルの数を一定にする場合は、行数を設定します。 最初のバックテストは比較的短い期間でのみトレーニングされます。 行数に関係なくすべてのバックテストの期間を一定にするには、期間を選択します。 いずれの場合でも、モデルはホールドアウトデータの開始日よりも新しいデータでトレーニングされません。

_検定_は、常に期間の単位で行われます（トレーニングが行単位で指定されている場合でも）。 行数を選択した場合、DataRobotでは、行数に基づいて検定の長さが設定されます。

トレーニング期間の変更¶

トレーニング範囲およびサンプル率を変更し、日付パーティショニングビルドの特定のモデルを返すことができます。 モデルを構築した後に検定パーティションの期間を変更することはできないことに注意してください。この設定は、構築を開始する前にのみ高度なオプションリンクから使用できます。 プラス記号（+）をクリックして、新しいトレーニング期間ダイアログを開きます。

新しいトレーニング期間ボックスには、次の表で説明する複数のセレクターがあります。

	選択項目	説明
	フローズン実行トグル	実行を固定。
	トレーニングモード	別のトレーニング期間を使用してモデルを再実行する。 値の設定をする前に、行数とそれに対する期間、及びそれらがデータ群にどのように適用されるのかの詳細を参照してください。
	切り替え先	事前定義済みのポイントに「スナップ」して値の入力を行い、手動でのスクロールや計算を回避できます。
	時間ウィンドウサンプリングを有効化	期間または開始/終了トレーニングモードで、時間ウィンドウ内のデータのサブセットをトレーニングします。 選択して有効にし、割合を指定します。
	サンプリング方法	データセットから行を割り当てるサンプリング方法を選択します。
	サマリーグラフ図	モデルの構築に使用された観測値およびテストパーティションのサマリーを表示します。
	最終モデル	日付を調整すると変更されるイメージ（予測を作成するモデルで使用するデータが反映されます）を表示します（以下の備考を参照）。

新しい値を設定した後、新しいトレーニング期間で実行をクリックします。 新しいモデルが構築され、リーダーボードに表示されます。

ウィンドウとギャップの設定例¶

ギャップの長さの設定（モデルを本番環境に移すのに必要な時間）と、ウィンドウ設定によって作成される ギャップ期間（モデルでデータを使用できるようにするのに必要な時間）の間には重要な違いがあります。

次の説明では、これらの値がそれぞれ本番環境の最終モデルにどのように影響するかを示す具体的な例を示します。

最上位レベルでは、時系列プロジェクトのモデル化に関連する2つの個別のアクションがあります。

1. データ処理を含むモデルを構築すると、モデルは最終的に予測を行います。

2. 構築したらモデルを製品化すると、組織での価値が向上します。

より単純な部分から始めましょう。 項目2は ギャップの長さです。作業を完了してから、IT部門が実際に最新モデルを本番環境に移行するまでにかかる時間など、1回限りの遅延です。 （一部の厳しく規制された環境では、30日以上かかる場合があります。）

項目1については、データに関する次の基本事項を理解する必要があります。

• データの収集または集計の頻度

• データのタイムスタンプは 実際には 何を表していますか？ 非常に 一般的な実例：

  • データベースシステムはデータに対して更新プロセスを実行します。この例では、2022年9月9日（「今日」）にデータが使用可能になったとします。
  • ただし、更新プロセスは実際には前の金曜日（この例では2022年9月2日）のデータに適用されています。
  • データベースは、実際には2022年9月2日のデータですが、処理が行われた日（2022年9月9日）として更新のタイムスタンプが付けられます。

以下に、別の例を示します。

• データベースシステムはデータに対して更新プロセスを実行しますが、最新のデータ更新で実際の日付（2022年9月2日）でタイムスタンプが付けられます。

データ取得で発生していることを把握すると、それを考慮してプロジェクトを調整できます。 トレーニングでは、タイムスタンプ/遅延の問題は問題になりません。 時間の経過に伴うデータセットがあり、毎日値が入力されます。 しかし、これ自体が課題でもあります。ユーザーと使用しているシステムは、トレーニングデータと本番データの違いを考慮する必要があるからです。 以下に、別の例を示します。

• 今日は2022年9月9日金曜日で、データの更新を受信しました。 月曜日の予測を行う必要があります。 この状況では、特徴量派生ウィンドウと予測ウィンドウをどのように設定すべきですか？

  • 保持している最新のデータは 実際には 7日前のものです。
  • 2022年9月9日の時点で、毎日行う必要がある予測は3日先であり、1週間先を予測したいと考えています。
  • 特徴量派生ウィンドウの開始日はいつでも構いませんが、この例の「長さ」は28日間です。

_予想の時点_からすべてを考慮してください。 任意の日付の予測の時点で、次のように例を要約できます。

• 最新のデータは、実際には過去7日間です。
• 特徴量派生ウィンドウは28日間です。
• 今日から3日前を予測するとします。
• 次の7日間に何が起こるか知りたいとします。
• モデルを構築した後、企業がそれを本番環境にデプロイするのに30日かかります。

設定方法は？ このシナリオでは、設定は次のようになります。

• 特徴量の派生ウィンドウ：-35日〜-7日
• 予測ウィンドウ：+3～+10 日 ギャップの長さ：30 日

別の言い方をすれば、ブラインド履歴は7日間、「運用不可」期間は3日間、ギャップの長さは30です。