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 впливає сильніше, ніж сама дата свята. Середня економія бюджету на інференсі для клієнта склала значну суму.

Як правильно оцінювати якість прогнозів?

Не використовуйте 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, а не тільки в ноутбуці.