За walk-forward оптимизацией закрепилась репутация честного способа настроить стратегию — и заслуженно, если сравнивать с оптимизацией по всем данным и любованием результатом. Но у метода есть тихие способы провала, и каждый из них выдаёт один и тот же артефакт: отчёт о валидации со словом «робастно», подшитый к стратегии, которая таковой не является. Вот три, против которых нам пришлось строить защиту, — по порядку разрушений, которые они оставляют.
Провал первый: окна протекают
Как делать не надо: настроить на январе-июне, проверить на июле, а потом позволить чему-нибудь из июля повлиять на второй заход — перезапуск после того, как вы увидели out-of-sample число, «небольшая правка» сетки параметров, признак, отнормированный по всему ряду. По отдельности каждое выглядит невинно. Вместе они превращают out-of-sample окно в in-sample данные с задержкой.
Разрушения: out-of-sample Sharpe, который загадочным образом повторяет in-sample Sharpe. Настоящие out-of-sample результаты шумные и разочаровывающие; подозрительно гладкая связь IS/OOS означает, что информация течёт назад. Мы следим за этим отношением явно — in-sample больше чем в 3 раза выше out-of-sample помечает прогон, а out-of-sample на нуле или ниже убивает его, какой бы красивой ни была in-sample картинка.
Провал второй: подбор метрики по окнам
Прогоняем три walk-forward окна, получаем три шумных результата — и обобщаем: средний Sharpe? Медианный? Выбросить худшее окно из-за «смены режима»? Каждый такой выбор — степень свободы, и настойчивый оптимизатор (человек или байесовский) найдёт ту сводку, при которой эта стратегия выглядит лучше всего. Семьдесят пять испытаний Optuna на окно — это семьдесят пять шансов подогнаться под шум, помноженных на количество сводок, которые вы готовы рассмотреть.
Разрушения: стратегия проходит валидацию, а в бою выдаёт результат худшего окна — потому что худшее окно было единственным честным. Наше правило: способ агрегации фиксируется в конфиге до прогона, бюджет испытаний фиксирован, а аналитик читает результаты по каждому окну с показанным разбросом. Стратегия, которой нужна дружелюбная сводка, чтобы пройти, не проходит.
Провал третий: holdout, который перестал им быть
Holdout работает ровно один раз. Во второй раз, когда стратегию проверяют на нём — после подкрутки параметра, правки сигнала, «да просто посмотрим», — это уже не holdout, а медленный валидационный набор. Пятнадцать нетронутых дней кажутся мелочью, которую легко сохранить, — ровно до момента, когда появляется давление итераций и повторная проверка выглядит безобидной.
Разрушения тут малозаметны: результаты на holdout улучшаются от итерации к итерации одной и той же стратегии. У свежих out-of-sample данных нет никаких причин вознаграждать третью итерацию сильнее первой, а если это происходит — значит, holdout уже выработан. Мы обеспечиваем однократность механически: holdout оценивается один раз за прогон пайплайна, результат записывается в историю, а стратегия, которой нужна ещё одна попытка, проходит всю полосу препятствий заново — с новыми окнами и всем прочим. Она обязана сохранить минимум 70% walk-forward out-of-sample Sharpe, и второго броска этих костей не бывает.
Симптом, который переживает все три
До всего этого мы прогоняем обычный анализ чувствительности: сдвигаем каждый параметр на ±20% и смотрим на метрики. Настоящее преимущество деградирует плавно; совпадение срывается в пропасть. Это самый дешёвый тест в пайплайне, и он отсекает стратегии, которые прошли бы через всё вышеописанное без сучка и задоринки, — потому что обрыв по параметру и есть то, как переобучение выглядит до того, как вы дали ему шанс спрятаться в механике валидации.
Ничто из этого не делает оптимизацию безопасной. Оно делает провалы громкими — а это максимум, о чём честно можно просить процесс валидации.
← Все статьи