Rodamos novamente um backtest salvo e obtivemos uma curva de patrimônio diferente. Mesmo código da estratégia, mesmo período, mesmo ativo. O saldo final diferia em 1.8%, e 3 operações tinham mudado em 1 candle.
Isso já basta para tornar difícil confiar em um resultado de pesquisa. Se um colega, uma versão futura de você ou um serviço de paper trading não consegue reproduzir a execução, não dá para saber se uma mudança melhorou a estratégia ou apenas alterou o experimento. Veja a sequência que seguimos para encontrar a divergência.
Dia 1: Definimos o que queria dizer “a mesma execução”
Nosso primeiro erro foi tratar o arquivo da estratégia como se fosse o experimento. Não era. A execução também dependia dos dados de entrada, da versão do mecanismo, do calendário, dos metadados do instrumento e das configurações de execução. O código descrevia apenas uma parte do cálculo.
Criamos um manifesto da execução antes de mudar qualquer coisa. Ele registrava o commit da estratégia, os identificadores dos snapshots de dados, o período, a plataforma, a tabela de taxas, a fonte de funding, o modelo de preenchimento e as versões do software. Também salvamos as ordens e os fills resultantes, porque uma curva de patrimônio, sozinha, não mostra em que ponto duas execuções divergiram pela primeira vez.
| Artefato | O que registrar | Por que isso importa |
|---|---|---|
| Dados de mercado | ID do snapshot, versão do esquema, ajustes | Os fornecedores corrigem o histórico e revisam ações corporativas |
| Execução | Faixa de taxas, série de funding, configurações de preenchimento e impacto | Configurações padrão e premissas da conta alteram os resultados |
| Ambiente de execução | Commit do código, versões do mecanismo e das dependências | Bibliotecas podem alterar a ordenação, o arredondamento ou os indicadores |
| Resultado | Ordens, fills, posições e métricas | Mostra em que ponto as execuções começam a divergir |
Dia 2: Comparamos as operações, não o Sharpe
As métricas resumidas nos distraíram. As duas execuções tinham Sharpe quase igual, mas os registros de fills mostraram que a primeira divergência ocorreu em uma liquidação de funding. Uma execução aplicou a taxa à posição aberta no timestamp da liquidação; a outra usou a posição após o rebalanceamento daquele timestamp.
O código da estratégia não tinha mudado. A ordenação dos eventos no mecanismo, sim. Uma pequena atualização de versão tornou explícita a sequência que antes dependia da ordem em que dois eventos acabavam sendo classificados.
Corrigimos o contrato da execução para especificar a ordem: aplicar o funding à posição mantida até a liquidação e, em seguida, processar as decisões da estratégia naquele timestamp. A convenção exata pode variar conforme a plataforma e o mecanismo. Deixá-la implícita é o problema.
Dia 3: Um arquivo de dados “igual” acabou sendo diferente
Depois de fixar a ordem dos eventos, as divergências restantes se concentravam em algumas operações com ações. O fornecedor havia corrigido um ajuste histórico de desdobramento. Nosso arquivo tinha o mesmo nome e a mesma quantidade de linhas de antes, o que nos levou a pensar que nada havia mudado.
Agora calculamos uma impressão digital de cada snapshot de dados imutável e mantemos a política de ajustes junto com ele. Um hash nos diz se os bytes mudaram; não explica por quê. Por isso, o manifesto também registra a fonte, o horário de obtenção e a versão da transformação. Para dados que são revisados, esses detalhes fazem parte do resultado.
Um backtest reproduzível precisa responder à pergunta: “qual versão do passado ele viu?”
Dia 4: Encontramos uma configuração padrão discreta
A última diferença era uma taxa maker definida como zero porque a configuração da estratégia não incluía esse campo. Uma versão mais recente do mecanismo aplicou a taxa padrão da conta. Essa única configuração padrão alterou as operações marginais o suficiente para explicar a maior parte da diferença no saldo final.
Deixamos explícitas as configurações com impacto econômico e fizemos o mecanismo imprimir a configuração resolvida no registro da execução. As configurações padrão são convenientes durante a exploração. Elas são evidências fracas quando comparamos resultados ao longo do tempo.
O que faríamos diferente da próxima vez
Passamos meio dia comparando métricas agregadas antes de olhar o primeiro fill divergente. Não comece por aí. Ordene os dois registros de eventos por timestamp e compare a primeira divergência; as diferenças seguintes muitas vezes decorrem daquela causa inicial.
Também deixaríamos de acreditar que uma imagem de contêiner, por si só, torna uma execução reproduzível. Ela fixa boa parte do ambiente de software, mas não um arquivo de dados externo, uma tabela de taxas consultada em tempo de execução ou o histórico revisado de um fornecedor.
Quando um backtest muda, preserve os dois manifestos e registros de execução e, em seguida, corrija uma fonte de divergência por vez. O resultado útil não é apenas uma curva que você consegue gerar novamente. É um registro que explica quais dados e premissas a produziram e por que a próxima execução pode ser diferente.
← Todos os artigos
