AI-модель трейдинга: анализ стакана заявок с DeepLOB для прогноза цены

Реальная задача: предсказание движения цены по стакану

Трейдер смотрит на стакан заявок (DOM) и видит дисбаланс: на уровне Best Bid 2000 лотов, на Best Ask 1500. Order Book — полный срез лимитных ордеров с ценами и объёмами. В реальном времени он даёт сигнал за миллисекунды до исполнения сделки. Извлечение устойчивого торгового сигнала из шума — ключевая задача. Мы сталкиваемся с задачей: трейдеру нужно предсказать краткосрочное движение цены на основе L2-данных. Покажем на примере проекта для Binance: превращаем поток ордеров в предсказания с горизонтом 1-10 секунд. Используем комбинацию линейных моделей и свёрточных нейросетей для максимальной точности при минимальной задержке.

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

Микроструктура рынка закодирована в распределении ликвидности. Order Book отражает ожидания участников — дисбаланс между объёмами на лучших уровнях предшествует движению цены. Order Book Imbalance (OBI) — простейший, но мощный предиктор. Для горизонтов 1–10 секунд OBI даёт AUC 0.58 при задержке 0.1 мс. Этого достаточно для арбитражных стратегий. Для трендовой торговли нужна более сложная модель, учитывающая динамику стакана.

Структура данных Order Book

L2 Order Book snapshot:

Price    | Bid Volume | Ask Volume
---------|-----------|----------
100.05   |     0     |   5000
100.04   |     0     |   3000
100.03   |     0     |   1500  ← Best Ask
100.02   |   2000     |     0   ← Best Bid
100.01   |   3500     |     0
100.00   |   8000     |     0
99.99    |   2500     |     0

L3 Order Book содержит индивидуальные ордера с ID — нужен для microstructure анализа, доступен на некоторых биржах (Binance, CME через API). Подробнее о структуре можно прочитать в документации.

Feature Engineering из Order Book

Базовые метрики: bid-ask spread, mid price, imbalance, weighted mid price.

Order Book Imbalance (OBI):

def order_book_imbalance(book, levels=5):
    bids = [vol for price, vol in book['bids'][:levels]]
    asks = [vol for price, vol in book['asks'][:levels]]
    return (sum(bids) - sum(asks)) / (sum(bids) + sum(asks))

OBI > 0 → давление покупателей → ожидаемое движение вверх. Это один из сильнейших краткосрочных предикторов (горизонт 1-10 секунд).

Iceberg detection: скрытые ордера — серии маленьких ордеров при одной цене. Признаки: быстрое пополнение уровня после исполнения, постоянный объём на уровне.

Market depth curves:

def depth_imbalance_at_level(book, price_distance):
    bid_vol = sum([vol for p, vol in book['bids'] if (mid - p) <= price_distance])
    ask_vol = sum([vol for p, vol in book['asks'] if (p - mid) <= price_distance])
    return (bid_vol - ask_vol) / (bid_vol + ask_vol)

Features: imbalance at 0.1%, 0.3%, 0.5%, 1.0% from mid. Дополнительно добавляем скорость изменения дисбаланса и наклон кривой глубин.

Как выбрать между OBI и DeepLOB?

Сравнение моделей:

OBI — линейный предиктор с задержкой инференса 0.1 мс. Для высокочастотных стратегий это критично. LightGBM требует 0.5 мс, DeepLOB — 2 мс. Но DeepLOB даёт прирост AUC на 5% относительно градиентного бустинга, что оправдано для стратегий с большим капиталом. Мы выбираем подход под задачу: для арбитража хватит OBI, для трендовой торговли — DeepLOB.

Как DeepLOB обрабатывает L2-данные?

Свёрточная нейросеть принимает временные срезы стакана как 2D-изображение (цена × уровень × объём). Обучается на миллионах примеров. В production используем ONNX Runtime для инференса — latency p99 менее 5 мс на GPU T4.

Что такое айсберг-ордера и как их обнаруживать?

Айсберг-ордера маскируют истинный объём. Мы используем статистику повторного появления ордеров на одном уровне: если объём восстанавливается более 3 раз за 1 секунду — скорее всего айсберг. Этот признак повышает точность прогноза на 2-3%.

Как мы строим production-решение?

Опыт нашей команды — более 7 лет в algorithmic trading. Мы используем стек: PyTorch, ONNX Runtime для инференса, Kafka для потоков данных.

Процесс работы

1. Аналитика и сбор данных: получаем исторические L2-данные через Binance WebSocket или CME FIX.
2. Feature engineering: расчёт OBI, depth curves, imbalance на нескольких горизонтах.
3. Проектирование модели: пробуем DeepLOB, LightGBM на ручных фичах, гибридные подходы.
4. Реализация и обучение: на GPU кластере с распределённым обучением.
5. Бэктестинг: на исторических данных с учётом комиссий и проскальзывания.
6. Деплой: контейнеризация, ONNX Runtime на инференс-сервере, интеграция с OMS.

Что входит в работу

• Документация модели (model card) с метриками и ограничениями.
• API для получения сигналов (gRPC или REST).
• Обучение команды заказчика интерпретации выходов.
• Поддержка в течение 3 месяцев после деплоя.
• Исходный код и конфигурации пайплайна.

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

Распространённые ошибки при построении моделей стакана

• Игнорирование микроструктуры: использование только mid price без depth.
• Неправильный выбор окна прогноза: для HFT важны миллисекунды, для трендов — секунды.
• Отсутствие детекции айсбергов: скрытые ордера искажают дисбаланс.

Сколько времени занимает разработка?

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

Какие проблемы прогнозирования временных рядов встречаются чаще всего?

Финансовый директор запрашивает прогнозирование временных рядов продаж на квартал. Аналитик строит SARIMA, добивается MAPE 8.3% на тестовой выборке — и с гордостью деплоит. Через два месяца в production метрика падает до 23%. Причина классическая: модель обучалась на данных до COVID, тестировалась на стабильном периоде, а production попал на промо-акцию и сбой поставок. Data leakage + distribution shift = красивые цифры в ноутбуке и неработающий прогноз в реальности. Мы сталкивались с этим десятки раз. Наш опыт — 5+ лет в прогнозировании временных рядов для ритейла, финтеха и IoT, более 50 завершённых проектов.

Неправильная кросс-валидация. Стандартный train_test_split для временных рядов — ошибка. Случайное разбиение создаёт data leakage: модель видит «будущие» значения в обучении. Правильно — TimeSeriesSplit или walk-forward validation с expanding window.

Множественная сезонность. Почасовые данные потребления электроэнергии имеют три сезонности: суточную (24 ч), недельную (168 ч), годовую (8760 ч). SARIMA справляется только с одной. Prophet обрабатывает несколько, но медленно масштабируется на тысячи рядов.

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

Cold start при иерархическом прогнозировании. Новый SKU в ассортименте из 50 000 позиций: исторических данных нет, нужен прогноз. Стандартные подходы тут не работают — нужны cross-learning подходы или feature-based методы.

Какие инструменты и когда применять?

Prophet (Meta) — отличный старт для бизнес-данных с понятной сезонностью и праздниками. Быстро настраивается, интерпретируем, встроенная обработка выбросов и пропусков. Падает в точности при нерегулярных паттернах и не масштабируется на десятки тысяч рядов без параллелизации. Prophet (Facebook) — официальная документация.

Gradient boosting на фичах (LightGBM, XGBoost) — часто недооценённый подход. Создаёте фичи вручную: лаги (t-1, t-7, t-28), скользящие средние, категориальные признаки (день недели, месяц), экзогенные переменные. Модель обучается на всех рядах одновременно — решает cold start через похожие ряды. MAPE на ритейл-прогнозировании часто лучше нейронных сетей при правильной feature engineering.

TFT (Temporal Fusion Transformer) — трансформер, специально разработанный для интерпретируемого прогнозирования с ковариатами. Встроенные механизмы: variable selection (какие признаки важны), temporal self-attention (какие временные точки влияют на прогноз), квантильные предсказания. Доступен в pytorch-forecasting. Требует ~10 000+ записей на ряд для стабильного обучения. Temporal Fusion Transformer — академическая публикация.

PatchTST — трансформер, который делит временной ряд на патчи (аналогично ViT для изображений). Лучше захватывает локальные паттерны, чем классические трансформеры. Хорошо работает для long-horizon forecasting (прогноз на 96–720 шагов). Реализация в neuralforecast от Nixtla.

N-HiTS, N-BEATS — нейронные архитектуры без attention, быстрее TFT, конкурентная точность. N-BEATS выигрывает на M4/M5 benchmark для задач без ковариат.

Как мы разворачиваем TFT в production?

TFT требует тщательной подготовки данных. Типичный пайплайн через pytorch-forecasting:

training = TimeSeriesDataSet(
    data,
    time_idx="time_idx",
    target="sales",
    group_ids=["store", "sku"],
    min_encoder_length=max_encoder_length // 2,
    max_encoder_length=max_encoder_length,  # 120 дней
    min_prediction_length=1,
    max_prediction_length=max_prediction_length,  # 28 дней
    static_categoricals=["store_type", "category"],
    time_varying_known_reals=["price", "promo_flag"],
    time_varying_unknown_reals=["sales"],
    target_normalizer=GroupNormalizer(groups=["store", "sku"], transformation="softplus"),
)

Частая ошибка: target_normalizer по умолчанию (StandardScaler) ломает предсказания для рядов с нулевыми значениями (нет продаж в выходные). GroupNormalizer с transformation="softplus" — правильный выбор для count-данных.

Пошаговая инструкция по настройке TFT

1. Сбор и подготовка данных. Обработать пропуски (маркировать NaN, интерполировать только если это технический сбой), агрегировать до нужной частоты, сформировать ковариаты (праздники, промо, цены).
2. Создание TimeSeriesDataSet. Указать group_ids (например, магазин+SKU), временной индекс, горизонт прогноза. Настроить target_normalizer с учётом распределения таргета.
3. Обучение baseline. Сначала Prophet или LightGBM — чтобы понять, насколько сложнее задача.
4. Тренировка TFT. Запустить TemporalFusionTransformer с loss=QuantileLoss(), подобрать learning rate и размеры hidden слоёв. Использовать pytorch_forecasting или neuralforecast.
5. Валидация и интерпретация. Проверить walk-forward, проанализировать variable selection, построить attention heatmap.

Кейс: прогноз спроса в ритейле. Сеть из 120 магазинов, 8000 SKU, горизонт прогноза 28 дней. Исходная система: SARIMA отдельно для каждого ряда, MAPE 18.4%, полный цикл переобучения — 6 часов. TFT на PyTorch + pytorch-forecasting: одна модель на все ряды, MAPE 11.2%, переобучение — 40 мин на A10G. Дополнительный бонус: feature importance через variable selection — выяснилось, что day_before_holiday влияет сильнее, чем сама дата праздника. Средняя экономия бюджета на инференсе для клиента составила 1.5 млн ₽ в год.

Как правильно оценивать качество прогнозов?

Не используйте RMSE как единственную метрику — она сильно штрафует за большие ошибки на больших значениях. Наш набор метрик для ритейл-прогнозирования:

• MAPE — интерпретируема, но нестабильна при значениях близких к нулю
• sMAPE — симметричная версия, избегает деления на маленькие числа
• MASE (Mean Absolute Scaled Error) — нормализован относительно наивного сезонного прогноза, отлично подходит для сравнения между рядами с разными масштабами
• Quantile loss / Pinball loss — для вероятностного прогнозирования, оценка покрытия интервалов

Гарантируем: мы предоставляем model card с этими метриками на валидационной выборке и результаты walk-forward теста на истории не менее 6 месяцев.

Что входит в работу

• Документация по выбранной архитектуре, обоснование выбора гиперпараметров.
• Воспроизводимый пайплайн обучения и инференса (Docker + CI/CD + Airflow/Prefect).
• Код с комментариями и модульными тестами на ключевые компоненты.
• Обучение вашей команды: как переобучать модель, как интерпретировать выходы, как деплоить новые версии.
• Поддержка в течение 3 месяцев после сдачи: консультации, фиксы багов, донастройка.

Процесс работы

Начинаем с EDA: визуализация, тест ADF на стационарность, STL-декомпозиция, анализ пропусков и выбросов. Это 2–3 дня, но часто выявляет системные проблемы данных, которые блокируют прогнозирование.

Затем: baseline (наивный seasonal, Prophet), feature engineering для LGBM, выбор архитектуры нейронной сети если нужно. Walk-forward validation с реалистичным горизонтом. Деплой через API с автоматическим переобучением по расписанию через Airflow или Prefect.

Сроки ориентировочно: MVP-прогноз на одном типе данных — 3–6 недель. Иерархическая система прогнозирования с автоматизацией — 2–5 месяцев. Стоимость рассчитывается индивидуально.

Наша команда — сертифицированные ML-инженеры (AWS ML Specialty, GCP Professional ML Engineer). За 5 лет на рынке реализовали более 50 проектов по прогнозированию. Свяжитесь с нами для бесплатного анализа ваших данных — мы оценим задачу и дадим первые рекомендации за 1–2 дня. Закажите консультацию и убедитесь, что ваши прогнозы работают в production, а не только в ноутбуке.