Скользящие оценки параметров: когда обновлять, а когда нет
Суть идеи
Автор продолжает серию о портфельной оптимизации и задаётся вопросом, который на практике встаёт перед любым систематическим трейдером: нужно ли пересчитывать ключевые параметры стратегии (Sharpe Ratio, волатильность, корреляции) на скользящем окне, или лучше использовать всю доступную историю? Отправная точка — обнаружение структурного перелома в 1989 году в momentum-правиле на кукурузе: до перелома стратегия работала, после — нет. Формальный тест (предположительно Chow-тест или аналог) этот перелом выявил.
Идея в том, что если параметры нестационарны — Sharpe «уплыл», режим сменился — то использование всей истории даёт смещённую оценку. Rolling-окно адаптируется быстрее, но платит за это дисперсией: короткое окно шумит, длинное запаздывает. Автор, судя по анонсу, исследует компромисс между этими крайностями и, возможно, предлагает гибридный подход через формальное тестирование на переломы как триггер для сброса/обновления оценок.
Механизм, который должен работать: если структурный перелом реален (изменилась микроструктура рынка, регуляторика, состав участников), то оценки, посчитанные «через» перелом, систематически врут. Детектор переломов позволяет вовремя «забыть» старый режим и не тащить мёртвый груз в форвардную торговлю.
Применимость к крипте
Для BTC/ETH это не просто применимо — это острее, чем на традиционных рынках. Крипта прошла через несколько очевидных структурных переломов: запуск CME-фьючерсов (декабрь 2017), институциональный приток 2020–2021, крах Luna/FTX 2022, ETF-апрув 2024. Каждый из них потенциально менял режим волатильности, VRP, funding-carry и скew.
Наши ряды, где это особенно актуально: ATM IV (режим волатильности явно менялся), funding rate (структура участников менялась с каждым крупным событием), basis на CME (появление институционалов). Rolling-z на этих рядах в нашем движке — прямое приложение идеи. Вместо фиксированного z-score можно тестировать, не произошёл ли структурный перелом в среднем или дисперсии ряда, и адаптировать окно.
Тестируемо ли
Высокая тестируемость. В нашем Python-движке уже есть rolling-z с настраиваемым окном — это ровно та переменная, которую исследует автор. Конкретно: взять ряд VRP (realized vol минус ATM IV) или funding rate, прогнать стратегию с фиксированным окном (например, 90 дней) против адаптивного окна, где переключение триггерится тестом Чоу или CUSUM. Walk-forward с ребалансировкой по детектору переломов — стандартная процедура.
Чего нет напрямую: полного текста статьи (аннотация обрывается), поэтому конкретный алгоритм выбора окна придётся реконструировать самостоятельно или взять из серии автора.
Сомнения
Главная ловушка — data-snooping на самих переломах. Если мы ищем переломы постфактум на той же выборке, на которой оптимизируем стратегию, то тест «находит» именно те переломы, которые улучшают бэктест. Это классический look-ahead bias в disguise. Второе: переломов в крипте так много, что короткие окна после каждого «сброса» дают ничтожно мало наблюдений для надёжной оценки Sharpe — статистическая мощность падает до нуля. Третье: сам выбор теста на структурный перелом (порог p-value, минимальная длина сегмента) — это дополнительные гиперпараметры, которые легко переподогнать.
Следующий шаг
Прогнать на ряду VRP (ATM IV минус 30-дневная realized vol BTC) walk-forward тест: сравнить fixed-window z-score (90 дней) против CUSUM-адаптивного окна с детектором перелома. Метрика — Deflated Sharpe на OOS-периоде 2022–2024, чтобы захватить режим после FTX.
Результаты тестов
Дописано 4 июля 2026 — прогон «Следующего шага» на нашем движке. Сама статья выше не менялась.
Взял ряд VRP BTC (Deribit DVOL 30д ATM IV минус 30-дневная реализованная волатильность, с марта 2021), зафиксировал стратегию (высокий z(VRP) → лонг BTC) и менял только способ оценки среднего и дисперсии для z-score — ровно та переменная, которую исследует автор. Вход t+1, издержки 6 б.п., Deflated Sharpe с поправкой на 10 испытаний (5 оценщиков × 2 порога).
| Оценщик окна | Sharpe (весь период) | DSR | Sharpe (OOS 2022–2024) |
|---|---|---|---|
| Rolling 90 дней (базлайн статьи) | 0.24 | 0.42 | −0.16 |
| Rolling 180 дней | 0.52 | 0.66 | 0.47 |
| Rolling 365 дней | 0.61 | 0.74 | 0.56 |
| Expanding (вся история) | 0.66 | 0.77 | 0.53 |
| CUSUM-adaptive (сброс на переломе) | 0.17 | 0.35 | −0.00 |
| Buy&hold BTC | 0.34 | — | 0.70 |
«Обновлять быстрее» здесь не вознаграждается. Порядок ровно обратный интуиции про адаптивность: короткое 90-дневное окно — худшее из фиксированных (0.24, а на OOS вообще −0.16), а чем длиннее окно, тем лучше — вплоть до expanding на всей истории (0.66). Короткое окно не «быстро адаптируется», оно шумит: оценка среднего VRP скачет, z-score дёргается, стратегия перевходит. На этом ряду ответ на вопрос статьи — «держитесь длинной оценки».
Детектор переломов — это ловушка, а не решение. Добавил CUSUM-сброс окна при структурном переломе, как предлагает автор. Три находки, все в пользу «Сомнений» из статьи:
- Adaptive — худший из всех (0.17 против 0.24–0.66 у фиксированных). Каждый сброс оставляет слишком мало наблюдений, чтобы оценить среднее — ровно та потеря мощности, о которой предупреждает статья.
- По числу переломов порог h почти инертен — реальную частоту тайно задаёт
min_seg. При min_seg = 90 порог h от 4 до 12 даёт одни и те же ~21 перелом. То есть «адаптивный детектор» на персистентном ряду не ловит дискретные переломы — он сбрасывается по расписанию, спрятанному в новом гиперпараметре. При min_seg = 180 переломы идут как часы каждые полгода, и лишь 1 из 10 попадает в ±30 дней от реального события (Luna, FTX, ETF…). Вы не решили задачу выбора окна — вы переименовали её. - Результат хрупок до неприличия. OOS-Sharpe адаптивной версии при min_seg = 30 скачет от −0.78 до +1.22 в зависимости от порога h. Тот, кто «настроит» h = 12 и найдёт +1.22, поймает соседний −0.78 на чуть другой выборке — это классическая переподгонка на самих переломах, ровно как предупреждает статья.
Вывод. «Когда обновлять скользящую оценку?» — на нашем VRP: длинное/расширяющееся окно уверенно бьёт короткое, а сброс по детектору переломов доходности не добавляет, зато добавляет пару переподгоняемых ручек. И честности ради: ни один вариант не проходит DSR (лучший — 0.78 при N = 10), так что речь про «меньшее из зол» в оценке, а не про рабочую альфу. Отдельно приятно, что метод сам себя разоблачил в духе соседней заметки про Sharpe шума: «детектор поймал FTX» — иллюзия, когда переломов и так один в полгода.
Проверка: research_validate_rolling.py + независимая адверсариальная верификация — синтетический тест на лукахед (шок будущего VRP не двигает прошлые позиции ни у одного оценщика, включая онлайн-CUSUM), сверка единиц VRP и тайминга DVOL, воспроизведение грида хрупкости и дат переломов.