Кастомный фреймворк бэктестинга: где ломаются нестандартные стратегии
Стандартные системы тестирования рассчитаны на стратегии вида «сигнал — вход — фиксированный стоп и тейк». Нестандартные стратегии так не описываются: вход зависит от совпадения условий по нескольким источникам, выход идёт этапами, решение опирается на состояние портфеля. Готовый инструмент тестирования подменяет такую логику своей моделью, и искажение результатов тестирования всплывает уже на живых сделках.
Первый разрыв — условия входа: событие требует одновременного выполнения правил по разным инструментам и периодам, а стандартный движок сводит их к одному закрытию свечи. Заявка в модели встаёт не там, где встала бы в реальном потоке, и на длинной серии сделок разница накапливается.
Второй — многоэтапный выход. Частичное закрытие, перенос защитного уровня вслед за ценой, повторный вход на откате: типовой шаблон закрывает позицию целиком по одному правилу. В тесте стратегия выглядит прибыльной ровно потому, что её настоящая логика выхода не исполнялась.
Третий — порядок исполнения заявок. На всплеске волатильности несколько заявок претендуют на одну цену, и то, какая обработана первой, меняет результат сильнее самого сигнала. Синтетический поток сглаживает просадки, а редкие события — разрывы, остановки торгов, аномальные спреды — не воспроизводятся вовсе.
Собрать кастомный фреймворк бэктестинга — значит перенести в модель вашу логику целиком, вместе с очередью заявок и редкими сценариями. Дальше разбираем, как это закрывается по этапам.
Что даёт отдельный тестовый контур: измеримые эффекты
Прогонять гипотезы на живом контуре дорого: ошибка становится видна только по просадке, а каждая проверка расходует реальные средства. Отдельный тестовый контур переносит проверку на исторические данные — гипотеза отсеивается до того, как в дело пойдут деньги, а результат прогона сравнивается с предыдущими запусками.
Скорость прогона набора стратегий
На кастомном фреймворке бэктестинга набор из 200–300 конфигураций стратегии проходит за ночь, тогда как последовательный прогон тех же конфигураций растягивается на неделю — ускорение в 8–12 раз. Достигается оно распараллеливанием по срезам данных и переиспользованием посчитанного состояния: при изменении только правила выхода история заново не пересчитывается.
Воспроизводимость и контроль рисков
Каждый прогон привязан к зафиксированному срезу данных и сохранённой конфигурации, поэтому результат воспроизводится и через месяц, и после правок кода: расхождение между запусками — доли процента, и видно его построчно в журнале. Так уходит целый класс отказов — расхождение результатов при одинаковых входных данных и тихая подмена источника котировок между запусками.
Подглядывание вперёд, то есть расчёт на данных, которых в реальном времени ещё не было, отсекается отдельной проверкой. Котировки сверяются с историей оракульных цен Chainlink, а стратегия дополнительно идёт по граничным срезам: разрыв ликвидности, скачок сетевых комиссий, остановка источника данных. То, что выживает на них, уходит в реальный контур с заранее понятной ценой риска.
Варианты реализации каркаса бэктестинга: сравнение подходов
Выбор между готовым продуктом и своим каркасом определяет не скорость запуска, а то, какие стратегии вы вообще сможете проверить. Пока логика держится на стандартных индикаторах, хватает готовой библиотеки. Как только появляются данные разных интервалов, очередь ордеров или нестандартный риск-контур, начинается обвязка вокруг чужого кода.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Готовый каркас как есть | Стратегии на стандартных индикаторах, быстрая проверка гипотез | Модель исполнения зашита в ядро, нестандартные правила подгоняются под чужую логику |
| Доработка готового решения | Нужен узкий слой: свой источник данных, нестандартный расчёт комиссий | Правки теряются при обновлении, тесты ядра не покрывают вашу логику |
| Собственный слой проверки поверх готового | Сигналы свои, а учёт сделок и портфеля устраивает | Две модели данных надо синхронизировать, расхождение в расчёте позиции видно на реальном счёте |
| Полностью собственный каркас | Уникальная логика исполнения, требования к воспроизводимости и аудиту | Дольше и дороже на старте, нужны тесты и эталонные наборы данных |
Ограничения готовых решений
Главное ограничение — не производительность, а зашитая модель мира: порядок событий, тип данных, способ учёта проскальзывания и комиссий. Всё, что выходит за эти рамки, обходится костылями, а расхождение проверки с реальным исполнением всплывает уже после запуска.
Когда нужен собственный слой
Свой слой оправдан, когда стратегия опирается на данные вне типовой модели: стакан, внебиржевые котировки, внешние сигналы, ручные вмешательства. Гибридный вариант — компромисс: учёт сделок и портфеля берёт на себя готовое ядро, а логика сигналов остаётся вашей и тестируется отдельно.
Этапы разработки: от разбора стратегий до приёмки и передачи
Этапы разработки строятся вокруг главного риска: нестандартная стратегия ломает типовые инструменты, поэтому проверять её нужно на вашей логике, а не на усреднённой. Начинаем с разбора, а не с кода, и только после согласования модели исполнения переходим к реализации.
Разбор стратегий и данных
- Аудит стратегий. Фиксируем логику входа и выхода, набор инструментов, частоту ребалансировки, работу с плечом и правила управления риском. На выходе — формализованное описание, которое однозначно проверяется расчётом.
- Схема данных. Сводим исторические ряды к единому формату: таймзоны, пропуски, корпоративные события, делистинг. Отдельно описываем, чем восполняем дыры, чтобы это не создавало ложной доходности.
- Проектирование контура. Определяем модель исполнения: тип ордеров, проскальзывание, комиссии, задержку подачи, частичные исполнения. Именно здесь чаще всего расходятся тест и реальная торговля.
Реализация, приёмка и передача
- Настройка ядра. Собираем расчётную часть под согласованный контур и выносим параметры стратегий в конфигурации — новая логика подключается без переписывания ядра.
- Проверка. Прогоняем контрольные сценарии и сверяем результат с независимым ручным расчётом на коротком окне: так ошибки схемы данных и модели исполнения всплывают до приёмки.
- Приёмка и передача. Прогон на вашей истории, сверка метрик, разбор расхождений, затем исходники, документация, схема данных и обучение команды. После передачи вы запускаете новые стратегии сами.
Состав поставки: код, схемы данных, регламенты и отчёты
Поставка по кастомному фреймворку бэктестинга собирается так, чтобы команда заказчика дальше вела разработку и прогоны без нас: код — в вашем репозитории, результаты воспроизводятся на вашем контуре, решения по доступам принимаете вы. Ниже — состав поставки и то, чем она закрепляется.
Документация и регламенты
- Исходный код с историей изменений и правами на использование, со схемой сборки — без зависимости от наших внутренних сервисов.
- Схемы данных: структуры исторических котировок и ончейн-событий, правила обработки корпоративных действий, точки очистки и обрезки датасетов.
- Регламент прогона: как фиксируются параметры, версии данных и конфигурации, чтобы результат повторялся и через месяц, и после смены состава команды.
- Отчёты о верификации движка на эталонных стратегиях: где расхождения с ожидаемым результатом и чем они объясняются.
- Инструкция по подключению новой стратегии: какие модули править, как прогнать регресс и на какие метрики смотреть при приёмке.
Права и доступы к контуру
- Матрица ролей: кто может менять ядро, кто — только конфигурации и данные, кто — только читать отчёты прогонов.
- Порядок выдачи и отзыва доступов, включая наши технические учётные записи: после сдачи они отключаются по вашему запросу.
- Разделение сред разработки и прогона, правила выгрузки данных за пределы контура и журналирование действий с ними.
Кейс с метриками: проверка стратегии до и после
Клиент — торговая команда с нестандартной логикой входа: ликвидность пула на Uniswap, частичное закрытие ступенями. Готовые движки требовали переписать стратегию под их модель свечей, поэтому решения принимались почти на глаз.
Контекст задачи
Проверка одной конфигурации занимала около четырёх часов: движок пересчитывал весь исторический ряд для каждого набора параметров, а условия входа не помещались в его модель.
Перебирали три-четыре варианта в день, редкие сценарии — всплески ликвидности, каскадные ликвидации — в проверку не попадали. По итогам квартала 18% сделок в бою не совпадали с бэктестом.
Что изменилось в проверке
Мы собрали кастомный фреймворк бэктестинга под логику команды: свой слой описания стратегий, отдельное хранилище событий по блокам и пересчёт только изменившихся участков вместо всего ряда.
- Время прогона конфигурации — с четырёх часов до 11 минут, перебор параметров идёт пакетно.
- Доля расхождений с боевыми сделками — с 18% до 3%: добавлены комиссии, проскальзывание и задержки исполнения.
- Просадка в бэктесте и в бою сходится в пределах двух пунктов вместо расхождения втрое.
Первые же прогоны показали, что часть «рабочих» конфигураций держится на одном удачном периоде — теперь это видно до вывода средств.
Что делать, если стратегия уже проверяется в готовом решении?
Готовое решение и собственный контур не конкурируют — они отвечают на разные вопросы. Готовое решение быстро показывает, есть ли в идее сигнал; собственный контур показывает, воспроизводится ли этот сигнал на нашей инфраструктуре, с нашими комиссиями и нашим профилем исполнения заявок. Пока ответы расходятся, стратегию рано отдавать в реальную торговлю.
Начинаем с параллельной проверки, а не с переписывания. Один и тот же исторический отрезок, одинаковые правила входа и выхода, одинаковые комиссии — обе системы считают метрики независимо, и мы смотрим не на абсолютную доходность, а на расхождение по сделкам. Разница в доходности на бар сразу показывает, где модели расходятся: учёт проскальзывания, задержка заявки, обработка пропусков в данных или порядок расчёта позиции.
Внедрение в текущий процесс идёт сбоку и не останавливает команду. Готовое решение продолжает крутить текущие исследования, собственный контур подключается к тем же выгрузкам данных и складывает результаты в отдельное хранилище — сначала на одной-двух стратегиях, с ежедневным сравнением отчётов. Если контур падает или считает дольше, исследовательский процесс этого не замечает.
Переход на собственный контур — не одномоментный, а по критерию. Считаем его завершённым, когда на выбранном историческом окне и на нескольких режимах рынка расхождение с готовым решением укладывается в оговорённый допуск, а повторный прогон даёт тот же результат. После этого готовое решение остаётся быстрым черновым фильтром, а спорные стратегии проверяются только в кастомном фреймворке бэктестинга.
Частые технические сомнения перед стартом работ
Сомнения на старте обычно одни и те же: совпадёт ли модель исполнения с реальной торговлей, как кастомный фреймворк бэктестинга встроится в уже написанные стратегии и что будет после передачи. Ниже — ответы по каждому пункту.
Насколько точна модель исполнения?
Считаем не по цене закрытия свечи, а по тому, как заявка реально попадёт в стакан: тип ордера, момент отправки, доступная глубина. Проскальзывание, задержка и комиссии — параметры, а не зашитые константы: модель калибруется по вашей истории сделок и сверяется с фактическим результатом.
Стратегии придётся переписывать?
Нет. Фреймворк даёт интерфейс: вы отдаёте сигналы и правила управления позицией, ядро берёт на себя исполнение, учёт комиссий и расчёт метрик. Логика из прода переносится точечно и сверяется на отрезке, где известен фактический итог.
Можно считать на своих данных и своих источниках?
Да. Подключаем вашу историю — котировки, стакан, сделки — и при необходимости поток в реальном времени. Если данные неполные, фиксируем это в отчёте: лучше видеть, где расчёт опирается на допущение, чем получить гладкую кривую без объяснения.
Что после передачи — останемся одни?
Передаём код, конфигурации и расчётные сценарии с описанием: как запустить, воспроизвести результат, добавить новый инструмент. Сопровождение после передачи — отдельный этап: разбираем запуск с вашей командой и устраняем найденное.
Как потом вносить правки и доработки?
Через тот же контур: новая модель исполнения, метрика или источник данных добавляются отдельным модулем, не ломая проверенные расчёты. Конфигурации версионируются — результат до и после правки сравним, откат возможен.
Обсудим задачу: какие данные нужны для оценки и плана
Оценка такого проекта опирается не на общее описание стратегии, а на её вычислительный профиль: сколько инструментов в срезе, как часто принимаются решения, какие данные нужны на каждом шаге. Поэтому в обсуждении задачи мы сначала собираем вводные — по ним видно трудоёмкость и достаточно ли доработки существующей среды тестирования или нужен отдельный контур.
Что присылаете для оценки и плана работ:
- Логика стратегии: правила входа и выхода, условия фильтрации, ручные исключения и случаи, где решение принимает человек.
- Данные: источники истории, глубина и периодичность, формат файлов, есть ли стаканы заявок и лента сделок, а не только бары.
- Модель исполнения: как учитывать комиссии, проскальзывание, задержку подачи и частичное заполнение заявок.
- Проверка на устойчивость: как делится история на обучающий и проверочный участки, по каким метрикам отбраковываем результат.
- Набор отчётности: какие показатели и графики нужны на выходе, в каком виде и куда отдаются.
- Ограничения: доступы к данным, требования инфраструктуры, режим повторных прогонов и правила воспроизводимости результата.
- Что уже есть: текущий стек тестирования, прошлые реализации, узкие места, которые мешают сейчас.
Пришлите то, что есть, в любом рабочем виде — черновик спецификации, скрипты, выгрузку сделок. Разберём, зададим уточняющие вопросы по модели исполнения и вернёмся с оценкой сроков и планом работ по этапам.
