Backtesting: um processo verificável das regras à execução

Um backtest é uma experiência sobre regras e dados antigos, não uma autorização automática para negociar dinheiro real. Um processo útil permite explicar o que foi observado, quais condições faltam e por que motivo a próxima etapa responde a uma pergunta diferente. Uma curva bonita pode esconder seleção de parâmetros, custos incompletos ou um programa que gere mal uma rejeição.

Começar pela pergunta e pelo comportamento esperado

Prepare uma ficha versionada com hipótese, dados, regras, estado esperado, estado observado e limitações por resolver. Inclua entrada normal, saída com perda, ausência de sinal, rejeição confirmada e reinício. «Não verificado» é uma conclusão aceitável quando falta evidência; «passou» exige um critério definido antes do resultado.

Imagine que escolhe um retorno de 30% entre 300 combinações. A escolha justifica investigar o efeito da seleção, não anunciar uma vantagem. O mesmo se aplica a um programa com 98 testes normais aprovados e duas rejeições confirmadas mal tratadas. O total dá 98/100=98%, mas a categoria obrigatória de rejeições tem 0/2=0%. Não compense a ausência de controlo numa categoria obrigatória com sucessos noutra.

Neste modelo, as rejeições já estão confirmadas: o requisito era registá-las sem inventar uma execução. Uma resposta de rede desconhecida é outro caso; pode exigir reconciliação porque a ordem talvez exista. Corrija a falha, repita esses casos e os normais que possam ter sido afetados. A percentagem da bateria não estima a probabilidade de falha futura nem a rentabilidade da estratégia.

Especificar regras que duas pessoas consigam reproduzir

«Comprar na tendência» não chega. Um exemplo hipotético usa EMA 50/200, RSI 14, média de 20 períodos, stop de 1,5 ATR 14, alvo de 2,5 ATR e risco planeado de 1%. Ainda faltam o momento de observação, a definição de toque, preços executáveis e prioridade quando condições coincidem. Um cruzamento no fecho é diferente de um cruzamento passageiro durante a vela.

Indique se o risco parte do saldo ou da equity, como converte moeda, quando dimensiona e como lida com volume mínimo. Um stop não garante a perda prevista. No modo algorítmico, aceite que uma função de envio bem-sucedida não comprova execução; confirme respostas e estado. Desenvolva primeiro um caso conhecido que permita conferir manualmente sinal, quantidade, custo e saída.

Escolher e conservar dados adequados

Não existe um número de anos que torne qualquer sistema válido. A janela deve corresponder à frequência dos sinais e às condições que pretende investigar. Registe fornecedor, produto, fuso horário, origem Bid/Ask/Last, lacunas e versões. Distinga ticks registados de trajetórias geradas e conserve inputs, relatório e operações. Um histórico pago também pode ser inadequado.

Mais negócios não significa mais observações independentes: sinais sobrepostos podem partilhar a mesma exposição. Investigue as lacunas e limites do histórico antes de interpretar um drawdown. Não preencha silenciosamente uma ausência de cotação com um preço que nunca esteve disponível.

Separar desenvolvimento e avaliação

Uma divisão cronológica de 70/30 é um exemplo de desenho, não uma regra universal. Defina-a antecipadamente, incluindo o tratamento de indicadores junto à fronteira e de posições que atravessam períodos. A parte posterior deve permanecer fora das escolhas anteriores. Uma avaliação fraca pode refletir regime, custos, amostragem ou seleção; exige diagnóstico, não uma explicação conveniente.

Suponha que a versão 1.0 foi testada em 2024–2025. Ao observar perdas à segunda-feira cria a versão 1.1 que exclui esse dia e repete os mesmos anos. Essa repetição é desenvolvimento, porque a regra aprendeu com esses resultados. Guarde ambas as versões e procure uma avaliação ainda não usada. Mudar o nome do ficheiro não devolve independência ao período.

Walk-forward com denominadores explícitos

Um esquema ilustrativo treina em 2018–2021 e avalia 2022; depois treina 2019–2022 e avalia 2023. Cinco a sete ciclos podem ser uma opção de desenho, mas não constituem certificação. Defina janelas, atualização de parâmetros e forma de agregar resultados antes de consultar os períodos posteriores.

A eficiência walk-forward, por vezes abreviada WFE, depende da métrica e do denominador escolhidos. Valores como 0,5–0,75 ou inferiores a 0,3 não têm significado universal sem essa definição. Não exclua ciclos difíceis para melhorar a razão. O objetivo de walk-forward é observar repetição do procedimento, não tornar um limiar arbitrário numa licença de negociação.

Demo verifica execução e estado, não só retorno

Registe sinal, permissão, pedido, resposta, negócios efetivos, ordens ativas e posição por identificador da ideia. Uma conta demo permite observar acontecimentos em novas cotações; a opção Forward do tester MT5 separa uma parte posterior do histórico e não equivale a esse acompanhamento. Meses sem incidente também não testam um acontecimento raro que nunca ocorreu.

Exemplo de reinício: pretende 0,20 lote, executa 0,08 antes de perder a ligação e confirma depois o cancelamento do remanescente. Estipulamos ausência de outras ordens ou posições para essa ideia. Reenviar 0,20 produz 0,28 lote, ou 40% acima do alvo. A diferença para o alvo é 0,12. Se o cancelamento não estiver confirmado, o pedido antigo ainda pode executar; a diferença aritmética, sozinha, não autoriza outro envio.

O mesmo erro visto em euros nominais

Como extensão própria, suponha um contrato de 100 000 EUR por lote. Os 0,08 representam 8 000 EUR de quantidade nominal; 0,12 acrescenta 12 000 EUR até 20 000 EUR. Reenviar o alvo completo acrescentaria 20 000 EUR aos 8 000 existentes. Estes euros representam quantidade contratual, não margem nem perda máxima; numa conta de outra moeda são necessárias conversões. A reconciliação resolve primeiro o estado, depois a quantidade.

Um percurso completo mantém os limites de cada etapa

Considere um breakout hipotético EUR/USD M30: entrada acima do máximo das 20 velas anteriores e saída abaixo do mínimo de dez. Falta ainda definir instante, tipo de ordem e execução. Desenvolvimento 2014–2020 e avaliação 2021–2023 são janelas ilustrativas. Uma otimização escolhe 23/11 velas e stop 1,4 ATR; guarde o universo de escolhas, não apenas o vencedor.

Resultados fictícios: desenvolvimento com 58% de acerto, profit factor 1,72 e 22% anual; avaliação com 54%, 1,51 e 18%. Estes resumos não reconstituem negócios, drawdown, exposição ou seleção. Uma demo pode depois revelar mais meio pip de custo, enquanto uma eventual fase real apresenta 51% de acerto. Nenhum desses números decide sozinho o próximo tamanho. Compare custos e distribuição de perdas em condições compatíveis.

Passar a uma fase real é opcional e requer justificação própria. «Microlote» ou um décimo do tamanho pretendido não mede automaticamente a exposição suportável. Três a seis meses são durações ilustrativas, não um prazo para aumentar. Um processo com 12% por etapa não é necessariamente mais seguro que 30% no desenvolvimento e 8% na avaliação: faltam drawdown, custos e incerteza.

Três entregáveis antes de mudar de fase

1. Escreva regras executáveis, orçamento de perda e mapa dos estados; assinale cada condição obrigatória ainda não ensaiada.
2. Congele dados, parâmetros e custos; conserve divisão cronológica, variantes tentadas e resultados por categoria.
3. Compare eventos da demo com o esperado e justifique qualquer fase real com exposição limitada ao contexto, sem aumentos automáticos por calendário ou WFE.

Uma diferença de 50% não prova por si uma avaria, tal como diferenças de dez pontos percentuais, 0,3 no profit factor ou 0,5 R não são limites universais. Primeiro alinhe sinais, quantidades, custos líquidos, exposição, equity e tratamento de ordens não executadas. Monte Carlo reorganiza ou modela cenários sob pressupostos; não cobre todos os acontecimentos futuros. O produto final do processo é uma explicação reproduzível, com limites conhecidos.