Look-ahead Bias é um erro temporal de avaliação em que informações disponíveis mais tarde são usadas numa decisão anterior, no treino ou na seleção de uma regra. A medição posterior do resultado de uma previsão já feita não constitui, por si só, esse erro.
A QuantConnect descreve Look-ahead Bias como decidir com informação que só estaria disponível mais tarde. A nossa pergunta de controlo é, portanto: o que poderia o procedimento realmente saber no instante dessa decisão? Não basta que o dado pertença ao mesmo dia civil. Os momentos do evento, publicação, receção e envio da ordem podem ser diferentes. É necessário demonstrar a disponibilidade de cada entrada e a sequência das operações; uma tabela corretamente ordenada não basta para o provar. [QuantConnect — Custom Securities: Avoid Look-Ahead Bias]
O modelo temporal do LEAN entrega um ponto de dados concluído segundo o seu EndTime. A nossa consequência: o fecho definitivo, o máximo, o mínimo e o volume de todo o período não podem orientar uma decisão anterior dentro desse período. Com vários intervalos temporais, cada série precisa da sua própria regra de disponibilidade. Deslocar uma linha pode corrigir um erro específico, mas não substitui a verificação dos fusos horários, do fim do período e do atraso da fonte. Usar um valor anterior já conhecido é diferente de usar o valor final, conhecido mais tarde, da vela em curso. [QuantConnect — Time Modeling: Timeslices]
A documentação do FRED distingue informação sobre o passado disponível hoje de informação conhecida durante um período histórico; o ALFRED permite selecionar o período de disponibilidade correspondente. A nossa exigência metodológica: ao trabalhar com um dado corrigido mais tarde, é preciso preservar a versão então disponível e a sua publicação. A data do período económico não substitui a data de divulgação. Mesmo uma versão histórica não demonstra, por si só, a disponibilidade intradiária exata; esta deve ser verificada separadamente. Uma correção posterior não pode ser inserida silenciosamente numa decisão anterior. [Federal Reserve Bank of St. Louis — FRED API Real-Time Periods]
O scikit-learn exige aprender as transformações apenas nos dados de treino e depois aplicar a mesma transformação aprendida ao teste. A nossa verificação temporal abrange normalização, preenchimento de valores em falta, seleção de variáveis e alvos de treino. O resultado de um período futuro pode servir para avaliar posteriormente uma previsão; não pode ser usado na criação anterior dessa previsão nem na escolha da regra. No retreino contínuo, só podem entrar no treino alvos já conhecidos naquele momento. [scikit-learn — Common Pitfalls: Data Leakage]
O TradingView explica que o seu emulador de corretora usa pressupostos sobre movimentos dentro da vela ao trabalhar com dados OHLC históricos. A nossa distinção: o máximo e o mínimo registados não determinam, por si só, a ordem real de todos os preços e ordens. O teste deve separar a geração do sinal, o envio e a possível execução. Escolher uma entrada ou saída segundo um extremo conhecido mais tarde é um problema diferente de um modelo de custos simplesmente otimista. Dados mais detalhados podem melhorar a verificação, mas não garantem execução real. [TradingView — Strategies: Broker Emulator and Lookahead Bias]
O Freqtrade compara resultados de testes repetidos e alterações de indicadores ou sinais; também alerta para o acesso a linhas futuras e agregações sobre toda a tabela. A nossa auditoria examina, portanto, não só a sintaxe do deslocamento, mas também a origem de cada cálculo. A documentação limita expressamente a verificação aos sinais ativados durante o teste. Uma saída sem alertas não valida ramos não percorridos. O resultado deve ser lido em conjunto com a cobertura e as definições da simulação; certas configurações de ordens limitadas podem provocar falsos positivos. [Freqtrade — Lookahead Analysis]
O TradingView distingue Look-ahead Bias de Overfitting, isto é, a adaptação das regras a dados de desenvolvimento específicos. A nossa conclusão: mesmo um teste temporalmente admissível pode resultar de uma vasta seleção do vencedor. Inversamente, uma regra simples pode conter fuga de informação futura. Após a correção, é preciso recalcular os resultados e registar a alteração; não se pode manter o relatório lucrativo original. A diferença entre um resultado histórico e um posterior não revela, por si só, se a causa foi um erro temporal, uma mudança de mercado ou outro pressuposto. [TradingView — Strategies: Broker Emulator and Lookahead Bias]
A NFA salienta a diferença entre resultados hipotéticos e negociação real. O nosso registo reproduzível contém, por isso, a versão dos dados e das regras, o instante de disponibilidade das entradas, o estado da conta, a sequência das ordens e os custos descritos. A auditoria deve conseguir reproduzir a decisão apenas com informação então disponível. Paper Trading pode fornecer registos adicionais ao longo do tempo, mas não garante, por si só, a preparação correta dos dados nem liquidez real. Eliminar um erro demonstrado não é prometer um retorno futuro. [NFA — Use of Promotional Material Containing Hypothetical Performance Results]
O lucro obtido com conhecimento do futuro não é uma estratégia disponível
Para ter uma visão mais completa, leia este verbete junto com Backtesting, Overfitting, Walk-forward Analysis, Survivorship Bias, Paper Trading. Também há referências a este verbete em Walk-forward Analysis, Overfitting, Survivorship Bias, On-chain Analysis.
01Basta deslocar todos os indicadores uma linha?+
Não. O deslocamento pode eliminar um uso específico de um valor futuro, mas não resolve automaticamente fusos horários, divulgação tardia, revisões ou preparação dos dados. O que decide é a disponibilidade demonstrada de cada entrada naquele instante.
02Usar um resultado futuro na avaliação é sempre um erro?+
Não. O resultado conhecido mais tarde é necessário para avaliar uma previsão feita antes. O erro surge se essa informação futura entrar na decisão anterior, no treino ou na seleção da regra que produziu a previsão.