シミュレートされたライブ取引モジュールの概要

この章は、ライブ取引を開始する前に、何ができるか、バックテストとの違い、重要な用語の意味、次に読むべき章など、包括的な概要を構築するのに役立ちます。

ユーザーの皆様、戦略のバックテストが完了し、戦略のパフォーマンスを「リアルタイム」で観察したい場合は、このモジュールが最適です。バックテストとして 同じセット の戦略コードを使用するよう努めており、注文の発行とログをローカルでシミュレートすることで、実際の証券会社に接続する前にプロセス全体を完了できるようにします。

0. 适用场景

  • 戦略のバックテストが完了し、シミュレートされたライブ取引 段階に入る準備が整いました (実際の取引プラットフォームにはまだ接続していないか、一時的に接続していません)。

  • 「設定→注文→トランザクション完了→ログ→トラブルシューティング」というプロセスの全体的な理解を迅速に確立したいと考えています。

  • 将来的に本物の証券会社 (QMT など) を含めるように拡張する予定がある場合は、安定したドキュメントのエントリ ポイントが必要になります。

1. 这个模块解决什么问题

  • 疑似ライブトレードにおける「設定、発注、約定、ロギング、トラブルシューティング」の全プロセスを統一的に解説。

  • バックテストからライブ テストに切り替えるときの認知負荷を軽減します。「バックテストのパラメーターは機能しているが、ライブ テストが開始されると完全に混乱する」という状況を回避します。

  • これにより、実際のカウンターをサポートするための将来の拡張のためのドキュメントのエントリ ポイントが提供され、最初から始める必要がなくなります。

2. 与回测的关系

Qteasy の設計目標は、バックテストとライブ取引の両方に同じ戦略ロジックを使用することです。主な違いは、戦略コード全体を書き直すのではなく、「時間の経過」と「誰がマッチングを実行するか」にあります。以下の表は、選択時にオプションを簡単に比較するのに役立ちます。すでにバックテストに精通している場合は、「ライブ取引」列の「ライブ取引」に関連するエントリーポイントと取引方法に注目してください。

列の意味: 比較項目は寸法を表します。 バックテスト 列では、履歴検証モードについて説明します。 **シミュレートされたライブ取引 (mode=0) 列は、実際のクロックで実行されるライブ モードを説明します。

使用方法: 「今どのモードを使用するか」を決めるときは、行で検索します。ライブを開始するときに、最後の行エントリが mode=0 + qt.run(op) であることを確認してください。

比較項目

バックテスト

シミュレートされたライブ取引 (mode=0)

時間

履歴間隔で早送りする

リアルタイムは取引カレンダーに従って進行します。

戦略コード

同じOperator/戦略

同じ一連のロジック

取引

過去の価格に基づいてシミュレーションされたマッチング

通常、取引はシミュレーターによってライブ価格で照合されます。

典型的な入り口

op.run_backtest() / qt.run(op, mode=1)

qt.run(op) と mode=0

Operator (Trader コンテナ): これは、戦略のために作成および保持する「トレーダー」オブジェクトです。バックテストとライブ取引の両方で、モードが異なるだけで使用されます。これは、同じトレーダーが「過去の試験」と「模擬ライブ試験」の両方で同じテストを受けると考えることができます。

ライブを開始するための一般的な 1 行のコード:

import qteasy as qt
qt.configure(mode=0, ...)  # 0 表示 live / 模拟实盘
qt.run(op)                 # op 为您的 Operator

3. 您将获得的 capability（能力地图）

最近のバージョンでは、シミュレートされたライブ取引を 検証可能、傍受可能、監査可能、およびスケーラブルにすることを目的として、次の機能が徐々に改善されています。

  • 構成検証可能: ライブ関連のパラメーターは実行前にチェックされるため、構成が正しくない場合は、プロセスの途中でクラッシュするのではなく、早期にエラーが報告されます。

  • 可能なリスク管理: 注文は、実際に証券会社に引き渡される前に、ルールに従ってローカルでブロックできます (注文前レビューパネルなど)。

  • 監査可能な拒否: 注文が拒否された場合、ルール番号と英語の理由を使用してログから取得できるため、「注文がクローズされなかった理由」を簡単に確認できます。

  • 仲介インターフェイスはスケーラブルです: 取引の接続、送信、ポーリングのための統合インターフェイスを提供し、QMT などの現実世界の取引プラットフォームとの将来の統合を容易にします。

  • より明確な注文ステータス: 部分的に完了や完全に完了などのステータスは、累積取引量とより一貫性があり、インターフェイスの表示と期待との間の差異が減少します。

4. 术语速查表

シミュレートされたライブ取引ドキュメントでは、Operator、Trader、ブローカー、リスク管理、商品パスなどの用語が繰り返し使用されます。このセクションはモジュール全体の用語ハブです。トピックごとにグループ化されており、各章の本文に最初に登場した後に再度参照することができます。一度にすべて読む必要はありません。馴染みのない用語に遭遇した場合は、ページ内検索を使用してください。

列の意味: 用語は英語の名前または構成キーです。 説明 では、qteasy ライブ ワークフローにおける責任を説明します。 アナロジーでは、記憶を助けるために投資/日常シナリオを使用します (アナロジーと現実世界の行動に違いがある場合は、説明欄が優先されます)。

使用方法: まず、「実行エンティティ / 構成 / オーダー / メンテナンス」のどのカテゴリに陥っているのかを判断し、対応するセクションを開きます。現在の問題 (例: 「拒否された注文を確認する場所」) に基づいて、手順 列でキーワードを見つけて、:doc:3-risk-and-order-lifecycle や :doc:5-artifacts-and-troubleshooting などのセクションにジャンプします。

例: シェルに partial-filled が表示されますが、理解できません → §4.3 を開いてその行を見つけます → これが「部分的に埋められている」という意味であることがわかります → :doc:3-risk-and-order-lifecycle に移動してステータスの変化を確認します。

4.1 運営主体

ライブ実行時は、Operator がポリシーを保持しますが、実際のスケジュールに従って Trader によって駆動されます。注文は ブローカー によって処理されます。この表は、「ポリシー コンテナ」から「インターフェイス」までの主な役割をカバーしています。特定の構成キーは含まれません (§4.2 を参照)。

用語

説明

類推

Operator

ポリシー グループを保持し、スケジューリングと信号のマージを担当する最上位のコンテナー。

ポートフォリオ マネージャー: いつ、どの戦略を実行するかを決定する

Trader

ライブモードでは、ストラテジーの実行、発注、ログの書き込みなど、スケジュールに従って実際に実行される主要なプロセスが操作の核となります。

Trader 席: シェルの会話でやり取りする人

ブローカー (証券会社)

注文の受付、処理結果の返信、取引確認の対象者。

証券カウンター：シミュレーターとは「練習カウンター」の意味です。

mode=0

設定項目: ライブ/シミュレートされたライブ取引を示します (バックテスト モード = 1 を基準としたものなど)

スイッチ: 0 = リアルタイムで実行

CLI command

コマンドライン対話型インターフェース (Trader シェル)

コマンドを入力するための「トレーダーターミナル」。

TUI

グラフィカルターミナルインターフェース

パネルまたは CLI オプションを使用した全画面インターフェイス。

4.2 構成とデータ

LiveTrade を開始する前に、qt.configure(...) 経由で書き込んだ項目は LiveTradeConfig として凍結され、資産タイプ、市場データの取得元、およびデータの補足方法が決定されます。この表は、構成の章 (:doc:2-configuration-and-run) の用語索引です。

用語

説明

類推

LiveTradeConfig

ライブ構成のスナップショットは起動前にフリーズされ、実行中に誤って変更されることはありません。

飛行前検査フォームは、一度署名したら変更しないでください。

The set of names of the historical data to be fetched, if htypes is empty, the system will try to create all possible htypes by basing on the name of the historical data and the freq/asset_type parameter. the input can be str or list: - str: 'open, high, low, close' - list: ['open', 'high', 'low', 'close'] - list: ['open', 'high', 'low', 'close'] - list: ['open', 'high', 'low', 'close'] 'high', 'low', 'close']

E (株式) や FD (上場投資信託/ETF) などの資産タイプ。

「この一連の資産の取引にどのルールセットが適用されるか」をシステムに伝えます。

Market conditions and refill

オンライン チャネルからローカル データ ソースに不足しているテーブル/範囲を入力します。

ローカルの「データ ウェアハウス」を補充する

ライブ市場頻度

たとえば、live_price_acquire_freq='15MIN' は、リアルタイム価格を取得する頻度を指定します。

市場監視の更新間隔

``simulator''

デフォルトのシミュレートされた仲介タイプでは、ライブ価格設定を使用してトランザクションをシミュレートします。

紙取引カウンター

4.3 注文とリスク管理

戦略シグナルから実行までのプロセスは、「ローカルリスク管理→仲介処理→非同期実行」となります。この表には、:doc:3-risk-and-order-lifecycle; の中心となる語彙が含まれています。 「リスク管理拒否」行と「カウンター拒否」行を必ず区別してください。

用語

説明

類推

オーダーインテント

計画オーダー: 主題、方向、数量、価格など。

記入済みの承認フォームの草案

アカウントのスナップショット

リスク評価時点の現金、オープンポジション、日々の取引高

注文が行われた時点のアカウントのスナップショット。

RiskManager

複数のルールを順番に実行して、通過を許可するかどうかを決定します。

レビューデスク: いずれかのルールが要件を満たさない場合、注文は拒否されます。

リスクに関する決定

リリースまたは拒否、英語での拒否理由、ルール番号

結論書をレビューする

リスク管理による注文拒否

ローカル ルール インターセプト: 注文テーブルには入力しないでください。risk_log に記録します。

フォームは送信される前に審査デスクから返送されました。

拒否された注文に対するカウンターサービス

証券会社は注文を拒否しました。注文テーブルには rejected 行が含まれており、ブローカー ID が空です。

カウンターではレシートを返却いたします。

partial-filled

部分的に取引されている: 取引されたトランザクションの数が、発注された注文の数よりも少ないです。

注文の一部のみが実行されました。

filled

トランザクションの成功

コミッションの数に達しました。

Often rejected

拒否されました（多くの場合、カウンターでの拒否を指します）

無効な委任

broker_order_id

証券会社の注文番号は、処理が成功するとローカル システムに返送されます。

カウンター受付番号

submit_with_ack

注文を送信すると、注文が受け入れられたかどうかの結果を同期的に受け取ります。

申請書を提出するとすぐに窓口スタッフが「承諾・不承諾」を告げます。

poll_fills

非同期に到着するトランザクション結果のポーリング

定期的に窓口に「新たな取引はありましたか？」と尋ねましょう。

4.4 運用と可観測性

ライブ テストやトラブルシューティングを長時間実行すると、ログ パス、アクセス制御、調整、およびデバッグが発生します。このテーブルは、:doc:5-artifacts-and-troubleshooting、:doc:6-trader-snapshot-gate、および:doc:8-cli-trader-capability-matrixに対応します。

用語

説明

類推

4 ボンド製品

4 つの固定パスは、sys_log、trade_log、break_point、risk_log です。

4 つの専用フォルダー: システム ログ、トランザクション詳細、ブレークポイント アーカイブ、およびリスク コントロール レコード。

スタートアップゲート

実行前チェック: 戦略の準備、データ テーブル、リモート台帳とのオプションの比較。

出発前の安全確認

戦略スナップショット (ロードマップ 5-A)

データは戦略の実行前にプリフェッチされ、このステップではデータを再利用して冗長 I/O を削減します。

事前に今日の資料を机の上に準備してください。

調整 (調整スナップショット)

決算時などにローカル台帳とリモート台帳の差分をJSON形式で出力します。

一日の終わりの調整声明

デバッグモード

Trader デバッグスイッチ、run --task ... に手動で設定可能

修復モード: タスクは段階的にトリガーできます。

5. 推荐阅读路径

モジュールのホームページ ディレクトリと一致します。

  1. doc:

    2-configuration-and-run — 実行可能な最小構成を完了します

  2. doc:

    ../tutorials/8-live-trade-risk-and-broker-walkthrough — チュートリアルに従ってください

  3. doc:

    5-artifacts-and-troubleshooting — 問題が発生した場合のアーティファクトとスクリプトのチェック

  4. doc:

    4-broker-adapter-and-integration — 証券ポートフォリオを拡大する必要がある場合にお読みください。

  5. doc:

    8-cli-trader-capability-matrix — CLI コマンドの比較。長距離比較: ⟦C​​ODE1⟧ と 7-manual-smoke-live-grid-roadmap

6. 相关索引