Um snapshot congelado de dados de mercado não basta para tornar um backtest fiável. Pode reproduzir o mesmo resultado e, ao mesmo tempo, ocultar que o fornecedor alterou os dados que lhe deram origem.
Guarda o snapshot. Depois, mantém um registo de alterações que indique o que mudou, quando mudou e se a estratégia foi afetada. Isto é especialmente importante quando a investigação usa transações corrigidas, dados fundamentais revistos, financiamento reconstruído ou um histórico que o fornecedor atualizou discretamente.
Como pode um backtest reproduzível continuar a induzir-te em erro?
Imagina que descarregas 5 anos de barras horárias na segunda-feira e executas uma estratégia. Na sexta-feira, o fornecedor já corrigiu uma transação incorreta, ajustou uma ação societária ou preencheu uma lacuna. O ficheiro que guardaste continua a produzir exatamente o resultado de segunda-feira. Isso é reprodutibilidade. Mas, se voltares a executar a estratégia com o histórico atual do fornecedor, podes obter um resultado diferente e não ter qualquer registo do motivo.
O problema não se limita a correções drásticas. Uma única máxima alterada pode acionar um stop; um fecho revisto pode fazer um indicador ultrapassar o seu limiar. Num universo amplo, o histórico de um símbolo pode alterar a sua classificação e excluir outro ativo da carteira. O Sharpe final pode variar mesmo que o código e a configuração da estratégia sejam idênticos.
Um hash de ficheiro diz-te que dois ficheiros são diferentes. Não te diz se um ajuste por split alterou 40 anos de preços, se o fornecedor corrigiu 3 transações ou se um parser converteu um campo vazio em zero.
O que deve incluir um registo de alterações dos dados de mercado?
Regista as alterações com a menor granularidade que seja útil e com contexto suficiente para voltares a executar a investigação afetada. Num feed de barras, isso costuma incluir o instrumento, o intervalo, a hora do evento, os valores anteriores e novos, a origem e a hora em que observaste a atualização. Guarda o payload original quando o fornecedor o disponibilizar.
| Registo | Porquê guardá-lo | Exemplo |
|---|---|---|
| Versão da origem ou hora de obtenção | Identifica o estado do fornecedor utilizado | Snapshot obtido em 2026-11-02 08:15 UTC |
| Campo alterado e valores antigo/novo | Mostra o que mudou efetivamente | ETHUSDT 1h máxima: 3,412.10 → 3,418.60 |
| Classificação da alteração | Distingue correções de transformações | Correção tardia de transação, ajuste por split, preenchimento retroativo |
| Versão do pipeline e do esquema | Distingue alterações na origem do processamento feito por ti | Normalizador v7, esquema de barras ajustadas v3 |
Para conjuntos de dados grandes, guarda snapshots imutáveis e um manifesto compacto com os respetivos checksums, versões da origem e horas de obtenção. Acrescenta diferenças ao nível das linhas para as partições alteradas. Assim, tens uma solução intermédia prática: é possível reproduzir integralmente a análise sem escrever cada linha inalterada numa segunda tabela de auditoria.
Como meço se uma correção é relevante?
Não te limites a contar as linhas alteradas. Volta a executar a estratégia afetada com os dados antigos e os novos, mantendo o mesmo código, parâmetros, comissões e pressupostos de execução. Compara as decisões e o percurso até ao resultado.
- Identifica os instrumentos e as horas dos eventos afetados com base nas diferenças.
- Determina quais as features, sinais, ordens ou ponderações da carteira que usam esses registos.
- Repete a execução na menor janela válida, incluindo o lookback e o estado das posições abertas.
- Compara ordens, execuções, exposição, volume de negócios, drawdown e desempenho final.
Por exemplo, uma correção do fornecedor que altere uma máxima de 1 minuto em $0.02 pode afetar 1 milhão de linhas sem ter qualquer efeito numa estratégia de momentum diária. Uma única barra corrigida num nível de stop pode ter mais impacto. Mede o efeito nas decisões; a contagem de registos alterados é um indicador fraco desse efeito.
Mantém separadas estas duas perguntas: “Consigo reproduzir o resultado com os dados que guardei?” e “Esta versão dos dados estaria disponível para a estratégia naquela altura?” Um registo de alterações ajuda a responder a ambas, mas a segunda também exige registos de disponibilidade point-in-time.
Qual é o custo e quando compensa?
O acompanhamento de alterações exige armazenamento, trabalho de ingestão e decisões operacionais. Os fornecedores podem não disponibilizar versões estáveis e alguns feeds históricos são reconstruídos periodicamente sem aviso claro das correções. Não podes registar uma alteração que nunca observas.
Começa pelos dados cujas revisões podem alterar as conclusões da investigação: barras usadas pela lógica de stop, ações ajustadas por ações societárias, dados fundamentais point-in-time e séries de financiamento ou de open interest que são reconstruídas. Um manifesto diário e checksums por partição podem bastar para conjuntos de dados amplos e estáveis. Acrescenta diferenças ao nível dos campos onde as atualizações são frequentes ou as decisões de trading dependem de registos individuais.
Os críticos têm razão: um arquivo completo e permanente de todas as respostas dos fornecedores pode tornar-se dispendioso e, ainda assim, não registar o que a origem sabia na altura. A solução é limitar a auditoria aos dados e às decisões relevantes e documentar as lacunas. Um snapshot permite voltar a executar uma experiência. Um registo de alterações permite explicar por que mudou o resultado da experiência.
← Todos os artigos
