Como detectar viés de antecipação no backtest de um bot de trading

Comece pela linha do tempo das informações

Para cada operação, registre quatro eventos: quando os dados subjacentes foram publicados, quando a estratégia pôde lê-los, quando a decisão ocorreu e quando uma ordem poderia ser executada. O horário de um candle frequentemente marca sua abertura, não o momento em que máxima, mínima e fechamento finais eram conhecidos. Fluxos de dados da corretora, calendários de mercado e limites de sessão podem alterar o momento exato de disponibilidade.

Considere um candle de cinco minutos marcado como 10:00 que cobre de 10:00 até pouco antes de 10:05. Uma regra baseada no fechamento final não pode conhecer esse fechamento às 10:00. Se o backtest registra uma compra na abertura das 10:00 porque o mesmo candle acabou fechando acima de um limiar, ele cruzou a fronteira da informação. Mesmo uma execução no fechamento das 10:05 exige um simulador que realmente suporte esse momento; uma estratégia padrão que decide no fechamento costuma executar uma ordem a mercado no próximo tick disponível, geralmente na abertura do candle seguinte.

Esse é um exemplo hipotético de horários, não uma operação real ou resultado de desempenho da TensorParadigm.

Sintomas que justificam uma auditoria

Uma curva de patrimônio suave, entradas quase perfeitas em pontos de virada ou retornos que desabam após deslocar o sinal um candle adiante merecem inspeção. Nenhum desses sinais prova vazamento por si só. Market making e alguns sistemas de horizonte curto têm formatos incomuns por outros motivos; por outro lado, uma estratégia com vazamento ainda pode perder dinheiro.

• As operações aparecem na máxima ou mínima do mesmo candle, embora a regra precise do fechamento completo dele.
• Indicadores de uma hora mudam dentro de um candle anterior de cinco minutos em um teste histórico.
• Uma variável tem correlação surpreendentemente forte com um retorno ou rótulo futuro.
• O resultado de treinamento e teste muda drasticamente depois que o pré-processamento é ajustado separadamente nos dados de treinamento.
• O backtest registra execuções antes que a cotação ou observação relevante estivesse disponível.

Verifique solicitações de periodicidades superiores no Pine Script

O TradingView documenta que usar request.security() para uma periodicidade superior com barmerge.lookahead_on pode expor valores finais dessa periodicidade cedo demais nos candles históricos se a expressão solicitada não tiver deslocamento. Por exemplo, fornecer o fechamento final de uma hora ao primeiro candle de cinco minutos dessa hora permite que a regra de cinco minutos veja o fim da hora antes de ele ocorrer.

Para uma estratégia que só precisa do candle anterior completo da periodicidade superior, o padrão documentado pelo TradingView que evita repainting desloca a expressão solicitada em um candle dessa periodicidade enquanto usa lookahead_on. Isso alinha a disponibilidade histórica e em tempo real nesse caso. Não copie esse padrão indiscriminadamente para solicitações de periodicidades inferiores ou regras que negociam intencionalmente valores ainda em formação.

Inspecione cada expressão request.security(), sua periodicidade, a configuração de lookahead e o índice de candle usado nas decisões. Verifique também se os cálculos estão confirmados na periodicidade do gráfico. Corrigir uma entrada de periodicidade superior não corrige um simulador que ainda concede uma execução irrealisticamente antecipada.

Audite a criação de variáveis em Python antes do ajuste

Uma média móvel centralizada utiliza observações dos dois lados do horário atual. Um deslocamento negativo em uma coluna de variável pode colocar o valor de amanhã na linha de hoje. Ambos podem ser válidos para um rótulo usado posteriormente para avaliar previsões; nenhum deve fazer parte das variáveis disponíveis para uma decisão real hoje.

Monte uma pequena tabela com colunas para decision_time, source_time e available_time de cada variável, target_window_end, signal_time e earliest_fill_time. Verifique que available_time não seja posterior a signal_time para nenhuma variável. Se criar rótulos como retorno do próximo candle, mantenha-os fora das entradas do modelo, dos metadados associados e de pré-processamentos que possam revelar a resposta indiretamente.

Dados de eventos exigem seu horário real de divulgação ou ingestão. Uma taxa de funding, uma série macroeconômica revisada ou uma notícia com um horário de mercado atribuído ainda pode chegar depois desse horário. Retratos dos dados em cada momento e históricos de revisão importam quando essas entradas orientam operações.

Divida cronologicamente e ajuste o pré-processamento dentro de cada partição

Uma divisão aleatória permite que o modelo treine em regimes posteriores e teste em observações anteriores. O TimeSeriesSplit do scikit-learn preserva a ordem cronológica de treinamento e teste e oferece um intervalo entre eles. Escolha esse intervalo com base no horizonte do rótulo e nas janelas de observação sobrepostas; ele não é um número fixo universal.

Calcule escalonamento, imputação, seleção de variáveis e seleção de hiperparâmetros usando apenas os dados de treinamento em cada divisão. Um Pipeline do scikit-learn ajuda a manter as transformações dentro da validação cruzada. Mesmo um escalonador não supervisionado treinado na amostra completa aprende propriedades do período futuro de teste. Um período final de avaliação intocado ajuda a avaliar as escolhas feitas durante o desenvolvimento.

Mudar repetidamente a estratégia depois de ver o conjunto de teste é viés de seleção ou sobreajuste, mesmo quando nenhuma variável individual contém dados futuros. Registre os experimentos e distinga esse problema do vazamento direto por antecipação.

Concilie sinais com execuções simuladas de ordens

O momento do sinal e o da execução são separados. O emulador de corretora do TradingView normalmente cria uma ordem em um tick de cálculo e só pode executá-la em um tick disponível posterior. Sua opção process_orders_on_close pode tentar execuções no tick de fechamento do candle. Outras configurações intrabar e tipos de ordem também podem mudar o modelo de execução, então leia as configurações reais da estratégia antes de declarar uma diferença de um candle como erro.

Para cada operação suspeita, exporte ou registre os valores dos indicadores usados, a confirmação do fechamento, o horário de criação da ordem, o tipo de ordem e o horário e preço informados da execução. Pergunte se o preço indicado era alcançável após a decisão. Inclua separadamente as premissas de spread, comissão e slippage: elas não corrigem vazamento, mas afetam se o backtest corrigido tem valor econômico.

Execute três verificações de refutação

Primeiro, atrase cada sinal em um candle completo do gráfico e meça quanto o resultado muda. Isso é um diagnóstico, não uma correção automática: um sinal rápido válido também pode enfraquecer com atraso. Segundo, recalcule os indicadores um candle de cada vez em uma reprodução cronológica e compare-os com o cálculo do histórico completo em cada horário de decisão. Terceiro, execute novamente após reconstruir cada partição de treinamento de forma independente e congelar a estratégia antes de verificar um período posterior.

Quando os resultados divergirem, rastreie a primeira operação incompatível, em vez de comparar apenas o lucro principal. Identifique o campo exato de dados ou a execução que não poderia ter existido no horário informado. Depois de corrigir, repita o teste com custos de execução e alterações razoáveis nos parâmetros. Um resultado que resiste é uma evidência melhor, não uma garantia de desempenho real.

Uma auditoria concreta de uma operação suspeita

Suponha que um bot compre na abertura das 10:00 porque um candle de cinco minutos fecha acima de sua máxima anterior. Registre a abertura das 10:00 como execução proposta, a conclusão às 10:05 como o primeiro momento em que o fechamento final é conhecido, e os horários reais de decisão e ordem da estratégia. A condição depende de informações posteriores à execução proposta, então essa operação registrada é inválida sob essa regra.

Se o código for corrigido para decidir às 10:05, inspecione o que o mecanismo de execução realmente faz em seguida. Uma execução a mercado no próximo tick pode ocorrer perto da abertura do candle seguinte; a opção de tick de fechamento é uma premissa diferente e pode não corresponder a um alerta real que chega depois de o mercado se mover. Não mantenha o preço antigo de entrada ao mover apenas o horário do sinal.

Agora verifique qualquer filtro de uma hora na mesma operação. Se ele lê o fechamento final da hora antes de ela terminar, a entrada de cinco minutos continua contaminada mesmo após corrigir o horário da execução. Tanto a disponibilidade das entradas quanto as execuções precisam passar na verificação.

O que um backtest sem vazamento pode ou não dizer

Remover o vazamento de dados futuros restaura um requisito básico de um teste confiável. Não estabelece que a estratégia sobreviverá a mudanças de regime, interrupções, spreads maiores, pagamentos de funding, liquidez insuficiente ou limites de risco. Um backtest válido ainda pode representar um sistema de trading ruim.

Preserve versões dos dados, código da estratégia, custos, escolhas de parâmetros e limites das partições para que o teste seja reproduzível. Ao descobrir um defeito, divulgue tanto o resultado suspeito quanto o corrigido, explicando a mudança. Uma correção transparente é mais útil do que uma curva de patrimônio polida.