7. バックテスト、ライブ取引、最適化: 統合されたエントリーポイントとさまざまなモード

7.1. 1. 统一入口

ユーザーは **qt.run(op, mode=…, kwargs) を介して実行をトリガーします。内部的には次のようになります。

  • kwargs をグローバル設定と config (ConfigDict) にマージします。

  • op.run(config, datasource, logger) を呼び出し、qteasy のデフォルトのデータソースとロガーを渡します。

mode はどの分岐を取るかを決定します。

  • mode=0: ライブ取引モード。 Trader ワークフロー (スケジュールされたトリガー、リアルタイム データの取得、信号の生成、注文、および記録) に入ります。

  • mode=1: バックテストモード。 Backtester を構築し、group_timing_table に従って段階的に Operator を実行し、フィルをシミュレートし、エクイティ カーブとパフォーマンスを出力します。

  • mode=2: 最適化モード。オプティマイザーはパラメーター空間を検索します。各パラメーター セットは 1 つのバックテストを実行し、結果は目的関数に従って集計されます。

  • mode=3/4: 追跡や予測などのモード。ドキュメントと API を参照してください。

したがって、同じ Operator は、異なるモードで「タイム ステップによる戦略の実行と信号の混合」という同じメカニズムを再利用します。唯一の違いは、データ ソースと結果の処理方法です。

7.2. 2. 配置（config）的作用

config には、資産ユニバース、バックテスト期間、コストパラメータ、資本計画などが含まれます。バックテスト/ライブ取引/最適化は同じ構成構造を共有します。例えば：

  • アセットプール、アセットタイプ、バックテストの開始日/終了日。

  • 取引コスト（手数料率、最低手数料など）。

  • 資本配分計画 (invest_cash_amounts など)。

  • ライブ取引関連 (口座、ブローカー タイプなど。mode=0 の場合に使用)。

config は **qt.run(…, kwargs) をグローバル QT_CONFIG とマージすることで取得され、op.run(config, …) に渡されます。 Backtester、Trader、およびオプティマイザーはそれぞれ必要なフィールドを読み取ります。

7.3. 3. 回测模式（mode=1）

  1. 履歴データの準備: アセット ユニバース、構成内のバックテスト期間、Operator 内のすべての戦略の data_types と window_length に基づいて、check_and_prepare_backtest_data などを呼び出して、DataSource から必要な履歴データを取得して組み立てます (期間の開始をカバーするのに十分なルックバック履歴を含む)。

  2. Backtester を構築します: Operator、資産リスト、資本計画、取引価格データ、コストパラメーターなどを渡して Backtester インスタンスを作成します。

  3. ブランチ選択: op.check_dynamic_data() が False の場合 (戦略はプロセス データに依存しない)、静的ブランチ を選択します。すべての信号を一度に生成し、Numba ベクトル化されたバックテストを実行します。 True の場合 (戦略が get_data('proc.xxx') または従来の動的データ型を使用する)、動的分岐 を実行します。信号を段階的に生成し、充填を段階的にシミュレートし、次のステップで使用する戦略のプロセス データを更新します。詳細については、「プロセスデータ (proc.*) と動的バックテスト」(09-process-data-and-dynamic-backtest.md) を参照してください。

  4. ステップバイステップで実行: group_timing_table のタイム ステップごとに、op.run_strategies(steps) (または同等のインターフェイス) を呼び出して、各ステップの (signal_type, signal) を取得します。

  5. 約定の解析とシミュレーション: signal_type (PT/PS/VS) によってシグナルを解析して買い/売りインテントにし、backtest_step などのロジックを使用してポジション、現金、決済キューを更新し、毎日の株式曲線と取引記録を生成します。

  6. 評価と出力: 株式曲線と取引記録 (シャープ レシオ、ドローダウンなど) のパフォーマンスを評価し、結果をユーザーに返し、オプションでレポートとチャートを生成します。

7.4. 4. 实盘模式（mode=0）

  1. Trader は Operator と設定を保持し、run_freq、run_timing、および取引カレンダーに従って取引日内の指定された時間にタスクをトリガーします。

  2. 現在の時刻のデータを取得: 戦略宣言に基づいて、現在のステップに必要なデータ ウィンドウを DataSource (またはリアルタイム インターフェイス) から取得します。

  3. Operator を実行します。このステップでは、Operator を呼び出してシグナルを生成します (バックテストと同じ run_strategy フロー)。

  4. 注文の解析と発注: シグナルを解析して注文にし、実行のために ブローカー に渡し (シミュレートまたはライブ ブローカー インターフェイス)、約定とポジションを記録します。

7.5. 5. 优化模式（mode=2）

  1. オプティマイザは、戦略のパラメータ定義に基づいてパラメータ空間（グリッド検索、ランダムサンプリング、遺伝的アルゴリズムなど）を決定します。

  2. 各パラメーター セットについて: set_parameter などを介してパラメーターを Operator に書き込み、バックテスト を 1 つ実行します (つまり、mode=1 ワークフロー)。

  3. バックテスト結果から 目的関数 (シャープ レシオ、リターン対ドローダウン比など) を計算し、すべてのパラメーターの組み合わせの結果を集計します。

  4. より適切なパラメーターの組み合わせと、ユーザーが選択できる対応するバックテスト結果を出力します。

7.6. 6. 小结

バックテスト、ライブ取引、最適化は、「Operator + 時間の経過に伴うステップバイステップ実行」メカニズムを共有しています。これらはすべて、最初にデータと設定を準備し、次に group_timing_table に従って戦略を段階的に呼び出し、シグナルをミックスします。唯一の違いは、バックテストでは履歴データと Backtester を使用して約定をシミュレートすることです。ライブ取引では、リアルタイム データと Trader/ブローカーを使用して注文を実行します。最適化ではバックテストを複数回実行し、目的関数を比較します。パラメータと使用法の詳細については、「ユーザーガイド」、「取引戦略のバックテストと評価」、「取引戦略の最適化」、および API リファレンスを参照してください。