バックテストは再現性が高すぎることがある

完全に再現できるバックテストでも、結果が少し変動するものより信頼性が低いことがあります。同じ答えを2回得られることは再現性の証明になりますが、その答えが恣意的なデータスナップショット、ライブラリの癖、あるいは隠れたデフォルト設定に依存していないかは分かりません。

再現性に反対しているように聞こえるかもしれませんが、そうではありません。実行内容を説明できるように、まず実行を固定します。そのうえで、結果を左右するべきではない前提を意図的に変えます。最初の段階で結果を監査可能にし、次の段階でその結果に意味があるかを確かめます。

再現可能なバックテストで、実際に何が確かめられるのでしょうか？

同じコード、データ、設定、乱数シードから同じ取引と指標が得られれば、混乱の重要な原因を1つ抑えられています。エージェントによる「改善」を親の実行結果と比較できます。バグ修正と手数料体系の変更を切り分けられます。同僚が同じ台帳を確認し、同じ約定を見つけられます。

ただし、その結果が成り立つのは、固定したすべての条件のもとでです。1分足を含む過去データファイルを使った暗号資産戦略を考えてみましょう。ファイルのハッシュを保存し、コードのバージョンを固定すると、再実行のたびにSharpe 1.4が得られます。後にベンダーが複数のローソク足を修正したとしても、きれいな再現性が示しているのは古いファイルでの結果です。シグナルが修正後の履歴でも有効か、あるいは当時その形式のローソク足を利用できたのかは分かりません。

ハッシュには意味があります。依存関係を見えるようにしてくれます。しかし、その依存関係に問題がないことを示す証拠ではありません。

実行を固定し、知見を検証する

私は2つの問いを分けて考えます。この実行を寸分違わず再構築できるか。そして、妥当な変更を加えても研究上の結論が維持されるか。前者には変更不能な記録が必要で、後者には一度に1つずつ行う統制された摂動が必要です。

たとえば、先物戦略のベースライン再生で、年率換算の超過リターンが8%だったとします。takerコストを25%上げ、資金調達料を次に観測された決済時点へずらし、リターンへの寄与が最大の2銘柄を1つずつ除いて再実行します。これはモデルを改善する3つの方法ではありません。もっともらしい細部のどれかが、目立つ結果を支えていないかを確かめる検証です。

検証項目はそれぞれ分けておきます。データ、手数料体系、執行タイミングを同時に変えると、結果が悪化しても原因をほとんど特定できません。また、現実味のない検証は、起こりそうな結果として示さず、ストレスケースと明記します。

バイト単位の一致を数値的な正しさと取り違えない

計算のなかには、処理順序に左右されるものがあります。浮動小数点数の加算には結合則が成り立たないため、小さな損益値を多数、異なる順序で合計すると、末尾の数桁が変わることがあります。並列集計、ハードウェア、ライブラリのバージョンも、出力の完全一致に影響することがあります。多くの場合は問題になりませんが、わずかな数値の変化で閾値を超えたり、ポジションが変わったりして、シミュレーションのその後の経路が変わることもあります。

そのため、比較用の許容差とともに、成果物そのものも保存しておくのがよいでしょう。最終的なSharpeだけでなく、取引台帳も記録します。まず判断とキャッシュフローを比較し、その後、明示した許容差の範囲内で指標を比較します。1セントの差で注文の発注有無が変わるなら、その境界を明示的に調べます。

変動がノイズなのか、知見なのか

数値が変わるたびに問題になるわけではありません。集計順序の違いによるわずかな指標のずれがあっても、取引は変わらないかもしれません。閾値付近の取引が変わった場合は、確認する価値があります。ベンダーが過去データの小さな一部分を改訂しただけで結果の大半が失われる戦略は、元の実行が完全に再現できたとしても、自らの脆弱性について何かを明らかにしています。

ロバスト性検証への批判には、もっともな点が1つあります。望む戦略が頑健に見えるまで前提を変え続けたり、意図的に極端なシナリオで妥当な結果を否定したりするのは簡単です。妥当な変動を事前に定め、すべての結果を報告し、通常想定される別案とストレスケースを区別します。そのうえで、別の研究者が見た内容を正確に再現できるよう、ベースラインを保存します。

再現性があれば、信頼できる出発点を得られます。その次に問うべきなのは、実行を取り巻く環境が合理的に予想できる範囲で変わったとき、答えのどの部分が変わらずに残るかです。