Como impedir que um agente de estratégia com IA use informações de amanhã hoje?

Um agente de estratégia com IA pode gerar um backtest válido usando informações que ainda não existiam quando as operações deveriam ocorrer. O código funciona. A curva de patrimônio parece plausível. O sinal pode até fazer sentido. Mesmo assim, um timestamp, uma junção ou um campo de dados revisado pode ter fornecido discretamente a resposta de amanhã.

A solução é incluir o momento em que cada dado se torna disponível no contrato de pesquisa. Para cada entrada, é preciso responder claramente a duas perguntas: a que momento esse valor se refere e quando a estratégia poderia tê-lo conhecido pela primeira vez?

Como o viés de antecipação aparece em uma estratégia gerada por IA?

O caso mais óbvio é um sinal calculado com o fechamento da mesma barra e uma execução nesse fechamento. Se a estratégia precisa do preço de fechamento para decidir, ela não pode também negociar por esse preço. Mas, ao combinar fontes de dados ou escolher padrões convenientes, os agentes muitas vezes criam versões mais sutis desse problema.

Imagine que um modelo calcule uma média móvel de 20 barras no fechamento de cada minuto e assuma uma posição quando o fechamento cruza essa média. Se o backtest executar a ordem nesse mesmo fechamento, ele usou o último negócio da barra antes que esse negócio estivesse disponível para a estratégia. Adiar a ordem para a abertura da barra seguinte pode ser uma aproximação razoável, embora uma ordem a mercado ainda precise considerar taxas e impacto.

Agora, imagine que o recurso seja um dado fundamental diário de ações ou uma fotografia do open interest em cripto. A data da linha pode indicar segunda-feira, mas o valor talvez só tenha sido publicado depois do fechamento de segunda-feira ou tenha sido corrigido mais tarde. Uma data não é um timestamp de disponibilidade.

Como devo registrar o horário das entradas de uma estratégia?

Quando a fonte permitir, mantenha pelo menos 3 horários: o período a que o valor se refere, o horário em que o publicador o divulgou e o horário em que seu sistema o recebeu. No momento da decisão, o conjunto de informações da estratégia só pode incluir valores que já estavam disponíveis.

Em uma estratégia de 1 minuto, um atraso de 1 segundo não é automaticamente inofensivo. Sua importância depende de quando a decisão é tomada e do que o sinal usa. Se a entrada for uma estatística horária já consolidada, talvez quase não faça diferença. Se for um desequilíbrio do livro de ofertas medido perto do envio da ordem, pode inverter a operação.

Um repositório de dados point-in-time pode evitar vazamentos?

Pode ajudar, se “point-in-time” significa que você consegue recuperar o valor conhecido em um momento histórico de decisão, incluindo a revisão vigente naquele momento. Uma tabela que apenas contém datas históricas ainda pode trazer os valores corrigidos hoje para essas datas.

Para cada registro, preserve um intervalo de vigência e um timestamp de disponibilidade, e mantenha as revisões em vez de sobrescrevê-las. Em seguida, deixe explícitas as consultas históricas: retorne a versão mais recente disponível até o momento simulado da decisão. Isso é especialmente importante para dados fundamentais, composição de índices, divulgações econômicas e conjuntos de dados tratados por fornecedores.

Há um detalhe operacional pouco glamouroso: um horário perfeito de divulgação não serve para nada se o processo de ingestão rodou com 20 minutos de atraso. Se o repositório histórico não registrar o horário de ingestão, use um atraso conservador e deixe isso claro. Precisão que a fonte nunca registrou é só enfeite.

Quais testes detectam viés de antecipação antes do paper trading?

Peça ao agente de pesquisa que gere uma linha do tempo dos recursos e das ordens junto com o backtest. Para cada decisão, registre o horário de disponibilidade mais recente da fonte de cada recurso, o horário da decisão, o horário da ordem e o horário de execução modelado. Rejeite qualquer linha em que uma entrada tenha chegado depois da decisão.

• Adiante os sinais em 1 barra e compare os resultados. Uma queda acentuada pode revelar dependência do timing entre fechamentos, embora isso seja um diagnóstico, não uma prova de vazamento.
• Limite cada fonte a um ponto de corte histórico, execute o pipeline novamente e compare os recursos resultantes com os recursos históricos armazenados.
• Substitua um recurso suspeito por uma constante. Se o desempenho continuar quase igual, verifique se o código realmente usou a série esperada.
• Passe pelo pipeline um recurso deliberadamente impossível, que use dados futuros. A validação deve falhar claramente quando o horário de disponibilidade ultrapassar o horário da decisão.

Esses testes não certificam uma estratégia. Eles tornam visíveis pressupostos específicos sobre o timing e detectam formas comuns de violá-los.

O paper trading prova que o backtest não teve vazamentos?

Não. O paper trading pode revelar que o fluxo de dados ao vivo chega atrasado, está incompleto ou está alinhado de forma diferente do histórico. Ele não comprova que os recursos antigos usados no treinamento refletiam o que se sabia na época. Além disso, um modelo pode deixar de se beneficiar de um vazamento simplesmente porque o futuro que viu por engano agora é o presente.

Use o paper trading para verificar a paridade: compare os valores dos recursos ao vivo, os timestamps das decisões, a geração das ordens e as execuções modeladas com as definições do backtest. Quando houver diferenças, rastreie a entrada exata e o relógio. Uma equipe de agentes capaz de explicar o conjunto de informações de cada decisão está fazendo pesquisa útil. Uma equipe que só consegue mostrar uma curva suave deixou de lado a auditoria mais difícil.