Одного деления IS/OOS мало: дизайн окон walk-forward

Вывод: если OOS — один отрезок, это всё ещё «один тест»

Разделение данных на оптимизационную (IS) и проверочную (OOS) части — полезный первый шаг, если вы подозреваете переоптимизацию. Но при единственном делении результат OOS говорит лишь о том, как система показала себя на этом одном отрезке.

Наш вывод таков: OOS нужно разбить на несколько окон, проверять их последовательно, двигаясь вперёд, и смотреть не на сумму, а на то, прибылен ли каждый отдельный диапазон. Если итог в плюсе, но прибыль сосредоточена в одном-двух окнах, оценку мы откладываем.

Слабые места фиксированного деления

Точка разделения влияет на результат

При фиксированном делении точку разреза выбирает разработчик. Если OOS случайно попал на период с выраженным трендом, логика выглядит лучше, чем есть на самом деле. Если попал на обратный период, можно отбросить вполне рабочую логику. В обоих случаях результат зависит от одного выбора — точки разделения.

Если смотреть на OOS много раз, он перестаёт быть OOS

Вторая проблема связана с поведением самого разработчика. Результат на OOS плохой — правим параметры и снова смотрим OOS. Повторив это несколько раз, вы по сути подбираете параметры под OOS. Формально данные не использовались, фактически они участвовали в оптимизации. Такая ошибка может случиться и у нас самих, и без жёсткой процедуры её не избежать.

Как строить окна walk-forward

Walk-forward — это метод, в котором «период оптимизации» и «следующий сразу за ним период проверки» образуют одно окно, а затем окно сдвигается вперёд во времени, и цикл повторяется. Период проверки всегда лежит в будущем относительно периода оптимизации, и в итоге получается несколько OOS-отрезков.

По какому критерию выбирать длину окна

Длину окна безопаснее определять не количеством лет по календарю, а количеством сделок. Если в проверочный отрезок попадает слишком мало сделок, прибыль или убыток определяются случайностью. Чем дольше удержание позиций и реже сделки, тем длиннее должен быть проверочный отрезок.

Порядок проверки по окнам

1. Расположить окна так, чтобы проверочные отрезки не пересекались
2. В каждом окне провести оптимизацию и применить полученные параметры только к следующему сразу за ним проверочному отрезку
3. Для каждого проверочного отрезка записать прибыль/убыток, PF, число сделок и максимальную просадку (drawdown)
4. Посмотреть, сколько окон имеют PF не ниже 1.0 и на какие периоды приходятся убыточные окна
5. Убедиться, что сумма остальных окон остаётся в плюсе, даже если исключить окно с наибольшей прибылью
6. Проверить, не «прыгают» ли выбранные для разных окон параметры слишком сильно

Ключевых проверок три:

• не сосредоточены ли прибыльные окна в одной части выборки
• не слишком ли велики убытки в убыточных окнах относительно прибыли в прибыльных
• не меняются ли оптимальные параметры экстремально между соседними окнами

Мы не считаем, что все окна обязаны быть прибыльными. Трендовым системам нормально проигрывать в окнах без направленного движения. Проблема в другом: если причину убытков в окне объяснить нельзя, а глубина убытка выходит за ожидаемые пределы.

Ограничения и оговорки

Если сделок мало, окна не получаются

Бэктест ATLAS охватывает 7.5 года проверки и содержит 1193 сделки, поэтому даже при делении на несколько окон в каждом остаётся достаточное количество сделок. А вот бэктест ETHEREUM EA за те же 7.5 года содержит всего 154 сделки. Если нарезать такую малочастотную логику на мелкие окна, на каждое окно придётся совсем немного сделок, и прибыль или убыток в отдельном окне почти ничего не говорит. Остаётся либо укрупнять окна, либо воспринимать оценку по окнам лишь как справочную.

Опубликованные нами цифры — за весь период

PF и доля прибыльных сделок в рейтинге по реальным замерам — это значения за весь период проверки. Это не результаты по отдельным окнам, поэтому только по ним нельзя судить, есть ли переоптимизация. Читайте их с поправкой на это.

Сам дизайн окон тоже можно оптимизировать

Если менять длину и число окон и выбирать комбинацию, при которой результат выглядит лучше, это тоже переоптимизация. Предпосылка такова: дизайн окон фиксируется до запуска проверки и потом не меняется. Со стороны проверить, соблюдалась ли эта предпосылка, практически невозможно.

Будущее всё равно неизвестно

Даже успешно пройденный walk-forward не гарантирует работу на рынке, какого раньше не было. Среди советников, которых мы ведём на форвард-тесте на демо-счёте, несколько находятся в минусе. Это демо-счёт, а не результаты реального, и прошло ещё мало времени, поэтому делать выводы по хорошим или плохим результатам пока рано. Методика проверки — инструмент, сокращающий число промахов, а не обещание попаданий.

Итоги

• Результат фиксированного деления IS/OOS зависит от точки разреза и от числа пересмотров OOS
• Walk-forward — метод, в котором создаётся несколько проверочных отрезков и результат проверяется по мере продвижения вперёд
• Смотреть нужно не на сумму, а на прибыль/убыток по окнам: проверяем перекос прибыли и стабильность параметров
• Чем меньше сделок у логики, тем нестабильнее вывод при делении на окна
• Дизайн окон фиксируется заранее. Прохождение проверки ничего не говорит о будущих результатах

Подход к проверке мы также собрали в сборнике know-how.