Um backtest perfeitamente reproduzível pode ser menos confiável do que um que varia um pouco. A repetibilidade prova que você consegue obter a mesma resposta duas vezes; não diz nada sobre se a resposta depende de um snapshot de dados arbitrário, de uma peculiaridade de biblioteca ou de um padrão oculto.
Isso parece um argumento contra a reprodutibilidade, mas não é. Congele a execução para poder explicá-la. Depois, varie deliberadamente as premissas que não deveriam determinar o resultado. A primeira etapa torna o resultado auditável; a segunda mostra se ele significa alguma coisa.
O que um backtest reproduzível realmente comprova?
Se o mesmo código, os mesmos dados, a mesma configuração e a mesma semente aleatória produzem as mesmas operações e métricas, você controlou uma fonte importante de confusão. Dá para comparar a “melhoria” de um agente com a execução que lhe deu origem. Uma correção de bug pode ser separada de uma mudança na tabela de taxas. Um colega pode inspecionar o mesmo livro de operações e encontrar os mesmos preenchimentos.
Mas o resultado depende de tudo o que você congelou. Considere uma estratégia cripto cujo arquivo histórico contém candles de 1 minuto. Você salva o hash do arquivo, fixa o código e obtém um Sharpe de 1.4 em todas as reexecuções. Se o fornecedor corrigir vários candles depois, essa reprodutibilidade impecável ainda descreve o arquivo antigo. Ela não diz se o sinal resiste ao histórico corrigido nem se aqueles candles estavam disponíveis naquele formato na época.
O hash é útil: ele deixa a dependência visível. Mas não prova que essa dependência seja inofensiva.
Mantenha a execução fixa; ponha a descoberta à prova
Gosto de separar duas perguntas. Conseguimos reconstruir exatamente esta execução? E a conclusão da pesquisa resiste a mudanças razoáveis? A primeira exige um registro imutável; a segunda, perturbações controladas, uma de cada vez.
| O que registrar | O que variar depois | O que isso pode revelar |
|---|---|---|
| Versão dos dados brutos e checksums | Revisão do fornecedor ou uma segunda fonte | Dependência de valores corrigidos ou específicos do fornecedor |
| Commit do código e versões dos pacotes | Implementação numericamente equivalente | Sensibilidade à ordem, ao arredondamento ou à biblioteca |
| Taxas, funding e premissas de preenchimento | Uma faixa defensável de custos | Se uma vantagem pequena depende de uma execução excepcionalmente favorável |
| Universo e composição em cada momento histórico | Regras alternativas para mercados elegíveis | Dependência de decisões de inclusão ou exclusão |
Por exemplo, suponha que uma estratégia de futuros apresente retorno excedente anualizado de 8% em uma simulação de referência. Execute-a novamente com custos de taker 25% maiores, funding deslocado para a liquidação observada seguinte e, em rodadas separadas, sem os dois maiores contribuintes. Essas não são três formas de melhorar o modelo. São sondagens: cada uma pergunta se um detalhe plausível está sustentando o resultado principal.
Mantenha cada sondagem separada. Se você mudar os dados, a tabela de taxas e o momento da execução ao mesmo tempo, um resultado pior pouco ajudará a diagnosticar o problema. E, se uma sondagem for implausível, identifique-a como um cenário de estresse em vez de apresentá-la como o resultado mais provável.
Não confunda igualdade byte a byte com verdade numérica
Alguns cálculos são sensíveis à ordem. A soma em ponto flutuante não é associativa, então somar muitos valores pequenos de P&L em outra ordem pode alterar os últimos dígitos. Reduções paralelas, hardware e versões de bibliotecas também podem afetar a saída exata. Em geral, isso é inofensivo; às vezes, uma pequena mudança numérica inverte um limite, altera uma posição e leva o restante da simulação por outro caminho.
Por isso, eu preservaria tanto os artefatos exatos quanto as tolerâncias usadas nas comparações. Registre o livro de operações, não apenas o Sharpe final. Compare primeiro as decisões e os fluxos de caixa; depois, as métricas dentro de uma tolerância declarada. Se uma diferença de um centavo mudar se uma ordem será enviada, examine explicitamente esse limite.
Um registro útil da execução inclui a identidade dos dados e do código, a configuração, a semente aleatória, o ambiente de execução e saídas intermediárias suficientes para rastrear uma métrica até os preenchimentos e os fluxos de caixa. Uma pontuação final, por si só, não é um artefato de pesquisa reproduzível.
Quando a variação é ruído e quando é uma descoberta
Nem toda mudança de número é uma crise. Uma pequena oscilação na métrica causada por outra ordem de redução pode deixar as operações inalteradas. Vale a pena revisar uma operação alterada perto de um limite. Se uma estratégia perde a maior parte do resultado quando um fornecedor revisa um pequeno trecho do histórico, você descobriu algo sobre a fragilidade dela, mesmo que a execução original continue perfeitamente reproduzível.
Quem critica as verificações de robustez tem razão em um ponto: é fácil continuar mudando as premissas até uma estratégia preferida parecer resiliente, ou rejeitar um resultado sólido porque algum cenário deliberadamente extremo o derruba. Defina previamente as variações plausíveis, informe o conjunto completo e diferencie alternativas comuns de cenários de estresse. Depois, preserve a referência para que outra pessoa possa reproduzir exatamente o que você observou.
A reprodutibilidade oferece um ponto de partida confiável. A pergunta útil vem em seguida: quais partes da resposta permanecem iguais quando o mundo ao redor daquela execução muda de maneiras que você poderia razoavelmente esperar?
← Todos os artigos
