Розробка звітів бектестингу: метрики Sharpe, просадка, P&L

Чому бектестинг розходиться з результатами реальної торгівлі

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

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

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

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

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

Третє — різні правила підрахунку метрик. Sharpe, drawdown і P&L рахують за денними дохідностями або за угодами, за закритими позиціями або за внутрішньоденною еквіті, з реінвестуванням або без, з урахуванням фінансування та дивідендів або у вакуумі.

Дві команди на одному наборі даних отримають різні цифри, і обидва звіти будуть формально правильні.

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

Що змінюється, коли метрики рахуються за єдиними правилами

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

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

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

Формати звітів бектестингу: порівняння підходів

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

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

Варіанти та їх обмеження

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

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

Порядок робіт: від постановки метрик до регулярного бектестингу

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

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

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

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

3. Налаштування розрахункового контуру. Сховище історії, довідник інструментів і сервіс, який збирає звіт на запит і за розкладом на одних і тих самих правилах.

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

5. Передача замовнику. Звіт з метриками, схема розрахунку та інструкція з читання — цифру можна захистити перед інвестором або ризик-комітетом.

6. Регламент регулярного запуску. Розклад перерахунку, версіонування конфігурацій та оповіщення про збій: результат не залежить від того, хто і коли запустив звіт.

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

Що передаємо на руки: схеми, правила розрахунку та регламенти

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

• Опис метрик і припущень — формули Sharpe, drawdown і P&L, вікно дохідності, базова ставка, що вважаємо безризиковою дохідністю і чому саме так.
• Схеми розрахунку — ланцюжок від сирих котирувань до підсумкової таблиці: де чистимо дані, де агрегуємо, на якому кроці з'являється кожна метрика.
• Правила обробки аномалій — пропуски в ряду, викиди, розриви в неторгові дні, корпоративні події: коли дані виключаються, коли інтерполюються і що потрапляє в журнал розрахунку.
• Інструкції із запуску — параметри середовища, порядок кроків, точка входу та очікуваний час перерахунку на історичному періоді.
• Регламент перевірки звіту — еталонний прогін, контрольні суми за метриками та перелік розходжень, які вважаються помилкою, а не нормою.
• Шаблони звітності — формат вивантаження, склад полів, періодичність і порядок передачі результатів у ризик-контроль та керівництву.
• Журнал змін методики — версія конфігурації до кожного звіту, щоб порівняння між періодами залишалося коректним.

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

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

До старту робіт метрики рахувалися в трьох місцях: дослідницький ноутбук, скрипти ризик-менеджменту та звірка бек-офісу.

Різні припущення щодо комісій і прослизання давали різні P&L на одних і тих самих угодах, а Sharpe і максимальна просадка відрізнялися залежно від того, чий розрахунок брали за основу.

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

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

Методику привели до вимог GIPS — розрахунок став відтворюваним: той самий вхід і та сама версія моделі дають той самий Sharpe, ту саму просадку і той самий P&L у будь-якого інженера команди.

Що змінили

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

Чому просадка у звіті менша, ніж у реальній торгівлі

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

Ті самі припущення завищують і коефіцієнт Шарпа, і частку прибуткових угод: чим м'якша модель витрат, тим рівніше виглядає крива прибутку та збитку.

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

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

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

Технічні сумніви щодо розрахунку метрик і звітності

Розрахунок метрик зазвичай ламається не на формулі коефіцієнта Шарпа, а на якості вхідних даних.

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

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

Нижче — інженерні питання, які найчастіше піднімаються до старту робіт.

Як часто перераховується звіт і наскільки це дорого?

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

Які метрики вважаються спірними і як знімається різночитання?

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

Розрахунок підключається до вже працюючого торгового контуру?

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

Обговоримо задачу та повернемося з оцінкою і планом розрахунків

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

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

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

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