Como impedir que um agente de estratégias com IA use hoje informação de amanhã?

Um agente de estratégias com IA pode produzir um backtest válido usando informação que ainda não existia quando as operações deveriam ter ocorrido. O código é executado. A curva de capital parece plausível. O sinal pode até fazer sentido. No entanto, um carimbo temporal, uma junção ou um campo de dados revisto deu-lhe discretamente a resposta de amanhã.

A solução é incluir o momento de disponibilidade no contrato de investigação. Para cada dado de entrada, é preciso responder claramente a 2 perguntas: a que momento se refere este valor e quando poderia a estratégia tê-lo conhecido pela primeira vez?

Como se manifesta o viés de antecipação numa estratégia gerada por IA?

A versão mais óbvia é um sinal calculado a partir do fecho da mesma vela, seguido de uma execução a esse preço de fecho. Se a estratégia precisa do preço de fecho para decidir, não pode também negociar a esse preço. Mas os agentes criam muitas vezes versões mais subtis ao combinar fontes de dados ou escolher valores predefinidos convenientes.

Imaginemos que um modelo calcula uma média móvel de 20 velas no fecho de cada minuto e abre uma posição quando o fecho a cruza. Se o backtest executar a ordem nesse mesmo fecho, usou o último negócio da vela antes de esse dado estar disponível para a estratégia. Adiar a ordem para a abertura da vela seguinte pode ser uma aproximação razoável, embora uma ordem a mercado continue a ter de considerar comissões e impacto.

Agora, façamos da feature um dado fundamental diário de uma ação ou um retrato do open interest de uma criptomoeda. A data da linha pode indicar segunda-feira, mas o valor pode ter sido publicado depois do fecho de segunda-feira ou corrigido mais tarde. Uma data não é um carimbo temporal de disponibilidade.

Como devo registar os carimbos temporais dos dados de entrada de uma estratégia?

Sempre que a fonte o permita, mantenha pelo menos 3 momentos: o período a que o valor se refere, o momento em que o publicador o divulgou e o momento em que o seu sistema o recebeu. O conjunto de informação da estratégia no momento da decisão só pode incluir valores que já estivessem disponíveis nessa altura.

Numa estratégia de 1 minuto, um atraso de 1 segundo não é automaticamente inofensivo. O impacto depende do momento em que a decisão é tomada e dos dados usados pelo sinal. Se o dado de entrada for uma estatística horária já concluída, pode quase não ter importância. Se for um desequilíbrio do livro de ordens registado perto do envio da ordem, pode inverter a operação.

Um armazenamento de dados disponíveis à data pode impedir fugas de informação?

Ajuda, se «disponíveis à data» significar que é possível recuperar o valor conhecido num dado momento histórico de decisão, incluindo a versão em vigor nessa altura. Uma tabela que apenas contenha datas históricas ainda pode incluir os valores corrigidos hoje para essas datas.

Para cada registo, preserve um intervalo de validade e um carimbo temporal de disponibilidade, e mantenha as revisões em vez de as substituir. Depois, torne explícitas as consultas históricas: devolva a versão mais recente que estivesse disponível no momento simulado da decisão. Isto é especialmente importante para dados fundamentais, composição de índices, divulgações económicas e conjuntos de dados tratados por fornecedores.

Há um pormenor operacional pouco vistoso: um carimbo temporal perfeito de divulgação não serve de nada se o processo de ingestão tiver sido executado com 20 minutos de atraso. Se o armazenamento histórico não registar o momento da ingestão, use um atraso conservador e indique-o. A precisão que a fonte nunca registou é apenas decorativa.

Que verificações detetam o viés de antecipação antes do paper trading?

Peça ao agente de investigação que produza uma cronologia das features e das ordens juntamente com o backtest. Para cada decisão, registe o momento de disponibilidade mais recente de cada feature, o momento da decisão, o momento do envio da ordem e o momento de execução simulado. Rejeite qualquer linha em que um dado de entrada tenha chegado depois da decisão.

• Adiante os sinais 1 vela e compare os resultados. Uma grande quebra pode revelar dependência da temporização entre fecho e fecho, embora seja um diagnóstico e não uma prova de fuga de informação.
• Limite todas as fontes a uma data de corte histórica, volte a executar o pipeline e compare as features resultantes com as features históricas armazenadas.
• Substitua uma feature suspeita por uma constante. Se o desempenho permanecer quase igual, verifique se o código usou realmente a série pretendida.
• Faça passar pelo pipeline uma feature futura deliberadamente impossível. A validação deve falhar claramente quando o seu momento de disponibilidade for posterior ao momento da decisão.

Estas verificações não certificam uma estratégia. Tornam visíveis pressupostos concretos sobre a temporização e detetam formas comuns de os violar.

O paper trading prova que o backtest não teve fugas de informação?

Não. O paper trading pode revelar um fluxo de dados em tempo real atrasado, incompleto ou alinhado de forma diferente do histórico. Não consegue demonstrar que as features de treino antigas refletiam o que era conhecido na altura. Um modelo também pode deixar de beneficiar da fuga de informação simplesmente porque o futuro que viu por acidente passou a ser o presente.

Use o paper trading como verificação de paridade: compare os valores das features em tempo real, os carimbos temporais das decisões, a geração das ordens e as execuções simuladas com as definições do backtest. Quando houver diferenças, siga o dado de entrada e o relógio exatos. Uma equipa de agentes capaz de explicar o conjunto de informação de cada decisão está a fazer investigação útil. Uma equipa que só consegue mostrar uma curva suave passou ao lado da auditoria mais difícil.