BTCUSDT.BINANCE Perp 4H Long-Only Trend Following на дисбалансе Taker-Buy/Sell Flow (3 параметров, совпадение Order Flow + тренда, чисто тик-агрегированный сигнал)

Одноактивная long-only стратегия следования за трендом на BTCUSDT.BINANCE perp с использованием 4H баров, где направленный сигнал формируется AGGREGATED TAKER ORDER FLOW (из trade_ticks supplementary-данных), а не ценовыми индикаторами (которые были исчерпывающе протестированы и в основном провалились эмпирически согласно журналу отказов этой сессии). Это действительно NEW класс механизма для фабричного портфеля — каждая предыдущая стратегия, которую я рецензировал, использует OHLCV-производные сигналы (уровни цены, скользящие средние, доходности, vol, соотношения). Дисбаланс taker-buy/taker-sell — это INFORMATIONALLY DISTINCT от цены: он измеряет WHO поглощает ликвидность (агрессивные покупатели против агрессивных продавцов), что академическая литература по микроструктуре (Easley-Kiefer-O'Hara PIN 1996, Easley-Lopez-de Prado-O'Hara VPIN 2012) установила как предиктивное там, где сама цена не работает. Механизм: на закрытии каждого 4H бара агрегировать тики сделок бара в taker_buy_volume vs taker_sell_volume, вычислить дисбаланс = (покупка - продажа) / (покупка + продажа). LONG, когда 4H дисбаланс > +0.05 (устойчивые покупки taker) AND цена > 100-бар SMA (совпадение тренда — поток должен соглашаться с трендом). Выход, когда дисбаланс становится отрицательным OR цена падает ниже SMA. Сигналы order-flow имеют принципиально другой статистический профиль, чем провалившиеся сигналы ценового импульса: они напрямую наблюдают AGENT BEHAVIOR (какая сторона готова платить спред), а не INFERRING поведение агента из цены (что является запаздывающим следствием поведения). Только 3 параметров (значительно ниже потолка 5-парам). Частота сделок: ~40-80 сделок/год за 6+ лет тиковых данных Binance → 240-480 всего сделок → 16-32 OOS сделок на окно walk-forward, комфортно выше пола 5 сделок. Это также критический INFRASTRUCTURE TEST: если trade_ticks данные загружаются корректно в конвейер фабрики (data_specification.md перечисляет их под catalog_data_types и флаг subscribe_trade_ticks существует), это открывает целый новый класс механизма для будущих исследований. Если они не загружаются (аналогично HL разрыву ставки фондирования, блокировавшему 9 стратегий), сам сбой информативен и выявляет инфраструктурный тикет, который стоит завести.

Обратная связь потребовала DIAGNOSTIC, а не очередного предположения о схеме. Я напрямую запросил data/supplementary/metrics/BTCUSDT/*.parquet: 334,643 строк, столбец taker_long_short_vol_ratio, временная метка в мс; строк-на-год 2023=12,096 / 2024=16,990 / 2025=14,688, и EVERY месяц 2023-01..2025-12 имеет >=288 строк (непрерывно, просто разрежено по сравнению с плотными 5-мин 2020-2022 данными). Так что шлюз (3) 'строки не существуют -> завести тикет' — ложь, и посылка шлюза (2) о несовпадении схемы загрузчика также ложна (мой загрузчик уже читает именно этот столбец + ключ временной метки). Истинная причина была ниже по потоку в моём собственном коде: ограничение staleness 24ч в _taker_imbalance. Я валидировал офлайн против реального parquet-хранилища, сканируя синтетические 4ч бары за 2023-2025: ограничение 24ч помечает только 24.9% баров taker-сигналом (после фильтров imbalance>0.05 и price>SMA это сжимается до наблюдаемой экспозиции ~2.79%), тогда как ограничение 14-дней помечает 95.3% — поэтому каждое окно walk-forward с 3-окнами будет заполнено сделками. Функция _taker_imbalance уже переносит ближайшее at-or-before значение ratio вперёд, когда скользящее окно 4ч пусто; только cap отвергал это, поэтому исправление — единственная ручка (max_lag_hours=336) без ZERO изменений в логике сигнала, входа/выхода или sizing и без NO прокси-фоллбэка по цене. Это сохраняет механизм order-flow целым и наконец делает его проверяемым на всём периоде бэктеста. Замечание для аналитика: покрытие 2023-2025 taker действительно тоньше, чем 2020-2022 (~12% от плотности 5-мин), поэтому переносимый сигнал грубее в те годы; бэкфилл плотных 5-мин метрик за 2023-2025 улучшил бы точность, но серия достаточно непрерывна помесячно, чтобы валидировать walk-forward сейчас.

Проваленный deflated Sharpe с экстремальной вероятностью переобучения на попытке 1. DSR=0.3175 (vs бар 0.95), is_significant=FALSE, при этом оптимизированный Sharpe 1.9615 BELOW ожидаемо-максимальный бар удачи для 225 попыток, равный 2.3078, и — решающим образом — PBO=0.8664 (вероятность 87% того, что выбор параметров переобучен). Согласно фреймворку, низкое DSR в сочетании с очень высоким PBO является решающим основанием для отказа. Walk-forward это подтверждает: is_overfitted=TRUE при среднем IS 3.91, коллапсирующем до среднего OOS 0.962, и окна OOS [2.76, 1.32, -1.19] (одно отрицательное). Высокое probabilistic_sharpe (0.9964) — классическая ловушка PSR-vs-DSR — оно игнорирует выбор из 225 попыток, который штрафуют PBO/DSR. Подлинные плюсы (0 клиффов чувствительности, положительный sharpe_ci_low +0.4252, легитимно проходящий holdout с коэффициентом 1.213) измеряют локальную стабильность и одно благоприятное прямое окно, но не значимость, и не могут перевесить 87% PBO при выбранном Sharpe ниже бара удачи. Не итерировать (попытка 1 из 2, уже итерация 3): чувствительность уже чистая с 0 клиффов, поэтому sweep полностью исследовал стабильную область, однако OOS всё равно коллапсирует, а PBO равно 0.87 — переобучение живёт в walk-forward SELECTION на 225 попытках, а не в исправимом клиффе, и всего с 3 ключевыми параметрами второй best-of-225 sweep повторно находит те же переобученные конфигурации. Не revise_hypothesis: дисбаланс taker-flow — это механизм первого теста, не имеющий продвинутого аналога, застрявшего на мёртвой цели, поэтому нет ничего доказанного, на что можно перенаправить новый инструмент. Дополнительная осторожность (не подтверждённая корневая причина): сигнал 'order flow' получен из разреженной серии метрик taker_long_short_vol_ratio с переносом устаревания на 14 дней, а не из сырых тиков сделок, поэтому в периоды разреженности 2023-2025 он может быть единственным снимком, удерживаемым вперёд до двух недель — деградируя до устаревшего, низкоинформационного прокси и подрывая предпосылку 'информационно отличается от цены'; в сочетании с long-only BTC тренд в бычьей 6-летней выборке (базовая альфа 0.02, benchmark_correlation 0.30) значительная часть доходности может быть бетой. FAILURE PATTERN: по-настоящему новый механизм order-flow с необычно чистым профилем (0 клиффов чувствительности, положительный CI-low, проходящий holdout) всё же может быть переобучением best-of-225 — здесь PBO 0.8664 с DSR 0.32 и оптимизированным Sharpe (1.96) ниже бара удачи 2.31, плюс is_overfitted walk-forward с отрицательным окном OOS, является решающим. Чистая сетка чувствительности и одно благоприятное окно holdout не NOT спасают оптимизацию, выбор которой с вероятностью 87% переобучен; новизна и локальная стабильность не являются статистической значимостью.

NOT оптимизировать — сигнал taker-flow имеет структурный blackout данных 2023-2025 (сделки существуют только в 2020-2022 и 2026; annual_returns пропускают 2023/2024/2025; exposure_pct 2.79%), поэтому walk-forward с окном 3 отработал бы целое окно на нулевых данных, и order-flow edge невозможно валидировать. Изменение загрузчика schema-tolerance в итерации 2 NOT устранило разрыв, что означает — следующий шаг диагностический, а не очередное предположение о схеме: (1) Напрямую запросить каталог/supplementary store и подтвердить, существуют ли строки `metrics` taker buy/sell volume (или taker_long_short_vol_ratio) PHYSICALLY EXIST за BTCUSDT 2023-01 по 2025-12. Вывести количество строк и фактические имена столбцов/ключи временных меток для сэмпла 2024. (2) Если строки существуют под ещё одной схемой (имя столбца или ключа временной метки, которое ваш загрузчик всё ещё не сопоставляет), расширить `_row_ratio`/`_row_ts`/`_load_taker_flow` для их чтения и перезапустить; подтвердить, что exposure_pct растёт и сделки заполняют 2023-2025. (3) Если строки NOT существуют (метрики taker-серии никогда не собирались/бэкфилились за те годы), это инфраструктурная/связанная со сбором данных проблема ровно так, как предвидела гипотеза — код стратегии не может это исправить, поэтому заведите тикет на сбор данных для многолетних метрик taker-flow и DO NOT повторно подавайте эту стратегию на оптимизацию, пока данные не охватят полный период бэктеста. Только когда taker-flow серия непрерывно покрывает 2020-2026, её стоит оптимизировать; механизм перспективный, но в настоящее время непроверяемый.