Разработка системы бэктестинга арбитражных стратегий под ключ

Бэктестинг арбитражных стратегий: где расчёт расходится с фактом

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

Причина почти всегда в трёх местах. Исторические данные собраны из разных источников с разными метками времени: там, где лента сделок склеена с обновлением стакана, появляются цены, которых не существовало, и такие ошибки в исторических данных рисуют прибыль, которой не было. Дальше — задержки котировок: между получением сигнала и постановкой заявки спред успевает закрыться, и это не рыночный шум, а систематический минус, не отражённый в модели.

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

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

Что меняется после внедрения корректного тестирования стратегий

Когда исторические данные собирают вручную — выгрузками с бирж, с разными часовыми поясами и форматами, — проверка одной гипотезы растягивается на недели. Хуже, что результат не воспроизводится: повторный прогон на «той же» выборке расходится с предыдущим на 15–20%, и непонятно, изменилась стратегия или данные.

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

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

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

Режимы проверки гипотез: сравнение подходов и ограничений

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

Ни один режим не даёт полной картины — расхождение между историей и реальными ордерами накапливается именно на задержках, частичных исполнениях и отказах. Поэтому выстраиваем их как последовательность с проверяемым переходом: история, затем живой поток, потом тестовый контур и только после этого ограниченный капитал.

Этапы внедрения: от разбора данных до передачи стенда

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

1. Аудит данных. Разбираем источники котировок и стаканов: с какой частотой приходят записи, как ведут себя ряды в моменты разрывов связи и переносов торговых сессий. На выходе — карта источников с перечнем пробелов, которые придётся восстанавливать при расчёте.
2. Схема расчёта. Фиксируем модель исполнения: задержку реакции, частичное исполнение заявки, комиссии и доступный объём на каждой стороне. Согласованная схема становится эталоном, через который потом объясняется любое расхождение.
3. Настройка окружения. Собираем стенд: хранилище исторических данных, сервис расчёта, изолированные задачи для длительных прогонов и раздельное логирование каждого шага.
4. Прогон эталонных сценариев. Проверяем расчёт на заранее размеченных периодах с известным результатом — так ошибки в логике всплывают до того, как на стенд поставят реальные стратегии.
5. Сверка с реальными сделками. Сопоставляем расчёт с фактическими исполнениями за прошлые периоды и разбираем каждое расхождение: часть окажется ошибкой модели, часть — честной особенностью рынка.
6. Приёмка и передача. Прогоняем полный цикл на данных заказчика, фиксируем контрольные показатели, передаём документацию по схеме расчёта и обучаем команду работать со стендом самостоятельно.

Комплект поставки: конфигурации, схемы и регламенты

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

• Конфигурации окружения — версионируемые файлы с параметрами подключений, лимитами запросов, таймаутами и переключателем тестового и рабочего контура.
• Схемы интеграций — путь рыночных данных от источника до хранилища, точки съёма стаканов и сделок, правила нормализации и уязвимые места, где возможны разрывы лент.
• Политики доступа — роли аналитика, оператора и развёртывания, вынос ключей за пределы репозитория, ротация и запрет правок в рабочем контуре.
• Регламенты эксплуатации — порядок подготовки исторических данных, запуска прогона, воспроизведения результата и учёта комиссий с проскальзыванием.
• Описание отчётов — состав метрик (доходность, просадка, оборот, доля исполненных сигналов), формат выгрузки и трактовка показателей.
• Реестр известных ограничений — где модель упрощает реальность: глубина истории, задержки, тонкая ликвидность, частичные исполнения.
• Инструкции по развёртыванию и откату — подъём контура с нуля и возврат на предыдущую конфигурацию.

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

Кейс: как сократили расхождение модели и реальных сделок

Где терялась точность

Стратегия строилась на ручном сборе котировок: данные с биржи и из пулов сводили в таблицах, комиссии и проскальзывание учитывали оценочно. Расхождение расчётной доходности с фактическими сделками доходило до 18–20%, а подготовка отчёта по одной гипотезе занимала два-три дня. Из-за этого проверяли одну-две идеи в месяц, и часть из них разваливалась уже на реальном счёте.

Что перестроили

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

Что получилось

Расхождение расчётного и фактического результата сократилось с 18–20% до 4–6%. Проверка гипотезы занимает 20–30 минут вместо двух-трёх дней, ручных операций в подготовке данных стало около пяти вместо сорока. Отчёт формируется автоматически из журнала прогона. Система устойчива к сбоям: при обрыве связи с биржей незавершённый шаг поднимается с последней контрольной точки, а не начинается заново.

Чем отличается проверка на истории от теста в реальном времени?

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

Переоценивает история почти всегда. Главная причина — переобучение модели: когда параметров входа и выхода много, а отрезок один, подгонка ловит шум конкретной недели вместо спреда, и на следующем участке результат обнуляется. Второй источник оптимизма — идеальные условия прогона: мгновенное исполнение по лучшей цене, полный объём и отсутствие других участников, закрывающих ту же возможность.

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

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

Технические сомнения: данные, задержки, воспроизводимость

Сомнения по бэктестингу арбитражных стратегий сводятся к одному: совпадёт ли расчёт с реальными торгами. Расчёт на истории не обещает прибыль — он показывает, при каких условиях стратегия работает и где ломается. Ниже — вопросы, которые задают чаще всего.

Как понять, что модель не переобучена?

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

Как учитываются задержки котировок?

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

Будет ли расчёт воспроизводим?

Да: фиксируем срез данных, состав инструментов и параметры расчёта, поэтому повторный прогон даёт тот же отчёт — версии стратегии можно сравнивать между собой.

Можно ли проверить стратегию до торгов и что после передачи?

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

Обсудим задачу: с чего начать проверку торговых гипотез

Чтобы бэктест отвечал на вопрос «сработает ли стратегия», а не подгонял кривую под историю, на входе нужны конкретные вводные. На обсуждении задачи уточняем: какие биржи и рынки в контуре, какие типы арбитража интересуют — межбиржевой, фандинговый, треугольный, — как учитывать комиссии, задержки исполнения и глубину стакана, какая история сделок и стаканов доступна за нужный период.

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

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

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