Um teste de backtest útil não serve para encontrar um parâmetro melhor: pare o processo a meio, restaure-o e termine a mesma reprodução. Com entradas idênticas e um simulador de execução controlado, as decisões, as ordens e o capital próprio devem coincidir com uma execução sem interrupções.
Se não coincidirem, encontrou um problema de gestão de estado. A estratégia depende de algo que não guardou ou não conseguiu reconstruir. Essa dependência importa sempre que as execuções de investigação são retomadas, os workers são substituídos ou um serviço de paper trading recebe código novo.
Gosto deste teste porque a resposta esperada é invulgarmente clara. Não há discussão sobre se o mercado mudou. Ambas as execuções recebem o mesmo mercado.
Eis três formas erradas de reiniciar. Os números são ilustrativos; cada falha pode ocorrer num sistema determinístico em todos os outros aspetos.
1. Carregar algumas barras e considerar os indicadores preparados
Suponha que uma estratégia usa uma média móvel exponencial de 100 períodos. A sua atualização é:
alpha = 2 / 101
ema_next = alpha * close + (1 - alpha) * ema_previousO processo ininterrupto transporta consigo a EMA acumulada. O processo reiniciado carrega 100 barras, inicializa a EMA com o primeiro fecho e parte do princípio de que um indicador de 100 períodos precisa de 100 observações.
Esta suposição confunde o parâmetro de suavização do indicador com uma janela de memória finita. Uma EMA mantém uma contribuição decrescente do seu estado inicial. Se duas versões começarem com uma diferença de 10 unidades de preço na EMA, os mesmos preços subsequentes reduzem essa diferença da seguinte forma:
| Atualizações desde a inicialização | Diferença restante | Fração do erro inicial |
|---|---|---|
| 100 | 1.353 | 13.53% |
| 250 | 0.0674 | 0.674% |
| 500 | 0.000454 | 0.00454% |
O cálculo é 10 * (99 / 101)^k. Carregar 100 barras dá-lhe apenas 99 atualizações, se a primeira observação servir de valor inicial.
O estrago costuma surgir junto de um limiar de decisão. Uma execução vê o preço acima da EMA; a outra vê-o abaixo. Uma pequena diferença numérica cria uma operação adicional. A partir daí, os períodos de espera, o dinheiro disponível e as decisões seguintes também podem divergir.
Guarde o estado recursivo do indicador, o estado de inicialização e o último evento processado. Em alternativa, reproduza os dados a partir de um estado inicial conhecido. Um período de aquecimento mais longo pode dar uma aproximação aceitável, mas escolha a sua duração com base numa tolerância de erro explícita e verifique se essa tolerância pode alterar 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 após uma perda tem de se lembrar da perda e do contador.
2. Guardar as posições e esquecer as ordens em curso
A posição-alvo é de 10 unidades. Uma ordem de compra de 10 foi executada em 4, ficando 6 por executar. Guarda a posição como 4 num checkpoint, reinicia e envia outra ordem de compra para as 6 em falta.
Se o remanescente original e a ordem de substituição forem ambos executados, fica com 16 unidades.
A versão deste erro no backtest passa muitas vezes despercebida porque o reinício do motor de execução apaga silenciosamente as ordens ativas. No paper trading, o simulador ou o serviço externo pode mantê-las. O mesmo código de recuperação produz então uma exposição diferente, consoante o componente que sobreviveu.
| No reinício | Estado real | O que a recuperação baseada apenas na posição deteta |
|---|---|---|
| Posição-alvo | 10 | 10 |
| Posição executada | 4 | 4 |
| Quantidade de compra pendente | 6 | 0 |
| Quantidade adicional necessária | 0 | 6 |
O estrago manifesta-se numa vaga inexplicável de ordens imediatamente após a recuperação. Por vezes, duplica a exposição. Outras vezes, fecha uma posição cuja ordem de proteção continua ativa, permitindo que essa ordem abra uma nova posição mais tarde.
Um checkpoint precisa de 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 tem de reconciliar esses registos com o sistema de execução. Uma ordem cujo resultado é desconhecido precisa de ser investigada; assumir que «nenhuma confirmação guardada» significa «nunca enviada» é assim que nascem as ordens duplicadas.
Os identificadores de ordem do cliente estáveis ajudam a consultar o que aconteceu. Só evitam duplicados quando o sistema recetor aplica efetivamente as regras de unicidade ou idempotência necessárias. Persista também os identificadores das execuções processadas, para que uma execução reproduzida não aumente a posição duas vezes.
Tenho uma certa predileção pelo banal ecrã de estado das ordens. No dia do reinício, aquelas pequenas linhas tornam-se de repente a interface mais interessante do edifício.
3. Restaurar a posição e começar um novo livro de resultados
Considere um exemplo à vista, sem alavancagem nem comissões. Comece com $10,000 em dinheiro, compre 10 unidades a $100 e crie um checkpoint quando a cotação atingir $110.
O estado correto é $9,000 em dinheiro mais uma posição no valor de $1,100: capital próprio de $10,100. Se a recuperação restaurar as 10 unidades, mas repuser o dinheiro para os $10,000 iniciais, apresenta $11,100. Criou $1,000 do nada ao reiniciar um processo.
Há variantes menos espetaculares. A recuperação mantém intacto o capital próprio, mas repõe o preço de entrada em $110. O capital próprio total pode continuar correto, enquanto a atribuição entre resultados realizados e não realizados muda. Se um stop ou condição de saída fizer referência ao preço de entrada, este atalho contabilístico passa a alterar o comportamento de negociação.
Ou o sistema esquece o máximo anterior do capital próprio. Suponha que este atingiu um pico de $10,600 antes de cair para $10,100. A sua perda máxima é de cerca de 4.72%. Se repuser o máximo histórico durante a recuperação, a estratégia passa subitamente a acreditar que a perda máxima é zero. Qualquer controlo de risco baseado na perda máxima acabou de ser reposto sem autorização.
O estrago pode, portanto, surgir como uma descontinuidade no capital próprio, uma melhoria suspeita da perda máxima ou uma regra de risco que deixa de ser acionada após as implementações. Preserve o livro de contabilidade e o estado da estratégia que dele depende: movimentos de dinheiro, posições, custo de aquisição aplicável, encargos acumulados e memória dos controlos de risco. Reconcilie o capital próprio restaurado com o livro de contabilidade à mesma hora de valorização.
Um checkpoint precisa de um limite consistente. Guardar o dinheiro depois de uma execução e a quantidade da posição antes dessa mesma execução cria um estado que nunca existiu. Grave os estados relacionados em conjunto ou registe uma sequência duradoura de eventos que permita reconstruí-los. Guarde o cursor dos eventos com esse estado, para que a recuperação não ignore a execução nem a aplique duas vezes.
No ambiente de investigação, manteria um teste que executa primeiro uma reprodução de referência sem interrupções e depois reinicia uma segunda execução em pontos deliberadamente complicados: durante a inicialização dos indicadores, após uma execução 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 registos de ordens e execuções e a evolução do capital próprio. Um saldo final coincidente pode esconder erros que se anulam entre si.
Para uma falha após o envio, mas antes da confirmação, o ambiente de testes também tem de preservar o estado do serviço de execução de forma independente do processo da estratégia. Caso contrário, apaga a própria incerteza que está a tentar testar.
A especificação de uma estratégia inclui aquilo de que se lembra. Torne essa memória suficientemente explícita para poder terminar o processo a meio de uma reprodução e mostrar exatamente como retoma o trabalho.
← Todos os artigos
