Backtesting vs Diário de Operações: Por Que Você Precisa dos Dois

Em resumo. O backtesting simula uma estratégia contra dados históricos de preço antes de qualquer capital estar em risco; um diário de trading registra o que realmente aconteceu depois que ordens reais foram feitas. Eles respondem a perguntas diferentes e nenhum substitui o outro: um backtest pode mostrar se um conjunto de regras tinha mérito historicamente, mas só um diário mostra se um trader consegue de fato executá-lo, com slippage real, taxas reais e psicologia real no caminho.

Os traders tendem a se apoiar em um e pular o outro. Alguém roda uma estratégia em um backtest, vê uma curva de patrimônio limpa e começa a operá-la ao vivo supondo que o backtest já provou a tese. Outra pessoa registra diligentemente cada operação ao vivo, mas nunca verificou, em dados históricos, se a ideia subjacente tem algum mérito estatístico. Os dois hábitos criam um ponto cego que a outra prática teria detectado.

O que o backtesting realmente testa

Um backtest aplica um conjunto fixo de regras de entrada e saída a dados históricos de preço e mede o que teria acontecido: lucro ou prejuízo líquido, taxa de acerto, drawdown e outras estatísticas de desempenho, calculadas sem arriscar um centavo (Corporate Finance Institute, "Backtesting"). Isso o torna barato de rodar e rápido de iterar. Uma ideia de regra pode ser testada contra anos de histórico de preços, ajustada e testada de novo, tudo antes de uma única ordem real sair. Plataformas de varejo como o Strategy Tester do MetaTrader existem especificamente para isso: simular a execução de uma estratégia automatizada contra dados históricos de preço armazenados para que sua lógica possa ser verificada antes de tocar uma conta real ou demo (MetaQuotes, documentação MQL5, "Testing Trading Strategies").

O valor de um backtest é estreito e específico: responde se um conjunto definido de regras teria produzido um resultado positivo ao longo de um trecho escolhido da história. Não responde se esse mesmo trader, em condições reais de mercado, consegue realmente seguir as regras.

O que um backtest não consegue ver

Um backtest roda com dados históricos limpos e um preenchimento simulado em cada sinal. Ele não tem acesso ao que acontece entre a regra e a ordem real: o meio segundo de hesitação antes de clicar em comprar, o stop que é movido porque a operação "parece" errada, a posição fechada cedo por nervosismo, ou a que é mantida por tempo demais na esperança de uma recuperação. Nada disso aparece em uma simulação, porque uma simulação não tem nervos.

Ele também tende a subestimar os custos reais de trading. Os preenchimentos históricos em um backtest costumam ser assumidos no preço exato do sinal, enquanto uma ordem real é preenchida ao preço que o mercado oferece um instante depois, mais spread e comissão. O slippage em um instrumento líquido pode ser uma fração de um percentual; em um mercado mais raso pode passar bem de um percentual, e até uma pequena suposição de slippage pode transformar uma vantagem do backtest em perdedora ao vivo quando aplicada de forma consistente a cada operação.

Importante. Um backtest que não levou em conta slippage, comissões e preenchimentos realistas não está medindo a estratégia que o trader realmente vivenciará ao vivo. Trate uma curva de backtest limpa como uma hipótese inicial, e não como uma garantia.

O que um diário de trading captura em vez disso

Um diário de trading registra a operação que foi realmente feita: o preço real de entrada e saída, o tamanho real, o resultado real depois das taxas e, se o diário capturar, o estado de espírito ao entrar e ao sair da operação. Este é o único registro que mostra a diferença entre a regra como escrita e a regra como executada.

Essa diferença costuma ser onde mora a história real. Um setup pode ser testado com uma taxa de acerto limpa de 55% e ainda assim perder dinheiro ao vivo, não porque o setup estivesse errado, mas porque a execução ao vivo devolve de forma consistente alguns pontos-base por operação para slippage, hesitação ou uma saída feita um candle cedo demais. Registrar cada operação com uma tag de setup é o que torna essa comparação possível; sem isso, um período de perdas ao vivo e uma ideia quebrada parecem idênticos de dentro.

O ponto cego que cada um tem sozinho

Um fluxo de trabalho prático: backtest primeiro, depois registre a lacuna de execução

As duas práticas funcionam melhor como uma sequência, e não como uma escolha. Faça o backtest de uma ideia primeiro, em um trecho suficientemente longo da história e em mais de uma condição de mercado, para filtrar regras que nunca tiveram mérito antes de qualquer capital ser comprometido. Se o backtest se sustentar, opere a ideia ao vivo com tamanho reduzido e registre cada operação sob uma tag dedicada, incluindo preço de entrada e saída, tamanho e resultado depois dos custos.

Depois de um número significativo de operações ao vivo sob essa tag, compare a taxa de acerto e o resultado médio registrados no diário com os números do backtest para o mesmo conjunto de regras. Uma correspondência próxima, dentro da faixa que os custos e a variância normal explicariam, é sinal de que a estratégia sobrevive ao contato com a execução real. Uma lacuna ampla e consistente aponta para um problema real: custos que foram subestimados no backtest, ou regras que não estão sendo seguidas como escritas quando dinheiro real e emoção real entram em jogo. Revisar o detalhamento da estratégia para essa tag em um calendário regular, em vez de apenas quando o setup parece ter parado de funcionar, é o que mantém essa comparação honesta.

Lendo uma sequência de perdas ao vivo contra uma linha de base de backtest

Um período de perdas em um setup ao vivo e registrado em diário é fácil de interpretar mal sem um backtest para comparar. Se o teste histórico já mostrou períodos de cinco ou seis perdas consecutivas como parte normal do padrão de retorno daquela estratégia, uma sequência de perdas ao vivo de duração semelhante não é informação nova; é a estratégia se comportando como esperado. Sem essa linha de base, a mesma sequência pode parecer a prova de que a ideia parou de funcionar, e os traders abandonam setups que nunca estiveram quebrados, ou dobram a aposta em outros que silenciosamente estão.

Este é um modo de falha diferente de julgar uma vantagem a partir de uma amostra ao vivo pequena demais, que é um problema de tamanho de amostra. Aqui o problema é não ter nenhum ponto de referência sobre como é o "normal" para esta estratégia específica, porque a etapa do backtest foi pulada. A expectativa, calculada da mesma forma no backtest e no diário ao vivo, é o número que torna essa comparação concreta em vez de um sentimento.

O que registrar para a comparação realmente funcionar

A comparação entre backtest e ao vivo só funciona se o diário capturar detalhes suficientes para se alinhar com a própria saída do backtest. Um registro de diário que só anota ganho ou perda não pode ser conferido contra um backtest que reporta taxa de acerto, resultado médio e drawdown; os dois conjuntos de dados precisam falar a mesma língua.

No mínimo, cada operação ao vivo sob a tag precisa do nome do setup, do preço de entrada e saída, do tamanho da posição, do resultado depois das taxas e da data, para que as mesmas estatísticas (taxa de acerto, resultado médio, drawdown máximo para aquela tag) possam ser calculadas dos dois lados e colocadas lado a lado. Exemplos de diários de trading construídos em torno desse nível de detalhe fazem da comparação uma consulta de cinco minutos em vez de uma reconstrução manual a partir dos extratos da corretora depois do fato.

Erros comuns

• Operar ao vivo uma ideia testada em backtest sem nunca comparar os resultados ao vivo de volta com o backtest. A comparação é o ponto central; pulá-la significa que o backtest foi um exercício pontual em vez de uma verificação contínua.
• Supor que os preenchimentos e custos de um backtest correspondem às condições ao vivo. Suposições irreais de slippage e comissão transformam rotineiramente uma vantagem de backtest em perdedora ao vivo.
• Registrar operações ao vivo de uma ideia que nunca foi testada em dados históricos. Não há como distinguir um período normal de perdas de uma ideia quebrada sem uma linha de base.
• Abandonar uma estratégia depois de uma sequência de perdas que corresponde ao seu próprio padrão de drawdown de backtest. Compare com o backtest antes de concluir que a vantagem acabou.
• Tratar uma única execução de backtest como prova permanente. As condições de mercado mudam; um conjunto de regras que testou bem há um ano precisa ser reverificado periodicamente com dados novos, do mesmo modo que uma vantagem ao vivo.

Este artigo tem fins exclusivamente educacionais e não constitui aconselhamento financeiro ou de investimento. Operar com alavancagem envolve alto risco de perda. O desempenho passado, seja de um backtest ou de um histórico ao vivo, não garante resultados futuros.

Compare automaticamente as expectativas do backtest com os resultados reais registrados no diário com o diário de trading da BitStat, em vez de acompanhar duas planilhas separadas e adivinhar a diferença entre elas.