Бектест опціонів може змінитися, навіть якщо жоден рядок коду стратегії не змінився. Постачальник виправляє некоректне котирування, додає запізнілу угоду, переглядає метадані контракту або змінює фільтр для перехресних ринків. Ви повторно запускаєте ті самі дати й отримуєте інше виконання, іншу позицію, а може, й інший Sharpe. Це не обов’язково помилка стратегії. Змінилися дані, на яких її тестували.
Щоб бектест опціонів можна було відтворити, вважайте ринкові дані версійованим вхідним набором. Фіксуйте використаний знімок, зберігайте первинні спостереження, на яких ґрунтувалося кожне рішення, і порівнюйте змінені результати на рівні контрактів і часових позначок, перш ніж довіряти новим зведеним показникам.
Чому змінився мій бектест опціонів, хоча код лишився тим самим?
Записи про опціони особливо чутливі до виправлень, адже видима можливість торгувати контрактом залежить від кількох полів, що змінюються разом: bid, ask, обсягів, ціни базового активу, дати експірації, страйку й мультиплікатора або умов постачання контракту. Виправлене котирування може перетворити видиму можливість на перехресний ринок. Виправлення метаданих може змінити значення мультиплікатора позиції.
Уявімо стратегію, яка купує кол, коли ask нижчий за $2.00. Під час першого завантаження даних котирування о 10:14 має ask $1.95, bid $1.90 та обсяг 5. Пізніше постачальник виправляє ask на $2.05 після звірки із запізнілим повідомленням біржі. Одне спостереження змінює сигнал. Якщо цей контракт був єдиною угодою стратегії за день, навіть невелике виправлення даних може визначити весь денний дохід.
Фільтрація котирувань теж має значення. Постачальники можуть відкидати застарілі котирування, прибирати перехресні ринки або інакше нормалізувати часові позначки. Такі правила можуть бути цілком обґрунтованими, але вони є частиною ідентичності набору даних. «Опціони SPY за січень–березень» — недостатній опис відтворюваної історії.
Що таке версія даних опціонів?
Версія даних — це точний набір історичних спостережень, доступний для конкретного дослідницького запуску. Зберігайте назву постачальника й набору даних, час отримання, діапазон дат, версію схеми та правила очищення чи фільтрації. Якщо постачальник надає ідентифікатори знімків або часові позначки редакцій, зберігайте й їх.
Для кожного симульованого рішення зберігайте достатньо інформації, щоб відповісти: який контракт розглядали, яке котирування вибрали, коли його опублікували або отримали та за яким правилом воно стало допустимим? Важливі і первинний запис, і похідний запис. Очищений NBBO без часових позначок джерела може приховати, чи було котирування застарілим або надійшло після симульованого рішення.
| Що зберігати | Чому це важливо | Приклад |
|---|---|---|
| Знімок джерела | Визначає, яку історію використовував запуск | Ідентифікатор редакції постачальника й час отримання |
| Походження котирування | Пояснює, який ринок було вибрано | Біржа, час події, час отримання, bid/ask та обсяги |
| Умови контракту | Визначають, що являв собою опціон | Страйк, експірація, мультиплікатор та умови постачання |
| Правила очищення | Показують, які спостереження вилучили | Поріг застарілості й обробка перехресних котирувань |
Як перевірити, чи вплинула редакція постачальника на результати?
Запустіть ту саму стратегію з тією самою конфігурацією на обох знімках. Спершу порівняйте кількість допустимих спостережень і контрактів за датами. Потім порівняйте рішення й виконання: які сигнали з’явилися або зникли, яке котирування змінилося та чи змінив новий запис модельовану ціну виконання.
Не обмежуйтеся загальною дохідністю. Відстежуйте зміни кількості угод, цін входу й виходу, відхилених сигналів і частки P&L від угод, що є лише в одній версії. Sharpe запуску може лишитися подібним, навіть якщо окремі угоди замінюються; головний показник не покаже, що дані під ним змінилися.
Для якісної перевірки зафіксуйте стратегію, комісії та припущення щодо виконання. Якщо одночасно змінити кілька речей, ви не зрозумієте, чи розбіжність виникла через виправлення постачальника, чи через власний експеримент.
Чи завжди варто використовувати найновішу історію опціонів?
Використовуйте найновішу історію, якщо хочете працювати з найкращою актуальною реконструкцією постачальника. Зберігайте старий знімок, якщо потрібно відтворити попередній результат або зрозуміти, які дані мала ваша дослідницька система на той момент. Це різні запитання.
Для досліджень на основі даних, доступних на той час, виправлений запис може бути точнішим зараз, але недоступним стратегії тоді. За можливості зберігайте час публікації й отримання; інакше чітко зазначайте це обмеження. Сучасна реконструкція автоматично не стає історичним набором інформації.
Коли бектест опціонів змінюється, перше запитання має бути: «Які спостереження змінилися?» Запитання «Який запуск правильний?» ставте після того, як зможете на нього відповісти.
Що зберігати для кожного бектесту?
Зберігайте поруч із результатами короткий маніфест: постачальника даних і знімок, час отримання, версії схеми й очищення, джерело метаданих контрактів, коміт стратегії, припущення щодо виконання та конфігурацію запуску. Для кожної угоди залишайте посилання на записи котирувань, що її обґрунтували.
Цей невеликий запис перетворює загадковий повторний запуск на відмінності, які можна перевірити. Історію опціонів і далі виправлятимуть. Ваш дослідницький процес має показувати кожне виправлення, щоб кращий архів покращував дані й водночас не переписував експеримент нишком.
← Усі статті
