В процессе загрузки ресурсов... загрузка...

Следует ли создавать свой собственный тест?

Автор:Доброта, Создано: 2019-03-19 14:03:46, Обновлено: 2019-03-19 14:08:48

О этой статье

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

Затем мы обсуждаем, стоит ли создавать свой собственный бэкстестер, даже с распространением инструментов с открытым исходным кодом, доступных сегодня.

Наконец, мы обсуждаем подробности системы обратного тестирования, основанной на событиях, темы, которые я часто освещал на QuantStart в предыдущих постах.

Что такое обратный тест?

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

Когда-то было сказано, что Все модели неверны, но некоторые полезны. То же самое верно и для бэкстеров.

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

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

Существует два основных типа программного обеспечения backtest - for-loop и event-driven системы.

При разработке программного обеспечения для обратного тестирования всегда существует компромисс между точностью и сложностью реализации.

Плохие последствия

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

  • Пробные испытания - это происходит, когда вы используете одни и те же данные для обучения своих торговых моделей, а также для их тестирования. Это почти всегда увеличивает эффективность стратегии выше, чем это было бы видно в живой торговле. Это связано с тем, что она не была подтверждена на невидимых данных, которые, вероятно, заметно отличаются от данных обучения. По сути, это форма переподготовки.
  • Склонность к выживанию - для фондовых индексов, таких как S&P500, происходит периодический процесс листинга и исключения из листинга, изменяющий состав с течением времени. Не принимая во внимание этот изменяющийся состав на обратном тесте, торговые стратегии автоматически "выбирают победителей" в силу игнорирования всех компаний, выпавших из индекса из-за низкой рыночной капитализации. Следовательно, при проведении долгосрочных обратных тестов всегда необходимо использовать данные, свободные от склонности к выживанию.
  • Look-Ahead Bias - будущие данные могут проникать в бэкстесты очень тонкими способами. Рассмотрим вычисление соотношения линейной регрессии в течение определенного периода времени. Если это соотношение затем используется в той же выборке, то мы косвенно принесли будущие данные и, следовательно, вероятно, увеличим производительность.
  • Изменение режима рынка - это связано с тем, что параметры фондового рынка не являются стационарными. То есть, основной процесс, генерирующий движение акций, не должен иметь параметров, которые остаются постоянными во времени. Это затрудняет обобщение параметризированных моделей (например, многие торговые стратегии), и, следовательно, производительность, вероятно, будет выше в бэк-тестах, чем в живой торговле.
  • Стоимость транзакции - многие обратные тесты For-Loop не учитывают даже базовые затраты на транзакции, такие как сборы или комиссии. Это особенно верно в академических статьях, где обратные тесты в значительной степени проводятся без затрат на транзакции. К сожалению, слишком легко найти стратегии, которые являются высокодоходными без затрат на транзакции, но приносят существенные потери, когда подвергаются реальному рынку. Типичные затраты включают спред, влияние на рынок и скольжение. Все это должно быть учтено в реалистичных обратных тестах.

Существуют некоторые более тонкие проблемы с бэкстестированием, которые не обсуждаются так часто, но все же невероятно важны для рассмотрения.

  • Данные OHLC - данные OHLC, то есть тип ежедневных данных, полученных с бесплатных сайтов, таких как Yahoo Finance, часто являются объединением нескольких биржевых каналов. Поэтому маловероятно, что некоторые из более экстремальных значений (включая высокую и низкую цены дня) могут быть получены живой торговой системой.
  • Ограничения мощности - при обратном тестировании легко использовать бесконечный горшок денег. Однако в реальности капитал, а также маржа, строго ограничены. Необходимо также думать о пределах среднего суточного объема (ADV), особенно для акций с небольшой капитализацией, где возможно, что наши сделки действительно могут двигаться на рынке. Такие эффекты влияния рынка должны быть учтены для целей управления рисками.
  • Например, если вы торгуете товарными фьючерсами и нейтральны к американскому индексу акций S&P500, действительно ли имеет смысл использовать S&P500 в качестве эталона?
  • Устойчивость - изменяя время начала вашей стратегии в рамках вашего бэкстеста, результаты кардинально меняются? для долгосрочной стратегии не должно иметь значения, начинается ли бэкстест в понедельник или в четверг. Однако, если он чувствителен к "начальным условиям", как вы можете надежно предсказать будущую производительность при живой торговле?
  • Превышение нагрузки/противоположность - мы обсуждали это немного выше в пункте тестирования в выборке. Однако перевыполнение является более широкой проблемой для всех (наблюдаемых) методов машинного обучения. Единственный реальный способ решить эту проблему - через тщательное использование методов перекрестной проверки. Даже тогда мы должны быть крайне осторожны, чтобы мы не просто приспособили наши торговые стратегии к шуму в учебном наборе.
  • Психологическая толерантность - Психология часто игнорируется в квантовых финансах, потому что (предположительно) она удаляется путем создания алгоритмической системы. Однако она всегда проникает, потому что кванты имеют тенденцию tinker или override систему, как только развернутая в реальном времени. Кроме того, то, что может показаться терпимым в бэкстестесте, может быть желудочным в реальном времени. Если ваша бэкстетированная кривая акций показывает 50% снижение в какой-то момент в истории торговли, можете ли вы также проехать через это в сценарии реального времени?

Многое было написано о проблемах с бэкстестированием.

Системы обратного тестирования фор-пути

For-Loop Backtester является самым простым типом системы бэкстестинга и вариантом, который чаще всего встречается в квантовых сообщениях в блогах, исключительно из-за его простоты и прозрачности.

По сути, система For-Loop повторяется в течение каждого торгового дня (или панели OHLC), выполняет некоторые расчеты, связанные с ценой актива, такие как скользящая средняя, и затем идет на длинный или короткий конкретный актив (часто по той же цене закрытия, но иногда на следующий день).

Вот псевдокод для такого алгоритма:

for each trading bar:
    do_something_with_prices();
    buy_sell_or_hold_something();
    next_bar();PythonCopy

Как видите, конструкция такой системы невероятно проста, что делает ее привлекательной для того, чтобы получить "первый взгляд" на эффективность конкретного набора правил стратегии.

Преимущества

For-Loop backtesters просты в реализации практически в любом языке программирования и очень быстры в выполнении.

Недостатки

Основным недостатком бэкстеров For-Loop является то, что они довольно нереалистичны. Они часто не имеют возможности затрат на транзакции, если специально не добавлены. Обычно заказы заполняются немедленно на рынке с ценой средней точки. Таким образом, часто не учитывается спред.

Существует минимальное повторное использование кода между системой обратного тестирования и системой реального трейдинга. Это означает, что код часто нужно писать дважды, что вводит возможность большего количества ошибок.

For-Loop backtesters склонны к Look-Ahead Bias из-за ошибок с индексацией. Например, следует ли использовать i, i+1 или i-1 в индексации панели?

For-Loop backtesters действительно должны использоваться исключительно в качестве фильтрационного механизма. Вы можете использовать их для устранения явно плохих стратегий, но вы должны оставаться скептическими в отношении сильной производительности. Часто требуются дальнейшие исследования. Стратегии редко работают лучше в живой торговле, чем в backtests!

Системы обратного тестирования, основанные на событиях

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

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

  • Tick Events - Signify прибытие новых данных о рынке
  • Сигнальные события - генерация новых торговых сигналов
  • События ордера - ордера, готовые к отправке в рыночный брокер
  • Заполните события - заполните информацию от брокера рынка

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

Псевдо-код для системы обратного тестирования на основе событий выглядит следующим образом:

while event_queue_isnt_empty():
    event = get_latest_event_from_queue();
    if event.type == "tick":
        strategy.calculate_trading_signals(event);
    else if event.type == "signal":
        portfolio.handle_signal(event);
    else if event.type == "order":
        portfolio.handle_order(event);
    else if event.type == "fill":
        portfolio.handle_fill(event)
    sleep(600);  # Sleep for, say, 10 minsPythonCopy

Как вы можете видеть, существует большая зависимость от модуля обработки портфеля.

Преимущества

Существует много преимуществ в использовании теста на события:

  • Устранение предвзятости - в силу своей конструкции передачи сообщений, системы, управляемые событиями, обычно свободны от предвзятости, по крайней мере на уровне торговли.
  • Код повторного использования - для торговли в режиме реального времени необходимо только заменить модули обработки данных и обработки исполнения.
  • Уровень портфеля - с системой, основанной на событиях, намного проще думать на уровне портфеля.
  • Правильное управление рисками/позициями - может легко модулировать управление рисками и позициями. может легко внедрять рычаги и методологии, такие как критерий Келли. также может легко включать предупреждения о отраслевой экспозиции, лимиты ADV, лимиты волатильности и предупреждения о неликвидности.
  • Удаленное развертывание/мониторинг - модульный характер кода облегчает развертывание в облаке или совместное размещение программного обеспечения вблизи обмена на виртуализированной системе.

Недостатки

Хотя преимущества очевидны, есть также некоторые серьезные недостатки использования такой сложной системы:

  • Трудно программировать - создание полностью протестированной системы, основанной на событиях, вероятно, займет недели или месяцы работы на полный рабочий день.
  • Требуется объектная ориентация - модульный дизайн требует использования принципов объектно-ориентированного программирования (ООП), и, следовательно, языка, который может легко поддерживать ООП.
  • Инженерное программное обеспечение - более вероятно, что потребуется хорошая экспертиза и возможности в области программного обеспечения, такие как регистрация, одиночное тестирование, контроль версий и непрерывная интеграция.
  • Медленное выполнение - характер передачи сообщений кода делает его намного медленнее для выполнения по сравнению с векторизированным подходом For-Loop.

Ландшафт программного обеспечения

В этом разделе мы рассмотрим программное обеспечение (как с открытым исходным кодом, так и коммерческое), которое существует как для For-Loop, так и для систем, управляемых событиями.

Для бэкстеров For-Loop основные языки программирования / программное обеспечение, которые используются, включают Python (с библиотекой Pandas), R (и библиотекой quantmod) и MatLab.

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

Дорогие коммерческие предложения включают Deltix и QuantHouse.

Облако-основанные системы бэкстестинга и торговли в режиме реального времени являются относительно новыми.

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

У розничных квантов есть выбор между использованием подхода cloud+data Quantopian или rolling their own с использованием поставщика облачных услуг, такого как Amazon Web Services, Rackspace Cloud или Microsoft Azure, наряду с соответствующим поставщиком данных, таким как DTN IQFeed или QuantQuote.

С точки зрения программного обеспечения с открытым исходным кодом существует множество библиотек. Они в основном написаны на Python (по причинам, которые я изложу ниже) и включают Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver/Investment Idiocy) и QSTrader (собственный бэкстестер QuantStart).

Однако один из наиболее важных аспектов заключается в том, что независимо от того, какое программное обеспечение вы в конечном итоге используете, оно должно быть сочетано с одинаково надежным источником финансовых данных.

Языки программирования

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

Несмотря на то, что у меня есть опыт разработчика количественного программного обеспечения, я лично не заинтересован в языковых войнах. В день есть только несколько часов, и, как кванты, мы должны делать вещи - не тратить время на споры о языковом дизайне на интернет-форумах!

Мы должны быть заинтересованы только в том, что работает.

Питон

Python - чрезвычайно легкий для изучения язык программирования и часто является первым языком, с которым люди вступают в контакт, когда решают изучать программирование.

Он имеет некоторые исключительные библиотеки квантовой / науки о данных / машинного обучения (ML) в NumPy, SciPy, Pandas, Scikit-Learn, Matplotlib, PyMC3 и Statsmodels.

Он отлично подходит для создания как For-Loop, так и систем обратного тестирования, основанных на событиях. На самом деле, это, пожалуй, один из немногих языков, который прямо позволяет исследование, обратное тестирование, развертывание, прямую торговлю, отчетность и мониторинг.

Возможно, его самый большой недостаток заключается в том, что он довольно медленно выполняется по сравнению с другими языками, такими как C ++. Однако ведется работа по улучшению этой проблемы, и со временем Python становится быстрее.

R

R - это среда статистического программирования, а не полноценный язык программирования первого класса (хотя некоторые могут утверждать обратное!). Он был разработан в первую очередь для выполнения передового статистического анализа временных рядов, классической / частотной статистики, байесовской статистики, машинного обучения и исследовательского анализа данных.

Он широко используется для бэкстестинга For-Loop, часто через библиотеку quantmod, но не особенно хорошо подходит для систем, управляемых событиями, или живой торговли.

C++

C++ имеет репутацию чрезвычайно быстрого. Почти все научные высокопроизводительные вычисления выполняются либо в Fortran, либо в C++. Это его главное преимущество.

К сожалению, это болезненно для проведения стратегических исследований. Из-за того, что он статически типизирован, довольно сложно легко загружать, читать и форматировать данные по сравнению с Python или R.

Несмотря на свой относительный возраст, он недавно был существенно модернизирован с введением C ++ 11 / C ++ 14 и дальнейшими уточнениями стандартов.

Другие?

Вы также можете взглянуть на Java, Scala, C #, Julia и многие другие функциональные языки.

Следует ли писать свой собственный (событийный) тест?

Ответ: Да!

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

Даже если вы не используете систему для торговли в режиме реального времени, она предоставит вам огромное количество вопросов, которые вы должны задать своим коммерческим или FOSS поставщикам.

Например: чем ваша нынешняя живая система отличается от вашей обратной симуляции с точки зрения:

  • Алгоритмическое исполнение и маршрутизация приказов?
  • Спред, комиссионные, скольжение и влияние на рынок?
  • Управление рисками и размещение позиций?

Хотя системы, управляемые событиями, не быстрые и не простые в написании, этот опыт принесет огромные образовательные дивиденды позже в вашей карьере в квантовой торговле.

Дизайн обратных тестов на основе событий 101

Как вы пишете такую систему?

Лучший способ начать - просто скачать Zipline, QSTrader, PyAlgoTrade, PySystemTrade и т. д. и попробовать прочитать документацию и код. Все они написаны на Python (по причинам, которые я изложил выше) и, к счастью, Python очень похож на чтение псевдокода. То есть, его очень легко следовать.

Роб Карвер из Investment Idiocy также излагает свой подход к созданию таких систем для торговли фьючерсами.

Помните, что вам не нужно быть экспертом в первый день. Вы можете делать это медленно, день за днем, модуль за модулем. Если вам нужна помощь, вы всегда можете связаться со мной или другими готовыми блогерами.

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

Главная база данных по ценным бумагам

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

Вместо этого мы используем первый класс базу данных или файловую систему, такую как PostgreSQL, MySQL, SQL Server или HDF5.

В идеале, мы хотим получить и сохранить данные уровня тика, так как это дает нам представление о торговых спредах. Это также означает, что мы можем построить свои собственные OHLC-бары, на более низких частотах, если захочется.

Мы всегда должны быть в курсе обработки корпоративных действий (таких как разделение акций и дивиденды), предвзятости выживания (удаление акций из листинга), а также отслеживания различий часовых поясов между различными биржами.

Индивидуальные/розничные компании могут конкурировать здесь, поскольку многие технологии баз данных качества производства являются зрелыми, бесплатными и с открытым исходным кодом.

Есть еще много рынков и стратегий, которые слишком малы для крупных фондов.

Торговые стратегии

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

Этот модуль НЕ предназначен для получения количества, которое осуществляется через модуль размещения позиций.

95% дискуссий в блогах Quant обычно вращаются вокруг торговых стратегий. Лично я считаю, что это должно быть больше, чем 20%. Это потому, что я думаю, что гораздо проще увеличить ожидаемую отдачу за счет снижения затрат путем правильного управления рисками и размещения позиций, а не преследовать стратегии с "больше альфа".

Управление портфелем и заказами

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

Целью этой системы является переход от текущего портфеля к желаемому портфелю при одновременном минимизации риска и снижении затрат на транзакции.

Модуль объединяет стратегию, риск, размер позиций и возможности исполнения ордеров системы.

Основным преимуществом использования такой сложной системы является то, что она позволяет обрабатывать различные финансовые инструменты в рамках одного портфеля. Это необходимо для портфелей институционального типа с хеджированием. Такая сложность очень сложна для кодирования в системе бэкстестинга For-Loop.

Управление рисками и позициями

Отделение управления рисками в свой собственный модуль может быть чрезвычайно выгодным.

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

Отдельный модуль размещения позиций может реализовать правила оценки волатильности и размещения позиций, такие как кредитный кредит Келли.

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

Управление исполнением

В реальной жизни мы никогда не гарантируем, что получим рыночное наполнение в середине!

Мы должны учитывать такие транзакционные вопросы, как пропускная способность, спред, сборы, скольжение, влияние на рынок и другие проблемы алгоритмического исполнения, иначе наши результаты обратного тестирования, вероятно, будут сильно завышены.

Модульный подход к управляемой событиями системе позволяет нам легко переключать BacktestExecutionHandler с LiveExecutionHandler и развертывать на удаленном сервере.

Мы также можем легко добавить несколько брокеров, используя концепцию OOP inheritance. Это, конечно, предполагает, что указанные брокеры имеют простой интерфейс программирования приложений (API) и не заставляют нас использовать графический пользовательский интерфейс (GUI) для взаимодействия с их системой.

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

Результаты и отчетность

Розничные банки могут и должны использовать сложные методы отчетности, используемые институциональными банками. Такие инструменты включают в себя живые дашборд портфеля и соответствующих рисков, обратный тест собственного капитала против живого собственного капитала разницы или дельта, наряду со всеми обычными показателями, такими как затраты на сделку, распределение доходов, высокая водная отметка (HWM), максимальная задержка, средняя задержка торговли, а также альфа/бета по сравнению с эталоном.

Необходимо постоянно улучшать эту инфраструктуру. Это может действительно повысить доходность в долгосрочной перспективе, просто устраняя ошибки и улучшая такие проблемы, как задержка торговли. Не просто зацикливайтесь на улучшении "величайшей стратегии мира" (WGS).

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

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

Развертывание и мониторинг

Развертывание на удаленном сервере, наряду с обширным мониторингом этой удаленной системы, абсолютно важно для систем институционального уровня.

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

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

Помните закон Мерфи - "Если она может потерпеть неудачу, она потерпит неудачу".

Есть много поставщиков, которые предлагают относительно простые облачные развертывания, включая Amazon Web Services, Microsoft Azure, Google и Rackspace.

Заключительные мысли

К сожалению, нет "быстрого решения" в квантовой торговле.

Возможно, главным камнем преткновения для начинающих (и некоторых промежуточных квантов!) является то, что они слишком концентрируются на лучшей "стратегии". Такие стратегии всегда в конечном итоге поддаются альфа-распаду и, следовательно, становятся нерентабельными. Поэтому необходимо постоянно исследовать новые стратегии для добавления в портфель. По сути, "стратегия" всегда должна быть полной.

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

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

Наконец, всегда читайте, учитесь и совершенствуйтесь. Есть множество учебников, торговых журналов, академических журналов, квантовых блогов, форумов и журналов, которые обсуждают все аспекты торговли. Для более продвинутых идей стратегии я рекомендую SSRN и arXiv - Quantitative Finance.


Больше