4. 戦略によるデータの宣言と使用方法

4.1. 1. 策略层在整体中的位置

戦略層は 2 つのことを担当します。「どのようなデータが必要か」(およびウィンドウの長さ、最新の期間を使用するかどうか) を宣言し、realize() で「信号を計算するためにデータを使用する」ことです。データは戦略によって積極的に取得されません。代わりに、ランタイムは宣言に従って各ステップでそれを準備して注入し、ストラテジーは get_data(dtype_id) を介して ID によってのみそれを取得します。このように、バックテストとライブ取引はまったく同じデータビューと呼び出しパターンを使用します。

4.2. 2. 策略如何声明需要的数据

戦略クラス (__init__) を初期化するときに、次の属性を介してデータ要件を宣言します。

  • data_types: 1 つ以上の DataType オブジェクト (またはリスト/dict)。各 DataType は一種の「参照可能な情報」に対応し、一意の dtype_id (例: close_E_d) にマッピングされます。

  • window_length: 履歴データ ウィンドウの長さ (たとえば、20 は最新の 20 サイクルを意味します)。スカラー (宣言されたすべてのデータ型に適用される) にすることも、dtype で個別に指定することもできます。

  • use_latest_data_cycle: 「最新の単一サイクル」のデータのみを使用するかどうか (たとえば、銘柄選択に最新のクロスセクションのみを使用する)。 dtypeごとに個別に設定できます。

宣言後、エンジンはストラテジに必要な dtype_id とウィンドウの長さを認識するため、実行前に対応するデータ ウィンドウを準備し、各ステップでそれらを更新/挿入できます。

4.3. 3. 运行时数据如何到达策略

  1. 準備段階: バックテスト期間 (またはライブ取引の現在時刻)、および戦略の data_types と window_length に基づいて、エンジンは対応する期間のデータを DataSource から取得し、タイム ステップごとに「データ ウィンドウ」を事前スライス (またはオンデマンドでスライス) します。

  2. 各ステップが実行される前: 現在のステップで実行されるグループ内の各ストラテジについて、エンジンは update_running_data_window を呼び出し、現在のステップのデータ ウィンドウをそのストラテジの内部状態 (dtype_id によってインデックス付けされる) に書き込みます。

  3. realize() の内部: この戦略は、get_data(dtype_id) を介して ID によって挿入されたウィンドウ データ (numpy 配列) を取得し、信号を計算します。パラメーターは必要なく、データがどのテーブルからのものかを気にする必要もありません。

したがって、データの流れとしては「宣言→エンジンが段階的に注入→get_dataで参照」となります。戦略コードには、「テーブル読み取り」や「プル/フェッチ」ロジックがまったく含まれていません。

4.4. 4. 数据窗口的含义

  • 時間ディメンション: window_length は「何期間遡るか」を意味します。たとえば、毎日の頻度では、window_length=20 は直近 20 取引日のデータを意味します。配列の形状は通常 (n_periods,) または (n_assets, n_periods) で、最後の次元は時間、最後の列は最新の期間です。

  • マルチアセットの場合のシェイプ: 異なる戦略基本クラスでは、データの編成方法が若干異なります。

    • RuleIterator: 通常はアセットごとに反復されます。各 Realize() は、単一資産の時系列または断面を参照します。

    • ファクターソーター: ランキングと銘柄の選択に使用される複数の資産のクロスセクション (例: 銘柄ごとに 1 つのファクター値)。

    • GeneralStg: マルチアセット、マルチ dtype ウィンドウ。アセットの数と同じ長さの信号配列を返します。

正確な形状は、API および戦略の基本クラスのドキュメントに従います。このシリーズでは、「ウィンドウは宣言に従ってエンジンによって準備され、ストラテジーは get_data を介して ID によってウィンドウを取得する」ことを強調しています。

4.5. 5. 过程数据（proc.*）

上記の静的な履歴データ (「宣言→エンジン噴射」) に加えて、qteasy は プロセス データ: バックテスト/ライブ実行パスに依存する状態 (現在のポジション、キャッシュ、過去の取引記録など) をサポートします。プロセス データは data_types で宣言する必要はありません。これは、Backtester (バックテスト) または Trader (ライブ取引) によって実行時に維持され、注入されます。

  • アクセス パターン: realize() では、self.get_data('proc.own_cash')、self.get_data('proc.trade_records', lag=0) などのフォームを介して必要に応じて取得します。 lag ('1d' などのステップまたは時間) および window ('5d' など) パラメーターをサポートします。

  • 制約: 1 回の呼び出しでは 1 つの proc.* フィールドのみが許可され、同じ呼び出し内で静的データと混合してはなりません。プロセスデータを使用する戦略はすべて、動的バックテスト パス (シグナルを段階的に生成し、取引を段階的に実行する) に自動的に従います。

詳細については、「プロセスデータ (proc.*) と動的バックテスト」(09-process-data-and-dynamic-backtest.md) を参照してください。

4.6. 6. 参考数据（若有）

ストラテジーによって宣言された data_types に加えて、qteasy は「参照データ」 (市場リターンの計算などに使用されるインデックスの終値など) をサポートします。参照データとプライマリ データの違いは、通常、アセット プールと 1 対 1 の対応関係がないこと、および対応する dtype_id または専用インターフェイスを介して戦略で取得することもできることです。具体的な設定と参照方法については、現在のバージョンのドキュメントと API を参照してください。

4.7. 7. 小结

「宣言 → エンジン挿入 → get_data 参照」により、次のことが保証されます。

  • バックテストとライブ取引では、同じデータビューとアクセスパターンが使用されます。

  • この戦略は、未宣言のデータや将来のデータにアクセスできないため、メカニズム レベルでの先読みバイアスが防止されます。

  • 保守と拡張が簡単な統合インターフェイス。

「宣言 → エンジン注入 → get_data 参照」はプロセス データにも適用されます。ただし、プロセス データは宣言する必要がなく、ランタイム層によって段階的に注入され、使用時にのみ動的バックテスト パスをトリガーします。詳しい使い方については「ユーザーガイド」および「APIリファレンス」をご覧ください。