Чому бектестинг криптовалютних стратегій бреше на історії
Рівна крива дохідності на графіку та збиток у перші ж дні живої торгівлі — найчастіша історія, з якою приходять до нас замовники.
Справа зазвичай не в самій стратегії, а в тому, як побудована перевірка стратегії на історичних даних: тест вимірює не те, що буде відбуватися з грошима.
Найчастіше в розрахунку є підглядання в майбутнє. Сигнал рахується за ціною закриття свічки, і угода виконується за цією ж ціною, хоча в реальності заявка йде вже після закриття.
Якщо індикатори перераховуються по всій історії одразу, то в кожній точці часу неявно використовується ще не настала інформація — і дохідність виходить завищеною.
Далі — зміщення вижившего: список монет береться на сьогодні, тому обнулені та делістинговані пари в тест не потрапляють. Плюс якість даних: дірки в свічках, різні часові пояси бірж, різний спосіб зведення періодів при склейці дають сигнали там, де угоди фізично не було.
Витрати в тесті зазвичай занижені або відсутні: комісії, спред, просковзування, ставка фінансування за безстроковими контрактами та глибина стакана на рідкісних парах. В реальності саме вони з'їдають прибуток на частих угодах.
Нарешті, перенавчання: якщо перебрати тисячі наборів параметрів на одній і тій самій історії, найкращий результат майже напевно підігнаний під шум. Звідси й розходження тесту та реальної торгівлі, яке не лікується підкручуванням порогів. Розбираємо, як це закривається на рівні самої платформи.
Що дає чесна перевірка стратегії на історичних даних
Швидкість прогону стратегії визначає, скільки гіпотез ви встигнете перевірити до зміни ринкового режиму.
Векторне ядро на VectorBT рахує всю матрицю параметрів за історією свічок паралельно: перебір, який у подієвому циклі займав години, вкладається в хвилини, і сітка перестає бути вузьким місцем.
Відтворюваність результатів тестування тримається на трьох фіксаціях: снапшот ринкових даних з контрольною сумою, версія коду стратегії та зафіксоване зерно генератора.
Будь-який прогін з журналу піднімається заново і дає ту саму криву дохідності — розходження в частки відсотка вже сигнал про неявне джерело випадковості, яке треба прибрати до виведення стратегії в роботу.
Стійкість стратегії до перенавчання перевіряємо схемою ковзного вікна: параметри підбираються на одному відрізку, перевіряються на наступному, якого розрахунок не бачив.
Якщо оптимум виглядає самотньою вершиною, а не плато, стратегія тримається на шумі й розвалиться на живих даних. Додатково проганяємо набір через тренд, боковик і ділянки різких просадок окремо.
Журнал прогонів зберігає по кожному запуску датасет з його версією, повний набір параметрів, враховані комісії та просковзування, криву угод і метрики ризику.
За ним видно, яка перевірка відсіяла гіпотезу і на якому кроці — так закриваються цілі класи помилок: підглядання вперед, тестування тільки на вцілілих інструментах, недооцінка витрат.
Режими прогону: векторний, подієвий і потоковий
Три режими відрізняються не форматом підсумкового звіту, а тим, що саме вони моделюють. Векторний прогін рахує угоди за масивами історичних свічок і працює найшвидше — він потрібен, щоб відсортувати тисячі комбінацій параметрів і відкинути явно слабкі гіпотези.
Подієвий прогін по стакану відтворює потік заявок з урахуванням глибини, часткових виконань і часу відгуку, а потоковий розрахунок у реальному часі йде на живих даних і перевіряє, що модель збігається з фактичним виконанням.
Вибирати один режим безглуздо: порівняння режимів тестування будується як піраміда — від швидкої відбраковки до точної перевірки.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Векторний прогін | Первинний відбір гіпотез, перебір великої кількості наборів параметрів | Не бачить рух ціни всередині свічки, чергу заявок і просковзування — результат оптимістичніший за реальний |
| Подієвий прогін по стакану | Перевірка виконання: просковзування, часткові заявки, поведінка на рідкісних інструментах | Потрібен архів глибини ринку, розрахунок іде помітно довше, обсяг даних зростає швидко |
| Потоковий розрахунок у реальному часі | Фінальна перевірка перед виведенням стратегії на реальні обсяги | Історію не переграти, вікно спостереження обмежене, потрібна стійкість до розривів зв'язку |
Щоб результати були зіставні, всі три режими проганяємо на одному наборі даних, з одними правилами розрахунку комісій і однаковою логікою управління позицією.
Розходження між векторним і подієвим прогоном — це і є вимірювальна оцінка того, наскільки модель виконання відрізняється від ринку; якщо розрив великий, стратегія йде на доопрацювання до виведення на живий контур.
Етапи розробки платформи: від аудиту даних до передачі
Перш ніж писати код, розбираємо, звідки беруться дані й як саме рахується результат угоди. Платформа ламається не на математиці, а на розходженнях: різні часові пояси бірж, пропущені свічки, делістинг пар, неврахована ставка фінансування.
Тому перші етапи — аудит історичних даних і узгоджена схема розрахунків: без них будь-яка цифра дохідності на графіку нічого не значить. Нижче — послідовність, за якою ми ведемо проєкт.
- Аудит історичних даних. Звіряємо ряди з незалежним джерелом, шукаємо пропуски, дублі, розриви на лістингах і делістингах, приводимо мітки часу до одного поясу. Фіксуємо, які пари та періоди покриті, а де перевіряти стратегію не можна.
- Схема розрахунків. Домовляємося про модель виконання: комісії, спред, просковзування, ставка фінансування, момент спрацювання заявки всередині свічки. Схема стає еталоном, за яким потім звіряється кожна цифра.
- Реалізація ядра розрахунку. Прогін по подіях з детермінованим результатом: один і той самий набір даних і параметри дають один і той самий звіт, який можна відтворити.
- Перевірка коректності розрахунків. Еталонні сценарії — стратегія без угод, купівля та утримання, заздалегідь порахований вручну випадок. Плюс звірка з незалежною реалізацією та регресійні тести на кожній зміні.
- Прогін на відкладеному періоді. Ділимо історію на навчальну та контрольну частини, перевіряємо стійкість результату до затримки виконання і до просковзування.
- Передача. Документація, схема розрахунків, тестовий стенд, розгортання на вашій інфраструктурі та навчання команди роботі з платформою.
Склад поставки: схеми даних, журнали прогонів, регламенти
Комплект поставки збираємо так, щоб платформу можна було вести й розвивати без нас. Кожен артефакт закриває своє питання: звідки беруться дані, як повторити конкретний прогін, за яким регламентом його запускати і що перевіряти після правок у стратегії.
- Схема даних — сутності та зв'язки: інструменти, історичні котирування, сигнали, угоди, метрики, правила нормалізації та зберігання. За нею нове джерело підключається без втручання в розрахункове ядро.
- Регламент прогону — параметри запуску, вікно історії, обробка пропусків і викидів, порядок фіксації версії стратегії. Прогін відтворюється за тим самим входом і через місяці.
- Журнали прогонів — по кожному: версія стратегії, зріз даних, метрики ризику та дохідності, повний лог угод. Порівняння варіантів іде за збереженими результатами, без повторного перерахунку.
- Документація платформи — опис модулів, інтерфейс розрахункового ядра, порядок додавання індикаторів і нових стратегій.
- Інструкція з розгортання — підняти стенд з нуля, налаштувати резервне копіювання та відновлення після збою.
- Приймальні перевірки — набір тестів на коректність розрахунку метрик, який ви запускаєте самі після кожної правки.
- Матриця доступу — ролі та права: хто змінює стратегії, хто запускає прогони, хто вивантажує результати.
Передаємо комплект з прийманням на ваших даних: ви проганяєте свої стратегії та звіряєте метрики з очікуваними до закриття робіт.
Кейс: як прибрали розходження між тестом і реальною торгівлею
Де втрачалася точність
Замовник — керуючий алгоритмічною стратегією на споті та ф'ючерсах Binance. Прогін на історії давав плавну криву, а фактична торгівля приносила інший результат: розходження за підсумком дня сягало 15-20%. Шукали причину не в логіці стратегії, а в рушії виконання — і знайшли три.
Перша: рішення приймалося за ціною закриття бару, хоча в реальності ордер йде всередині бару. Друга: просковзування, комісії та ліквідність стакана в моделі не враховувалися взагалі.
Третя: тікові ряди приходили з різними часовими поясами та пропусками, а сховище на ClickHouse не перевіряло їхню неперервність.
Що змінили
Переписали рушій подій: бар розбирається по кроках, сигнал рахується тільки на даних, доступних на цей момент. Додали модель просковзування та комісій за фактичними умовами виконання, снапшоти стакана — щоб обсяг угоди не рухав ціну в тесті сильніше, ніж у житті.
Зібрали модуль звірки угод: сигнал, відправлений ордер і факт виконання зв'язуються за ідентифікатором, розходження підсвічується автоматично.
Стало: розходження тесту та реальної торгівлі вклалося в 1-2% за підсумком дня, ручна звірка угод скоротилася з двох днів до 15 хвилин на звіт.
Стратегії, які на старому рушії виглядали прибутковими за рахунок помилок виконання, тепер відсіюються до запуску — цей клас «гарних» відмов пішов.
Чим відрізняється бектестинг від форвард-тесту на демо-рахунку?
Бектестинг проганяє стратегію за історичними даними: угоди рахуються на вже відомих цінах, тому результат виходить за хвилини, а не за тижні.
Форвард-тест працює за тим самим кодом, але на живому потоці котирувань — заявки проходять реальні перевірки, а виконання залежить від поточної ліквідності. Це і є відмінність форвард-тесту: він перевіряє не логіку сигналу, а її стик з ринком.
Тестування на демо-рахунку вразливе до підгонки: якщо перебирати параметри по одному й тому ж відрізку історії, знаходиться набір, який ідеально працював у минулому й ламається на нових даних. Форвард так підігнати не можна — майбутні котирування невідомі.
Але в нього своя ціна: щоб набрати значущу кількість угод, потрібні тижні, а на повільних стратегіях — місяці.
Тому питання «бектестинг чи форвард-тест» зазвичай не ставиться як вибір одного. Ми будуємо обидва режими на спільному ядрі виконання — та ж логіка заявок, той самий розрахунок комісій, просковзування та ставок фінансування.
Інакше сам перехід з історії в живий потік змінює результат, і порівнювати прогони безглуздо. Вибір способу перевірки залежить від частоти стратегії: для внутрішньоденних спочатку довга історія, потім короткий форвард; для позиційних — навпаки.
Практичний критерій готовності — розходження метрик. Якщо дохідність і просадка у форварді тримаються в межах того, що показує бектест з урахуванням витрат, стратегію можна випускати в торгівлю.
Систематичне відхилення — сигнал, що в історії чогось не хватало: неповних даних, відсутності просковзування або режиму ринку, який більше не повторюється.
Часті сумніви: дані, затримки, ліквідність, перенавчання
Сумніви інженерів зводяться до одного: чи відтвориться результат тесту на реальному рахунку. Розбираємо чотири теми, які спливають до старту робіт.
Звідки беруться історичні дані та як перевіряється їхня якість?
Зводимо угоди та свічки за потрібними парами й біржами, помічаємо пропуски, дублікати та аномальні сплески. Окремо прибираємо помилку вижившего: пари, що пішли з біржі, залишаються у вибірці — інакше тест завищує дохідність.
Стратегія не перенавчиться під історію?
Навчаємо на одному відрізку часу, перевіряємо на наступному, якого модель не бачила. Обмежуємо кількість параметрів і проганяємо на різних режимах ринку — тренд, боковик, різкий провал.
Результат, який тримається на одному наборі налаштувань, — це перенавчання, і ми скажемо про нього до запуску.
Чи враховуються ліквідність і затримка виконання?
У тест закладаємо спред, комісії, просковзування та затримку між сигналом і виконанням, обсяг заявки звіряємо з доступною ліквідністю. Стратегія, прибуткова тільки при миттєвому вході за ціною закриття, відсіюється тут.
Як зрозуміти, що тест збігається з реальним виконанням?
Звіряємо розрахункові угоди з фактичними за часом, ціною, обсягом і комісією. Розходження розбираємо до причини: дані, модель виконання або логіка стратегії. Журнал звірки залишається у замовника.
Обговоримо задачу і повернемося з оцінкою та планом робіт
Щоб розмова про оцінку проєкту платформи була предметною, надішліть опис задачі у вільній формі: ринки та інструменти, частота сигналів, горизонт утримання позиції, потрібні режими перевірки. Цього достатньо, щоб зрозуміти клас навантаження та контур рішення.
Мінімальний набір для старту:
- Формулювання двох-трьох стратегій — правилами входу та виходу: за якою величиною рахується сигнал, де ставиться стоп, як розподіляється розмір позиції.
- Джерела історичних котирувань: біржові вивантаження, свої архіви або агрегатори, глибина історії та частота свічок.
- Вимоги до реалізму розрахунку: комісії, просковзування, обмеження ліквідності, затримка виконання.
- Метрики рішення: дохідність з поправкою на ризик, просадка, частка прибуткових угод, поведінка на відкладеному відрізку.
- Сценарії перевірки: прогін за відкладеним періодом, стрес на волатильних ділянках, порівняння з пасивною тактикою.
- Ролі та доступи: хто запускає прогони, хто бачить результати, чи потрібна ізоляція команд між собою.
- Обмеження щодо інфраструктури та термінів: де розміщуємо, які обсяги даних тримаємо, до якої дати потрібен робочий контур.
Після обговорення задачі повертаємося з планом робіт: склад модулів завантаження даних, рушія прогонів і звітності, черговість, точки здачі та оцінка діапазоном.
Чим раніше прийдуть матеріали, тим менше уточнень на старті — зазвичай достатньо одного дзвінка та списку вище, щоб зафіксувати етапи й підготуватися до запуску.
