Чому прогнозування ліквідності крипторинку зривається на практиці
Прогнозування ліквідності крипторинку ламається не на етапі моделі, а на етапі даних. Оцінка глибини ринку надходить із запізненням: на момент, коли сигнал розраховано й передано, котирування вже пішли, а тонкий стакан заявок на парах другого ешелону розійшовся.
За галузевими вимірами Kaiko глибина в межах кількох відсотків від ціни на частині інструментів відновлюється хвилинами — і весь цей час прогноз залишається вірним на історичних зрізах і нездійсненним за фактом.
Ціна цієї помилки видно одразу. Прослизання угоди зростає нелінійно до розміру заявки, а на волатильності ринку розрахункова ціна входу й фактична відрізняються настільки, що угода втрачає сенс.
Модель, навчена на усереднених денних агрегатах, фізично не бачить моменту, коли книга заявок розсипається у відповідь на новинний імпульс: у навчальній вибірці такого стану просто немає.
Друга зона збою — розрив між прогнозом і виконанням. Модель і логіку виставлення заявок роблять окремо, між ними немає спільної метрики, тому зрив виконання списують на «поганий ринок», а не на те, що прогноз не враховував витрати й затримку доставки сигналу. Звідси ж зростає частка скасованих і переставлених заявок, які самі рухають ринок проти позиції.
Третя причина — відсутність зворотного зв'язку. Без журналу фактичних виконань не можна зрозуміти, де саме втрачається якість: у ознаках, у затримці розрахунку чи в правилах роботи із заявками.
Розбираємо, як це закривається: від потокового збору даних і синхронізації міток часу до наскрізної перевірки прогнозу проти реального виконання.
Що змінюється після впровадження моделі: вимірювані ефекти
Ефект від впровадження вимірюється не загальною метрикою якості, а чотирма величинами, які видно у звіті за угодами. Вимірюємо їх двічі — на історії з реконструкцією стакана і на живому потоці, щоб відокремити внесок моделі від зміненої кон'юнктури.
- Точність прогнозу на горизонті угоди. Модель на PyTorch спирається на глибину стакана, потік угод і перекіс між сторонами; частка вірних сигналів на потрібному горизонті йде з рівня випадкового вгадування до 60–70% на відкладеній вибірці.
- Зниження прослизання та вартість виконання. Обсяг заявки рахується від прогнозу доступної ліквідності, тому вхід рідше «з'їдає» стакан: відхилення ціни виконання від розрахункової падає в рази, а комісії та втрати на спреді перестають бути основною витратою стратегії.
- Скорочення простоїв у роботі із заявками. Сервіс прогнозу тримає відгук у заданому бюджеті, черга заявок не накопичується, при деградації підхоплює резервна версія — торговий контур не зупиняється на час перенавчання.
- Стійкість у шокові періоди. На різких рухах метрика просідає контрольовано: контроль дрейфу переводить модель в обережний режим із зменшеним розміром позиції замість лавиноподібного зростання помилок.
Перевіряємо кожен ефект на історичних вікнах, включно з шоковими, і на живому потоці — з журналом версій і можливістю відкату.
Прогнозування ліквідності: підходи та їхні обмеження
Ліквідність — не одна величина, а набір: ширина спреду, глибина книги заявок, стійкість ціни до угоди певного розміру.
Прогноз на хвилину й на добу — різні задачі, і метрика помилки в них непорівнювана, тому першим ділом фіксуємо горизонт прогнозу й рішення, яке за ним ухвалюється.
Головний обмежувач — зміна режиму волатильності. Модель, налаштована на спокійному ринку, на різкому русі видає впевнені, але неправильні значення, і це небезпечніше за відмову: система продовжує торгувати за застарілою логікою. Тому варіанти порівнюємо не за точністю на історії, а за поведінкою на межі режимів.
| Варіант | Коли підходить | Де ламається |
|---|---|---|
| Порогові правила за спредом і обсягом | Спокійний режим, груба сигналізація, потрібен швидкий запуск | Не переносяться на зміну режиму, потребують ручного переналаштування |
| Статистичні моделі (ARIMA, GARCH) | Короткий горизонт, ліквідні пари, важлива інтерпретованість | Потребують стаціонарності ряду, пропускають нелінійні зсуви |
| Навчувані моделі на табличних ознаках | Багато даних і ознак, середній горизонт прогнозу | Перенавчання на рідкісних подіях, дрейф ознак між режимами |
| Послідовнісні мережі за потоком заявок | Секундний горизонт, є повний потік подій | Дорогий супровід, чутливість до затримки даних |
На практиці робочий контур зазвичай комбінує два рівні: швидкі статистичні оцінки для короткого горизонту й навчувану модель — для середнього, з детектором зміни режиму та консервативним запасним прогнозом.
Розбираємо, як такий контур збирається під конкретну задачу й які перевірки відсіюють моделі, нестійкі до зміни режиму.
Етапи впровадження: від аудиту даних до робочої моделі
Порядок робіт вибудувано так, щоб кожна сходинка спиралася на перевірений результат попередньої. Модель прогнозування ліквідності помиляється частіше не через архітектуру, а через якість історії: пропуски в стакані, різні часові пояси бірж, зміна режиму ринку. Тому навчання не починається, поки дані не приведені до порівнюваного вигляду.
- Аудит даних — звіряємо глибину історії за біржами й парами, шукаємо розриви в часі та пропуски у знімках стакана. Позначаємо ділянки, придатні для навчання, і ті, що доведеться виключити.
- Постановка задачі — обираємо горизонт прогнозу й цільову величину: спред, глибину стакана або ймовірність просідання. Від неї залежить тип моделі та спосіб оцінювання результату.
- Підготовка ознак — дисбаланс заявок, інтенсивність скасувань, волатильність і обсяг за вікна. Кожна ознака рахується лише за минулими даними, інакше майбутнє просочується в навчання.
- Навчання та відбір — порівнюємо кілька моделей не за однією метрикою, а за стійкістю на спокійному ринку й у моменти різких рухів.
- Перевірка моделі — ковзне вікно: навчаємо на одному відрізку, перевіряємо на наступному, зсуваємо й повторюємо. Так видно, де почалося перенавчання під конкретний режим ринку.
- Впровадження в експлуатацію — сервіс віддає прогноз з оновленням ознак у реальному часі; налаштовуються поріг спрацювання та відкат до попередньої версії.
Кожен етап закінчується перевірюваним артефактом: звітом за даними, набором ознак, метриками на відкладених періодах. До наступного кроку переходимо лише тоді, коли попередній витримав перевірку.
Дані, ознаки та регламенти експлуатації моделі
Після здачі моделі замовнику залишається не звіт, а відтворюваний контур: дані, ознаки, код і регламенти, за якими модель живе далі без нашої участі.
Будь-який прогін навчання повторюється з вихідних зрізів однією командою — розходження виникає лише там, де ми свідомо змінювали параметри.
- Набори даних. Сирі зрізи стакана й угод, погодинні агрегати, єдиний формат зберігання. Версія набору фіксується контрольною сумою — перенавчання йде рівно на тій самій вибірці.
- Розмітка ознак. За кожною ознакою: джерело, вікно розрахунку, обробка пропусків, нормалізація. Окремо зазначено, які ознаки зсунуті в часі, щоб майбутні значення не витікали в навчання.
- Код моделі. Навчання й розрахунок сигналів розведені, зерно генератора випадкових чисел зафіксовано, параметри винесені у файл налаштувань — правка не потребує перезбирання.
- Схеми розрахунку. Потік даних від джерела до підсумкового сигналу та карта залежностей між ознаками.
- Регламент моніторингу. Перелік метрик якості та дрейфу ознак, горизонти контролю, пороги, за яких модель знімається з експлуатації, і хто ухвалює це рішення.
- Регламент оновлення. Періодичність перенавчання, вікно валідації, порядок відкату на попередню версію при деградації якості.
- Документація моделі. Припущення, межі застосовності та відомі слабкі місця — їх не доведеться шукати в проді.
Кейс: як модель утримала виконання угод у шокові дні
Задача надійшла від команди, яка виконувала великі заявки на спотовому ринку. Логіка дроблення була фіксованою: обсяг різався на рівні частини через рівні інтервали, стан стакана не враховувався.
У спокійні години це давало прийнятний результат, але в шокові періоди глибина на потрібному боці падала в рази за хвилини — виконання йшло на дальні рівні, а частина обсягу залишалася невибраною до скасування.
Ознаки зібрали з історії стакана: глибина за десятьма рівнями, спред, перевага обсягів купівлі та продажу, інтенсивність угод, поведінка сусідніх інструментів.
Задача формулювалася як прогнозування ліквідності на горизонті вікна виконання; історичну розмітку шокових епізодів звірили з публічними даними CoinGecko, щоб модель навчалася не лише на внутрішніх журналах.
На виході — ймовірність, що ліквідність на потрібному рівні доживе до кінця вікна, і рекомендація щодо дроблення.
Метрики до і після на порівнюваних періодах:
- частка угод за найгіршою ціною в доступній глибині: 18% → 6%;
- частка зірваних заявок у шокові години: 12% → 3%;
- прослизання відносно середини спреду скоротилося вдвічі.
Три шокові епізоди з обвалом ліквідності модель відмітила заздалегідь — від сорока секунд до двох хвилин до провалу глибини. У двох випадках виконання встигли перевести в пасивний режим і не гнати ціну, у третьому заявку відклали до повернення глибини. Хибних сигналів у спокійні години — одиниці на сотні вікон, звичайній роботі вони не заважали.
Що робити, якщо історичних даних мало або вони неповні?
Коротка історія інструмента — не вирок, якщо розуміти, де закінчуються дані й починаються припущення. Проблема зазвичай не в обсязі, а в структурі: пропуски в записах торгів, розриви на зміні торгових сесій, поодинокі викиди від збоїв фіду.
На таких рядах модель легко вивчає шум і показує гарну точність на перевірці, яку не підтверджує на живих даних.
Збір історичних даних починаємо не з одного джерела, а з кількох: свічки й стрічка угод з різних майданчиків перекривають одна одну, і за перетином відновлюються пропуски.
Де перекриття немає — ділянку позначаємо як невідому, а не заповнюємо середнім: інтерполяція за сусідніми точками створює фіктивну гладкість, на якій модель перестає розрізняти сплески волатильності. Далі приводимо все до єдиної частоти й перевіряємо, що мітки часу синхронізовані.
За малої вибірки працюють перенесення навчання з більш ліквідних інструментів і жорстке обмеження кількості ознак — краще п'ять стійких, ніж сорок корельованих.
Додатково застосовуємо блокову генерацію синтетичних вікон, що зберігає порядок і автокореляцію, та ковзну перевірку за часом: навчання на минулому, перевірка на наступному періоді без перемішування.
Якість розмітки тут критичніша за архітектуру. Цільову змінну задаємо через спостережувані стани ринку — просідання глибини стакана, розширення спреду, зростання прослизання — і фіксуємо правила присвоєння мітки письмово.
Спірні ділянки йдуть на ручну перевірку двома розмітниками, розходження розбираються, а не усереднюються.
Чесні межі позначаємо заздалегідь: модель віддає інтервал і ймовірність, а не точковий прогноз, і ми говоримо, за яких режимів ринку вона втрачає надійність.
Якщо історії інструмента не вистачає для стійкої оцінки, це фіксується у звіті до запуску — краще вузька область застосовності, ніж відмова в момент, коли прогноз потрібен.
Сумніви щодо даних, горизонту та стійкості моделі
Сумніви замовників зазвичай не про архітектуру, а про практику: чи встоїть прогноз на волатильному ринку, як часто перенавчати модель і чи не стане вона точкою відмови в працюючому торговому контурі.
Стійкість моделі перевіряємо ковзним вікном за послідовними періодами, а не однією відкладеною вибіркою. Ринкові дані звіряємо за незалежними джерелами, включно з CoinGecko: розходження входів легко маскується під помилку прогнозу.
Наскільки прогноз стійкий на нестабільному ринку?
Модель перевіряємо на періодах різких рухів, а не однією відкладеною вибіркою: дивимося якість у кожному вікні та деградацію при зсуві ринку. Тримаємо ансамбль з порогом впевненості — за слабкого сигналу система отримує явну відмову замість сумнівного числа.
Як часто перенавчаєте і що із захистом даних?
Перезбирання йде за розкладом і за тригером: змістився розподіл входів або просіла якість поза вибіркою. Дані живуть в окремому контурі — права за ролями, шифрування при зберіганні та передачі, обезличені набори для дослідів, журнал доступу.
Як прогноз вбудовується в торгову систему?
Прогноз віддається окремим сервісом із версіонованим інтерфейсом. Торговий контур отримує значення разом з горизонтом і оцінкою впевненості, рішення ухвалює сам — збій прогнозу не блокує виконання, а відкат на попередню версію йде без зупинки торгівлі.
Обговоримо задачу: що потрібно для старту робіт
Щоб повернутися з оцінкою термінів і планом робіт, нам достатньо кількох ввідних — їхній збір займає менше часу, ніж перша розмова. Чим конкретніше сформульована постановка задачі та цільова метрика, тим менше припущень закладаємо в оцінку. Нижче — що корисно надіслати й які питання закриємо разом.
- Опишіть, що саме прогнозуємо: глибину стакана, спред, доступний обсяг виконання великої заявки або відтік ліквідності в конкретних парах і на яких біржах. Від цього залежить і набір ознак, і клас моделей.
- Укажіть горизонт прогнозу — хвилини, години чи добу — і рішення, яке на нього спирається: виставлення котирувань, розбиття великого ордера, ризик-ліміти.
- Надішліть доступні дані: історію угод і стакана, метрики за біржами й пулами ліквідності, агрегатори, власні логи. Відразу позначте відомі пропуски, розриви та зміни режимів ринку — це визначає обсяг підготовки даних.
- Назвіть цільові метрики якості та допустиму помилку на різних ділянках ринку, а також що вважаємо хибним сигналом. Без критерію приймання не можна ні порівняти моделі, ні зафіксувати результат робіт.
- Розкажіть про інфраструктуру та обмеження: де рахуємо, як швидко потрібен прогноз, які вимоги до відтворюваності та зберігання історії, хто з боку замовника приймає результат.
- Позначте пріоритети та очікувані рамки за термінами — від цього залежить порядок етапів і те, що увійде в першу версію.
Далі пропонуємо пілотний запуск: вузький контур на одному ринку або інструменті, навчання на історичних даних, перевірка на відкладеному періоді та порівняння з поточним підходом. Якщо якість підтверджується, розширюємо набір ринків і вбудовуємо модель у робочий контур. Опишіть задачу — повернемося з оцінкою термінів і планом робіт за етапами.
