Почему бэктестинг AI-стратегий ломается на реальных данных
Бэктестинг AI-стратегии на истории почти всегда показывает доходность лучше, чем последующая торговля. Разрыв возникает не из-за модели: прогон и живой рынок по-разному исполняют одну и ту же заявку. В истории заявка закрывается по цене бара, на рынке — по той, что осталась в стакане после всех, кто пришёл раньше.
Неучтённые издержки исполнения добивают результат тихо. Комиссия, спред, проскальзывание на объёме и задержка между сигналом и отправкой заявки накапливаются на каждой сделке, и стратегия, которая в прогоне рисует ровную кривую, в реальных торгах уходит в минус. Отдельная строка издержек в отчёте важнее итоговой доходности: она показывает, где система теряет деньги, а не где их обещает.
Третья причина — отсутствие повторяемости эксперимента. Если не зафиксированы срез данных, состав инструментов, версия признаков и случайные состояния, два прогона одной стратегии дают разные кривые, и сравнение гипотез теряет смысл. Повторяемость здесь не про удобство, а про то, можно ли вообще доверять выводу.
Обычно всё это упирается в узкое место расчётного контура: перебор параметров идёт часами, проверка на устойчивость к сдвигу окна не влезает в цикл исследования, а расхождение прогона и реальных торгов обнаруживается уже после запуска. Разбираем, как это закрывается на уровне архитектуры платформы.
Что даёт платформа: измеримый эффект на каждом этапе
Эффект платформы измеряется, а не описывается словами: каждый прогон оставляет метрики, по которым видно, что изменилось. Ниже — четыре участка, где разница заметна сразу после первого месяца работы.
Время одного прогона
Кэш промежуточных расчётов и параллельный обсчёт инструментов сжимают полный прогон портфеля с часов до десятков минут. Это меняет режим работы: стратегию успеваешь прогнать на нескольких состояниях рынка в тот же день, а не «к следующей неделе».
Воспроизводимость результатов
Прогон фиксирует версию кода, срез данных, параметры, зерно генератора и окружение — повторный запуск даёт те же метрики. Журнал экспериментов ведём в MLflow, поэтому видно, какая гипотеза что дала и к какому состоянию кода её откатить.
Скорость проверки гипотез
Единый формат данных, готовые шаблоны стратегий и автоотчёт сокращают путь от идеи до цифры до нескольких часов. За день проверяется 10–15 конфигураций вместо одной-двух: слабые гипотезы отбрасываются до того, как в них вложена разработка.
Устранённые отказы и переобучение
Уход от ручных выгрузок убирает рассинхрон данных и метрик, потерю артефактов и падения на длинной истории: прогон либо завершается целиком, либо падает с диагностикой. Проверка на отложенной выборке и по шагам во времени отсекает стратегии, которые хороши на истории и рассыпаются на живых данных — рядом с доходностью выводятся метрики устойчивости.
Сравнение режимов бэктестинга AI-стратегий: таблица выбора
Выбор режима прогона определяет не только скорость, но и то, какие классы ошибок вы вообще увидите. Пакетный расчёт считает всю историю одним проходом по матрице доходностей — он годится для грубого перебора гипотез, но не воспроизводит порядок исполнения заявок. Расчёт по событиям прогоняет ленту бар за баром и повторяет реальный цикл: заявка, сделка, комиссия, проскальзывание.
Потоковый режим держит стратегию в том же виде, в котором она уйдёт в торговлю, поэтому только он честно показывает лаг отклика модели на новые данные. Режим бэктестинга выбирают под задачу, а не по умолчанию — таблица ниже.
| Режим прогона | Когда подходит | Ограничения режима |
|---|---|---|
| Пакетный расчёт | Первичный отсев сотен гипотез и поиск закономерностей в признаках на длинной истории | Не учитывает очередь заявок и частичные исполнения — результат выходит оптимистичнее реального |
| Расчёт по событиям | Финальная проверка перед выводом: комиссии, проскальзывание, лимиты, запрет коротких позиций | Полный перебор параметров на большой истории идёт часами, стоимость прогона растёт с числом событий |
| Потоковый режим | Проверка реакции в реальном времени: лаг отклика модели, дрейф признаков, обрыв канала данных | Сложнее воспроизвести: нужен детерминированный журнал входящего потока и повтор одного и того же окна |
| Гибридный прогон | Нужен и широкий поиск, и честная оценка: отсев пакетно, финал — по событиям | Требует согласованных определений признаков в двух контурах, иначе результаты не сходятся |
Как мы строим платформу: этапы инженерной работы
Работу начинаем не с кода, а с аудита данных: откуда приходит история котировок, как обрабатываются пропуски, сплиты и дивиденды, совпадают ли временные интервалы источников. Пока это не проверено, стратегия красиво выглядит на истории и расходится с реальными сделками — поэтому схему расчёта для бэктестинга и метрики фиксируем письменно заранее.
- Аудит данных. Сверяем источники, проверяем полноту истории, находим дыры и дубли, приводим торговые календари и часовые пояса к одному виду. Итог — отчёт о пригодности данных и список ограничений.
- Схема расчёта. Фиксируем метрики, правила входа и выхода, учёт комиссий, задержек исполнения и проскальзывания — чтобы расчёт не расходился с реальной торговлей.
- Прототип на узком срезе. Собираем расчётный контур на одном инструменте и коротком периоде: гипотеза проверяется быстро, а ошибки в логике видны до масштабирования.
- Настройка окружения. Разворачиваем изолированные среды, настраиваем воспроизводимость прогонов и хранение результатов вместе с параметрами запуска — любой расчёт можно повторить и сравнить.
- Проверка на контрольных наборах. Данные для проверки отделяем заранее, смотрим устойчивость на разных периодах и рыночных режимах, отсекаем варианты, которые держатся только на переобучении под историю.
- Промышленный контур. Ставим прогоны по расписанию, добавляем отчёты и оповещения о расхождениях между ожидаемой и фактической динамикой — платформа работает без ручных запусков.
- Передача и обучение команды. Отдаём документацию, доступы, разбор архитектуры и проводим совместные прогоны на ваших задачах, чтобы ваши специалисты могли менять стратегии и данные самостоятельно.
Что передаём на руки: конфигурации, схемы, регламенты
Проект по бэктестингу AI-стратегий считаем сданным не тогда, когда модель отработала на демонстрационном наборе, а когда ваша команда воспроизводит любой прогон без нас. Поэтому передаём не презентацию с графиками, а рабочий контур: конфигурации, схемы расчёта, политики доступа и регламенты, по которым платформа живёт дальше.
- Конфигурации платформы — версионируемый набор параметров: источники котировок, окна ребалансировки, комиссии и проскальзывание, ограничения на размер позиций.
- Схемы расчёта — конвейер от загрузки данных до метрик: где считаются доходность, просадка и оборачиваемость, как исключается подглядывание в будущее.
- Спецификация признаков — какие ряды и производные показатели подаются в модель, как фиксируются версии весов при переобучении.
- Политики доступа — роли участников, права на данные, запуск прогонов и правку конфигураций, журнал действий.
- Документация — архитектура, локальный запуск, разбор типовых сбоев с признаками и порядком действий.
- Регламенты сопровождения — периодичность переобучения, контроль расхождения тестового и рабочего результата, откат на предыдущую версию стратегии.
- Приёмочные прогоны — эталонные сценарии с зафиксированными результатами: после ваших правок видно, что расчёт не разошёлся.
Разбираем контур вместе с вашей командой: инженер проходит по каждому артефакту и отвечает на вопросы по расчётам и доступам. Опишите задачу — вернёмся с оценкой и планом.
Кейс: от разрозненных скриптов к единому расчётному контуру
До: разрозненные скрипты
До переезда расчёт жил в десятках отдельных ноутбуков Jupyter и локальных скриптов: у каждой стратегии свой набор исторических данных и свои промежуточные выгрузки. Прогон одного набора параметров занимал около шести часов и не влезал в рабочее окно, поэтому проверку запускали ночью, а правки вносили уже после. Результат зависел от окружения: две копии одного скрипта на разных машинах давали разную доходность, и до трети чисел приходилось перепроверять вручную.
После: единый расчётный контур
Собрали единый расчётный контур бэктестинга: один источник исторических данных с версионированием срезов, неизменяемые окружения под каждый запуск и журнал параметров, который однозначно восстанавливает любой прогон. Тяжёлые расчёты разбили на независимые задачи и распараллелили, а результаты складываются в общее хранилище вместе со срезом данных и версией кода.
Время прогона сократилось с шести часов до сорока минут — гипотезу проверяют несколько раз в день, а не раз в сутки. Доля воспроизводимых результатов выросла с 70 до 99%: тот же набор параметров на том же срезе даёт тот же итог, а расхождения объясняются новыми рыночными данными, а не окружением. Число спорных результатов, которые разбирали вручную, упало почти в пять раз — сравнение стратегий идёт по общим метрикам, а не по переписке.
Что делать, если часть расчётов уже автоматизирована
Автоматизированный расчётный контур — не помеха, а точка опоры: обычно в нём уже есть выверенные правила подготовки данных, массивы исторических котировок и логика исполнения заявок. Мы начинаем с инвентаризации — фиксируем источники данных, форматы хранения, расписание прогонов и то, какие метрики команда считает эталонными. После этого по каждому блоку решаем отдельно: переносим как есть, оборачиваем в тонкий слой совместимости или оставляем на месте и только подключаемся к нему.
Наработки при этом сохраняются: индикаторы, правила фильтрации, обработка пропусков и корпоративных событий переезжают в новый контур без переписывания логики. Мы приводим их к единому интерфейсу, чтобы движок бэктестинга AI вызывал их так же, как собственные модули, — иначе сравнение старых и новых результатов теряет смысл.
Бесшовное встраивание проверяется параллельным прогоном: прежний и новый контуры считают один и тот же исторический отрезок, а мы сверяем кривую доходности, максимальную просадку, число сделок и распределение результатов по периодам. Расхождение выше оговорённого порога останавливает переключение — сначала находим причину. На практике это чаще всего разное заполнение пропусков, момент учёта комиссии или разъезд в правилах переноса позиции через ночь.
Перевод идёт по стратегиям, а не целиком: до последнего шага остаётся возможность вернуться к прежнему расчёту и сравнить обе картины рядом. Воспроизводимость держим на версионировании исторических данных и журнале всех параметров прогона — через месяц любой прошлый результат поднимается и объясняется без археологии по скриптам.
Технические сомнения инженеров перед стартом
Перед первым запуском инженер задаёт одни и те же вопросы: хватит ли истории, где гарантия, что расчёт верен и не получится ли красивая кривая на прошлых данных, которая рассыплется на живом рынке. Эти сомнения снимаем до разработки — здесь ошибка в расчёте стоит не бага, а неверного решения о запуске стратегии.
Ниже — короткие ответы на технические возражения, которые чаще всего всплывают на этапе оценки.
Историю придётся чистить вручную?
Загрузчик приводит ряд к единому часовому поясу, пересчитывает корпоративные действия и помечает пропуски, а не заполняет их молча. Отдельно подтягиваем делистингованные инструменты, иначе расчёт смещён в сторону выживших.
Как понять, что стратегия не подогнана под прошлое?
Обучающее и проверочное окна разделены, скользящая проверка идёт по последовательным периодам, результат считается только на невиданных данных. Комиссии и проскальзывание заложены в расчёт, а не в отчёт.
Как подключаются биржевые и брокерские источники?
Работаем и с потоковыми подключениями, и с выгрузками в файлах: схема полей, часовой пояс и точность метки времени описаны для каждого источника. Дубликаты отсекаются по ключу инструмент-время, разрывы дозагружаются, расхождения между источниками уходят в журнал.
Как вы убеждаетесь, что расчёт корректен?
Есть эталонные сценарии с заранее известным ответом — последовательность сделок, комиссии, дивиденды. Тот же прогон повторяем независимой реализацией и сверяем журнал сделок, а на коротком окне с живым рынком — расчётные сделки с фактическими.
Обсудим задачу и вернёмся с оценкой и планом
Для старта обсуждения задачи достаточно описать её в терминах стратегий, данных и результата — тогда оценка опирается на инженерную реальность, а не на общие соображения. Специально готовить пакет документов не нужно: подойдут выгрузки, заметки аналитика или краткое описание идеи.
- Стратегии. Логика входа и выхода, набор инструментов, горизонт удержания позиции, правила управления риском, частота сигналов.
- Исходные данные для оценки. Какие исторические ряды уже есть, за какой период и с какой детализацией, в каком формате и где лежат; если данных нет — из каких источников их брать и есть ли к ним доступ.
- Требования к отчётности. Ключевые метрики — доходность, максимальная просадка, доля прибыльных сделок; нужны ли разрезы по периодам и инструментам и в каком виде отчёт удобен вам.
- Критерии качества. Как отличаем рабочую стратегию от подгонки под историю: проверка на отложенном периоде, скользящее окно, сравнение с базовым сценарием.
- Ограничения. Сроки, доступы к данным и инфраструктуре, размещение — облако или закрытый контур, число одновременных прогонов.
- Пользователи и сценарии. Кто работает с платформой — аналитик, трейдер, риск-менеджер: от этого зависят интерфейс и разграничение прав.
Порядок дальнейших шагов одинаков: разбираем вводные, уточняем неясное и возвращаемся с планом работ — этапы, состав, что понадобится от вас на каждом. Если часть данных пока закрыта, оценим по тому, что есть, и отдельно отметим, что повлияет на сроки.
