Разработка системы A/B тестирования торговых моделей

A/B тестирование торговых моделей: где ломается сравнение

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

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

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

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

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

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

Контур сравнения строится вокруг контрольной группы: поток сигналов разделяется детерминированно — по ключу из идентификатора инструмента и времени входа, — поэтому модель-кандидат и эталонная модель получают одинаковые рыночные условия. Разделение потока фиксирует долю отсечённых сигналов, и расхождение в результате объясняется логикой модели, а не разной выборкой сделок. Без этого A/B-сравнение торговых моделей вырождается в спор о том, чей период был удачнее.

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

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

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

Форматы сравнения: живой запуск, реплей, теневой режим

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

Условия применимости диктуют объём и качество архивных данных, ликвидность инструмента и то, насколько обратимо решение.

Где какой формат уместен

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

Этапы внедрения контура сравнения моделей

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

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

Такой порядок даёт главное: результат сравнения можно перепроверить в любой момент и повторить без нас.

Что остаётся у команды: конфигурации, схемы, регламенты

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

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

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

Кейс: сократили цикл выбора модели в три раза

Заказчик — команда количественных стратегий, которая выбирала торговые модели почти вручную. Очередь гипотез росла, а цикл проверки одной занимал 3–4 недели: половина времени уходила на пересборку окружения и разбор расхождений, когда два аналитика на одном наборе данных получали разные числа. В реальную торговлю уходило 4 модели из 10, и каждая вторая из них откатывалась — решение принимали по среднему результату, без оценки разброса.

Что изменили

Собрали единый контур A/B тестирования: манифест запуска фиксирует версию набора данных, хеш кода, параметры стратегии и размер групп, поэтому любой прогон повторяем. Историческая проверка и тест на живом рынке идут одним маршрутом через Airflow, группы сравнивает один модуль статистики — с доверительными интервалами, а не средними. Все запуски пишутся в журнал: видно, кто, что и на каких данных проверял.

Что стало

Цикл проверки гипотезы сократился с 3–4 недель до 5–7 дней, и узкое место сместилось с подготовки окружения на формулировку самой гипотезы. Доля откатов после выхода в торговлю упала с 40% до 12%: модели с широким разбросом отсеиваются до запуска, а не после потерь. Повторный прогон на том же манифесте даёт идентичный результат в 100% случаев, тогда как раньше расхождения встречались почти в каждом третьем прогоне. Выбор модели перестал зависеть от того, кто именно считал.

Что делать, если несколько моделей уже работают на одном счёте?

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

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

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

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

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

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

Как проверяете достоверность разницы?

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

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

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

Как качество данных влияет на результат?

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

Какие искажения ищете отдельно?

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

Обсудим задачу: что прислать для оценки

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

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

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