Бектест, який ідеально відтворюється, може заслуговувати на меншу довіру, ніж той, чиї результати трохи коливаються. Повторюваність доводить, що ви можете двічі отримати ту саму відповідь; вона нічого не каже про те, чи не залежить ця відповідь від довільного знімка даних, особливості бібліотеки або прихованого значення за замовчуванням.
Звучить так, ніби це аргумент проти відтворюваності, але це не так. Зафіксуйте запуск, щоб можна було його пояснити. Потім навмисно змінюйте припущення, які не повинні визначати результат. Перший крок робить результат придатним до аудиту; другий показує, чи має він якесь значення.
Що насправді підтверджує відтворюваний бектест?
Якщо той самий код, дані, конфігурація та випадкове зерно дають ті самі угоди й метрики, ви усунули важливе джерело плутанини. «Покращення» агента можна порівняти з його батьківським запуском. Виправлення помилки можна відокремити від зміни тарифів. Колега може перевірити той самий журнал і побачити ті самі виконані угоди.
Але результат залежить від усього, що ви зафіксували. Уявіть криптовалютну стратегію, чий історичний файл містить 1-хвилинні бари. Ви зберігаєте хеш файлу, фіксуєте версію коду й отримуєте Sharpe 1.4 під час кожного повторного запуску. Якщо постачальник даних згодом скоригує кілька свічок, ця бездоганна відтворюваність і далі описуватиме старий файл. Вона не покаже, чи зберігається сигнал на скоригованих історичних даних і чи були ці свічки доступні в такому вигляді на той час.
Хеш корисний: він робить залежність видимою. Але він не доводить, що ця залежність нешкідлива.
Зафіксуйте запуск; перевірте висновок
Я волію розділяти два запитання. Чи можемо ми відтворити саме цей запуск? І чи зберігається висновок дослідження за розумних змін? Перше вимагає незмінного запису; друге — контрольованих змін по одній за раз.
| Що записати | Що змінити згодом | Що це може виявити |
|---|---|---|
| Версія сирих даних і контрольні суми | Редакція постачальника або друге джерело | Залежність від скоригованих або специфічних для постачальника значень |
| Коміт коду та версії пакетів | Чисельно еквівалентна реалізація | Чутливість до порядку обчислень, округлення або бібліотеки |
| Комісії, фандинг і припущення щодо виконання угод | Обґрунтований діапазон витрат | Чи потребує невелика перевага надзвичайно сприятливого виконання |
| Універсум і склад ринку на відповідний момент часу | Альтернативні правила включення ринків | Залежність від рішень про включення чи виключення |
Наприклад, припустімо, що стратегія на ф’ючерсах показує 8% річної надлишкової дохідності в базовому відтворенні. Запустіть її з витратами taker на 25% вищими, зсуньте фандинг до наступного зафіксованого розрахунку та по черзі вилучіть двох найбільших внесків у результат. Це не три способи покращити модель. Це перевірки: кожна з них з’ясовує, чи не визначає правдоподібна деталь головний результат.
Проводьте кожну перевірку окремо. Якщо одночасно змінити дані, тарифи й час виконання, погіршення результату мало що пояснить. А якщо перевірка неправдоподібна, позначте її як стрес-сценарій, а не подавайте як найімовірніший результат.
Не плутайте побайтову тотожність із числовою точністю
Деякі обчислення чутливі до порядку операцій. Додавання чисел із плаваючою комою не є асоціативним, тож підсумовування багатьох невеликих значень P&L в іншому порядку може змінити останні цифри. На точний результат також можуть вплинути паралельні обчислення, обладнання та версії бібліотек. Зазвичай це нешкідливо; іноді крихітна числова зміна перетинає поріг, змінює позицію і спрямовує решту симуляції іншим шляхом.
Тому я зберігав би і точні артефакти, і допуски для порівняння. Записуйте журнал угод, а не лише підсумковий Sharpe. Спершу порівнюйте рішення й грошові потоки, а потім — метрики в межах зазначеного допуску. Якщо різниця в один цент визначає, чи буде подано ордер, окремо перевірте цю межу.
Корисний запис запуску містить ідентифікатори даних і коду, конфігурацію, випадкове зерно, середовище виконання та достатньо проміжних результатів, щоб простежити метрику до виконаних угод і грошових потоків. Самої підсумкової оцінки недостатньо для відтворюваного дослідницького артефакту.
Коли варіація — це шум, а коли — результат
Не кожна зміна числа — привід для тривоги. Невелике коливання метрики через інший порядок підсумовування може не змінити угод. Зміну угоди біля порогового значення варто перевірити. Якщо стратегія втрачає більшу частину результату, коли один постачальник переглядає невеликий фрагмент історичних даних, це дещо говорить про її крихкість, навіть якщо початковий запуск досі ідеально відтворюється.
Критики перевірок стійкості мають рацію в одному: легко змінювати припущення, доки бажана стратегія не здаватиметься стійкою, або відкинути обґрунтований результат через те, що його руйнує якийсь навмисно екстремальний сценарій. Заздалегідь визначте правдоподібні зміни, наведіть повний набір результатів і розмежуйте звичайні альтернативи та стрес-сценарії. Потім збережіть базовий варіант, щоб інший дослідник міг точно відтворити побачене вами.
Відтворюваність дає надійну відправну точку. Далі постає корисне запитання: які частини відповіді залишаються незмінними, коли навколишній світ змінюється так, як ви могли б розумно очікувати?
← Усі статті
