Новый-старый подход к оптимизации торговых систем
Размышляя над темой оптимизации систем, поймал себя на мысли, что популярная трейдерская парадигма тестирования 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: никакая оптимизация не даст гарантии, что система будет работать в будущем, поэтому помимо статистики в рынку нужно прикладывать и голову, чтобы понимать процессы которые происходят на рынке.
В тестировании в рамках парадигмы 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: никакая оптимизация не даст гарантии, что система будет работать в будущем, поэтому помимо статистики в рынку нужно прикладывать и голову, чтобы понимать процессы которые происходят на рынке.