Um backtest perfeitamente reproduzível pode ser menos fiável do que outro cujo resultado varia um pouco. A repetibilidade prova que consegues obter a mesma resposta duas vezes; não diz nada sobre se essa resposta depende de um retrato arbitrário dos dados, de uma particularidade de uma biblioteca ou de um valor predefinido oculto.
Parece um argumento contra a reprodutibilidade, mas não é. Fixa a execução para a poderes explicar. Depois, varia deliberadamente os pressupostos que não deveriam determinar o resultado. O primeiro passo torna o resultado auditável; o segundo diz-te se significa alguma coisa.
O que é que um backtest reproduzível demonstra realmente?
Se o mesmo código, dados, configuração e semente aleatória produzirem as mesmas transações e métricas, controlaste uma fonte importante de confusão. Podes comparar a «melhoria» de um agente com a execução que lhe deu origem. Podes distinguir uma correção de um erro de uma alteração na tabela de comissões. Um colega pode inspecionar o mesmo livro de registos e encontrar as mesmas execuções.
Mas o resultado depende de tudo o que fixaste. Imagina uma estratégia de criptomoedas cujo ficheiro histórico contém barras de 1 minuto. Guardas o hash do ficheiro, fixas o código e obténs um Sharpe de 1.4 em cada nova execução. Se o fornecedor corrigir mais tarde várias velas, essa reprodutibilidade impecável continua a descrever o ficheiro antigo. Não te diz se o sinal resiste ao histórico corrigido, nem se aquelas velas estavam disponíveis nesse formato na altura.
O hash é útil: torna a dependência visível. Não é prova de que essa dependência seja inofensiva.
Mantém a execução fixa; põe a conclusão à prova
Gosto de separar duas perguntas. Conseguimos reconstruir exatamente esta execução? E a conclusão da investigação resiste a alterações razoáveis? A primeira exige um registo imutável; a segunda exige perturbações controladas, uma de cada vez.
| O que registar | O que variar depois | O que pode revelar |
|---|---|---|
| Versão dos dados em bruto e somas de verificação | 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 |
| Comissões, funding e pressupostos de execução | Um intervalo de custos defensável | Se uma vantagem reduzida depende de uma execução invulgarmente favorável |
| Universo e composição à data considerada | Regras alternativas para os mercados elegíveis | Dependência das decisões de inclusão ou exclusão |
Por exemplo, suponhamos que uma estratégia de futuros apresenta um retorno excedentário anualizado de 8% numa reprodução de referência. Volta a executá-la com custos taker 25% mais elevados, com o funding deslocado para o momento de liquidação observado seguinte e removendo, à vez, os dois maiores contributos. Não são três formas de melhorar o modelo. São sondagens: cada uma pergunta se um pormenor plausível está a sustentar o resultado principal.
Mantém cada sondagem separada. Se alterares os dados, a tabela de comissões e o momento de execução ao mesmo tempo, um resultado pior pouco te dirá sobre a causa. E, se uma sondagem for implausível, identifica-a como cenário de stress em vez de a apresentar como o resultado mais provável.
Não confundas identidade byte a byte com verdade numérica
Alguns cálculos são sensíveis à ordem. A adição em vírgula flutuante não é associativa, por isso somar muitos valores pequenos de P&L por uma ordem diferente pode alterar os últimos algarismos. As reduções paralelas, o hardware e as versões das bibliotecas podem afetar o resultado exato. Normalmente, isso é inofensivo; por vezes, uma pequena alteração numérica faz ultrapassar um limiar, altera uma posição e encaminha o resto da simulação por um percurso diferente.
É por isso que preservaria tanto os artefactos exatos como as tolerâncias para as comparações. Regista o livro de transações, não apenas o Sharpe final. Compara primeiro as decisões e os fluxos de caixa; depois, as métricas dentro de uma tolerância definida. Se uma diferença de um cêntimo alterar a decisão de submeter uma ordem, analisa explicitamente esse limiar.
Um registo ú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 resultados intermédios suficientes para seguir uma métrica até às execuções e aos fluxos de caixa. Uma pontuação final, por si só, não é um artefacto de investigação reproduzível.
Quando a variação é ruído e quando é uma descoberta
Nem todo o número alterado é motivo para alarme. Uma pequena deriva na métrica causada por uma ordem de redução diferente pode deixar as transações inalteradas. Uma transação alterada perto de um limiar pode merecer uma análise. Uma estratégia que perde a maior parte do resultado quando um fornecedor revê um pequeno trecho do histórico revelou algo sobre a sua própria fragilidade, mesmo que a execução original continue a ser perfeitamente reproduzível.
Os críticos das verificações de robustez têm razão num ponto: é fácil continuar a alterar pressupostos até uma estratégia preferida parecer resiliente, ou rejeitar um resultado sólido porque um cenário deliberadamente extremo o faz falhar. Define antecipadamente as variações plausíveis, apresenta o conjunto completo e distingue alternativas correntes de cenários de stress. Depois, preserva a referência para que outra pessoa possa reproduzir exatamente o que observaste.
A reprodutibilidade dá-te um ponto de partida fiável. A pergunta útil vem a seguir: que partes da resposta se mantêm quando o mundo à volta dessa execução muda de formas que seria razoável esperar?
← Todos os artigos
