BTCUSDT.BINANCE Perp 4H Acompanhamento de Tendência Long-Only com Desequilíbrio do Fluxo de Compra/Venda Taker (3 Parâmetros, Fluxo de Ordens + Confluência de Tendência, Sinal Agregado Diretamente dos 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 impulsionado por AGGREGATED TAKER ORDER FLOW (de dados suplementares trade_ticks) em vez de por indicadores derivados de preço (que foram testados exaustivamente e em grande parte falham empiricamente conforme o log de abandono desta sessão). Esta é uma classe de mecanismo genuinamente NEW para o portfólio da fábrica — toda estratégia anterior que revisei usa sinais derivados de OHLCV (níveis de preço, médias móveis, retornos, vol, razões). O desequilíbrio taker-buy/taker-sell é INFORMATIONALLY DISTINCT do preço: mede WHO está tomando liquidez (compradores agressivos vs vendedores agressivos), que a literatura acadêmica de microestrutura (Easley-Kiefer-O'Hara PIN 1996, Easley-Lopez-de Prado-O'Hara VPIN 2012) estabeleceu como preditiva onde o preço sozinho não é. Mecanismo: no fechamento de cada barra de 4H, agregue os ticks de trade da barra em taker_buy_volume vs taker_sell_volume, calcule o desequilíbrio = (compra - venda) / (compra + venda). LONG quando o desequilíbrio de 4H > +0.05 (compra sustentada de taker) AND preço > 100-bar SMA (confluência de tendência — o fluxo deve concordar com a tendência). Saia quando o desequilíbrio inverte para negativo OR o preço cai abaixo de SMA. Sinais de order-flow têm um perfil estatístico fundamentalmente diferente dos sinais falhos de momentum de preço: eles observam diretamente AGENT BEHAVIOR (qual lado está disposto a pagar o spread) em vez de INFERRING comportamento de agente a partir do preço (que é a consequência defasada 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 trade tick da Binance → 240-480 trades totais → 16-32 OOS trades por janela walk-forward, confortavelmente acima do piso de 5 trades. Este também é um INFRASTRUCTURE TEST crítico: se os dados trade_ticks carregam corretamente no pipeline da fábrica (o data_specification.md lista isso sob catalog_data_types e o flag subscribe_trade_ticks existe), isso abre uma classe de mecanismo inteiramente nova para pesquisas futuras. Se falhar ao carregar (similar à lacuna de funding rate HL que bloqueou estratégias 9), a falha em si é informativa e revela um ticket de infraestrutura que vale a pena abrir.

O feedback exigia uma DIAGNOSTIC, não outra suposição sobre o esquema. Consultei diretamente data/supplementary/metrics/BTCUSDT/*.parquet: 334,643 linhas, coluna taker_long_short_vol_ratio, timestamp 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 min 2020-2022). Portanto, o critério (3) 'as linhas não existem -> abrir chamado' é falso, e a premissa do critério (2) de incompatibilidade no esquema do carregador também é falsa (meu carregador já lê exatamente essa coluna + chave de timestamp). A causa raiz verdadeira estava abaixo, no meu próprio código: o limite de defasagem de 24h em _taker_imbalance. Validei offline com o armazenamento parquet real, percorrendo barras sintéticas de 4H ao longo de 2023-2025: o limite de 24h marca apenas 24.9% das barras com sinal taker (depois dos filtros imbalance>0.05 e price>SMA, isso cai para a exposição observada de ~2.79%), enquanto um limite de 14 dias marca 95.3% — portanto, cada janela de walk-forward de 3 será preenchida com negociações. A função _taker_imbalance já carrega adiante a razão mais próxima anterior ou igual quando a janela móvel final de 4h está vazia; apenas o limite a vetava, então a correção é um único parâmetro (max_lag_hours=336), sem ZERO alteração na lógica do sinal, entrada/saída ou dimensionamento e sem NO fallback de proxy de preço. Isso preserva o mecanismo de fluxo de ordens e finalmente permite testá-lo ao longo de todo o período do backtest. Ressalva para o analista: a cobertura taker de 2023-2025 é genuinamente mais esparsa que 2020-2022 (~12% da densidade de 5 min), então o sinal carregado é mais grosseiro nesses anos; um preenchimento retroativo de 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 o walk-forward agora.

Falhou no Sharpe deflacionado com uma probabilidade extrema de overfitting na tentativa 1. DSR=0.3175 (vs barra 0.95), is_significant=FALSE, com o Sharpe otimizado 1.9615 BELOW a barra de sorte esperada-máxima de 225 tentativas de 2.3078, e — decisivamente — PBO=0.8664 (uma probabilidade 87% de que a seleção de parâmetros está overfit). Segundo o framework, um DSR baixo combinado com um PBO muito alto é um abandono decisivo. O walk-forward confirma: is_overfitted=TRUE com média IS 3.91 colapsando para média OOS 0.962 e janelas OOS [2.76, 1.32, -1.19] (uma negativa). O alto probabilistic_sharpe (0.9964) é a clássica armadilha PSR-vs-DSR — ignora a seleção de 225 tentativas que PBO/DSR penaliza. Os positivos genuínos (cliffs de sensibilidade 0, sharpe_ci_low +0.4252 positivo, uma razão de holdout passando legitimamente 1.213) 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á iteração 3): a sensibilidade já está limpa com 0 cliffs, então o sweep explorou totalmente a região estável, porém OOS ainda colapsa e PBO é 0.87 — o overfitting vive no walk-forward SELECTION sobre 225 tentativas, não em um cliff corrigível, e com apenas 3 parâmetros centrais um segundo sweep best-of-225 reencontra as mesmas configurações overfit. Não revise_hypothesis: o desequilíbrio de taker-flow é um mecanismo de primeiro teste sem irmão promovido preso em um alvo morto, então não há nada comprovado para reapontar a um novo instrumento. Cautela adicional (não é uma causa raiz confirmada): o sinal de 'order flow' é derivado da série esparsa de métricas taker_long_short_vol_ratio com um carry-forward de desatualização de 14 dias em vez de ticks brutos de trade, então durante os períodos esparsos 2023-2025 pode ser um único snapshot mantido à frente por até duas semanas — degradando-se em direção a um proxy obsoleto de baixa informação e minando a premissa de 'informacionalmente distinto do preço'; combinado com tendência BTC long-only em uma amostra 6-year de viés altista (alpha base 0.02, benchmark_correlation 0.30), grande parte do retorno pode ser beta. FAILURE PATTERN: um mecanismo de order-flow genuinamente novo com um perfil incomumente limpo (cliffs de sensibilidade 0, CI-low positivo, um holdout passando) ainda pode ser um overfit best-of-225 — aqui PBO 0.8664 com DSR 0.32 e um Sharpe otimizado (1.96) abaixo da barra de sorte 2.31, mais um walk-forward is_overfitted com uma janela OOS negativa, é decisivo. Uma grade de sensibilidade limpa e uma única janela de holdout favorável não NOT resgatam uma otimização cuja seleção é 87% provavelmente overfit; novidade e estabilidade local não são significância estatística.

Não otimize NOT — o sinal de fluxo do taker apresenta um apagão estrutural de dados 2023-2025 (as negociações existem apenas em 2020-2022 e 2026; annual_returns ignoram 2023/2024/2025; exposure_pct 2.79%), portanto um walk-forward com janela de 3 executaria uma janela inteira com dados zerados, e a vantagem do fluxo de ordens não pode ser validada. A alteração do carregador tolerante a esquemas da iteração 2 não fechou a lacuna NOT, o que significa que a próxima etapa é diagnóstica, não mais uma suposição sobre o esquema: (1) Consulte diretamente o catálogo/armazenamento suplementar e confirme se as linhas de volume de compra/venda do taker de `metrics` (ou taker_long_short_vol_ratio) PHYSICALLY EXIST para BTCUSDT 2023-01 até 2025-12. Imprima a contagem de linhas e os nomes reais das colunas/chaves de timestamp de uma amostra de 2024. (2) Se as linhas existirem em outro esquema (nome de coluna ou chave de timestamp que seu carregador ainda não reconhece), amplie `_row_ratio`/`_row_ts`/`_load_taker_flow` para lê-las e execute novamente; confirme que exposure_pct aumenta e que as negociações preenchem 2023-2025. (3) Se as linhas não existirem NOT (a série de taker das métricas nunca foi coletada nem preenchida retroativamente para esses anos), trata-se de um problema de infraestrutura/coleta de dados, exatamente como previa a hipótese — o código da estratégia não pode corrigi-lo; portanto, abra um chamado de coleta de dados para métricas de fluxo do taker com vários anos e DO NOT reenvie esta estratégia para otimização até que os dados cubram todo o período do backtest. Só vale a pena otimizar quando a série de fluxo do taker cobrir 2020-2026 continuamente; o mecanismo é promissor, mas atualmente não pode ser testado.