FIELD GUIDE
How Quants Keep a Trading Loop From Overfitting
自動化された戦略探索ループは、きれいな equity curve と引き換えに、過去だけに効くルールや閾値を積み増しやすい。 見るべきなのは最高スコアではなく、どの部品が out-of-sample でも残るかだ。
Loopが増やす見えない過剰適合
ソースの出発点は単純だ。ループが十二個のルールと完璧なバックテストを渡してきても、 実際に edge を運んでいるのは二個だけで、残り十個は過去データへの装飾かもしれない。
スコアを追うループは、ルール、フィルター、閾値を足し続ける。各部品が backtest を少しずつ押し上げるからだ。 しかし、その上昇分の多くは、見せられた履歴にぴったり合うように曲げただけの lift である可能性がある。 したがって、運用前の仕事は「何を足せるか」ではなく「何を消しても性能が残るか」を確認することになる。
Ablate
一つずつルールを止め、out-of-sample の落ち方で load-bearing か decoration かを分ける。
Shake
閾値や lookback を前後に動かし、edge が一点の spike ではなく plateau を作るか見る。
Penalize
ルールとパラメータが増えるほど、戦略に求める証拠の水準を上げる。
Compare
太った版と削った版を並べ、少ない可動部品で残るほうを採用する。
Kill one rule at a time
最も直接的な検査は ablation だ。ルールを一つ止め、out-of-sample で再実行し、結果がどれだけ動くかを見る。
ほとんど動かなければ、そのルールは性能を支えていない。削除候補である。明確に落ちるなら、 そのルールは残す価値がある。全コンポーネントに対してこれを行うと、戦略の部品を重要度で並べられる。 ソースの表現を借りれば、十二個のルールのうち二個だけが ablation を生き残るなら、それは十二個の戦略ではない。 二個の戦略が複雑な服を着ているだけだ。
| Observation | Likely Meaning | Action |
|---|---|---|
| Rule off, out-of-sample barely changes | Rule is decorative or redundant | Delete or merge it |
| Rule off, out-of-sample drops meaningfully | Rule may be carrying real signal | Keep, then test its parameters |
| Many rules survive only in-sample | Loop fitted the exact past it saw | Prefer the leaner variant |
SpikeではなくPlateauを見る
本物の edge は、単一の数字にだけ依存しにくい。loop が選んだ lookback や stop を十から二十パーセントほど動かし、 周辺でも成績が崩れないかを確認する。
たとえば lookback 20 が最良なら、18、19、21、22 も近い範囲に残るかを見る。 周辺値が同じ高台を作るなら、戦略は exact number ではなく、ある程度幅のある market inefficiency を捉えている可能性が高い。 逆に 20 だけが勝ち、18 や 22 が崩れるなら、loop が数値を発見したのではなく、履歴を暗記した疑いが強い。
この検査はパラメータが増えるほど厳しくなる。lookback 単独、stop 単独では安定して見えても、 その組み合わせだけが joint spike になっていることがあるからだ。ソースは、Robert Pardo が 1992 年に walk-forward analysis を構築し、 rolling windows で再最適化した設定が未学習データでも働くかを確認した、と説明している。 ただし walk-forward は単一の price path を見るため、ablation と complexity check と組み合わせる必要がある。
採用したいのは「最高値」ではなく「周辺値も含めて壊れにくい領域」だ。最高点だけを shipping target にすると、 market に出た瞬間に past-fit が露出しやすい。
Complexityには罰を与える
追加ルールは、それ自体がリスクである。ルールやパラメータが一つ増えるたびに、loop が noise に合わせる自由度も増える。
似た out-of-sample 成績の戦略が二つあるなら、動く部品の少ないほうが live でも残る可能性が高い。 ルールが degree of freedom のコストを正当化できないなら削る。重要なのは、パラメータ数を正直に数えることだ。 それぞれのノブは、edge を見つける可能性だけでなく、過去を fitting する可能性も上げる。
Bloated Version
in-sample では高く見えるが、装飾ルールと fragile parameter が混ざっている可能性がある。
Lean Survivor
削っても out-of-sample に残る。採用候補は、最も少ない可動部品で十分な性能を出す版である。
Traders get this wrong
ソースが挙げる失敗は繰り返し現れる。in-sample の貢献でルールを評価し、ablation をせず、 parameter spike を出荷し、ルール数を sophistication と誤解する。
- in-sample で上げたルールほど、過剰適合ルールである可能性を疑う。
- ablation なしでは、load-bearing rule と decorative rule を分けられない。
- 単一の最良値だけを選ぶと、plateau ではなく spike を live に持ち込む。
- ルール数が多いほど、説明力ではなく fitting capacity が増えているかもしれない。
Horizon についての記述は、同じアイデアをルールあり/なしの variants として並べ、out-of-sample で比較する場所として紹介されている。 この記事では製品評価には踏み込まず、ソース内の位置づけどおり「lean version と bloated version を比較するワークフロー例」として扱う。
