Кастомний фреймворк бектестингу: де ламаються нестандартні стратегії
Стандартні системи тестування розраховані на стратегії вигляду «сигнал — вхід — фіксований стоп і тейк». Нестандартні стратегії так не описуються: вхід залежить від збігу умов за кількома джерелами, вихід іде етапами, рішення спирається на стан портфеля.
Готовий інструмент тестування підміняє таку логіку своєю моделлю, і викривлення результатів тестування спливає вже на живих угодах.
Перший розрив — умови входу: подія вимагає одночасного виконання правил за різними інструментами та періодами, а стандартний рушій зводить їх до одного закриття свічки. Заявка в моделі стає не там, де стала б у реальному потоці, і на довгій серії угод різниця накопичується.
Другий — багатоетапний вихід. Часткове закриття, перенесення захисного рівня за ціною, повторний вхід на відкаті: типовий шаблон закриває позицію повністю за одним правилом. У тесті стратегія виглядає прибутковою саме тому, що її справжня логіка виходу не виконувалася.
Третій — порядок виконання заявок. На сплеску волатильності кілька заявок претендують на одну ціну, і те, яка оброблена першою, змінює результат сильніше за сам сигнал.
Синтетичний потік згладжує просадки, а рідкісні події — розриви, зупинки торгів, аномальні спреди — не відтворюються взагалі.
Зібрати кастомний фреймворк бектестингу — означає перенести в модель вашу логіку повністю, разом із чергою заявок і рідкісними сценаріями. Далі розбираємо, як це закривається за етапами.
Що дає окремий тестовий контур: вимірювані ефекти
Прогоняти гіпотези на живому контурі дорого: помилка стає видною лише за просадкою, а кожна перевірка витрачає реальні кошти.
Окремий тестовий контур переносить перевірку на історичні дані — гіпотеза відсіюється до того, як у справу підуть гроші, а результат прогону порівнюється з попередніми запусками.
Швидкість прогону набору стратегій
На кастомному фреймворку бектестингу набір із 200–300 конфігурацій стратегії проходить за ніч, тоді як послідовний прогін тих самих конфігурацій розтягується на тиждень — прискорення у 8–12 разів.
Досягається воно розпаралелюванням за зрізами даних і повторним використанням порахованого стану: при зміні лише правила виходу історія заново не перераховується.
Відтворюваність і контроль ризиків
Кожен прогін прив’язаний до зафіксованого зрізу даних і збереженої конфігурації, тому результат відтворюється і через місяць, і після правок коду: розбіжність між запусками — частки відсотка, і видно її порядково в журналі.
Так зникає цілий клас відмов — розбіжність результатів за однакових вхідних даних і тиха підміна джерела котирувань між запусками.
Підглядання вперед, тобто розрахунок на даних, яких у реальному часі ще не було, відсікається окремою перевіркою.
Котирування звіряються з історією оракульних цін Chainlink, а стратегія додатково йде за граничними зрізами: розрив ліквідності, стрибок мережевих комісій, зупинка джерела даних. Те, що виживає на них, іде в реальний контур із заздалегідь зрозумілою ціною ризику.
Варіанти реалізації каркаса бектестингу: порівняння підходів
Вибір між готовим продуктом і своїм каркасом визначає не швидкість запуску, а те, які стратегії ви взагалі зможете перевірити. Поки логіка тримається на стандартних індикаторах, достатньо готової бібліотеки.
Як тільки з’являються дані різних інтервалів, черга ордерів або нестандартний ризик-контур, починається обв’язка навколо чужого коду.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готовий каркас як є | Стратегії на стандартних індикаторах, швидка перевірка гіпотез | Модель виконання вшита в ядро, нестандартні правила підганяються під чужу логіку |
| Допрацювання готового рішення | Потрібен вузький шар: своє джерело даних, нестандартний розрахунок комісій | Правки губляться при оновленні, тести ядра не покривають вашу логіку |
| Власний шар перевірки поверх готового | Сигнали свої, а облік угод і портфеля влаштовує | Дві моделі даних треба синхронізувати, розбіжність у розрахунку позиції видно на реальному рахунку |
| Повністю власний каркас | Унікальна логіка виконання, вимоги до відтворюваності й аудиту | Довше й дорожче на старті, потрібні тести та еталонні набори даних |
Обмеження готових рішень
Головне обмеження — не продуктивність, а вшита модель світу: порядок подій, тип даних, спосіб обліку прослизання й комісій. Усе, що виходить за ці рамки, обходиться костилями, а розбіжність перевірки з реальним виконанням спливає вже після запуску.
Коли потрібен власний шар
Власний шар виправданий, коли стратегія спирається на дані поза типовою моделлю: стакан, позабіржові котирування, зовнішні сигнали, ручні втручання.
Гібридний варіант — компроміс: облік угод і портфеля бере на себе готове ядро, а логіка сигналів залишається вашою і тестується окремо.
Етапи розробки: від розбору стратегій до приймання й передачі
Етапи розробки будуються навколо головного ризику: нестандартна стратегія ламає типові інструменти, тому перевіряти її потрібно на вашій логіці, а не на усередненій. Починаємо з розбору, а не з коду, і лише після узгодження моделі виконання переходимо до реалізації.
Розбір стратегій і даних
- Аудит стратегій. Фіксуємо логіку входу й виходу, набір інструментів, частоту ребалансування, роботу з плечем і правила управління ризиком. На виході — формалізований опис, який однозначно перевіряється розрахунком.
- Схема даних. Зводимо історичні ряди до єдиного формату: часові зони, пропуски, корпоративні події, делістинг. Окремо описуємо, чим заповнюємо діри, щоб це не створювало хибної дохідності.
- Проєктування контуру. Визначаємо модель виконання: тип ордерів, прослизання, комісії, затримку подання, часткові виконання. Саме тут найчастіше розходяться тест і реальна торгівля.
Реалізація, приймання й передача
- Налаштування ядра. Збираємо розрахункову частину під узгоджений контур і виносимо параметри стратегій у конфігурації — нова логіка підключається без переписування ядра.
- Перевірка. Прогоняємо контрольні сценарії та звіряємо результат із незалежним ручним розрахунком на короткому вікні: так помилки схеми даних і моделі виконання спливають до приймання.
- Приймання й передача. Прогін на вашій історії, звірка метрик, розбір розбіжностей, потім вихідні коди, документація, схема даних і навчання команди. Після передачі ви запускаєте нові стратегії самі.
Склад постачання: код, схеми даних, регламенти й звіти
Постачання за кастомним фреймворком бектестингу збирається так, щоб команда замовника далі вела розробку й прогони без нас: код — у вашому репозиторії, результати відтворюються на вашому контурі, рішення щодо доступів ухвалюєте ви. Нижче — склад постачання й те, чим воно закріплюється.
Документація й регламенти
- Вихідний код з історією змін і правами на використання, зі схемою збирання — без залежності від наших внутрішніх сервісів.
- Схеми даних: структури історичних котирувань і ончейн-подій, правила обробки корпоративних дій, точки очищення й обрізання датасетів.
- Регламент прогону: як фіксуються параметри, версії даних і конфігурації, щоб результат повторювався і через місяць, і після зміни складу команди.
- Звіти про верифікацію рушія на еталонних стратегіях: де розбіжності з очікуваним результатом і чим вони пояснюються.
- Інструкція з підключення нової стратегії: які модулі правити, як прогнати регрес і на які метрики дивитися під час приймання.
Права й доступи до контуру
- Матриця ролей: хто може змінювати ядро, хто — лише конфігурації та дані, хто — лише читати звіти прогонів.
- Порядок видачі й відкликання доступів, включно з нашими технічними обліковими записами: після здачі вони вимикаються на ваш запит.
- Розділення середовищ розробки й прогону, правила вивантаження даних за межі контуру та журналювання дій із ними.
Кейс із метриками: перевірка стратегії до й після
Клієнт — торгова команда з нестандартною логікою входу: ліквідність пулу на Uniswap, часткове закриття ступенями. Готові рушії вимагали переписати стратегію під їхню модель свічок, тому рішення ухвалювалися майже на око.
Контекст задачі
Перевірка однієї конфігурації займала близько чотирьох годин: рушій перераховував весь історичний ряд для кожного набору параметрів, а умови входу не вміщалися в його модель.
Перебирали три-чотири варіанти на день, рідкісні сценарії — сплески ліквідності, каскадні ліквідації — у перевірку не потрапляли. За підсумками кварталу 18% угод у бою не збігалися з бектестом.
Що змінилося в перевірці
Ми зібрали кастомний фреймворк бектестингу під логіку команди: власний шар опису стратегій, окреме сховище подій за блоками й перерахунок лише змінених ділянок замість усього ряду.
- Час прогону конфігурації — з чотирьох годин до 11 хвилин, перебір параметрів іде пакетно.
- Частка розбіжностей із бойовими угодами — з 18% до 3%: додано комісії, прослизання й затримки виконання.
- Просадка в бектесті й у бою сходиться в межах двох пунктів замість розбіжності втричі.
Перші ж прогони показали, що частина «робочих» конфігурацій тримається на одному вдалому періоді — тепер це видно до виведення коштів.
Що робити, якщо стратегія вже перевіряється в готовому рішенні?
Готове рішення й власний контур не конкурують — вони відповідають на різні питання. Готове рішення швидко показує, чи є в ідеї сигнал; власний контур показує, чи відтворюється цей сигнал на нашій інфраструктурі, з нашими комісіями й нашим профілем виконання заявок. Поки відповіді розходяться, стратегію рано віддавати в реальну торгівлю.
Починаємо з паралельної перевірки, а не з переписування. Один і той самий історичний відрізок, однакові правила входу й виходу, однакові комісії — обидві системи рахують метрики незалежно, і ми дивимося не на абсолютну дохідність, а на розбіжність за угодами.
Різниця в дохідності на бар одразу показує, де моделі розходяться: облік прослизання, затримка заявки, обробка пропусків у даних або порядок розрахунку позиції.
Упровадження в поточний процес іде збоку й не зупиняє команду.
Готове рішення продовжує крутити поточні дослідження, власний контур підключається до тих самих вивантажень даних і складає результати в окреме сховище — спочатку на одній-двох стратегіях, із щоденним порівнянням звітів. Якщо контур падає або рахує довше, дослідницький процес цього не помічає.
Перехід на власний контур — не одномоментний, а за критерієм. Вважаємо його завершеним, коли на вибраному історичному вікні й на кількох режимах ринку розбіжність із готовим рішенням укладається в обумовлений допуск, а повторний прогін дає той самий результат.
Після цього готове рішення залишається швидким чорновим фільтром, а спірні стратегії перевіряються лише в кастомному фреймворку бектестингу.
Часті технічні сумніви перед стартом робіт
Сумніви на старті зазвичай одні й ті самі: чи збігається модель виконання з реальною торгівлею, як кастомний фреймворк бектестингу вбудується у вже написані стратегії та що буде після передачі. Нижче — відповіді за кожним пунктом.
Наскільки точна модель виконання?
Рахуємо не за ціною закриття свічки, а за тим, як заявка реально потрапить у стакан: тип ордера, момент відправлення, доступна глибина.
Прослизання, затримка й комісії — параметри, а не вшиті константи: модель калібрується за вашою історією угод і звіряється з фактичним результатом.
Стратегії доведеться переписувати?
Ні. Фреймворк дає інтерфейс: ви віддаєте сигнали й правила управління позицією, ядро бере на себе виконання, облік комісій і розрахунок метрик. Логіка з проду переноситься точково й звіряється на відрізку, де відомий фактичний підсумок.
Можна рахувати на своїх даних і своїх джерелах?
Так. Підключаємо вашу історію — котирування, стакан, угоди — і за потреби потік у реальному часі. Якщо дані неповні, фіксуємо це у звіті: краще бачити, де розрахунок спирається на припущення, ніж отримати гладку криву без пояснення.
Що після передачі — залишимося самі?
Передаємо код, конфігурації та розрахункові сценарії з описом: як запустити, відтворити результат, додати новий інструмент. Супровід після передачі — окремий етап: розбираємо запуск із вашою командою та усуваємо знайдене.
Як потім вносити правки й доопрацювання?
Через той самий контур: нова модель виконання, метрика або джерело даних додаються окремим модулем, не ламаючи перевірені розрахунки. Конфігурації версіонуються — результат до й після правки порівнянний, відкат можливий.
Обговоримо задачу: які дані потрібні для оцінки та плану
Оцінка такого проєкту спирається не на загальний опис стратегії, а на її обчислювальний профіль: скільки інструментів у зрізі, як часто ухвалюються рішення, які дані потрібні на кожному кроці.
Тому в обговоренні задачі ми спочатку збираємо ввідні — за ними видно трудомісткість і чи достатньо доопрацювання наявного середовища тестування або потрібен окремий контур.
Що надсилаєте для оцінки та плану робіт:
- Логіка стратегії: правила входу й виходу, умови фільтрації, ручні виключення та випадки, де рішення ухвалює людина.
- Дані: джерела історії, глибина й періодичність, формат файлів, чи є стакани заявок і стрічка угод, а не лише бари.
- Модель виконання: як враховувати комісії, прослизання, затримку подання та часткове заповнення заявок.
- Перевірка на стійкість: як ділиться історія на навчальну й перевірочну ділянки, за якими метриками відбраковуємо результат.
- Набір звітності: які показники та графіки потрібні на виході, у якому вигляді й куди віддаються.
- Обмеження: доступи до даних, вимоги інфраструктури, режим повторних прогонів і правила відтворюваності результату.
- Що вже є: поточний стек тестування, минулі реалізації, вузькі місця, які заважають зараз.
Надішліть те, що є, у будь-якому робочому вигляді — чернетку специфікації, скрипти, вивантаження угод. Розберемо, поставимо уточнювальні запитання щодо моделі виконання й повернемося з оцінкою термінів і планом робіт за етапами.
