Разработка ML-модели прогнозирования ликвидности крипторынка

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

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

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

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

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

Что меняется после внедрения модели: измеримые эффекты

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

• Точность прогноза на горизонте сделки. Модель на PyTorch опирается на глубину стакана, поток сделок и перекос между сторонами; доля верных сигналов на нужном горизонте уходит с уровня случайного угадывания к 60–70% на отложенной выборке.
• Снижение проскальзывания и стоимость исполнения. Объём заявки считается от прогноза доступной ликвидности, поэтому вход реже «съедает» стакан: отклонение цены исполнения от расчётной падает в разы, а комиссии и потери на спреде перестают быть основной издержкой стратегии.
• Сокращение простоев в работе с заявками. Сервис прогноза держит отклик в заданном бюджете, очередь заявок не копится, при деградации подхватывает резервная версия — торговый контур не встаёт на время переобучения.
• Устойчивость в шоковые периоды. На резких движениях метрика проседает контролируемо: контроль дрейфа переводит модель в осторожный режим с уменьшенным размером позиции вместо лавинообразного роста ошибок.

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

Прогнозирование ликвидности: подходы и их ограничения

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

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

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

Этапы внедрения: от аудита данных до рабочей модели

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

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

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

Данные, признаки и регламенты эксплуатации модели

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

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

Кейс: как модель удержала исполнение сделок в шоковые дни

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

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

Метрики до и после на сопоставимых периодах:

• доля сделок по худшей цене в доступной глубине: 18% → 6%;
• доля сорванных заявок в шоковые часы: 12% → 3%;
• проскальзывание относительно середины спреда сократилось вдвое.

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

Что делать, если исторических данных мало или они неполные?

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

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

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

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

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

Сомнения по данным, горизонту и устойчивости модели

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

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

Как часто переобучаете и что с защитой данных?

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

Как прогноз встраивается в торговую систему?

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

Обсудим задачу: что нужно для старта работ

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

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

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