Модель расходится с бэктестом: где ломается MLOps в трейдинге
Бэктест почти всегда ровнее живой торговли — вопрос в том, насколько. Расхождение закладывается ещё на обучении: признаки считаются по данным, которые на тот момент ещё не были доступны, состав инструментов берётся по «выжившим», а издержки исполнения в расчёт не попадают. Модель показывает красивую кривую там, где у неё просто не было шанса ошибиться.
На живом рынке меняется сам режим, а не только данные. Проседает ликвидность внутри дня, растёт задержка между сигналом и исполнением, крупная заявка двигает цену против нас. Модель, обученная на трендовом участке, в боковике теряет точность, и причина не в рынке, а в том, что развёртывание не отслеживает смену режима.
Ручные пересчёты параметров добивают картину. Гиперпараметры подкручивают перед вечерней сессией, признаки пересобирают скриптом на локальной машине, веса обновляют копированием файла, а реестр версий моделей вроде MLflow так и не заводится. Через неделю уже никто не восстановит, какая версия модели и какой набор признаков дали сигнал в конкретной сделке — ни для разбора, ни для отката.
«Самое дорогое здесь — не убыток по одной сделке, а невозможность объяснить результат», — говорит наш инженер, выводивший такие системы в рабочую эксплуатацию. Чтобы расхождение с бэктестом стало управляемой величиной, а не сюрпризом, разбираем, где именно ломается MLOps в трейдинге и как это закрывается.
Что даёт управляемый жизненный цикл торговой модели
Контроль версий моделей перестаёт быть папкой с файлами по датам. Каждый артефакт связан с версией кода, составом обучающей выборки, набором гиперпараметров и окружением — по журналу видно, из чего собрана конкретная версия, и её можно поднять заново на другом узле. Это фундамент, на котором держатся остальные эффекты.
Воспроизводимость обучения уводит расхождения между прогонами из разряда загадок. Если модель на проверке показывает не те метрики, что при обучении, причина ищется в трёх известных местах: данные, окружение, порядок подачи примеров. Повторный запуск даёт тот же результат, и спорные эксперименты не приходится переделывать с нуля.
Время до выпуска модели сокращается за счёт предсказуемого пути: новая версия проходит те же ворота качества, что и предыдущая, а выкладка в торговый контур — отработанную процедуру, а не разовую ручную операцию. Рутинный выпуск перестаёт быть событием и занимает минуты вместо дней.
Снижение отказов торговли — следствие прямой проверки совместимости: расхождение набора признаков между обучением и работой на живых данных, дрейф входных распределений и несоответствие версий ловятся на входе, а не в момент выставления ордера. Разбор инцидента идёт по журналу решений — видно, какая версия сработала, на каких данных и почему фильтр пропустил или отклонил сигнал.
Собранный MLOps-контур делает жизненный цикл модели проверяемым: любую версию можно пересобрать, сравнить с соседней и откатить, не переписывая торговую логику.
Режимы работы MLOps-контура в трейдинге: сравнение вариантов
Режимы MLOps-контура различаются тем, где хранятся данные, где считается модель и кто отвечает за выпуск новой версии в работу. Полный цикл на стороне подрядчика запускается быстрее, развёртывание в контуре заказчика снимает вопросы по периметру данных, гибридный контур балансирует оба требования, а автоматический выпуск нужен там, где модель заметно смещается между пересчётами.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полный цикл на нашей стороне | Нет своей команды и мощностей, нужен быстрый выход на рабочие сигналы, данные допустимо передавать | Передача данных по внешнему каналу, чувствительные данные выносить нельзя, время реакции на сбой делится между сторонами |
| Развёртывание в вашем контуре | Данные не покидают периметр, есть требования безопасности, важна низкая задержка сигнала | Нужны свои вычислительные ресурсы и дежурная смена, обновления идут через согласование, часть эксплуатации остаётся на вашей команде |
| Гибридный контур | Обучение и эксперименты удобнее вести у нас, расчёт сигналов — у вас, признаки можно обезличить | Требуется синхронизация версий признаков и моделей, воспроизводимость результата подтверждать сложнее |
| Автоматический выпуск с контролем дрейфа | Модели переобучаются регулярно, данные идут потоком, нужен предсказуемый цикл обновления | Нужны метрики качества на рабочих данных и автооткат, пороги дрейфа калибруются под конкретный рынок |
Выбор редко бывает бинарным. Пакетный пересчёт закрывает ежедневное обучение и пересборку признаков, а потоковый пересчёт включают точечно — там, где задержка сигнала действительно влияет на результат. На практике рабочая конфигурация для большинства задач — гибридный контур с автоматическим выпуском и контролем дрейфа.
Этапы внедрения контура: аудит данных, схема, настройка, передача
Прежде чем разворачивать контур, мы восстанавливаем фактическую картину: откуда приходят котировки, как считаются признаки, где теряется история исполнения заявок. Без этого мониторинг превращается в наблюдение за случайными метриками, а расхождение между проверкой на истории и живым потоком всплывает уже на реальных позициях.
- Аудит данных и торговых журналов — сверяем источники котировок, глубину истории и полноту записей об исполнении, ищем разрывы и расхождения между логами площадки и внутренним учётом.
- Схема контура — фиксируем, где живут данные, признаки, модели и сигналы, как разделены обучение и исполнение, какие отказы считаются допустимыми.
- Версионирование моделей и признаков — каждая торговая модель привязана к набору данных и параметрам, откат к предыдущей версии проходит без пересборки всего контура.
- Настройка мониторинга — качество сигналов, задержка расчёта, доля отклонённых заявок и дрейф распределения признаков; оповещения привязаны к порогам, а не к факту падения процесса.
- Проверка на истории — прогон на накопленных данных: сверяем поведение модели с эталоном, смотрим устойчивость к смене режима рынка и к пропускам в потоке.
- Проверка на живом потоке — теневой режим: модель считает сигналы, но заявки не отправляет; сравниваем с рабочей логикой и смотрим, как ведёт себя мониторинг под нагрузкой.
- Передача контура — документация по схеме, регламенты переобучения и отката, разбор инцидентов с вашей командой и порядок дальнейшего сопровождения.
Артефакты передачи: конфигурации, регламенты, схемы доступа
Проект считается сданным не тогда, когда модель показала метрику на исторических данных, а когда контур живёт без авторов. Поэтому в конце работы мы передаём пакет артефактов, по которому другая команда сможет эксплуатировать и развивать систему. Что остаётся у заказчика на руках:
- Реестр моделей и версий — обучающий период, набор признаков, метрики на отложенной выборке и статус каждой версии: в контуре, в резерве или снята.
- Конфигурации контура — параметры расчёта признаков, расписания переобучения, пороги защит и лимиты; разворачиваются из репозитория без ручных правок.
- Политики доступа — роли по средам: кто выпускает модель, кто меняет лимиты, кто только читает журналы.
- Регламент выпуска и отката — обязательные проверки перед публикацией, критерии остановки и порядок возврата к предыдущей версии за считанные минуты.
- Журналы аудита — кто, когда и на каком основании менял модель, данные или ограничения; выгрузка для внутреннего контроля.
- Документация контура — схема потоков данных, внешние зависимости, точки отказа и ответственные за каждый узел.
- Инструкции для дежурной смены — что делать при расхождении метрик с ожидаемыми, как остановить торговлю и кого оповестить.
Пакет синхронизирован с рабочим контуром: изменение в репозитории отражается в документации, поэтому через полгода знания не приходится собирать по переписке.
Кейс: расхождение модели и фактического исполнения сделок
До внедрения сигналы считала одна версия модели, а заявки уходили по артефакту, выгруженному до последнего переобучения. Версии расходились на несколько суток, и это всплывало уже в открытой позиции: сигнал на выход есть, сделка не закрыта. Сверку журнала сигналов с журналом исполнения делали вручную — разбор одного торгового дня занимал 3-4 часа и почти не покрывал ночные сессии.
Что изменили в контуре MLOps
Модельный контур собрали вокруг реестра версий MLflow: каждая сборка получает неизменяемый номер, и тот же номер уходит в сигнал и в заявку — расхождение ловится на входе, а не в позиции. Контроль перевели на воспроизведение сессии: исторический срез данных и фактические сделки сравниваются автоматически, различия помечаются с указанием версии модели и набора параметров. Откат — переключение указателя в реестре, без пересборки и ручной правки конфигураций на сервере исполнения.
Метрики до и после
- Доля сигналов без парной сделки: 4-6% → 0.2%
- Разбор торгового дня: 3-4 часа вручную → 10-15 минут по готовому отчёту
- Возврат к предыдущей версии модели: около суток → минуты
- Покрытие сверкой: только дневная сессия → все сессии, включая ночные
Разбор инцидента перестал зависеть от того, кто вёл смену. Расхождение воспроизводится на тех же данных и той же версией модели — вместо поиска виноватого звена команда получает конкретный шаг, на котором разошлись сигнал и исполнение сделки.
Чем отличается теневой выпуск модели от канареечного?
Разница в том, куда попадает ответ модели. При теневом выпуске копия боевого трафика уходит на новую версию, но её сигналы никуда не отправляются: расчёт идёт параллельно, а мы сверяем предсказания двух версий на одном и том же потоке данных. При канареечном выпуске часть живого трафика — сначала 1%, затем 5, 25 и 100 — обслуживает новая версия, и её решения уже влияют на портфель.
Теневой режим поднимаем зеркалированием трафика, например через Istio, и он отвечает на вопрос «модель считает так же корректно?»: сходятся ли распределения сигналов, как изменилась латентность инференса, сколько отказов на редких инструментах. Ограничение честное — теневой прогон не проверяет связку с исполнением: ордера, лимиты риска, обработку частичного исполнения и повторных заявок.
Канареечный выпуск проверяет именно это, поэтому он идёт вторым. Постепенное включение версии привязываем к метрикам: просадка относительно эталонной версии, доля отклонённых ордеров, расхождение предсказаний с фактическим исходом. Автоматический откат срабатывает по порогу, а не по звонку дежурного — иначе версия остаётся в бою, пока кто-то смотрит графики.
Типовые ошибки при сравнении режимов выпуска: включать канарейку сразу, минуя теневой этап; сверять версии на разных окнах рынка — при спокойном и волатильном режиме это разные распределения; не фиксировать эталонную версию, из-за чего непонятно, что именно ухудшилось. Отдельная ловушка — общий для двух версий набор признаков: пересчитали его под новую модель, и откат уже не возвращает прошлое поведение.
На практике порядок такой: теневой прогон на нескольких торговых сессиях, затем канарейка с шагом по доле трафика и автоматическим возвратом. Обе ступени работают на одном конвейере подготовки данных — иначе расхождение версий не отделить от расхождения самих данных.
Технические сомнения: дрейф данных, задержки, доступы, откат
Перед стартом команды проверяют четыре вещи: что будет с моделью при смене режима рынка, сколько идёт путь от сигнала до заявки, как откатить версию, кто может вмешаться в систему.
Как вы отслеживаете дрейф данных?
Сравниваем распределение входных признаков и качество прогнозов на скользящем окне с эталонным профилем обучающей выборки. Расхождение выше порога запускает переобучение и оповещение, а не тихую деградацию. Профиль, окно и порог лежат в конфигурации — правило воспроизводимо.
Как держите задержку применения модели?
Базовые расчёты признаков идут заранее, в момент решения остаётся только лёгкий расчёт прогноза. Задержку измеряем по перцентилям, а не по среднему, и держим бюджет на всей цепочке «данные — сигнал — заявка»: отставший источник котировок помечает сигнал неактуальным, и в рынок он не уходит.
Как откатить версию модели?
Модель, схемы признаков и конфигурация версионируются одним набором. Откат — возврат к предыдущему набору артефактов одной командой, без пересборки; теневой прогон на истории подтверждает корректность. Глубина хранения рассчитана на откат на несколько шагов назад.
Как устроены доступы и аудит?
Права разделены по ролям: разработчик не выводит модель в бой в одиночку, запуск требует подтверждения. Обучение, выкатка и ручные правки параметров попадают в неизменяемый журнал с автором и временем.
Обсудим контур под ваш торговый процесс и команду
Оценка проекта в MLOps для торгового контура зависит не от числа моделей, а от того, как сигнал проходит путь от расчёта до заявки и где на этом пути остались ручные шаги. Поэтому обсуждение задачи начинаем с разбора текущего исполнения, а не с презентации. Чтобы вернуться с внятной оценкой, полезно иметь под рукой:
- перечень стратегий: какие модели работают, на каких данных обучаются и как часто переобучаются;
- текущий путь сигнала от расчёта до выставления заявки — с узкими местами и ручными действиями;
- источники данных: котировки, новостные и альтернативные потоки, их объём и частоту обновления;
- требования к задержке и допустимому простою в часы торгов;
- регламент риска: лимиты, автостопы, кто имеет право остановить контур;
- инфраструктуру: свои мощности или облако, изоляция сред, порядок выдачи доступов и кто принимает результат.
В ответ присылаем карту контура: сбор и подготовка данных, обучение и проверка модели, выкладка в торговый контур, наблюдение и откат на предыдущую версию. К ней — план внедрения по этапам: что делаем первым, какие артефакты передаём в каждой точке приёмки, какие зависимости остаются на стороне заказчика. План приходит документом с этапами, сроками, зонами ответственности и перечнем рисков.
Первый шаг — техническая сессия на 45–60 минут с инженером, который будет вести проект: разбираем поток данных и регламент риска, договариваемся о критериях готовности. Опишите задачу в свободной форме — вернёмся с оценкой и планом работ.
