Розробка системи бектестингу: де ламаються портфельні криптостратегії
Розробка системи бектестингу починається не з коду, а з чесної відповіді на питання: чому бектест портфеля показує зростання, а реальний рахунок — просадку. Типова причина — модель виконання.
У тестуванні криптостратегій угода закривається за ціною зі свічки, а в реальності ордер проходить за кількома рівнями стакана, і на тонких парах прослизання в бектесті з'їдає весь прибуток стратегії. Якщо цього не закласти в рушій, результат гарної кривої не має відношення до торгівлі.
Друга група помилок бектестингу — комісії та затримки.
Мейкер-тейкер, ставка фінансування за ф'ючерсами, вартість виведення між біржами, лаг між сигналом і постановкою ордера: кожна з цих статей окремо виглядає дрібницею, але на портфелі з десятків інструментів і обороті в сотні угод на добу вони змінюють знак дохідності.
Портфельний бектест зобов'язаний рахувати їх на рівні кожної угоди, а не віднімати середній відсоток у кінці.
Третє вузьке місце — дані. Діри в історії, різні таймфрейми у джерел, делістинг і перейменування токенів, відсутність стакана за ранні періоди. Стратегія, яка «бачить» майбутню ціну через зсув свічок або заповнення пропусків, показує дохідність, недосяжну в реальності.
Тому коректний бектест портфеля будується на єдиному сховищі даних з явною політикою обробки пропусків і версіонуванням наборів.
Четвертий шар — портфельна логіка. Ребалансування, перетин сигналів за інструментами, ліміти на кореляцію та загальну експозицію, розподіл капіталу між стратегіями.
Помилка тут не в окремій угоді, а в тому, як стратегії конкурують за один і той самий капітал і одночасно відкривають позиції в один бік ринку.
Розбираємо, як це закривається: від архітектури рушія та моделі виконання до валідації на out-of-sample і звірки з реальними угодами.
Що дає коректна розробка системи бектестингу портфельних стратегій
Подієвий і векторний підхід: де проходить межа
Векторний бектест рахує дохідність за масивом цін за один прохід — прогін на кількох роках історії вкладається в секунди, і це зручно для первинного відбору гіпотез.
Обмеження проявляється на портфелі: просідання, ребалансування та часткові виконання заявок у такій моделі не відтворюються, тому результат годиться лише для відсіювання явно слабких стратегій.
Подієвий бектест обробляє потік ринкових подій по одній свічці або угоді, і кожен ордер проходить через модель виконання. Прогін довший, але саме він показує реальне просідання та поведінку стратегії на розривах ліквідності.
У нашій практиці портфель із десятків інструментів на кількох роках історії рахується за хвилини, а не години — завдяки попередньому завантаженню даних і розпаралелюванню за інструментами.
Відтворюваність як інженерна вимога
Кожен прогін фіксується: версія даних, набір параметрів, стан портфеля на старті. Повторний запуск із тими самими вхідними даними дає біт-у-біт збіжний звіт — розходження означає баг у моделі, а не «ринковий шум».
Це прибирає цілий клас помилок, коли стратегія виглядає прибутковою через підглядання в майбутнє або невірний облік комісій.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Векторний | Швидкий відбір гіпотез, одиночні інструменти | Не моделює просідання та чергу заявок |
| Подієвий | Портфель, ребалансування, оцінка ризику | Довший прогін, складніший у реалізації |
| Гібридний | Відбір на векторі, перевірка на подіях | Потребує узгодження моделей даних |
Метрики стратегії — дохідність, максимальне просідання, коефіцієнт Шарпа, оборот — рахуються на одному й тому самому рушії для всіх прогонів, тому результати порівнювані між собою.
Архітектура бектестера будується так, щоб тестована стратегія не знала, працює вона на історії чи на живих даних: один і той самий код іде в бій без переписування. Такий підхід лежить в основі Backtrader і споріднених фреймворків.
Як ми будуємо систему бектестингу: етапи інженерної роботи
Розробка системи бектестингу починається не з коду, а з аудиту даних і правил, за якими стратегія ухвалює рішення. На вході — вивантаження угод, котирування з кількох майданчиків, історія ребалансувань портфеля.
На виході — відтворюваний конвеєр, де кожна цифра у звіті пояснюється конкретним джерелом і налаштуванням симулятора.
- Аудит торгових даних. Звіряємо джерела котирувань, перевіряємо пропуски, дублі та розбіжності між майданчиками, приводимо часові зони й валюти до єдиного вигляду. Без цього кроку будь-яка метрика стратегії — випадкове число.
- Формалізація стратегії та портфельних правил. Фіксуємо логіку входів і виходів, розмір позиції, ліміти за інструментами та правила ребалансування. Спірні місця виносимо в явні параметри, а не в приховані припущення в коді.
- Налаштування симулятора виконання. Задаємо комісії, прослизання, затримку виконання та модель ліквідності. Симулятор має відтворювати реальні умови угоди, інакше результати на історії не переносяться на живий ринок.
- Впровадження бектестера та прогін на історії. Збираємо конвеєр розрахунку, запускаємо стратегію на історичних даних, рахуємо дохідність, просідання, оборот і розподіл угод за часом.
- Валідація стратегій. Перевіряємо стійкість результату: розбиття історії на періоди, тести на різних наборах інструментів, перевірка чутливості до параметрів. Стратегія, яка тримається лише на одному вдалому відрізку, відсіюється тут.
- Звірка з незалежним розрахунком. Порівнюємо ключові метрики з ручним перерахунком на вибірці угод — так ловимо помилки в логіці портфеля та обліку витрат.
- Передача системи. Розгортаємо конвеєр в інфраструктурі замовника, документуємо параметри, навчаємо команду запускати прогони та додавати нові стратегії самостійно.
Кожен етап закінчується артефактом: очищений набір даних, специфікація правил, конфігурація симулятора, звіт за прогоном. Це дозволяє повернутися на будь-який крок без перезбирання всього конвеєра. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Чим подієвий бектест відрізняється від векторного і коли що вибирати?
Векторний бектест рахує всю історію одним матричним проходом: сигнали, дохідності та ваги портфеля перемножуються масивами, позиції перераховуються синхронно на кожному барі.
Це дає швидкість — десятки тисяч прогонів параметрів за хвилини, що критично на етапі первинного відбору стратегій.
Обмеження в тому, що такий підхід передбачає ідеальне виконання: заявка завжди спрацьовує за ціною закриття, ліквідність нескінченна, а порядок подій усередині бару не важливий. Для стратегій на ліквідних інструментах із рідкісною ребалансировкою цього достатньо.
Подієвий бектест відтворює роботу системи покроково: надходить ринкова подія, стратегія реагує, заявка йде в симулятор виконання, портфель перераховується з урахуванням комісій, прослизання та часткового заповнення.
Тут коректно моделюються стоп-заявки, лімітки, внутрішньобарні спрацьовування та затримки між сигналом і виконанням. Ціна — час: один прогін може займати хвилини замість секунд, тому масовий перебір параметрів на ньому не роблять.
Вибір методу визначається типом стратегії, а не зручністю. Для моментум-портфелів, що ребалансуються раз на тиждень або місяць, векторний підхід дає ту саму картину дохідності, що й подієвий, але в рази швидше.
Для стратегій із частими входами, стопами та залежністю від мікроструктури ринку векторний бектест завищує результат: він «бачить» ціни, яких у реальному виконанні не було.
Практика — двоступенева. Спочатку векторний прогін відсікає явно слабкі конфігурації за широкою сіткою параметрів, потім фіналісти перевіряються подієвим рушієм із реалістичною моделлю витрат.
Розбіжність між двома результатами — сам по собі діагностичний сигнал: якщо подієва дохідність помітно нижча за векторну, стратегія живе за рахунок ідеального виконання, і в реальній торгівлі це не відтвориться.
У розробці системи бектестингу ми закладаємо обидва рушії на спільному шарі даних, щоб перехід між ними не вимагав переписувати логіку стратегії.
Кейс: як портфельна криптостратегія перестала розходитися з реальністю
Замовник прийшов із класичним болем: портфельна стратегія на історичних даних показувала рівне зростання, а на реальному рахунку результат розходився з бектестом на десятки відсотків.
Розбір показав три причини — облік комісій і прослизання за усередненою ставкою замість моделі за кожним інструментом, ребалансування за ціною закриття без затримки на виконання та підглядання в майбутнє під час розрахунку сигналів. Тобто розходження бектесту з торгівлею було не ринковою випадковістю, а дефектом самої моделі.
Ми переписали ядро прогону: свічки завантажуються за кожним інструментом окремо, комісія та прослизання рахуються на кожну угоду, сигнал формується лише на закритій свічці, а виконання зсунуто на наступний бар.
Додали журнал рішень — за кожною угодою видно, який сигнал її породив і які дані були доступні в той момент. Це перетворило оптимізацію стратегії з підбору гарних чисел на перевірку логіки.
Що змінилося в цифрах
| Метрика | До | Після |
|---|---|---|
| Розходження бектесту з торгівлею | 30–40% за дохідністю | у межах 3–5% |
| Час прогону портфеля | години на одну конфігурацію | хвилини, прогін у паралель |
| Знайдено помилок у логіці стратегії | не відстежувалося | 11 підтверджених дефектів |
| Відтворюваність результату | залежала від порядку запуску | детермінований прогін |
Окремо закрили відтворюваність: той самий набір даних і параметрів тепер дає ідентичний результат незалежно від порядку запуску та машини. Це те, без чого кейс бектестингу не має сенсу — якщо прогін не можна повторити, порівнювати конфігурації нема з чим.
VectorBT взяли як основу для векторизованого прогону — він дає швидкість на портфелі з десятків інструментів, а обв'язку під облік комісій і затримок виконання писали самі, бо типові налаштування не покривали потрібну модель угоди.
Сумісність, міграція та доступи: що обговорити до старту
Розробка системи бектестингу майже ніколи не починається з чистого аркуша: у замовника вже є біржові ключі, історичні котирування, внутрішні звіти за портфелями і, можливо, власні розрахунки в таблицях або скриптах.
Тому до старту важливо зафіксувати три речі: як система стане поруч із поточною інфраструктурою, яким шляхом переносяться накопичені дані та хто отримує доступ до торгових ключів.
Якщо це не проговорити заздалегідь, на етапі приймання виринають сюрпризи — розбіжність історичних даних із попередніми розрахунками, відсутність ролей в аналітиків або неможливість відкотити оновлення стратегії без зупинки всього контуру.
Що як у нас уже є свої розрахунки? Ми не ламаємо їх, а звіряємо: проганяємо еталонний набір угод через нову систему та стару логіку, розбіжності розбираємо до цифри. Що як знадобиться відкат?
Кожна версія конфігурації стратегії та набору даних версіонується, тому повернення до попереднього стану — це перемикання на зафіксовану версію, а не відновлення з резервної копії. Що з доступами?
Ключі до бірж зберігаються в захищеному сховищі, права роздаються за ролями: аналітик бачить дані та результати, але не може вивести кошти.
Чи можна впроваджувати поетапно, не зупиняючи поточну роботу?
Так. Спочатку піднімаємо контур на історичних даних у режимі читання, звіряємо результати з вашими еталонами, і тільки після цього підключаємо реальні джерела та торгові ключі. Поточні процеси на цей час не зачіпаються.
На руки після здачі замовник отримує:
- розгорнуту конфігурацію системи з описом усіх параметрів розрахунку;
- схему інтеграції з біржами та джерелами історичних даних;
- політику доступу та розмежування ролей, включно з роботою з торговими ключами;
- регламент міграції накопичених даних і звірки з попередніми розрахунками;
- інструкцію з відкату змін і повернення до попередньої версії стратегії;
- документацію з експлуатації: моніторинг, оновлення даних, реакція на збої.
Опишіть вашу задачу та поточний стек — повернемося з оцінкою, планом робіт і переліком даних, які знадобляться на старті.
Терміни впровадження системи бектестингу за етапами
Терміни залежать від трьох речей: скільки історичних джерел потрібно підключити, наскільки складна логіка ребалансувань і чи потрібно враховувати виконання угод із прослизанням і комісіями. Нижче — орієнтовний розклад за етапами для типової портфельної стратегії.
Межі етапів перетинаються: підготовка даних іде паралельно з проєктуванням ядра, щоб не втрачати тижні на очікуванні.
Що зсуває терміни вгору
Найчастіше джерело затримок — не код, а дані: біржові вивантаження приходять із розривами, різними таймзонами та заднім числом переписаною історією. Якщо стратегія торгує на кількох біржах, додається звірка цін між майданчиками та врахування розбіжностей.
Друга причина — складна логіка ребалансування: правила з порогами, обмеженнями за ліквідністю та частковим виконанням потребують окремого шару симуляції угод.
Що прискорює роботу
Коли замовник одразу дає доступ до історичних даних і описує правила входу-виходу формально, етап підготовки скорочується вдвічі. Готовий шар метрик і звітів перевикористовується між стратегіями — друга та наступні моделі проходять шлях помітно швидше за першу.
Backtrader — один із движків, на яких ми збираємо такі системи: він дає готову інфраструктуру прогону по історії, а ми дописуємо під задачу врахування витрат і звітність.
