AI-трейдинг-бот: де ламається автоторгівля на живому ринку
AI-трейдинг-бот на тестовому періоді показує рівну дохідність, а на живому ринку першим ділом ламається не прогноз, а виконання.
Модель може бути сильною, але якщо бот втрачає зв'язок з біржею в момент сигналу, надсилає заявку двічі або виконується за ціною, якої вже немає, — результат розходиться з розрахунком у рази. Розбираємо, де рветься автоторгівля і як це закривається.
Перше вузьке місце — розриви зв'язку з біржею. Інтерфейс відповідає із затримкою, з'єднання перепідключається, і стан заявки в цей момент невідомий: пішла вона чи ні.
Бот без звірки фактичних позицій із журналом угод повторює ордер і отримує подвійний обсяг там, де планував одинарний. Обгортка над біржовими інтерфейсами CCXT дає єдиний спосіб читати позиції та заявки, але алгоритм звірки під кожен сценарій пишеться окремо.
Друге — прослизання ордерів. Сигнал рахується за однією ціною, виконання приходить за іншою: на ліквідних парах різниця в частки відсотка, на вузьких — кратно більше, і вся розрахункова дохідність стратегії йде в цей зазор.
Лікується лімітними заявками з ціновим допуском, дробленням обсягу та лімітом на відхилення ціни: якщо ціна пішла далі, угода не відкривається взагалі.
Третє — відсутність контролю просадки на рівні бота. Ліміт ризику на одну угоду не рятує, коли серія збитків і зависла позиція складаються в один день.
Потрібен незалежний шар: межа просадки на день і на період, автостоп при її досягненні та приведення портфеля до безпечного стану без участі людини.
Жоден із цих збоїв не видно на історії — вони проявляються тільки на реальному ринку. Далі розбираємо, як кожен із них закривається.
Швидкість реакції, дисципліна та контроль ризику в торгівлі
Ручна торгівля впирається в три речі: швидкість, дисципліну та розмір ризику на угоду. Поки трейдер бачить сигнал, перевіряє книгу замовлень і підтверджує вхід, ціна йде разом із частиною очікуваного прибутку.
Далі підключаються емоції: після серії збитків правило «не більше N% на угоду» непомітно перетворюється на «доберу, щоб відігратися».
Бот знімає обидві проблеми одразу. Сигнал від моделі перетворюється на ордер за секунди, а ліміти на угоду, денну просадку та кількість позицій прописані в коді й не залежать від настрою.
Виконання йде через CCXT — єдиний шар доступу до бірж, тому та сама стратегія працює на кількох майданчиках без переписування логіки.
| Параметр | Вручну | З ботом |
|---|---|---|
| Реакція на сигнал | секунди-хвилини, залежить від зайнятості | секунди, без пропусків |
| Правила входу | дрейфують після серії збитків | зафіксовані в коді стратегії |
| Ризик на угоду | «на око», переглядається під тиском | ліміт на угоду, день, кількість позицій |
| Нічні позиції | залежать від того, хто не спить | працює без оператора |
| Розбір угод | вивантаження вручну, частина губиться | журнал ордерів і сигналів |
Окремо рахується ризик: розмір позиції та стоп-рівні виводяться з поточного капіталу, тому після просадки обсяг наступної угоди зменшується автоматично.
У сумі це однакова поведінка стратегії на будь-якому обсязі, передбачувана просадка та журнал, за яким видно, де спрацювало правило, а де помилилася модель.
Способи запуску бота: хмара, власний сервер, гібрид
Де живе торгове ядро — визначає затримку до майданчика, доступність у момент волатильності та те, наскільки швидко ви відкочуєте невдалий реліз. Прогнозна частина чутлива до пам'яті під виведення моделі й до розкладу перенавчання, а не до швидкості реакції на тік.
Тому розміщення бота і спосіб підключення до бірж обирають разом: схема запуску задає і архітектуру відмовостійкості.
Нижче — три схеми, між якими реально обирають на старті та при масштабуванні.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарний запуск | швидкий старт, невеликий обіг, рідкі перенавчання | залежність від провайдера, мережеві затримки до майданчиків, обмеження на тривалі розрахунки |
| Власна інфраструктура | чутливість до затримки, вимоги до зберігання даних і доступів | оновлення, моніторинг і відмовостійкість залишаються на вас |
| Гібрид | торгове ядро поруч із майданчиком, історія угод і навчання — у хмарі | два середовища, потрібні спільна конфігурація та наскрізний моніторинг |
Підключення до бірж закриваємо єдиним конектором на CCXT: один інтерфейс до десятків майданчиків для ордерів, балансів та історії угод.
Додати нову біржу — правка конфігурації, а не переписування торгового ядра, тому диверсифікація за майданчиками не перетворюється на окремий проєкт. Ключі тримаємо в секретах із роздільними правами: торгівля без виведення коштів, ліміти на обсяг і частоту запитів.
Етапи роботи: аудит стратегії, схема, налаштування, перевірка
Порядок етапів тримаємо жорстким: поки правила стратегії не зведені до формальних умов, ні схема інтеграції, ні налаштування бота не дадуть передбачуваного результату.
Помилка, пропущена на будь-якому кроці, спливає вже на бойовому рахунку, тому кожен етап закривається перевірюваним артефактом.
- Аудит стратегії: розбираємо правила входу та виходу, робочі таймфрейми, допустиму просадку й ліміти на позицію — переводимо їх в однозначні умови, які код виконує без трактувань.
- Схема інтеграції: джерело ринкових даних, модуль зв'язку з біржею, зберігання ключів доступу та розділення тестового й бойового контурів.
- Підготовка даних: чистимо історію, відновлюємо пропуски, враховуємо комісії та прослизання — без цього прогноз виглядає краще, ніж торгівля.
- Налаштування бота: розрахунок сигналу, ризик-менеджер, виконавець ордерів, журнал угод — кожен модуль перевіряється окремо.
- Перевірка на тестовому контурі: спочатку прогін на історичних даних, потім демо-рахунок із реальним потоком котирувань.
- Перевірка відмов: обрив зв'язку, відхилена заявка, різкий стрибок ціни — дивимося, як бот закриває позиції та відновлює з'єднання.
- Передача під управління: панель із відкритими позиціями, оповіщення про збої, регламент ручної зупинки.
На виході — працюючий AI-трейдинг-бот і зрозумілий порядок дій на випадок, якщо ринок поведеться нештатно.
Конфігурації, схеми інтеграцій і регламенти на виході
Бот передається разом із комплектом, за яким його можна супроводжувати, перевіряти та передавати іншій команді. Нижче — склад поставки за кожним напрямом: конфігурація, схема інтеграцій, політики доступу до ключів і регламенти оновлення.
- Конфігурація бота — файли з переліком торгових пар, лімітами обсягу позиції, порогами спрацювання прогнозу та режимом ризику. Правки вносяться без зміни коду.
- Схема інтеграцій — діаграма взаємодії з торговими майданчиками, джерелом ринкових даних, сховищем історії, модулем прогнозу та шаром виконання заявок, із позначеними точками відмови.
- Політики доступу до ключів — розмежування прав за майданчиками, торгові права без виведення коштів, ротація ключів, захищене сховище та журнал звернень.
- Документація по моделі — які ознаки на вході, як рахується прогноз, за якими метриками оцінюється якість і коли запускається перенавчання.
- Регламент оновлення та відкату — контрольні знімки конфігурації та версії моделі, порядок переходу на нову гілку й повернення до попереднього набору параметрів.
- Засоби спостереження — метрики затримки до майданчика, частки відхилених заявок, розходження прогнозу з фактом і оповіщення в робочий чат.
Комплект збирається по ходу роботи, а не в кінці: конфігурація та політики фіксуються до перших угод, схема інтеграцій уточнюється при підключенні другого майданчика, а регламент оновлення перевіряється на навчальному відкаті.
Кейс: портфель на чотирьох біржах — метрики до і після
Як вели портфель вручну
Портфель на чотирьох біржах вів один трейдер: зводив книги замовлень вручну, стежив за розходженням цін між майданчиками і сам виставляв пари ордерів. Уночі та в моменти різких рухів сигнали губилися — за журналом пропуск сягав третини.
Частина заявок ішла з помилкою в обсязі або за ціною, яка встигала піти за секунди між рішенням і введенням; розбір таких угод і звірка балансів займали години щотижня.
Що змінили і що показали метрики
Виконання перевели на єдиний шар доступу до бірж на CCXT замість чотирьох розрізнених наборів скриптів. Прогнозна модель рахує ймовірність руху і працює фільтром: сигнал іде у виконання, тільки якщо збіглися модель, ризик-ліміти та перевірка ліквідності.
Заявки ідемпотентні за власним ідентифікатором, а після обриву зв'язку бот звіряє фактичні позиції з очікуваними та доводить їх до цільових.
Ручних дій залишилося дві: правка лімітів і розбір тижневого звіту. Трейдер перестав бути вузьким місцем — портфель працює в нічні години та на всіх чотирьох майданчиках одночасно.
Що робити, якщо вже розгорнутий класичний трейдинг-бот?
Так, переписувати бота заново не потрібно — прогнозну модель вбудовують у вже працюючий контур. Правила залишаються виконавчим шаром: вони тримають з'єднання з біржею, рахують позицію, дотримуються лімітів ризику.
Модель додається окремим модулем і відповідає лише на одне питання — чи варто взагалі входити в угоду зараз.
Розділення виходить чистим: модель віддає ймовірність руху за набором ознак — волатильність, режим ринку, поведінка обсягу, а правила переводять її в розмір позиції, стоп і момент входу. Такий контур простіше відлагоджувати. Якщо прогноз помиляється, відразу видно, на якому шарі: ознаки, сама модель чи виконання заявки.
Дані для навчання у вас уже є — журнали сигналів і угод самого бота. За ними відновлюють історію рішень і підшивають ринкові ряди за той самий період.
Ключова умова: ознаки рахуються тим самим кодом, що й при реальній торгівлі, інакше модель вчиться на одному розподілі, а бачить інший, і якість на історії не переноситься на живий рахунок.
Виведення в роботу йде етапами, без зупинки торгівлі. Спочатку тіньовий режим: модель рахує прогнози й пише їх поруч із рішеннями правил, бот торгує як завжди.
Коли накопиченої статистики досить, щоб порівняти точність за одних і тих самих умов, частку капіталу під модель збільшують поступово — від невеликої частини до повної. Зворотне перемикання на правила робиться одним налаштуванням.
Так доопрацювання наявного бота не перетворюється на стрибок: стара логіка залишається страховкою, поки нова не доведе якість на ваших даних і вашому режимі ринку.
Технічні сумніви: затримки, ризик, відмови, доступи
Замовник перед запуском ставить ті самі інженерні питання: що станеться при обриві каналу до біржі, чи можна довіряти прогнозу моделі, які права отримує бот на рахунку і як він поводиться при відмові. Нижче — короткі відповіді за кожним пунктом.
Загальний принцип один: будь-який нештатний стан переводить бота в консервативний режим — зупинка нових входів і скорочення позицій за правилами стратегії, а не спроба «додавити» угоду.
Що відбувається при обриві зв'язку з біржею?
Канал контролюється за часом відповіді та частотою помилок. При зникненні зв'язку бот не надсилає нових заявок, а після відновлення звіряє фактичний стан рахунку з внутрішнім обліком. Розходження фіксується в журналі та закривається повторною звіркою. Заявки, що пішли до обриву, відстежуються за ідентифікаторами — втрачених позицій не залишається.
Наскільки надійний прогноз моделі?
Модель дає оцінку ймовірності, а не гарантію. Якість перевіряється на історичних даних без підглядання в майбутнє, окремо — на періоді, якого модель не бачила. У реальній торгівлі поверх сигналу працюють обмеження розміру позиції та обов'язковий захисний ордер. Якщо якість сигналу падає нижче порогу, бот знижує обсяг або зупиняє торгівлю.
Які права потрібні боту на біржі?
Тільки торгові ключі, без права виведення коштів. Кошти залишаються на біржовому рахунку замовника, і бот фізично не може їх вивести. Ключі зберігаються в захищеному сховищі з обмеженим доступом. Відкликання ключа миттєво позбавляє бота доступу й не зачіпає виведення коштів.
Як бот поводиться при відмові?
Працюють кілька незалежних обмежень: межа втрат за день, ліміт на кількість угод і ручний «вимикач» для зупинки торгівлі. При спрацюванні будь-якого з них позиції закриваються за правилами стратегії, а бот переходить у режим очікування до підтвердження оператора. Кожна дія пишеться в журнал із часом і причиною — розбір інциденту займає хвилини.
Обговоримо стратегію і повернемося з оцінкою та планом
Щоб оцінка спиралася на дані, а не на відчуття, для старту достатньо кількох вступних. Далі ми розбираємо логіку входів і виходів, проганяємо її на історичних даних і лише після цього називаємо склад робіт і терміни.
Що надіслати, щоб ми почали рахувати:
- правила стратегії: умови входу та виходу, робочий таймфрейм, перелік інструментів;
- майданчики та типи рахунків, на яких бот має працювати;
- поточний код, якщо він є: репозиторій або архів, конфіги, логи останніх запусків;
- як зараз рахуються ризики: розмір позиції, ліміти просадки, стоп-умови;
- вимоги до прогнозної моделі: горизонт, набір ознак, допустима затримка сигналу;
- обмеження інфраструктури: де буде крутитися бот, чи є доступ до серверів і ключів із правом торгівлі без виведення коштів.
У відповідь ви отримуєте схему взаємодії модулів (збір даних через CCXT, розрахунок ознак, прогноз, виконання ордерів), склад робіт за етапами, план впровадження з точками контролю та оцінку термінів.
Якщо на історії заявлені правила не дають стійкого результату, скажемо про це прямо й запропонуємо скоригувати логіку, а не підганяти звіт під очікування.
Опишіть задачу — повернемося з оцінкою та планом.
