Data leakage e viés de antecipação

Data leakage é a passagem de informação proibida entre etapas da pesquisa. O viés de antecipação (look-ahead bias) é o caso temporal em que a regra usa, direta ou indiretamente, informação futura. Ambos podem surgir nos dados, nas transformações, na seleção do modelo, na validação ou no simulador de ordens.

Distinções essenciais

Os problemas podem coexistir, mas pedem controles diferentes. Separar treino e teste não corrige um dataset já revisado com o futuro; dados point-in-time não eliminam a seleção entre centenas de modelos.

Três relógios: sinal, ordem e fill

Uma regra de trading deve declarar pelo menos três momentos:

1. Horário do sinal: quando o sinal está pronto, distinto do corte da informação admitida no cálculo.
2. Horário da ordem: criação e envio, seguidos de chegada e aceitação no mercado.
3. Horário do fill: instante ou intervalo em que a ordem admitida pode encontrar preços e quantidades compatíveis.

Se a decisão exige o preço final close[t], não pode determinar a participação no mesmo leilão que forma esse preço. Uma ordem de fechamento enviada antes deve respeitar os cortes do mercado e usar a informação então disponível: a ficha da NYSE citada separa a entrada de ordens do processo de leilão. Um fill posterior poderia ter o mesmo preço numérico, mas não o mesmo instante. A máxima e a mínima definitivas da barra não são inputs disponíveis antes de sua conclusão; um replay intrabar deve mostrar apenas os eventos já observados em cada decisão.

Para comunicados, documentos regulatórios e dados macro, a data do período econômico não é o horário de divulgação. A estratégia também deve ter recebido e poder processar o dado. Os dados point-in-time preservam versões (vintages): uma revisão posterior não substitui a disponível na decisão. O ALFRED reconstrói o que era conhecido em uma data histórica; sozinho, não certifica o horário intradiário nem a latência do fornecedor utilizado.

Onde o leakage se esconde

Features e transformações

Normalizar com média e desvio da amostra inteira, preencher missing com valor calculado no futuro, ajustar PCA ou selecionar features antes do split transfere informação. Cada etapa com estado deve ser ajustada apenas no treino e aplicada ao período seguinte. Fundamental e macro exigem vintages e datas de publicação.

Para padronizar uma variável: z = (x − média_train) / desvio_train. Média e desvio são estimados no treino de cada fold e reutilizados no respectivo teste; é preciso tratar também o desvio nulo. O scikit-learn distingue fit de transform.

Pesquisa e seleção

O data snooping reutiliza a amostra para inferência ou seleção: pode produzir um vencedor por acaso mesmo quando todos os inputs respeitam o tempo. Portanto, difere do viés de antecipação.

Consultar repetidamente o holdout, escolher a melhor janela após ver o teste ou publicar apenas estratégias vencedoras torna a avaliação parte do treinamento. O registro de tentativas e um teste final intacto tornam essa seleção visível.

Ordens e execução

Um preço OHLC não prova que uma ordem seria executada: limites podem ser tocados sem fill, a quantidade pode faltar e a prioridade na fila pode ser desconhecida. Atribuir sempre o extremo mais favorável da barra usa retrospectiva. O simulador precisa de sequência, latência, quantidade e prioridade compatíveis com a chegada da ordem. Usar o volume completo antes do fim da barra ou uma composição ainda não anunciada contamina a decisão.

Protocolo causal

1. Definir o instante da decisão, o corte informativo e o primeiro instante executável.
2. Versionar os dados segundo publicação, ingestão e revisão.
3. Na decisão t, excluir registros com available_at > t e selecionar a versão então disponível de cada dado; documentar como available_at foi construído.
4. Ajustar imputação, escala e seleção de variáveis no treino de cada fold e aplicar ao teste as transformações aprendidas. Selecionar parâmetros com validação, preservando o teste final.
5. Usar no treino apenas labels já observáveis no seu corte; avaliar purge e gaps conforme os intervalos informativos reais, não só a proximidade das linhas.
6. Preservar composição histórica, eventos corporativos e a especificação da estratégia.
7. Modelar ordens e fills em eventos posteriores ao sinal.
8. Registrar todas as consultas ao holdout e todos os candidatos.
9. Reproduzir o processo a partir de um snapshot limpo, sem arquivos construídos com informação futura.

Testes diagnósticos

Truncar o dataset numa data antiga e recalcular tudo: valores anteriores não devem mudar sem revisão explicitamente versionada. Atrasar artificialmente inputs deve atrasar sinais. Um resultado alto com labels aleatórias é suspeito; mudanças de performance após perturbações não identificam sozinhas a causa. Comparar batch com execução sequencial ajuda a encontrar transformações globais. Esses testes detectam classes de erro, mas não provam ausência total de leakage.

Dependência entre observações e etapas aprendidas

A label é o resultado a prever. Por exemplo, o retorno dos cinco pregões após a linha t só é conhecido depois desses pregões. Usá-lo como alvo de um treino posterior é normal; incluí-lo nos inputs de t, ou num treino encerrado antes de sua realização, introduz informação futura. Excluir labels que ultrapassam o corte difere de proibir qualquer correlação entre observações. O gap do scikit-learn conta linhas excluídas: não reconstrói automaticamente duração e disponibilidade de cada label.

Toda etapa que aprende com dados pertence ao treino: imputação, seleção de variáveis, winsorization, normalização, redução de dimensionalidade e escolha de limiares. Primeiro ela é ajustada dentro do segmento permitido; depois é aplicada, sem reaprender, ao segmento seguinte. Fazer o pré-processamento uma única vez no dataset completo torna o teste parcialmente conhecido, mesmo que o modelo principal nunca tenha visto suas linhas.

Há ainda uma diferença entre processamento em lote e operação sequencial. Um arquivo produzido ao fim do dia pode conter correções e registros que não existiam quando uma decisão intradiária foi tomada. Por isso, um teste causal deve reconstruir não só a data do dado, mas a ordem de chegada e a primeira janela de execução possível. Logs de ingestão, snapshots e testes de atraso ajudam a localizar essa ruptura.

Limites

Nem toda correlação forte é leakage, e um resultado fraco não garante pipeline causal. Algumas fontes não preservam vintages; microestrutura pode exigir dados indisponíveis; labels sobrepostas criam dependência mesmo com ordem temporal. Lacunas devem ser declaradas e testadas por sensibilidade.

Fontes

• Halbert White, A Reality Check for Data Snooping, Econometrica, 2000 — inferência quando o resultado selecionado emerge de muitas especificações.
• Robert D. Arnott, Campbell R. Harvey e Harry Markowitz, A Backtesting Protocol in the Era of Machine Learning — separação entre pesquisa, seleção, holdout e escassez de dados financeiros.
• David H. Bailey, Jonathan M. Borwein, Marcos López de Prado e Qiji Jim Zhu, The Probability of Backtest Overfitting — risco de sobreajuste decorrente da seleção entre muitas configurações.
• Federal Reserve Bank of St. Louis, FRED® versus ALFRED® — diferença entre história conhecida hoje e vintage conhecido no passado.
• scikit-learn, Common pitfalls — Data leakage e StandardScaler — treinamento, pré-processamento e aplicação ao teste.
• NYSE, Opening and closing auctions, p. 2 — sequência de entrada de ordens e leilão de fechamento no mercado descrito.
• scikit-learn, TimeSeriesSplit — validação cruzada ordenada no tempo e parâmetro de gap; documentação técnica oficial.

Conexões

• Trading sistemático: estratégias, backtest e validação
• Backtest
• Dados point-in-time
• Viés de sobrevivência
• Out of sample