Розробка системи бектестингу арбітражних стратегій під ключ

Бектестування арбітражних стратегій: де розрахунок розходиться з фактом

Крива дохідності на історії виглядає рівною: арбітражний спред між майданчиками стабільно додатний, просадки короткі й швидко відновлюються.

Той самий алгоритм на реальному контурі за місяць не відтворює жодної великої угоди — сигнал надходить, а виконання за ціною, на якій будувався розрахунок, уже немає.

Причина майже завжди в трьох місцях. Історичні дані зібрані з різних джерел з різними мітками часу: там, де стрічка угод склеєна з оновленням стакана, з'являються ціни, яких не існувало, і такі помилки в історичних даних малюють прибуток, якого не було.

Далі — затримки котирувань: між отриманням сигналу й постановкою заявки спред встигає закритися, і це не ринковий шум, а систематичний мінус, не відображений у моделі.

Плюс неповна історія щодо інструментів: вихід з лістингу, зміна умов торгів, паузи майданчика випадають з вибірки, і стратегія тестується лише на тих, хто вижив.

Відтворюваність з'являється, коли бектестування арбітражних стратегій будується на єдиному знімку даних з однаковими правилами виконання, а розходження моделі та реальних угод вимірюється за кожною угодою, а не за підсумковою кривою.

Нижче розбираємо, як це закривається і як перевірка торгових гіпотез стає вимірюваною процедурою, а не суперечкою про гарний графік.

Що змінюється після впровадження коректного тестування стратегій

Коли історичні дані збирають вручну — вивантаженнями з бірж, з різними часовими поясами й форматами, — перевірка однієї гіпотези розтягується на тижні.

Гірше те, що результат не відтворюється: повторний прогін на «тій самій» вибірці розходиться з попереднім на 15–20%, і незрозуміло, змінилася стратегія чи дані.

Автоматизація тестування починається з конвеєра завантаження: снапшоти стакана й стрічки угод приводяться до єдиної схеми, дублі склеюються, пропуски позначаються.

На вході стоять перевірки якості — монотонність часу, аномальні спреди, розриви ліквідності, — і вікно з поганими даними в розрахунок не потрапляє. Прогін гіпотези займає години замість тижнів, а ручні вивантаження й перерахунок у таблицях зникають з процесу.

Відтворюваність тримається на специфікації прогону: версія нормалізованого набору ринкових даних Tardis, вікно, комісії, затримка виконання, глибина стакана, правила фільтрації аномалій.

Той самий набір з тією самою специфікацією дає той самий результат і через місяці — розходження між повторними розрахунками падає з відсотків до статистичного шуму.

Єдиний реєстр угод зберігає кожну змодельовану угоду з ідентифікатором прогону, версією даних, причиною входу й виходу.

Клас помилок, пов'язаних з ручним складанням даних — зсунуті мітки часу, загублені години, склеєні дублі, — перестає відтворюватися у звітах, а порівняння стратегій іде на одному зрізі ринку.

Режими перевірки гіпотез: порівняння підходів та обмежень

Арбітражна стратегія ламається об три речі: затримку між майданчиками, комісії та глибину стакана. Тому перевірка гіпотези на одній історії нічого не доводить — режими тестування стратегій відповідають на різні питання, і кожен має свої обмеження.

Жоден режим не дає повної картини — розходження між історією та реальними ордерами накопичується саме на затримках, часткових виконаннях і відмовах.

Тому вибудовуємо їх як послідовність з перевірюваним переходом: історія, потім живий потік, далі тестовий контур і лише після цього обмежений капітал.

Етапи впровадження: від розбору даних до передачі стенда

Етапи впровадження стенда вибудовуємо так, щоб кожен завершувався перевірюваним артефактом, а не усним звітом. Замовник бачить, на якому кроці йде робота, і може поправити розрахункову логіку до того, як вона закріпиться в коді.

1. Аудит даних. Розбираємо джерела котирувань і стаканів: з якою частотою надходять записи, як поводяться ряди в моменти розривів зв'язку й перенесень торгових сесій. На виході — карта джерел з переліком прогалин, які доведеться відновлювати під час розрахунку.
2. Схема розрахунку. Фіксуємо модель виконання: затримку реакції, часткове виконання заявки, комісії та доступний обсяг на кожній стороні. Узгоджена схема стає еталоном, через який потім пояснюється будь-яке розходження.
3. Налаштування оточення. Збираємо стенд: сховище історичних даних, сервіс розрахунку, ізольовані задачі для тривалих прогонів і роздільне логування кожного кроку.
4. Прогін еталонних сценаріїв. Перевіряємо розрахунок на заздалегідь розмічених періодах із відомим результатом — так помилки в логіці випливають до того, як на стенд поставлять реальні стратегії.
5. Звірка з реальними угодами. Зіставляємо розрахунок з фактичними виконаннями за минулі періоди й розбираємо кожне розходження: частина виявиться помилкою моделі, частина — чесною особливістю ринку.
6. Приймання та передача. Проганяємо повний цикл на даних замовника, фіксуємо контрольні показники, передаємо документацію щодо схеми розрахунку й навчаємо команду працювати зі стендом самостійно.

Комплект постачання: конфігурації, схеми та регламенти

Комплект постачання — не архів з кодом, а документація, за якою систему можна розгорнути, прогнати й передати в експлуатацію без автора на зв'язку. Нижче перелічено, що саме опиняється в руках на момент здачі.

• Конфігурації оточення — версіоновані файли з параметрами підключень, лімітами запитів, таймаутами й перемикачем тестового та робочого контуру.
• Схеми інтеграцій — шлях ринкових даних від джерела до сховища, точки знімання стаканів і угод, правила нормалізації та вразливі місця, де можливі розриви стрічок.
• Політики доступу — ролі аналітика, оператора й розгортання, винесення ключів за межі репозиторію, ротація та заборона правок у робочому контурі.
• Регламенти експлуатації — порядок підготовки історичних даних, запуску прогону, відтворення результату й обліку комісій з прослизанням.
• Опис звітів — склад метрик (дохідність, просадка, оборот, частка виконаних сигналів), формат вивантаження й трактування показників.
• Реєстр відомих обмежень — де модель спрощує реальність: глибина історії, затримки, тонка ліквідність, часткові виконання.
• Інструкції з розгортання й відкату — підйом контуру з нуля та повернення до попередньої конфігурації.

Перевіряємо комплект ділом на прийманні: розгортаємо контур на чистій машині строго за інструкцією й повторюємо еталонний прогін. Розходження в метриках означає, що документація неповна — і це правиться до підписання, а не після.

Кейс: як скоротили розходження моделі та реальних угод

Де втрачалася точність

Стратегія будувалася на ручному зборі котирувань: дані з біржі та з пулів зводили в таблицях, комісії й прослизання враховували оціночно. Розходження розрахункової дохідності з фактичними угодами сягало 18–20%, а підготовка звіту за однією гіпотезою займала два-три дні.

Через це перевіряли одну-дві ідеї на місяць, і частина з них розвалювалася вже на реальному рахунку.

Що перебудували

Зібрали єдиний конвеєр: історія угод і стакани завантажуються пакетно, потім проганяються в тому самому порядку, що й у реальному часі, з урахуванням комісій, затримки виконання та глибини пулу.

Прогін став відтворюваним — за контрольною точкою з журналу його можна повторити й отримати ті самі цифри. Арбітраж між пулами на Uniswap і централізованою біржею вважався окремим сценарієм зі своїми допущеннями.

Що вийшло

Розходження розрахункового й фактичного результату скоротилося з 18–20% до 4–6%. Перевірка гіпотези займає 20–30 хвилин замість двох-трьох днів, ручних операцій у підготовці даних стало близько п'яти замість сорока. Звіт формується автоматично з журналу прогону.

Система стійка до збоїв: у разі обриву зв'язку з біржею незавершений крок піднімається з останньої контрольної точки, а не починається заново.

Чим відрізняється перевірка на історії від тесту в реальному часі?

Історична перевірка — це прогін стратегії за записаним потоком: знімками стакана, стрічками угод, комісіями та правилами біржі на той момент. Вона відповідає на базове питання — чи є в парі сигналів закономірність взагалі, — і робить це швидко та відтворювано. Будь-який арбітражний задум починається з історії, але нею не можна закінчуватися.

Історія переоцінює майже завжди. Головна причина — перенавчання моделі: коли параметрів входу й виходу багато, а відрізок один, підгонка ловить шум конкретного тижня замість спреду, і на наступній ділянці результат обнулюється.

Друге джерело оптимізму — ідеальні умови прогону: миттєве виконання за найкращою ціною, повний обсяг і відсутність інших учасників, які закривають ту саму можливість.

У живому контурі додаються затримки даних. У прогоні сигнал і заявка живуть в одному знімку стакана, а на ринку між оновленням котирування, розрахунком і постановкою ордера минають частки секунди — за них спред зазвичай зникає.

Чим тонша можливість, тим сильніше розходження, тому перевіряти модель потрібно на затримках, знятих з реального каналу, а не на нульових.

Перехідний крок — тестовий контур без грошей: той самий живий потік і той самий код рішень, але ордери не виставляються, а пишуться в журнал з розрахунковою ціною заповнення.

Порівняння живого й історичного результату показує, яку частку можливості з'їдають затримки, комісії та прослизання. Якщо розходження в рази, справа не в ринку, а в моделі: її спрощують, скорочують число параметрів і перевіряють на кількох незалежних відрізках.

Технічні сумніви: дані, затримки, відтворюваність

Сумніви щодо бектестування арбітражних стратегій зводяться до одного: чи збіжиться розрахунок з реальними торгами. Розрахунок на історії не обіцяє прибуток — він показує, за яких умов стратегія працює і де ламається. Нижче — питання, які ставлять найчастіше.

Як зрозуміти, що модель не перенавчена?

Проганяємо стратегію на ділянці історії, якої вона не бачила, і дивимося результат у ковзному вікні, а не на одному вдалому відрізку. Просадку на перевірному періоді показуємо окремо.

Як враховуються затримки котирувань?

Розрахунок іде за часом, коли дані дійшли до системи, а не за часом угоди на біржі. Додаємо затримку каналу й дивимося, чи залишається арбітраж прибутковим за найгіршого виконання.

Чи буде розрахунок відтворюваним?

Так: фіксуємо зріз даних, склад інструментів і параметри розрахунку, тому повторний прогін дає той самий звіт — версії стратегії можна порівнювати між собою.

Чи можна перевірити стратегію до торгів і що залишається після передачі?

Так — прогін на живих котируваннях без виведення коштів показує розходження розрахунку з ринком. Після передачі залишаються конфігурації, звіти й порядок повторного запуску, супровід закриває зміни умов торгів.

Обговоримо задачу: з чого почати перевірку торгових гіпотез

Щоб бектест відповідав на питання «чи спрацює стратегія», а не підганяв криву під історію, на вході потрібні конкретні вхідні дані.

На обговоренні задачі уточнюємо: які біржі та ринки в контурі, які типи арбітражу цікавлять — міжбіржовий, фандинговий, трикутний, — як враховувати комісії, затримки виконання й глибину стакана, яка історія угод і стаканів доступна за потрібний період.

Від цих відповідей залежить логіка симулятора й набір метрик. Далі повертаємося з оцінкою та планом робіт: розкладаємо задачу на етапи й проговорюємо залежності — наприклад, якщо історія стаканів неповна, частину сценаріїв доведеться збирати з власного архіву.

• Обговорення задачі: гіпотеза, ринки, горизонт і частота сигналів — ви даєте вхідні дані, ми оцінюємо, чи вистачає даних для чесного прогону.
• Оцінка та план робіт: етапи, залежності, що постачаєте ви — доступи й історію, що робимо ми.
• Пілотний контур: один-два ринки й вузький набір пар, перевірка збіжності даних, комісій і логіки сигналів.
• Склад робіт: модуль прогону стратегій, облік комісій і затримок, звітність за метриками, відтворюваність кожного прогону.
• Старт проєкту: конфігурації, розмежування доступів, регламент приймання, фіксація еталонних прогонів.
• Передача: код, схеми даних і документація — команда запускає та змінює стратегії без нас.

Опишіть задачу в загальних рисах — повернемося з оцінкою та планом робіт, строками й межами пілотного контуру.