AI戦略エージェントは、想定された売買時点ではまだ存在していなかった情報を使いながら、有効なバックテストを出力することがあります。コードは動き、エクイティカーブももっともらしく見えます。シグナル自体も妥当かもしれません。それでも、タイムスタンプや結合処理、改訂済みのデータ項目によって、気づかないうちに明日の答えが渡されていることがあります。
対策は、データの利用可能時刻をリサーチ上の取り決めに含めることです。すべての入力について、次の2つの問いに明確に答えられる必要があります。この値はいつの状況を表すのか。そして、戦略がそれを最初に知り得たのはいつか。
AIが生成した戦略では、先読みバイアスはどのように現れるのでしょうか？
分かりやすい例は、同じバーの終値からシグナルを計算し、その終値で約定させることです。終値を見て判断する必要があるなら、その価格で同時に取引することはできません。しかし、データソースを結合したり、都合のよいデフォルト値を選んだりする過程で、エージェントはもっと見えにくい形の問題を作りがちです。
モデルが各分の終値で20本移動平均を計算し、終値がその移動平均を上抜けたときにポジションを取るとします。バックテストで同じ終値に約定させると、そのバーの最後の取引価格が戦略に利用可能になる前に使ったことになります。注文を次のバーの始値にずらすのは妥当な近似かもしれませんが、成行注文には手数料と価格インパクトも必要です。
次に、特徴量を日次の株式ファンダメンタルズや暗号資産の建玉スナップショットに置き換えてみましょう。行の日付は月曜日を示していても、値が公表されたのは月曜の取引終了後かもしれず、後日訂正されていることもあります。日付は利用可能時刻ではありません。
戦略の入力には、どのようにタイムスタンプを付けるべきでしょうか？
データの出所で確認できる範囲で、少なくとも3つの時刻を保持します。値が対象とする期間、提供元が公表した時刻、そしてシステムが受信した時刻です。判断時点で戦略が参照できる情報には、その時点までに利用可能だった値だけを含められます。
| 項目 | 分かること | よくある落とし穴 |
|---|---|---|
| イベント時刻 | 市場イベントはいつ発生したか？ | バーが完成する前に終値を使う |
| 公表時刻 | 提供元はいつ値を公表したか？ | 日次の終了時刻を取引開始時の公表時刻として扱う |
| 取り込み時刻 | このリサーチシステムはいつ値を利用できたか？ | ベンダーやパイプラインの遅延を無視する |
| 改訂時刻 | このバージョンはいつ記録または訂正されたか？ | 改訂後の履歴を、当初から存在したかのように補完する |
1分足の戦略では、1秒の遅延が必ず無害とは限りません。影響するかどうかは、判断を行うタイミングとシグナルが何を使うかによります。入力が確定済みの時間足統計なら、ほとんど影響しないかもしれません。注文直前に取得した板の不均衡なら、売買の方向が逆転することもあります。
ある時点のデータを保持するストアなら、情報漏洩を防げますか？
「ある時点のデータ」が、過去の判断時点で知られていた値を、その時点で有効だった改訂版も含めて取得できるという意味なら役立ちます。過去の日付が付いているだけのテーブルには、現在の訂正値がそのまま入っている場合があります。
各レコードについて、有効期間と利用可能時刻を保持し、改訂版は上書きせずに残します。そのうえで、過去のクエリでは、シミュレーション上の判断時点までに利用可能だった最新バージョンを返すよう明示します。これはファンダメンタルズ、指数構成銘柄、経済指標の公表データ、ベンダーが補正したデータセットで特に重要です。
地味ですが運用上の注意点もあります。公表時刻が正確でも、取り込みジョブが20分遅れて実行されていたなら意味がありません。過去データストアに取り込み時刻が記録されていない場合は、保守的な遅延を設定し、その前提を明記します。提供元が記録していない精度は、見せかけにすぎません。
ペーパートレーディングの前に、どんなチェックを行えば先読みバイアスを見つけられますか？
バックテストと一緒に、特徴量と注文のタイムラインを出力するようリサーチエージェントに指示します。各判断について、すべての特徴量のうち最も遅いデータ利用可能時刻、判断時刻、注文時刻、モデル上の約定時刻を記録します。入力が判断後に到着している行はすべて不合格にします。
- シグナルを1本先のバーにずらして結果を比較します。成績が大きく崩れるなら、終値から終値へのタイミングに依存している可能性があります。ただし、これは診断方法であり、情報漏洩の証明ではありません。
- すべてのデータソースを過去のある時点で打ち切り、パイプラインを再実行して、生成された特徴量を保存済みの過去の特徴量と比較します。
- 疑わしい特徴量を定数に置き換えます。それでも成績がほとんど変わらない場合、コードが意図した系列を実際に使っているか確認します。
- 意図的に実現不可能な未来の特徴量をパイプラインに通します。利用可能時刻が判断時刻を超えたときに、検証で明確にエラーが出ることを確認します。
これらのチェックで戦略の正しさが保証されるわけではありません。タイミングに関する具体的な前提を可視化し、よくある前提違反を見つけられるようにします。
ペーパートレーディングをすれば、バックテストに情報漏洩がなかったと証明できますか？
いいえ。ペーパートレーディングでは、ライブのデータ経路が遅れている、欠損している、あるいは過去データと異なる形で時刻合わせされていることが分かる場合があります。しかし、過去の学習用特徴量が当時知られていた情報を反映していたかは証明できません。また、モデルが誤って見ていた未来が現在になったことで、情報漏洩の恩恵を受けなくなることもあります。
ペーパートレーディングは、バックテストとの整合性を確認するために使います。ライブの特徴量の値、判断タイムスタンプ、注文生成、モデル上の約定を、バックテストの定義と比較します。違いがあれば、どの入力と時計が原因かを追います。各判断で利用できた情報を説明できるエージェントチームは、価値あるリサーチをしています。滑らかな曲線を見せることしかできないチームは、最も難しい監査を飛ばしています。
← 記事一覧
