Backtrader інтеграція: де розходяться тест і жива торгівля
Розбіжність бектесту й торгівлі майже ніколи не пов’язана з помилкою в логіці стратегії. Стратегія бачить закриття бару, ухвалює рішення і в тесті одразу отримує виконання за цією ж ціною.
На живому рахунку між сигналом і виставленням заявки є затримка, а між виставленням і виконанням — рух ринку, якого в історії не було.
Друге джерело — дані. Історичний бар зводить інтервал до чотирьох чисел: відкриття, максимум, мінімум, закриття. За ними не можна визначити, чи стояла на рівні заявка і чи був за нею реальний обсяг.
Тест вважає угоду виконаною на торканні ціни, жива торгівля залишає її невиконаною: перед вами пройшов великий ліміт.
Третє — модель виконання. За замовчуванням заявка закривається повністю за однією ціною, тоді як реальний стакан розбиває її на частини, і середня ціна відрізняється від сигнальної.
Це і є прослизання: на ліквідних інструментах воно непомітне, на тонких — перетворює рівну прибуткову криву на збиткову.
Поки всі три фактори приховані в допущеннях за замовчуванням, результат на історії нічого не говорить про результат на рахунку.
Інтеграція Backtrader цінна саме тут: той самий код запускається і на історії, і в живій торгівлі, а прослизання, комісія та правила виконання заявок задаються явно і перевіряються на тих самих даних. Розбираємо, як це закривається.
Що змінюється в результатах після переведення стратегії в живий контур
Контрольні прогони на тому самому зрізі даних дають збіжний результат — не «приблизно схожий», а такий, що сходиться до окремої угоди.
Це перше, що змінюється після коректної інтеграції: фіксуються порядок обробки барів, модель виконання й джерело котирувань, тому повторний запуск не приносить сюрпризів.
Затримка виконання перестає бути допущенням. Заявка в живому контурі проходить через адаптер брокера, підтверджується не миттєво і може виконатися частинами — модель виконання це враховує, і частка відхилених угод падає з п’ятнадцяти-двадцяти відсотків до поодиноких випадків.
Стійкість стратегії перевіряється на різних ринкових режимах — тренд, боковик, висока волатильність — і на суміжних періодах, які не брали участі в налаштуванні.
Якщо параметри підібрані під одну ділянку історії, на інших просідання зростає в рази; після перевірки видно, які налаштування тримають форму, а які просто підігнані.
Відтворюваність результатів тримається на звірці: журнал угод із живого контуру та з тестового зіставляється за часом входу й виходу. Розбіжність метрик понад два відсотки блокує випуск — це ознака помилки в інтеграції, а не «іншого ринку».
Інтеграцію ведемо на Backtrader: той самий код стратегії працює і на історії, і в живому контурі, тому розбіжність пояснюється моделлю виконання, а не різною логікою.
На виході — числа, за які можна відповідати: скільки заявок не дійшло, як поводиться стратегія при зміні режиму, чи збігаються контрольні прогони.
Режими підключення: архів даних, потоковий тест, живий рахунок
Та сама стратегія на Backtrader запускається в трьох режимах: прогін по архіву, потоковий тест на живих котируваннях і робота на живому рахунку. Саме тому такий контур і обирають — логіку не переписують під час переходу від перевірки гіпотези до реальних заявок.
Але однаковий код не означає однакову поведінку: у кожному режимі змінюються джерело даних, момент виставлення заявки та модель її виконання, і саме ці відмінності дають розбіжності в результатах.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Архів даних | Перебір гіпотез, оптимізація параметрів, прогін по довгій історії | Немає затримок і часткових виконань: заявка закривається за ціною бару — ідеалізація, якої на майданчику не буває |
| Потоковий тест | Перевірка логіки на живому потоці без ризику: котирування йдуть у реальному часі, ордери не виводяться назовні | Затримки й прослизання лише модельні, розбіжність із реальним виконанням залишається |
| Живий рахунок | Реальні заявки та підтвердження від майданчика | Відмови, відхилені ордери, обриви зв’язку; потрібні ідемпотентність заявок і відновлення позиції після рестарту |
Ми проганяємо стратегію через усі три режими на одному наборі інструментів і одному періоді та порівнюємо криві дохідності.
Якщо потоковий і живий результати розходяться з архівним сильніше, ніж допускає логіка стратегії, причина майже завжди в моделі виконання — її правлять до того, як у контур потраплять реальні кошти. Окремо перевіряємо обрив з’єднання та коректність відновлення стану позиції на тому самому коді.
Порядок робіт: від аудиту стратегії до передачі контуру
Порядок кроків фіксуємо до старту робіт: він закриває головний ризик — розбіжність результатів бектесту й торгівлі на реальному рахунку. Причина зазвичай не в логіці стратегії, а в різниці даних, комісій, прослизання та моменту виконання заявки в тесті й у робочому контурі.
- Аудит стратегії та даних. Розбираємо логіку входів і виходів, перевіряємо історичні ряди на пропуски, дублі та заглядання в майбутнє, узгоджуємо цільові метрики.
- Схема контуру. Визначаємо склад компонентів, потоки даних, точки відмови та поведінку при обриві зв’язку — до написання коду.
- Налаштування середовища. Збираємо ізольоване середовище із зафіксованими залежностями, щоб прогін на іншому стенді давав той самий результат.
- Контрольні прогони. Проганяємо стратегію на історичній ділянці й паралельно на тестовому рахунку, звіряємо угоди, час входу та підсумкові метрики.
- Приймання. Порівнюємо результат із допусками, узгодженими на аудиті; розбіжності розбираємо до передачі, а не після запуску.
- Передача контуру. Віддаємо конфігурації Backtrader, схеми, регламент запуску й відновлення, документацію та доступи.
- Навчання й супровід. Показуємо, як змінювати параметри, читати звіти та штатно зупиняти контур, і залишаємося на зв’язку щодо інцидентів.
Кожен етап закінчується артефактом, який можна перевірити: звіт по даних, схема, конфігурація, протокол прогонів, підписаний лист приймання.
Конфігурації, журнали та регламенти, які залишаються у вас
Передаємо не набір скриптів, а відтворюваний торговий контур: ті самі конфігурації, ті самі дані, ті самі журнали прогонів, на яких отримано цифри у звіті.
Ваша команда розгортає його на своїй стороні та отримує збіжні результати — без доступу до нашого середовища й без уточнювальних листів. Нижче — що саме фіксується в передачі.
- Конфігурації стратегій і джерел даних: таймфрейми, склад інструментів, комісії та модель прослизання, параметри ризику. Один файл — один прогін, без правок «з пам’яті».
- Схема контуру: які компоненти беруть участь, де зберігаються дані, чим технічно розділені тестовий прогін і бойовий запуск, у якій точці сходяться сигнали брокера.
- Журнали прогонів: сирі записи щодо кожної угоди, крива капіталу, зведення щодо просідань і дохідності. Будь-яку цифру зі звіту можна розгорнути до конкретної угоди.
- Регламенти: що робити при розбіжності тестового й бойового результату, як зупиняється стратегія, як відкочується на попередню конфігурацію, кому надходить оповіщення.
- Правила доступу: де зберігаються ключі та облікові дані, хто ними користується, як проходить ротація, чим обмежений бойовий контур у нештатній ситуації.
- Інструкції для команди: запуск і зупинка, додавання нового інструменту або стратегії, оновлення історичних даних, читання журналів.
- Чек-ліст приймання: набір перевірок, які ваша сторона проганяє самостійно та підтверджує відтворюваність на своїх даних.
Документація оновлюється разом із кодом — при зміні логіки входів або моделі витрат правки до регламентів вносимо ми, а далі це робите ви за описаним порядком. Опишіть задачу — повернемося з оцінкою та планом передачі.
Кейс: як скоротили розбіжність між тестом і торгівлею
Клієнт — команда алгоритмічної торгівлі. Стратегія на історичних даних показувала стійке зростання, але на реальному рахунку результат відрізнявся настільки, що рішення доводилося ухвалювати заново.
Корінь був не в логіці стратегії, а в контурі: тестовий прогін і бойове виконання жили в різних реалізаціях, тому розбіжність накопичувалася ще до першої угоди.
Що було до інтеграції
Заміри до робіт: підсумкова дохідність тесту й реальної торгівлі розходилися на 30–40%, а на окремих періодах знак результату змінювався на протилежний.
Причини — ідеалізоване виконання заявок, відсутність прослизання, різний набір історичних даних і продубльована логіка сигналів у двох місцях.
Що перебудували в контурі
Ми звели тест і торгівлю до одного ядра розрахунку сигналів на Backtrader, додали модель виконання із затримкою та прослизанням, привели потік котирувань і корпоративні події до єдиного джерела та ввімкнули журналювання кожного рішення з параметрами на вході.
Після цього розбіжність підсумкових метрик скоротилася до 4–6%, частка угод із нез’ясовним відхиленням — з 18% до 1–2%. Прогін річної історії прискорився вдвічі завдяки кешу даних, а перенесення стратегії в бойовий режим займає години замість днів.
Чим відрізняється прогін на історії від торгівлі на живому рахунку?
Історичний прогін і живий рахунок — два різних режими виконання однієї стратегії. У тестовому контурі свічка вже закрита, а ціна угоди відома заздалегідь; на живому рахунку рішення ухвалюється за неповними даними, і між сигналом і підтвердженням минає час. Звідси й головне джерело розбіжностей — затримки виконання.
Зводимо відмінності за трьома осями: дані, виконання й контроль позиції.
| Що порівнюємо | Історичний прогін | Живий рахунок |
|---|---|---|
| Дані | закриті бари, історія без пропусків | потік цін із паузами та затримкою публікації |
| Виконання | миттєво за ціною бару | заявка в черзі, часткове наповнення, прослизання |
| Стан позиції | із журналу угод | звірка зі звітом брокера, можливі розбіжності |
| Повторюваність | повна, прогін відтворюється | залежить від моменту й ліквідності ринку |
Відмінності режимів перевіряються на одному коді: Backtrader запускає ту саму стратегію і на історії, і на живому рахунку — змінюються джерело даних і брокерський інтерфейс, а логіка залишається. Це знімає головний ризик: розбіжність між тим, що тестували, і тим, що реально торгує.
Окремо варто відзначити контроль стану: після обриву зв’язку або відхиленої заявки позиція на рахунку може розійтися з локальним журналом. Тому в контур додають звірку зі звітом брокера, захист від дублів при повторному надсиланні заявок і журнал для розбору інцидентів.
Чим раніше в тестовому контурі з’являються штучні затримки та часткові наповнення, тим менше сюрпризів на живому рахунку.
Технічні сумніви, які варто зняти до старту
Частина питань повторюється майже в кожній інтеграції Backtrader — вони про те, де закінчується гарна крива на графіку й починається поведінка, яка відтворюється на реальному рахунку. Нижче — відповіді на ті, що найчастіше виринають на етапі оцінки.
Як у розрахунок потрапляють комісії та прослизання?
Комісія задається моделлю брокера й списується за кожною угодою окремо, а не віднімається один раз з підсумкової кривої. Прослизання описується як частка від ціни виконання або фіксований крок: заявка закривається за ціною наступного бару, а не за закриттям сигнального.
Через це стратегії на частих угодах втрачають помітну частину результату — і це видно до запуску, а не після перших тижнів торгівлі.
У нас своє джерело даних — його можна підключити?
Так. Свій потік котирувань описується як джерело з приведенням до єдиного формату: часовий пояс, пропущені інтервали, коригування на спліти й дивіденди. Це не формальність — розриви в історії та дублікати барів дають хибні сигнали на вхід і завищену дохідність у звіті.
Як зрозуміти, що стратегія стійка, а не підігнана під історію?
Прогін іде не на одному відрізку, а на кількох ринкових режимах: тренд, боковик, різкі рухи без продовження. Дивимося, як поводяться просідання та частка прибуткових угод при зсуві періоду перевірки.
Якщо показники тримаються — логіка переносима на реальний рахунок; якщо розсипається, вузьке місце знаходиться на етапі тестів.
Backtrader інтеграція: обговоримо ваш контур і повернемося з оцінкою
Щоб Backtrader інтеграція спиралася на реальні умови, а не на допущення, нам потрібен погляд усередину вашого торгового контуру: як зараз запускаються стратегії, звідки беруться дані й куди надходять заявки.
Чим повніші вхідні дані, тим менше припущень у плані робіт і тим точніші строки. Стартовий набір від вашої команди зазвичай такий:
- репозиторій зі стратегіями та правила їх запуску — що вже автоматизовано, а що робиться вручну;
- вивантаження історичних даних: таймфрейм, глибина, урахування комісій, прослизання та корпоративних подій;
- перелік брокерів і майданчиків, де потрібна торгівля в реальному часі, зі способами доступу та лімітами;
- вимоги до ризику: обмеження позиції, денний збиток, поведінка при розриві зв’язку та повторному надсиланні заявки;
- опис інфраструктури: де буде розміщено контур, які є обмеження щодо мережі, доступів і розкладу роботи;
- відповідальний з вашого боку, хто підтверджує логіку стратегій і приймає результати звірки;
- еталонний приклад: угода або період, де розрахунок має збігтися до останньої цифри.
Обговорення займає одну зустріч по суті: розбираємо контур торгівлі, знімаємо неясні місця та фіксуємо межі робіт. Після цього ми повертаємося з оцінкою задачі та планом робіт — етапами, строками й точками приймання, де ви бачите результат на кожному кроці. Опишіть задачу — повернемося з розрахунком.
