Backtesting de estratégia cripto sem se enganar

O backtesting de uma estratégia de trading em criptomoedas parece ciência. Você alimenta dados históricos de preços em um sistema, observa a curva de equidade subir e se convence de que encontrou uma vantagem. Na maioria das vezes, você não encontrou nada além de uma curva que se ajusta ao passado. Essa distinção — entre descobrir uma vantagem real e fabricar um backtest favorável — é uma das separações mais importantes no trading sistemático, e o mercado de criptomoedas torna esse erro incomumente perigoso.

Comecemos pelo que um backtest realmente é. Você aplica um conjunto fixo de regras a dados históricos e mede o que teria acontecido caso tivesse operado com essas regras durante aquele período. Ele informa apenas uma coisa: como essas regras se comportaram naquele conjunto de dados específico, sob as condições que existiram naquela janela. Ele não informa nada sobre o que ocorrerá a seguir. Isso parece óbvio, mas traders rotineiramente confundem um backtest com bom desempenho com evidência de lucratividade futura. A lacuna entre essas duas coisas é onde a maioria das estratégias de trading sistemático vai a óbito.

A distinção entre dados in-sample e out-of-sample é onde a disciplina aparece pela primeira vez no processo. Os dados in-sample correspondem à janela histórica utilizada para desenvolver e otimizar as regras. O out-of-sample é o conjunto de dados mantido completamente separado e utilizado apenas uma vez, após o término do desenvolvimento, como teste final para verificar se as regras generalizam além do período em que foram elaboradas. O erro típico é otimizar sobre todos os dados disponíveis e chamar o resultado de backtest. O que você fez, na verdade, foi encontrar o conjunto de parâmetros que melhor descreveu o passado — um mecanismo de descrição, não de previsão. Um processo correto utiliza os dados in-sample para construção, mantém de 30 a 40% dos dados históricos isolados, e testa nessa janela reservada somente após todas as decisões de parâmetros estarem congeladas. Se o desempenho out-of-sample cair drasticamente em relação ao in-sample, houve overfitting.

O overfitting, ou curve-fitting, é a patologia central do desenvolvimento de estratégias sistemáticas. Ocorre quando você adiciona graus de liberdade suficientes ao modelo — parâmetros, condições, filtros em excesso — a ponto de a estratégia essencialmente memorizar os dados de treino em vez de aprender um comportamento estrutural do mercado. Uma estratégia com doze parâmetros otimizada sobre sete anos de dados horários de BTC está quase certamente com overfitting, ainda que o backtest pareça excelente. O teste para overfitting não é a curva de equidade. É verificar se a lógica da estratégia corresponde a uma dinâmica de mercado identificável e repetível que tem razão para persistir. Se você não consegue explicar em uma frase por que compradores e vendedores deveriam se comportar dessa forma de maneira consistente, a vantagem é provavelmente um artefato estatístico do processo de otimização.

Os requisitos de tamanho amostral são subestimados no mercado de criptomoedas, em parte porque os traders tratam anos de dados como inerentemente suficientes. Não são, caso a estratégia opere com pouca frequência. Uma estratégia que gera 30 operações por ano ao longo de três anos produz 90 trades no backtest. A significância estatística para detecção de vantagem geralmente exige um mínimo de 200 a 400 operações, dependendo da variabilidade dos resultados. Com 90 trades, uma simulação de Monte Carlo da mesma distribuição de retornos produzirá curvas de equidade que vão de catastróficas a excepcionais — todas consistentes com a mesma expectativa subjacente. A taxa de acerto e o R médio observados em 90 trades praticamente não fornecem informação confiável. A frequência de trades multiplicada pelo horizonte temporal determina se sua amostra é significativa — não o tempo isoladamente.

O viés de antecipação (look-ahead bias) em criptomoedas merece atenção específica porque é mais fácil de introduzir acidentalmente do que em renda variável tradicional. Nos frameworks clássicos de backtesting, esse viés normalmente significa utilizar um preço futuro ou valor futuro de indicador para gerar um sinal. Em criptomoedas, ele se manifesta de formas mais sutis. Usar preços de fechamento diário para simular entradas intradia pressupõe que você conhecia o fechamento antes de ele ocorrer. Utilizar dados de livro de ordens agregados após o fato introduz um estado que não estava disponível em tempo real. Muitos provedores de dados de criptomoedas reconstroem candles OHLCV a partir de dados de trades, e a metodologia para tratar períodos de baixa liquidez ou interrupções de exchanges introduz inconsistências que podem distorcer os resultados de forma sistemática. Presuma que seus dados têm problemas até que você tenha verificado cuidadosamente a metodologia da fonte.

O mercado de criptomoedas apresenta desafios estruturais que tornam o backtesting materialmente mais difícil do que em renda variável. A liquidez na maioria das altcoins é escassa o suficiente para que os preenchimentos simulados não fossem alcançáveis nos tamanhos testados. Uma estratégia que executa 0,5 BTC por trade na Binance em 2024 pode estar sendo testada de forma adequada. A mesma estratégia testada em uma altcoin de capitalização intermediária com tamanho equivalente em dólares está simulando execuções que teriam movido o mercado contra você de forma significativa. Interrupções de exchanges — especialmente em plataformas de futuros durante períodos de alta volatilidade — criam lacunas de execução que nenhum backtest consegue replicar. Os regimes de funding rate em contratos perpétuos mudam drasticamente ao longo dos ciclos de mercado, e uma estratégia que ignora os custos de financiamento pode parecer lucrativa enquanto perde dinheiro no trading ao vivo. A modelagem de custos deve ser granular — maker versus taker, estruturas por faixas de volume, e o slippage realizado além da taxa cotada — caso contrário, o backtest será otimista por definição.

O forward testing é a ponte entre a validação histórica e a alocação de capital real. Após uma estratégia passar pela otimização in-sample e pelo teste out-of-sample, você a opera em condições reais de mercado com tamanho mínimo — ou em modo paper, embora a execução real ensine mais — e acompanha se o desempenho ao vivo corresponde à distribuição estatística prevista pelo backtest. A pergunta central não é se a estratégia gera lucro durante a janela de forward testing. É verificar se as características trade a trade — ganho médio, perda média, variância dos resultados — são consistentes com o que o backtest previu. Uma divergência significativa indica que o backtest foi falho ou que as condições de mercado mudaram de forma a invalidar a vantagem.

As métricas que importam não são as que a maioria dos traders apresenta. A taxa de acerto é praticamente irrelevante sem o payoff ratio associado a ela. Uma taxa de acerto de 35% com um ganho médio de 3R é uma vantagem melhor do que uma taxa de acerto de 65% com um ganho médio de 0,8R. A expectativa — o valor médio ganho por unidade arriscada, calculada como (taxa de acerto multiplicada pelo ganho médio) menos (taxa de perda multiplicada pela perda média) — é o número mais importante. Um índice de Sharpe acima de 1,0 indica que os retornos são adequados em relação à volatilidade. O drawdown máximo e o fator de recuperação — lucro líquido dividido pelo drawdown máximo — revelam se a estratégia sobrevive às inevitáveis sequências de perdas. Uma estratégia com alta expectativa, mas fator de recuperação abaixo de 2,0, exige uma disciplina de gestão de capital que a maioria dos traders não sustentará na prática.

O framework prático é este: construa apenas sobre dados in-sample, congele todos os parâmetros, execute uma única vez nos dados out-of-sample, exija no mínimo 300 trades na amostra combinada, verifique a metodologia da sua fonte de dados, modele custos e slippage de forma conservadora, e não inicie o forward testing até que o resultado out-of-sample seja aceitável. Se não for aceitável na primeira execução, a resposta correta não é re-otimizar até que passe. Essa re-otimização elimina completamente a distinção entre in-sample e out-of-sample. Meça primeiro, depois decida se a vantagem é real.