Реальна задача: передбачення руху ціни за стаканом
Трейдер дивиться на стакан заявок (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?
Порівняння моделей:
| Модель | Latency (p99) | AUC (0.1 sec horizon) | Застосування |
|---|---|---|---|
| OBI | 0.1 мс | 0.58 | Високочастотний арбітраж |
| LightGBM | 0.5 мс | 0.64 | Середньочастотні стратегії |
| DeepLOB | 2 мс | 0.69 | Трендова торгівля |
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 для потоків даних.
Процес роботи
- Аналітика та збір даних: отримуємо історичні L2-дані через Binance WebSocket або CME FIX.
- Feature engineering: розрахунок OBI, depth curves, imbalance на декількох горизонтах.
- Проєктування моделі: пробуємо DeepLOB, LightGBM на ручних фічах, гібридні підходи.
- Реалізація та навчання: на GPU кластері з розподіленим навчанням.
- Бектестування: на історичних даних з урахуванням комісій та прослизання.
- Деплой: контейнеризація, ONNX Runtime на інференс-сервері, інтеграція з OMS.
Що входить в роботу
- Документація моделі (model card) з метриками та обмеженнями.
- API для отримання сигналів (gRPC або REST).
- Навчання команди замовника інтерпретації виходів.
- Підтримка протягом 3 місяців після деплою.
- Вихідний код та конфігурації пайплайну.
Гарантуємо прозорість — ви отримаєте не чорну скриньку, а інтерпретований пайплайн. Усі результати підтверджуються бектестами на відкладеній вибірці. Економія за рахунок готових фічерерів та базових моделей сягає 30% бюджету.
Поширені помилки при побудові моделей стакану
- Ігнорування мікроструктури: використання тільки mid price без depth.
- Неправильний вибір вікна прогнозу: для HFT важливі мілісекунди, для трендів — секунди.
- Відсутність детекції айсбергів: приховані ордери спотворюють дисбаланс.
Скільки часу займає розробка?
| Етап | Терміни |
|---|---|
| Feature engineering + baseline | 2-3 тижні |
| DeepLOB з реальними даними | 8-12 тижнів |
| Production інтеграція | 4-6 тижнів |
| Разом | від 14 до 21 тижня |
Вартість розраховується індивідуально — залежить від об'єму даних, складності моделі та інфраструктури. Зв'яжіться з нами для попередньої оцінки вашого завдання — підберемо оптимальну архітектуру під стратегію. Отримайте консультацію щодо вашого проєкту прямо зараз.
