Чому AI-трейдинг-бот для криптовалют втрачає гроші на реальному ринку
Найчастіше ai трейдинг бот криптовалюта втрачає не на «поганому ринку», а на розриві між історією, на якій його навчали, і реальним виконанням. Бектест показує гарну криву, бо угоди в ньому закриваються за ціною зі свічки.
У живому стакані ордер проходить через кілька рівнів, і середня ціна входу виявляється гіршою за сигнальну — це прослизання. На тонких парах і в моменти волатильності воно з'їдає всю маржу стратегії, яка на папері виглядала прибутковою.
Друге джерело втрат — затримка виконання угоди. Поки сигнал доходить до біржі, поки API приймає й підтверджує ордер, ціна йде.
Чим коротший горизонт утримання позиції, тим сильніше це б'є: скальпінгова логіка, розрахована на миттєву реакцію, на реальній затримці перетворюється на систематичний вхід за гіршою ціною.
Окремо додається розрив ліквідності між біржами — арбітражний сигнал видно на одному майданчику, але виконати його там нічим, а на другому ціна вже зсунулася.
Третя причина — перенавчання стратегії. Модель підганяється під конкретний історичний відрізок, запам'ятовує його шум і видає відмінний результат на перевірковій вибірці з того самого періоду.
На нових даних закономірність не відтворюється, і торговий бот криптовалюта починає втрачати на кожному циклі.
Лікується це не «покращенням» моделі, а чесною валідацією: розділенням даних за часом, перевіркою на періодах з іншою волатильністю, урахуванням комісій і прослизання прямо в розрахунку результату.
Усі три фактори складаються, і стратегія, що давала плюс на історії, іде в мінус на живому ринку — не через помилку в коді, а через те, що умови виконання в бектесті не збігалися з реальними. Нижче розбираємо, як це закривається на рівні архітектури та контролю ризику.
Що дає AI-трейдинг-бот: вимірюваний ефект і режими роботи
Режими торгівлі: що саме автоматизується
Кожен режим вирішує своє завдання і має власну ціну помилки. Маркет-мейкинг утримує двосторонні котирування в стакані: бот виставляє і переставляє заявки в міру руху ціни, заробляючи на спреді.
Ключова метрика тут — частка заявок, виконаних без несприятливого відбору: за коректних лімітів і перерахунку котирувань кожні кілька секунд вона тримається вище 70%, інакше спред з'їдається інформованими контрагентами.
Арбітраж між біржами ловить розходження ціни однієї пари на різних майданчиках.
Вікно можливості живе частки секунди, тому рішення ухвалюється за потоком ордербуків, а не за свічками: затримка від сигналу до виставлення ордера вкладається в десятки мілісекунд, інакше розходження закривається раніше за вхід.
Слідування за трендом працює на старших таймфреймах і дає меншу частоту угод, зате потребує дисципліни на виході — частка хибних входів на боковику знижується фільтром волатильності.
Управління ризиком позиції
Розмір позиції рахується від волатильності інструмента, а не фіксованим лотом: при зростанні волатильності обсяг автоматично урізається, і просадка на серії збиткових угод залишається в заданому коридорі.
Стоп-заявки виставляються на біржі одночасно з входом — при обриві зв'язку позиція не залишається незахищеною. Прослизання на ліквідних парах утримується в межах кількох базисних пунктів завдяки лімітним входам замість ринкових.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Маркет-мейкинг | Ліквідні пари, стабільний стакан | Чутливий до комісій і різких випадів |
| Арбітраж між біржами | Кілька майданчиків, швидкий канал | Потребує балансу коштів на кожній біржі |
| Слідування за трендом | Спрямований рух, старші таймфрейми | Просадки на боковику, рідкісні входи |
Логіку виконання і ризик-контур збираємо на CCXT — єдиний інтерфейс до бірж спрощує перенесення стратегії між майданчиками без переписування ядра.
Як ми будуємо AI-трейдинг-бота: етапи інженерної роботи
Процес будується навколо одного принципу: спочатку перевіряємо, що торгова гіпотеза взагалі має статистичну підставу, і лише потім пишемо код.
Більшість провалів у розробці торгового бота — не технічні, а дослідницькі: стратегію запускають на живому рахунку, не перевіривши її на історичних даних і не заклавши ризик-контури.
Тому ми ведемо проєкт етапами, де кожен наступний крок відкривається лише після підтвердження попереднього.
- Аудит гіпотези та даних. Розбираємо логіку стратегії: на якому ринковому ефекті вона заробляє, за яких режимів ринку перестає працювати. Перевіряємо доступність і якість історичних даних за потрібними парами та таймфреймами — пропуски, викиди, коректність свічок.
- Формалізація правил і ризик-менеджмент бота. Фіксуємо умови входу та виходу, розмір позиції, ліміти на просадку та максимальну експозицію. Ризик-контури закладаємо в архітектуру з самого початку, а не прикручуємо після перших збитків.
- Тестування стратегії на історії. Прогоняємо правила на історичних даних з урахуванням комісій і прослизання, окремо перевіряємо стійкість результату на різних періодах. Стратегія, яка працює лише на одному відрізку, в роботу не йде.
- Підключення до біржі та виконання. Реалізуємо підключення до біржі через торговий інтерфейс, обробку ордерів, повторні спроби при збоях і звірку фактичних позицій з розрахунковими. Окремо закриваємо поведінку при обриві зв'язку.
- Перевірка на живих даних. Запускаємо систему в режимі реального ринку з мінімальним обсягом, звіряємо поведінку з результатами історичних прогонів. Розбіжності розбираємо до того, як збільшувати обсяг.
- Моніторинг і алерти. Налаштовуємо контроль просадки, завислих ордерів і відхилень від очікуваної поведінки — щоб збій було видно одразу, а не за підсумками тижня.
- Передача системи замовнику. Віддаємо вихідний код, конфігурації, документацію щодо стратегії та інструкції із запуску й зупинки. Проводимо навчання команди та залишаємося на зв'язку щодо супроводу.
Кожен етап закінчується артефактом, який можна перевірити: звіт щодо даних, зафіксовані правила, результати прогонів, логи виконання. Опишіть вашу торгову гіпотезу — повернемося з оцінкою та планом робіт за етапами.
Чим відрізняється навчання на історії від перевірки на живому ринку?
Тестування на історії та перевірка на живому ринку відповідають на різні питання. Перше показує, як стратегія повелася б на вже відомих даних, друге — чи витримає вона потік угод, якого модель ніколи не бачила.
Різниця принципова: історичний прогін можна несвідомо підігнати під минуле, живий ринок підгонці не піддається.
Перенавчання моделі — головний ризик першого етапу. Коли параметрів багато, а даних мало, алгоритм знаходить закономірності, яких у ринку не було: випадкові сплески волатильності, разові рухи ліквідності, артефакти біржових свічок.
На графіку така стратегія виглядає переконливо, але її стійкість тримається на шумі, а не на повторюваній логіці. Тому історію ділять на періоди: на одному налаштовують, на іншому — якого модель не бачила — перевіряють. Якщо результат на відкладеному відрізку різко падає, справа не в ринку, а в підгонці.
Валідація торгової логіки йде далі й включає те, що бектест спрощує: прослизання при виконанні, комісії, затримку між сигналом і ордером, часткове заповнення заявок, реальну глибину стакана.
На історії все це часто вважається ідеальним, і стратегія, прибуткова в моделі, на живому ринку йде в мінус саме на цих витратах.
Перевірка на живому ринку — це торгівля малим обсягом у реальному потоці, де видно і прослизання, і поведінку моделі на даних, яких не було в навчанні.
Стійкість стратегії перевіряють не одним вдалим прогоном, а серією: різні ринкові режими — тренд, боковик, різкі падіння, — і на кожному модель має поводитися передбачувано. Якщо результат тримається лише в одному режимі, це не стратегія, а збіг із конкретним відрізком історії.
Живий прогін малого обсягу дає те, чого не дасть жоден бектест: реальні відмови виконання, поведінку при розривах ліквідності та чесну оцінку витрат.
Практичний висновок для замовника: цифри історичного тесту без другого етапу нічого не значать.
Ми завжди будуємо перевірку у два кроки — спочатку відкладені періоди та стрес-сценарії, потім контрольований запуск на живому ринку з обмеженим обсягом, — і тільки після цього говоримо про те, як стратегія поведе себе в реальній торгівлі.
Кейс: як бот перестав втрачати на різких рухах ринку
Замовник прийшов із робочою стратегією: бот упевнено заробляв на спокійному ринку, але на різких рухах — новинних імпульсах, ліквідаціях великих позицій — втрачав більше, ніж приносив за тиждень. Проблема була не в логіці входу: сигнали відпрацьовували коректно.
Ламався вихід — позиція утримувалася за фіксованим часом, а захисна зупинка стояла статично і не встигала за розширенням амплітуди.
На волатильних ділянках частка збиткових угод сягала 68%, середній час утримання позиції — 40 хвилин, захисні зупинки спрацьовували рідко і з прослизанням.
Ми перебудували управління позицією, не торкаючись сигнальної частини. Захисна зупинка стала адаптивною: її рівень перераховується від поточної волатильності ринку — на розширенні амплітуди коридор зростає, на затуханні звужується.
Додали примусове закриття при відхиленні ціни на задану частку від точки входу і перевели утримання позиції з фіксованого часу на умову за рухом. Логіку винесли в окремий шар із журналюванням кожного рішення — стало видно, чому угоду закрито саме так.
Після змін частка збиткових угод на волатильних ділянках знизилася з 68% до 31%, середній час утримання позиції скоротився до 12 хвилин, кількість спрацьовувань захисних зупинок зросла втричі — але кожна зупинка тепер закривала позицію з контрольованим відхиленням, а не за фактом просадки. Просадка на різких рухах перестала з'їдати прибуток спокійних періодів.
Що саме змінили в логіці виходу
- Адаптивна захисна зупинка — рівень рахується від поточної волатильності, а не задається константою при старті.
- Умова виходу за рухом — позиція закривається при досягненні цільового відхилення, а не за таймером.
- Шар журналювання рішень — по кожній угоді видно вхід, причину виходу та параметри на момент спрацьовування.
| Варіант управління виходом | Коли підходить | Обмеження |
|---|---|---|
| Фіксована зупинка | Спокійний ринок, вузький коридор | Не встигає за розширенням амплітуди |
| Адаптивна від волатильності | Різкі рухи, новинні імпульси | Потребує коректного розрахунку метрики волатильності |
| Вихід за таймером | Скальпінг на передбачуваному ринку | Тримає позицію в збитку при розвороті |
Метрики стратегії знімали на історичних даних і на тіньовому прогоні паралельно з робочою версією — порівняння йшло за однаковими ринковими ділянками.
Інструментарій підбирали під задачу, спираючись на Walk-Forward Analysis для перевірки стійкості параметрів поза вибіркою, на якій вони налаштовувалися.
Сумісність, доступи та відкат: що обговорити до старту
Перше питання на старті — не «який алгоритм», а як бот отримає доступ до торгового рахунку і що станеться, якщо його поведінка виявиться неправильною.
Тому інтеграцію проєктуємо від обмежень, а не від стратегії: API-ключі створюються лише на торгівлю та читання, виведення коштів закрито на рівні налаштувань ключа, а не «на чесному слові».
Якщо біржа підтримує прив'язку ключа до IP — використовуємо її, тоді ключ, що витік, марний поза нашим контуром.
Що як бот уже працює з іншою біржею? Абстрагуємо виконання ордерів від конкретного майданчика: логіка стратегії не знає, куди надсилається заявка. Додавання другої біржі — це новий адаптер і прогін на історичних даних, а не переписування ядра.
Що як потрібно зупинити торгівлю прямо зараз? Передбачаємо аварійний прапорець: він знімає нові заявки, але не чіпає вже відкриті позиції — їхнє закриття залишається за вами, щоб бот не спрацював проти ринку в момент паніки.
Як відкочується конфігурація, якщо нова версія поводиться гірше?
Параметри стратегії та логіка виконання версіонуються окремо. Відкат — це повернення до попереднього набору параметрів і перезапуск з тими самими ключами, без перезбирання і без повторного узгодження доступів.
Перед кожною зміною знімаємо знімок стану: які ліміти, які пари, який режим ризику. Повернутися на крок назад можна за хвилини, а не за ніч розглядів.
Після здачі ви отримуєте на руки:
- репозиторій з історією змін та описом гілок;
- документацію по боту: схема виконання, параметри ризику, точки відмови;
- інструкцію з ротації ключів і налаштування прав на біржі;
- регламент безпечного відкату конфігурації з покроковою перевіркою;
- набір тестів на історичних даних і граничні сценарії;
- чекліст моніторингу: що дивитися в логах і коли бити на сполох;
- матрицю доступів — хто з вашої команди що може змінювати.
Опишіть задачу: які біржі в контурі, хто володіє ключами, які ліміти за ризиком вважаєте допустимими. Повернемося з оцінкою та планом робіт.
