あなたの戦略は240回試されました。本当はバックテストを何回実行したのでしょうか？

240通りのパラメーターを試しました。最良の結果はSharpe比2.1、中央値は0.1で、1.0を超えたのはわずか17通りでした。これらの数字は発見のように聞こえます。しかし、どの戦略にも真の優位性がない場合でさえ、これだけ広く探索すれば、偶然に見栄えの良い勝者が生まれ得ると知れば、印象は変わるでしょう。

意外な数字は240です。バックテストのレポートでは通常、選ばれた戦略が最初から単独で存在していたかのように扱われます。実際のリサーチはそうではありません。パラメーターの微調整、特徴量の入れ替え、対象ユニバースの変更、悪い結果が出た後の再実行。そのたびにノイズがシグナルに見える機会が増えます。

戦略を多く試すほど、なぜ最高のSharpeが高くなるのでしょうか？

真の優位性がなく、推定Sharpeにノイズがある独立した戦略を240個想像してください。推定値の多くはゼロ付近に集まりますが、最大値は正になりがちです。候補を多く調べるほど、その最大値は真の値から大きく離れ得ます。

大まかな例として、各候補の推定Sharpeの標準誤差が0.5だとします。独立した抽出が240回あれば、選択だけで最大推定値が平均より約1.4標準誤差、つまりSharpeでおよそ0.7高くなることがあります。実際の戦略候補には相関があるため、この計算値をそのままレポートに使って補正することはできません。幅広く探索した後では、「勝者がゼロを上回った」という結果が弱い証拠にすぎない理由を示す例です。

しかも、探索対象はたいていパラメーターのグリッドだけではありません。シグナルの系統を3つ試し、曲線を見てから2つを捨て、取引対象のユニバースを変え、残った戦略を別のリバランス日程で再実行したかもしれません。こうした選択がパフォーマンスに影響されていたなら、リサーチ履歴に含める必要があります。

バックテストの試行に数えるのはどれでしょうか？

結果が戦略の選択に影響し得た判断は、試行として数えます。公表しなかった実行や、エクイティカーブが悪く見えたため途中で打ち切ったバリエーションも含まれます。コンパイルエラーはパフォーマンスの試行ではありません。一方、期待外れのSharpeが出た実行は、通常、試行に当たります。

判断の分かれ目は、結果を使って何かを選んだかどうかです。記憶だけを頼りに後から再構成するのは難しいため、実験ログには実行ごとに仮説、コードまたは設定のバージョン、データ期間、コストの前提、結果を記録しましょう。

多重検定を補正できますか？

選択バイアスを推定したり、多数の試行に合わせて有意性を調整したりする方法はあります。有用な場合もありますが、候補同士の関係やリターンの振る舞いについて前提が必要です。名目上のp値や単一の補正Sharpe推定値があっても、実際の探索履歴を失ってしまえば、その探索を救うことはできません。

まず、自分たちで管理できることから始めましょう。本当に未使用の期間を評価する前に、最終仕様を固定します。候補の全体像を見える状態に保ちます。関連するバリエーションを多数試す場合は、それぞれを独立した発見と見せかけず、候補を生んだ判断ごとにまとめます。勝者とあわせて探索内容も報告しましょう。試行数、選択ルール、最終評価をその後の編集に反映したかどうかを記載します。

AIリサーチエージェントは何を記録すべきでしょうか？

エージェントは、人が作業記憶にとどめておけるよりも速く候補を生成できます。だから試行の記録は、報告のための雑務ではなく、リサーチシステムの一部です。候補は実行前に、親となる実験と、その候補を作った理由も含めて保存します。失敗した実行や、採用しなかった実行も残します。人やエージェントがいつパフォーマンスを確認し、その後どのような判断をしたかを記録します。

次に、選択プロセスを再現可能にします。同じ候補群とルールを与えれば、同じ勝者が選ばれるべきです。エージェントが結果を見てからプロンプト、目的、制約を変え続けるなら、その変更も探索の一部です。

Sharpe 2.1は調査する価値があるかもしれません。その意味は、そこに至るまでの過程次第です。リサーチログに、見出しを飾る成績をめぐって240個の候補が競ったと記録されているなら、次に問うべきことが見えてきます。そうした選択のどれにも、まだ使われていない証拠はどれだけ残っているでしょうか？