Новый-старый подход к оптимизации торговых систем

Размышляя над темой оптимизации систем, поймал себя на мысли, что популярная трейдерская парадигма тестирования In-Sample (IIS) и проверка на Out-Of-Sample(OOS) не лишена изъянов. В интервью Джеку Швагеру CIO хедж-фонда QIM Jaffray Woodriff раскритиковал этот подход, сказав что OOS это «cherry picking» результатов оптимизации, и по факту OOS является частью выборки IIS. Он предложил свое решение, которое изложено в его интервью в книге Hedge Fund Market Wizards. Но сегодня я хочу поговорить немного о другом подходе.
В тестировании в рамках парадигмы IIS-OOS, существует множество вопросов, например:
— Какой период отвести под IIS, какой под OOS и в каких пропорциях, 70/30, 50/50, 30/70?
— Какой период должен идти первым: IIS-OOS или OOS-IIS?
— В момент принятия решения, может возникнуть дилемма: а не изменился ли рынок, т.к. IIS и OOS у нас различаются.

От ответа на эти, на первый взгляд, простые вопросы зависит качество полученных результатов, и общая картина, и в конце концов это будет влиять на решение ставить или нет, ту или иную систему на торги.

Конечно во многих случаях проблемы выше можно решить с помощью walk-forward оптимизации, но для определенных типов стратегий/исследований этот подход не будет работать. Как например, для некоторых паттернов, которые либо есть, либо нет, как беременность ©. Такого рода паттерны тоже нужно проверять на прочность.

Больше всего меня лично в IIS-OOS подходе не устраивает, то что этот подход плодит дилемму «а не изменился ли рынок», и особенно в случаях когда IIS — это самые свежие данные, так и хочется подумать: OOS плохой потому-что рынок тогда давным давно был другим. Эта особенность мозга ломает все функции IIS-OOS по отбраковке подгонки.

Теперь к сути моего подхода, идея которого не нова, она знакома многим кто занимается data mining и machine learning как кросс-валидация, такую же идею в свое время выдвигал Kent .

Суть в том, что мы разбиваем наши данные не на 2 куска, а на 3, точнее 10 кусков по 3.
Куски будут иметь следующие функции:
1. In-Sample — критерий по которому будет проводится первичный отбор
2. Out-Of-Sample — критерий по которому будет проводится валидация IIS
3. xOOS — критерий по которому будет оцениваться «честный» performance системы

Как я разбиваю данные:
IIS — 25%
OOS — 25%
xOOS — 50%

Допустим выборка у нас 120 баров, мы делим ее на 10 кусков по 12 баров, с чередующимися IIS-OOS-xOOS.
Состав одного из кусков ниже, дальше повторяем такие блоки еще 10 раз, пока не заполним всю историю.
IIIOOOXXXXXX
I - InSample
O - OutOfSample
X - XOutOfSample
В пропорциях 25%/25%/50%


Как мы видим наши данные делятся пополам на 2 куска, один из которых участвует в анализе IIS-OOS, а другой исследуется на финальном этапе, как «честный» performance системы.

Теперь для отбора систем можно полноценно рассчитывать метрики на основе соотношений показателей IIS/OOS, при этом задействовав лишь 50% данных, а другие 50% использовать для общей валидации робастности оптимизационной выборки.

Проблема с изменением рыночных условий остается, но она уже не такая острая, т.к. мы используем все данные в IIS/OOS/xOOS, но редко встретишь системы которые хорошо работают на всех фазах рынка за 10 лет :) Думаю эту проблему нужно будет решать с помощью других методов, например понимания как и когда изменилась микроструктура рынка, и начинать тестирование с этого момента.

Disclaimer: никакая оптимизация не даст гарантии, что система будет работать в будущем, поэтому помимо статистики в рынку нужно прикладывать и голову, чтобы понимать процессы которые происходят на рынке.

Содержимое спойлера вам недоступно:
  • Просмотр содержимого доступен только Черным и Красным пиджакам

14 комментариев

avatar
может проще реализовать пропуском сделок?
Т.е. если запускаем в режиме iss, то торгуем каждую 5ю сделку начиная с 1ой(остальные пропускаем)
если oos, то каждую 5ю со 2ой,
если oosX, то 3 и 4, начиная с 3ей
Тогда не будет проблем, что при разбиении на равные участки в одни режимы может попасть больше сделок, в другие меньше, или то что сделка открытая на участке для одного режима перейдёт на другие и т.д.
avatar
Появится проблема, что нельзя будет сравнить динамику 2х систем, т.к. частота их сделок будет разной, и может приходиться на различные участки данных.
avatar
А ты их по участкам что-ли сравниваешь?
P.S. каков механизм работы с тремя зонами (ios,oos,xos)? Просто с двумя знаю, с тремя нет)) Или это то, что под катом?
Комментарий отредактирован 2013-06-07 15:43:44 пользователем Avals
avatar
Ну да по участкам. Механизм: выбрать на основе показателей IIS, лучшие показатели на OOS, и сделать их оценку через xOOS. И под катом тоже ;)
avatar
ну например, имеем трендовую систему. Были участки с трендом, где система естественно будет зарабатывать. Разбили котиры. Трендовые участки разбились по is,oos,xoos. Конечно, будет кластеризация хороших и плохих резалтов по is,oos,xos. Т.е. если участки «хороших фаз» для нашей системы достаточно продолжительны, то кластеризация хороших и плохих результатов при таком разбиении обеспечена.
avatar
С этими выборками печаль. Как ни крути получаются одни и те же яйца. Все упирается в то, что события- закономерности либо были, либо нет. Могли быть всегда а завтра исчезнуть. А могли быть только в 2009. И от жонглирования выборками ничего ж не изменится. Вся соль в вопросе «каково черта происходит так, если...?»

Про кросс-валидацию. Там вроде курвится на кусочке i, тест на n-1 кусках. Потом следующий кусочек и опять на n-1. И в итоге складывается большая большая еквити. Если в итоге еквити не фонтан то вся модель в мусор. Так Кургузкин проповедовал)

И опять вопрос. Какого черта что-то должно происходить на всех n-1 кусках так же как на всех i-ых.
avatar
Про выборки см. disclaimer :)

И опять вопрос. Какого черта что-то должно происходить на всех n-1 кусках так же как на всех i-ых.
Если выборка достаточно большая, допустим 5 лет, мы получим 10 кусков по 6 мес, в которых 1.5 мес IIS / 1.5 мес OOS / 3 мес xOOS, вполне достаточная выборка для интрадей/краткосрочных систем.
Имхо.
avatar
Тьфу. Наоборот. На n-1 курвится на i тестится.
avatar
Как вариант оценка подогнаности методом Монте-Карло.
Есть реальная эквити на куске данных. Целевой показатель, например ПФ. Генерируем 1000 случайных кусков данных такой же продолжительностью (СБ с такой же волой) и на каждом строим эквити этой системы. Оцениваем вероятность того, что ПФ на случайных данных больше или равен реальному. Чем меньше эта вероятность тем лучше. Т.е. выбираем порог, ниже которго считаем эквити не подогнаной
Комментарий отредактирован 2013-06-08 08:51:45 пользователем Avals
avatar
и на каждом строим эквити этой системы.
Предлагаешь прогнать логику системы на СБ?

Чем меньше эта вероятность тем лучше.
Совсем не понял, почему смотрим плохие варианты? Или это для исключения заглядывания в будущее?

Я в таком подходе не вижу смысла, особенно если стратегия юзает специфическое поведение участников (БГ), сезонность, или неценовые данные. Хотя помоему ты описал алгоритм как проверяет свои системы J. Woodriff. Хотя дела у него, надо сказать, не фонтан сейчас www.managedfutures.com/program_performance.aspx?fundtype=&productId=20167
avatar
да на сб. Много штук СБ)
Не плохие варианты смотрим. Подход почти тот же, что ты юзаешь для отключения систем
Прогоняем на куче сб с реальной структурой волы нашу систему. Получится какое-то распределение целевого показателя (например ПФ). Наш реальный ПФ попадает в какой-то квантиль. Или что тоже самое — сколько реализаций на сб обгонят наш резалт на реальных данных.
Это оценка вероятности получить такие же результаты (или лучше) случайно.
БГ отдельная история и тоже не без вероятности подгонки. Зависит от индивидуальных качеств охотника))
Комментарий отредактирован 2013-06-08 09:29:39 пользователем Avals
avatar
тоже не вижу смысла в таком подходе
avatar
Сам ценовой ряд моделировать имхо не правильно, т.к. в этом случае берется один процесс. А рынок генерируется из разных процессов, которые переключаются в каком то никому неизвестном порядке :)
Я использую полученный в бектесте трейдлист, что бы с помощью МК сделать его ресемплинг несколько тысяч раз и посмотреть потом на заданном уровне доверия целевые показатели- ПФ, worst case DD.
Тоже не лишено недостатков, но в этом вопросе не может быть единственно правильного подхода, как нет единственно правильной стратегии. Собственно по тем же фундаментальным первопричинам
avatar
смысл вычислить вероятность подгонки.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.