Reinicie sua estratégia no meio do backtest. Ela se lembra do que possui?

Um teste útil de backtest não tem nada a ver com encontrar um parâmetro melhor: interrompa o processo pela metade, restaure-o e conclua o mesmo replay. Com entradas idênticas e um simulador de execução controlado, as decisões, ordens e o patrimônio devem corresponder aos de uma execução ininterrupta.

Se não corresponderem, você encontrou um problema de gerenciamento de estado. A estratégia depende de algo que você não salvou ou não conseguiu reconstruir. Essa dependência importa sempre que execuções de pesquisa são retomadas, workers são substituídos ou um serviço de paper trading implanta código novo.

Gosto desse teste porque a resposta esperada é excepcionalmente clara. Não há discussão sobre se o mercado mudou. As duas execuções recebem o mesmo mercado.

Veja três maneiras erradas de reiniciar. Os números são ilustrativos; cada falha pode ocorrer em um sistema determinístico em todos os outros aspectos.

1. Recarregar algumas barras e considerar os indicadores aquecidos

Suponha que uma estratégia use uma média móvel exponencial de 100 períodos. Sua atualização é:

alpha = 2 / 101
ema_next = alpha * close + (1 - alpha) * ema_previous

O processo ininterrupto mantém o valor acumulado da EMA. O processo reiniciado busca 100 barras, inicializa a EMA com o primeiro fechamento e supõe que um indicador de 100 períodos precisa de 100 observações.

Essa suposição confunde o parâmetro de suavização do indicador com uma janela finita de memória. Uma EMA mantém uma contribuição decrescente de seu estado inicial. Se duas versões começarem com uma diferença de 10 unidades de preço na EMA, preços subsequentes idênticos reduzirão essa diferença da seguinte forma:

O cálculo é 10 * (99 / 101)^k. Buscar 100 barras fornece apenas 99 atualizações se a primeira observação servir de semente.

O estrago costuma aparecer perto de um limite de decisão. Uma execução vê o preço acima da EMA; a outra o vê abaixo. Uma pequena diferença numérica cria uma operação a mais. Depois disso, os períodos de espera, o caixa disponível e as decisões seguintes também podem divergir.

Salve o estado recursivo do indicador, seu status de inicialização e o último evento processado. Como alternativa, reproduza os eventos a partir de um estado inicial conhecido. Um aquecimento mais longo pode produzir uma aproximação aceitável, mas escolha sua duração com base em uma tolerância explícita de erro e verifique se essa tolerância pode alterar as decisões. “Cinco vezes o período” é uma convenção, não uma prova.

E os indicadores não são todo o histórico. Um percentil móvel precisa da sua janela. Um modelo online pode precisar do estado do otimizador. Uma regra que espera 3 barras depois de uma perda precisa se lembrar da perda e do contador.

2. Salvar posições e esquecer as ordens em andamento

Sua posição-alvo é de 10 unidades. Uma ordem de compra de 10 foi executada em 4, restando 6 em aberto. Você salva um checkpoint da posição em 4, reinicia e envia outra ordem de compra pelas 6 que faltam.

Se o restante da ordem original e a ordem substituta forem executados, você ficará com 16 unidades.

A versão desse bug no backtest muitas vezes passa despercebida porque reiniciar o mecanismo de execução apaga silenciosamente as ordens em aberto. No paper trading, o simulador ou serviço externo pode mantê-las. O mesmo código de recuperação produz então uma exposição diferente, dependendo de qual componente sobreviveu.

O estrago aparece como uma enxurrada inexplicável de ordens logo após a recuperação. Às vezes, a exposição dobra. Às vezes, uma posição é encerrada enquanto sua ordem de proteção continua ativa, podendo abrir uma nova posição mais tarde.

Um checkpoint precisa incluir a identidade e o estado do ciclo de vida das ordens, além das posições. Antes de gerar novas ações, a recuperação precisa reconciliar esses registros com o sistema de execução. Uma ordem cujo resultado é desconhecido precisa ser investigada; tratar “nenhuma confirmação salva” como “nunca enviada” é assim que surgem ordens duplicadas.

Identificadores de ordem do cliente estáveis ajudam você a consultar o que aconteceu. Eles só evitam duplicatas quando o sistema receptor realmente aplica as regras de exclusividade ou idempotência exigidas. Persista também os identificadores das execuções processadas, para que um fill reproduzido não aumente a posição duas vezes.

Tenho um carinho especial pela sem graça tela de status das ordens. No dia do reinício, suas pequenas linhas de repente viram a interface mais interessante do prédio.

3. Restaurar a posição e começar um novo livro de P&L

Considere um exemplo de spot sem alavancagem e sem taxas. Comece com $10,000 em caixa, compre 10 unidades a $100 e salve um checkpoint quando a marcação chegar a $110.

O estado correto é $9,000 em caixa mais uma posição no valor de $1,100: patrimônio de $10,100. Se a recuperação restaurar as 10 unidades, mas reiniciar o caixa em $10,000, ela informará $11,100. Você fabricou $1,000 ao reiniciar um processo.

Outras versões são menos espetaculares. A recuperação mantém o patrimônio intacto, mas reinicia o preço de entrada em $110. O patrimônio total pode continuar correto enquanto a atribuição entre realizado e não realizado muda. Se um stop ou uma condição de saída usar o preço de entrada, esse atalho contábil passa a alterar o comportamento de negociação.

Ou o sistema se esquece do pico anterior do patrimônio. Suponha que o patrimônio tenha atingido o pico de $10,600 antes de cair para $10,100. O drawdown é de cerca de 4.72%. Reinicie a máxima histórica na recuperação e, de repente, a estratégia acredita que o drawdown é zero. Qualquer controle de risco baseado em drawdown acabou de receber uma redefinição não autorizada.

O estrago pode, portanto, aparecer como uma descontinuidade no patrimônio, um drawdown suspeitosamente menor ou uma regra de risco que deixa de ser acionada depois das implantações. Preserve o livro contábil e o estado da estratégia que depende da contabilidade: movimentos de caixa, posições, custo de aquisição aplicável, encargos acumulados e memória dos controles de risco. Reconcilie o patrimônio restaurado com o livro contábil no mesmo instante de avaliação.

No ambiente de pesquisa, eu manteria um teste que executa primeiro um replay de referência sem interrupções e depois reinicia uma segunda execução em pontos deliberadamente complicados: durante a inicialização do indicador, depois de um fill parcial e enquanto um limite de risco está ativo. Use a mesma ordem de eventos e preserve qualquer estado aleatório do simulador. Compare a primeira decisão após a recuperação, os registros de ordens e fills e a trajetória do patrimônio. Um saldo final igual pode esconder erros que se compensam.

Para uma falha depois do envio, mas antes da confirmação, o ambiente de testes também precisa preservar o estado do serviço de execução de forma independente do processo da estratégia. Caso contrário, ele apaga justamente a incerteza que você está tentando testar.

A especificação de uma estratégia inclui o que ela lembra. Torne essa memória explícita o bastante para que você possa encerrar o processo no meio de um replay e mostrar exatamente como ele volta ao trabalho.