1. Ponto de partida: O objetivo da validação não é "provar rentabilidade"
As duas lições anteriores abordaram a divisão de trabalho no fluxo de operações e na estrutura dos dados de entrada. A terceira lição avança para a questão de saber se uma ideia apresenta consistência histórica. Muitos fracassos não resultam de direções fundamentalmente erradas, mas sim de backtests tratados como conclusões sem uma auditoria adequada: os dados incluem ativos entretanto removidos, os sinais utilizam informação futura, os custos são omitidos e os parâmetros são ajustados repetidamente em amostras curtas. A IA pode acelerar a escrita de código e a interpretação de indicadores, mas não pode decidir se uma estratégia é válida. O objetivo mais razoável da validação é: sob pressupostos claros, a estratégia não foi falseada do ponto de vista estatístico ou de custos — e não provar uma rentabilidade inevitável através de uma narrativa fluida.
2. Divisão razoável de tarefas para a IA em backtesting
A IA é adequada para ajudar em:
-
Gerar código para o quadro de backtest
-
Explicar o significado de Sharpe ratio, maximum drawdown e win rate
-
Listar possíveis fontes de viés look-ahead
-
Organizar tabelas de resultados em resumos de texto
As tarefas que devem ser concluídas ou revistas de forma independente por humanos incluem:
-
Se o universo de ativos contém viés de sobrevivência
-
Se os preços existiam antes da listagem dos tokens
-
Se estão incluídos custos de transação, slippage e taxas de financiamento
-
Se são realizados testes fora da amostra ou walk-forward
-
Se são consideradas as discrepâncias entre resultados teóricos e reais
O código ser executado significa apenas que os passos de engenharia estão concluídos; não significa que a estratégia tenha passado na validação.
3. Limpeza de dados: O passo mais frágil no backtesting de criptomoedas
Se um backtest utilizar apenas tokens ainda ativos hoje, os resultados tendem a ser sistematicamente otimistas. Os períodos anteriores à listagem do token não devem ser considerados negociáveis. Preços, volumes e taxas de financiamento variam entre exchanges; os backtests devem fixar a exchange ou especificar regras de síntese. Forks, migrações de contratos e renomeações de tokens provocam quebras nas séries de preços e exigem mapeamento manual ou exclusão. Utilizar uma única stablecoin para preços durante fases de desancoragem (depeg) pode distorcer as métricas de retorno e risco; as janelas de depreciação mais significativas devem ser marcadas ou explicadas separadamente. É necessário exigir que a IA liste as fontes de dados, os intervalos temporais e as definições do universo na documentação, e que verifique cada elemento contra os dados brutos — o que é mais importante do que simplesmente traçar curvas de backtest.
4. Viés look-ahead: Alinhamento temporal entre sinais e execução
Os viés look-ahead mais comuns incluem:
-
Utilizar estatísticas da amostra completa para normalização, mas realizar o backtest sobre a amostra completa
-
Gerar sinais ao fecho do dia e executá-los na abertura do dia seguinte
-
Utilizar endereços classificados como "smart money" apenas depois de o facto ser conhecido
-
Utilizar dados macro revistos como se fossem valores divulgados na altura
A disciplina deve especificar: os sinais gerados em t devem ser executados em t+1 ou mais tarde, consoante o tipo de estratégia; se os dados macro não puderem ser obtidos na sua forma originalmente divulgada, as conclusões daí decorrentes devem ser rebaixadas. Pode ser exigido que a IA anote, em comentários no código, o momento de disponibilidade de cada recurso; os humanos devem verificar aleatoriamente (spot-check) os elementos-chave para garantir que precedem a execução em pelo menos um dia.
5. Custos e fricção: Backtests sem custos são inválidos por defeito
As estratégias de criptomoedas devem, no mínimo, incluir taxas de negociação, slippage, taxas de financiamento perpétuo (se as posições cruzarem pontos de liquidação), taxas de empréstimo (se for utilizada alavancagem) e custos de retirada ou cross-chain, se aplicável. Cenários de taxas de base e de cenário pessimista (por exemplo, duplicação de taxas) podem ser utilizados para testes de stress. Se os retornos esperados se deteriorarem acentuadamente ou se tornarem negativos em cenários pessimistas, a estratégia é altamente sensível a custos e não deve ser avaliada apenas pelas curvas dentro da amostra. A IA assume frequentemente taxas zero ou um único ponto base; os humanos devem incluir tabelas de taxas nos pressupostos e relatórios do backtest.
6. Overfitting e fora da amostra: Mais parâmetros exigem maior cuidado na narrativa
Os sintomas incluem:
-
Apresentar apenas a melhor combinação após testar muitos conjuntos de indicadores
-
Ajustar parâmetros apenas em amostras curtas de mercado em alta
-
Regras muito específicas sem explicação do mecanismo subjacente
As contramedidas incluem:
-
Reservar intervalos fora da amostra que não sejam utilizados para ajuste de parâmetros
-
Aplicar testes walk-forward com janela deslizante
-
Simplificar as regras tanto quanto possível, dentro de premissas explicáveis
Os relatórios devem apresentar métricas-chave tanto dentro como fora da amostra; se o desempenho fora da amostra for significativamente inferior ao da amostra, o risco de overfitting deve ser sinalizado e a expansão ao vivo suspensa. A IA não deve otimizar repetidamente os parâmetros sem supervisão até a curva parecer boa — isso equivale a overfitting automatizado.
7. Do backtest à negociação real: Avanço gradual em vez de lançamento imediato
Recomenda-se uma abordagem em três níveis. Nível um: o backtest é aprovado com universo documentado, taxas e resultados fora da amostra. Nível dois: paper trading ou registos simulados verificam as diferenças de preço entre sinal e execução e observam o slippage real. Nível três: negociação real de pequena escala com limites e stop-loss, comparando continuamente os resultados do paper com os reais. O avanço em cada nível é decidido por humanos — e não por modelos que recomendam posições pesadas. A IA pode gerar listas de verificação para cada nível, mas não pode substituir as decisões de avanço.
8. Campos mínimos num relatório de backtest
Mesmo sem sistemas complexos, um relatório deve incluir:
-
Descrição da estratégia numa frase
-
Intervalo de dados e âmbito dos ativos
-
Tabela de pressupostos de custos
-
Retornos dentro e fora da amostra, maximum drawdown e número de negócios
-
Perda máxima consecutiva
-
Lista de questões não resolvidas
-
Conclusão sobre continuar a validação, pausar ou abandonar
Evitar afirmações como "cautelosamente otimista" que não orientam a ação. Backtests e revisões partilham a mesma disciplina: executável, auditável e repetível.
9. Resumo da lição
Esta lição centra-se em saber se as ideias foram efetivamente testadas. A IA é adequada para ajudar a escrever código de backtest, explicar indicadores, sinalizar viés look-ahead e custos em falta; não é adequada para substituir a confirmação humana de viés de sobrevivência nos dados, alinhamento entre sinal e execução, desempenho fora da amostra ou margem sob custos pessimistas. O código executar e as curvas dentro da amostra com bom aspeto significam apenas que os passos de engenharia estão concluídos — não que a negociação ao vivo esteja justificada. Um caminho mais seguro é documentar os backtests, depois acompanhar em paper antes de um ensaio de pequena escala — cada passo ascendente decidido por humanos. A próxima lição abordará eventos macro e grandes eventos on-chain: períodos com mais informação, mas também com maior probabilidade de se confundirem resumos com conclusões, exigindo limites claros sobre o que a IA pode ajudar a preparar e o que não pode substituir na verificação.
