BTCUSDT.BINANCE Perp 4H — Seguimento de Tendência Long-Only com Desequilíbrio do Fluxo de Compras/Vendas Taker (3 parâmetros, confluência de fluxo de ordens e tendência, sinal puro agregado de ticks)

Estratégia de seguimento de tendência long-only de ativo único no perp BTCUSDT.BINANCE usando barras de 4H, com o sinal direcional conduzido por AGGREGATED TAKER ORDER FLOW (a partir de dados suplementares trade_ticks) em vez de indicadores derivados de preço (que foram exaustivamente testados e falham largamente de forma empírica segundo o registo de abandono desta sessão). Esta é uma classe de mecanismo genuinamente NEW para o portfólio da fábrica — todas as estratégias anteriores que revi usam sinais derivados de OHLCV (níveis de preço, médias móveis, retornos, vol, rácios). O desequilíbrio compra-de-taker/venda-de-taker é INFORMATIONALLY DISTINCT do preço: mede WHO está a tomar liquidez (compradores agressivos vs vendedores agressivos), o que a literatura académica de microestrutura (Easley-Kiefer-O'Hara PIN 1996, Easley-Lopez-de Prado-O'Hara VPIN 2012) estabeleceu como preditivo onde o preço sozinho não é. Mecanismo: em cada fecho de barra 4H, agregar os ticks de trade da barra em taker_buy_volume vs taker_sell_volume, calcular desequilíbrio = (compra - venda) / (compra + venda). LONG quando desequilíbrio 4H > +0.05 (compra de taker sustentada) AND preço > 100 barra(s) SMA (confluência de tendência — o fluxo deve concordar com a tendência). Sair quando o desequilíbrio inverte para negativo OR preço desce abaixo de SMA. Os sinais de fluxo de ordens têm um perfil estatisticamente fundamentalmente diferente dos sinais de momentum de preço falhados: observam diretamente AGENT BEHAVIOR (que lado está disposto a pagar o spread) em vez de INFERRING comportamento do agente a partir do preço (que é a consequência atrasada do comportamento). Apenas 3 parâmetros (bem abaixo do teto de 5 parâmetros). Frequência de trades: ~40-80 trades/ano ao longo de 6+ anos de dados de ticks de trade da Binance → 240-480 trades totais → 16-32 OOS trades por janela walk-forward, confortavelmente acima do piso de 5 trades. Isto é também um INFRASTRUCTURE TEST crítico: se os dados trade_ticks carregam corretamente no pipeline da fábrica (o data_specification.md lista-o sob catalog_data_types e a flag subscribe_trade_ticks existe), isto abre uma classe de mecanismo totalmente nova para investigação futura. Se falhar ao carregar (semelhante ao gap de taxa de financiamento HL que bloqueou 9 estratégias), a própria falha é informativa e revela um ticket de infraestrutura vale a pena abrir.

O feedback exigia um DIAGNOSTIC, não mais uma suposição sobre o esquema. Consultei diretamente data/supplementary/metrics/BTCUSDT/*.parquet: 334,643 linhas, coluna taker_long_short_vol_ratio, carimbo temporal em ms; linhas por ano 2023=12,096 / 2024=16,990 / 2025=14,688, e o mês EVERY 2023-01..2025-12 tem >=288 linhas (contínuas, apenas esparsas em comparação com os dados densos de 5 2020-2022 min). Assim, o critério (3) «as linhas não existem -> abrir pedido» é falso, e a premissa do critério (2) de incompatibilidade do esquema do carregador também é falsa (o meu carregador já lê exatamente esta coluna e chave temporal). A verdadeira causa raiz estava a jusante, no meu próprio código: o limite de desfasamento de 24h de _taker_imbalance. Validei-o offline face ao armazenamento parquet real, percorrendo barras sintéticas de 4H ao longo de 2023-2025: o limite de 24h atribui um sinal taker apenas a 24.9% das barras (após os critérios imbalance>0.05 e preço>SMA, isto reduz-se à exposição observada de ~2.79%), ao passo que um limite de 14 dias atribui-o a 95.3% — assim, todas as janelas do walk-forward de 3 terão transações. A função _taker_imbalance já propaga o rácio mais próximo, anterior ou igual, quando a janela móvel de 4h não tem dados; apenas o limite o vetava, pelo que a correção consiste num único parâmetro (max_lag_hours=336), sem alterar a lógica do sinal, de entrada/saída ou de dimensionamento (ZERO) e sem recorrer a um indicador substituto baseado no preço (NO). Isto mantém intacto o mecanismo de fluxo de ordens e permite finalmente testá-lo ao longo de todo o período do backtest. Nota para o analista: a cobertura taker de 2023-2025 é efetivamente mais escassa do que 2020-2022 (~12% da densidade de 5 min), pelo que o sinal propagado é mais grosseiro nesses anos; preencher retroativamente métricas densas de 5 min para 2023-2025 melhoraria a fidelidade, mas a série é suficientemente contínua mês a mês para validar já o walk-forward.

Falha no Sharpe deflacionado com probabilidade extrema de overfitting na tentativa 1. DSR=0.3175 (vs barra de 0.95), is_significant=FALSE, com o Sharpe otimizado 1.9615 BELOW a barra de sorte esperada máxima de 225 ensaios de 2.3078, e — decisivamente — PBO=0.8664 (uma probabilidade de 87% de que a seleção de parâmetros esteja sobreajustada). Segundo a framework, um DSR baixo combinado com um PBO muito alto é um abandono decisivo. O walk-forward confirma-o: is_overfitted=TRUE com média IS 3.91 a colapsar para média OOS 0.962 e OOS janelas [2.76, 1.32, -1.19] (uma negativa). O probabilistic_sharpe elevado (0.9964) é a armadilha clássica PSR-vs-DSR — ignora a seleção de 225 ensaios que PBO/DSR penaliza. Os positivos genuínos (sensibilidade 0 a penhascos, sharpe_ci_low +0.4252 positivo, uma rácio de holdout 1.213 que passa legitimamente) medem estabilidade local e uma janela forward favorável, não significância, e não podem sobrepor-se a um 87% PBO com o Sharpe selecionado abaixo da barra de sorte. Não iterar (tentativa 1 de 2, já na iteração 3): a sensibilidade já está limpa com 0 penhascos, pelo que o sweep explorou totalmente a região estável mas OOS ainda colapsa e PBO é 0.87 — o overfitting encontra-se no walk-forward SELECTION ao longo de 225 ensaios, não num penhasco corrigível, e com apenas 3 parâmetros principais um segundo best-of-225 sweep reencontra as mesmas configurações sobreajustadas. Não revise_hypothesis: o desequilíbrio de fluxo de takers é um mecanismo de primeiro teste sem irmão promovido retido num target morto, pelo que não há nada provado para redirecionar para um novo instrumento. Cautela adicional (não uma causa raiz confirmada): o sinal de 'fluxo de ordens' é derivado da série de métricas esparsas taker_long_short_vol_ratio com um carry-forward de 14 dias de obsolescência em vez de ticks de negociação brutos, pelo que durante os 2023-2025 períodos esparsos pode ser um único snapshot mantido até duas semanas — degradando-se para um proxy obsoleto e de baixa informação e comprometendo a premissa de 'ser informativamente distinto do preço'; combinado com a tendência BTC long-only numa amostra de 6 anos com forte inclinação bullish (alfa base 0.02, benchmark_correlation 0.30), grande parte do retorno pode ser beta. FAILURE PATTERN: um mecanismo de fluxo de ordens genuinamente novo com um perfil invulgarmente limpo (sensibilidade 0 a penhascos, CI-low positivo, um holdout que passa) pode ainda ser um best-of-225 overfit — aqui PBO 0.8664 com DSR 0.32 e um Sharpe otimizado (1.96) abaixo da barra de sorte de 2.31, mais um walk-forward is_overfitted com uma janela OOS negativa, é decisivo. Uma grelha de sensibilidade limpa e uma única janela de holdout favorável NOT resgatar uma otimização cuja seleção é 87% provavelmente sobreajustada; a novidade e a estabilidade local não são significância estatística.

Não otimizar NOT — o sinal de fluxo de taker tem um apagamento estrutural de dados 2023-2025 (as trades existem apenas em 2020-2022 e 2026; annual_returns saltar 2023/2024/2025; exposure_pct 2.79%), pelo que uma janela walk-forward de 3 executaria uma janela inteira com zero dados e a vantagem de fluxo de ordens não pode ser validada. A alteração do loader com tolerância de esquema da iteração 2 NOT fechar a lacuna, o que significa que o próximo passo é diagnóstico, não outra suposição de esquema: (1) Consultar diretamente o catálogo/armazenamento suplementar e confirmar se as linhas de volume de compra/venda de taker `metrics` (ou taker_long_short_vol_ratio) PHYSICALLY EXIST para BTCUSDT 2023-01 até 2025-12. Imprimir a contagem de linhas e os nomes reais das colunas/chaves de timestamp para uma amostra 2024. (2) Se as linhas existirem sob outro esquema (nome de coluna ou chave de timestamp que o loader ainda não corresponde), estender `_row_ratio`/`_row_ts`/`_load_taker_flow` para as ler e executar novamente; confirmar que exposure_pct sobe e as trades preenchem 2023-2025. (3) Se as linhas NOT existirem (a série de métricas de taker nunca foi recolhida/preenchida retroativamente para esses anos), isto é um problema de infraestrutura/recolha de dados exatamente como a hipótese antecipou — o código da estratégia não o pode corrigir, pelo que deve abrir um ticket de recolha de dados para métricas de fluxo de taker plurianuais e DO NOT reenviar esta estratégia para otimização até que os dados cubram todo o período de backtest. Só quando a série de fluxo de taker cobrir 2020-2026 continuamente é que isto vale a pena otimizar; o mecanismo é promissor mas atualmente intratável.