Backtesting de Mercados de Predição com IA: Teste Estratégias de LLM sem Vazamento de Informação Futura
Uma estratégia gerada por IA não é um backtest. O modelo, a fronteira de informação, o protocolo de decisão, o estado do portfólio e a execução realizável precisam ser controlados no relógio histórico.
O backtesting de mercados de predição com IA avalia uma regra gerada por LLM ou uma decisão de modelo usando apenas informações disponíveis em cada timestamp histórico. Um teste confiável congela o prompt e o universo de mercado, bloqueia resultados já resolvidos e fatos futuros, reproduz ordens contra a profundidade registrada, preserva o estado do portfólio e relata cada decisão, rejeição e execução.
Por que o backtesting de IA é um problema separado
Uma regra determinística pode ser revisada linha por linha. Um LLM pode mudar seu raciocínio com o prompt, a versão do modelo, o contexto, os resultados das ferramentas e as configurações de amostragem. Ele também pode conhecer fatos que ocorreram após a data simulada porque seus dados de treinamento ou uma ferramenta de busca anexada alcançam além do relógio histórico. Um backtest de trading comum não controla automaticamente esses riscos.
Os mercados de predição tornam o vazamento especialmente grave. A pergunta do mercado e a resolução final são públicas após a liquidação, então um modelo pode parecer prever um evento enquanto recorda ou infere sua resposta a partir de informações posteriores. O teste deve preservar tanto a integridade do tempo de mercado quanto a integridade do tempo do modelo.
Dois fluxos de trabalho de backtesting com IA
O fluxo de trabalho atualmente público do DepthFeed suporta o primeiro caminho: peça a um modelo que proponha uma hipótese clara, traduza-a em uma regra predefinida ou personalizada, congele os parâmetros e execute-a no Backtest Lab. Isso separa a geração de ideias da avaliação e torna o replay reproduzível.
Um replay de modelo em loop exige controles adicionais: um ambiente de informação fechado, estado sequencial do portfólio, registros duráveis de chamadas do modelo e uma fita point-in-time para cada ciclo. Não descreva um histórico de chat sobre mercados resolvidos como essa forma mais forte de backtest.
| Fluxo de trabalho | O que está congelado | Melhor uso |
|---|---|---|
| Regra gerada por IA | A saída do prompt se torna lógica determinística explícita uma vez | Testa se uma hipótese de IA sobrevive aos dados de mercado e à execução |
| Replay de modelo em loop | Modelo, prompt, ferramentas e contexto point-in-time são executados a cada decisão | Avalia um previsor autônomo ou agente de portfólio |
Construa a fronteira de informação histórica
A implementação mais segura usa uma fronteira as-of: timestamp de origem menor ou igual ao tempo de decisão. Cada feature, resumo e resposta de ferramenta deve herdar essa fronteira. Um único campo de conveniência sem limite, como o status de mercado de hoje ou um rótulo de resultado final, pode invalidar a execução inteira.
- Defina um timestamp de decisão e inclua apenas linhas de mercado observadas nele ou antes dele.
- Limite explicitamente qualquer lookback móvel; nunca use a linha mais próxima que possa vir do futuro.
- Exclua resultados de liquidação, preços finais, manchetes posteriores e buscas atuais na web.
- Registre o universo exato de mercado mostrado ao modelo, incluindo contratos que ele pulou.
- Faça hash ou versione a fita de entrada para que a mesma decisão possa ser reconstruída posteriormente.
- Relate dados ausentes como ausentes em vez de preenchê-los a partir de uma observação posterior.
Previna vazamento de resposta e de prompt
Congele o prompt do sistema, as instruções do cliente, o identificador do modelo, o modo de amostragem, o schema de saída estruturada e as ferramentas disponíveis. Remova linguagem que revele o resultado indiretamente, incluindo status final do mercado, redação de liquidação, resumos de artigos retrospectivos ou nomes de arquivos criados após a resolução.
Para perguntas sobre eventos históricos, assuma que a memória do modelo pré-treinado pode conter fatos posteriores mesmo quando a navegação está desativada. Use perguntas seguras quanto ao cut-off sempre que possível, avalie os controles de vazamento separadamente e compare o desempenho em períodos mais recentes ou mantidos em sigilo. Uma pontuação alta em eventos resolvidos bem conhecidos não é, por si só, evidência de habilidade de previsão.
Torne o protocolo de decisão auditável
Peça ações estruturadas em vez de recomendações em formato livre. Uma decisão útil inclui identidade do mercado, lado, probabilidade estimada, confiança, preço máximo de entrada, nocional solicitado e uma tese curta. As regras do lado do servidor devem então aceitar, redimensionar ou rejeitar a proposta de acordo com caixa, exposição, confiança, edge e limites de preço.
Armazene passes e negociações rejeitadas, não apenas execuções. Se o relatório final contiver apenas vencedores escolhidos pelo modelo, não há denominador para análise de seletividade, cobertura ou falhas. O registro durável deve conectar cada ação à sua fronteira de entrada exata e ao estado de portfólio resultante.
Replique o portfólio sequencialmente
Os ciclos de portfólio devem ser executados em ordem cronológica porque uma decisão altera o caixa e a exposição aberta disponíveis para a próxima. Paralelize a descoberta de mercado dentro de um timestamp, se necessário, mas sintetize uma decisão final de portfólio contra uma fita congelada. Não deixe chamadas independentes do modelo gastarem o mesmo caixa.
Carregue posições abertas, caixa realizado e limites de risco para frente. Em seguida, relate P&L por categoria e venue, bem como de forma agregada. Isso revela se um portfólio aparentemente inteligente é uma única aposta direcional concentrada repetida em contratos correlacionados.
Use execuções executáveis, não o preço cotado pelo modelo
O modelo pode declarar um preço máximo; ele não deve ter permissão para inventar sua própria execução. Adicione um atraso de execução definido, localize o primeiro livro registrado no ou após esse tempo simulado e percorra asks ou bids disponíveis apenas até o limite. Armazene VWAP, fração executada, tempo de observação e o livro utilizado.
Marque o portfólio final de forma conservadora. Uma marca pelo midpoint assume liquidação sem cruzar o spread ou consumir tamanho. Uma liquidação executável ciente da profundidade responde melhor ao que o portfólio poderia ter realizado; livros obsoletos ou ausentes devem permanecer uma condição explícita de falha.
Fluxo de trabalho detalhado: de uma hipótese de LLM a um replay
Comece com um prompt limitado: peça ao modelo uma hipótese falseável Polymarket ou Kalshi, os insumos observáveis necessários, uma regra de entrada precisa, tamanho da posição, comportamento de saída ou liquidação e as condições sob as quais ela deve passar. Proíba alegações de lucro e solicite nenhum exemplo retrospectivo.
Traduza a resposta em um preset ou regra personalizada do Backtest Lab sem alterar seus limites após ver os resultados. Selecione a venue e a família de mercado pretendidas, use uma amostra cronológica e compare midpoint, slippage fixo e profundidade registrada. Inspecione cada negociação e preserve um holdout posterior. Se sobreviver, implante a regra congelada no paper trading e avalie-a em resultados que o modelo não poderia conhecer quando a regra foi criada.
Métricas que distinguem previsão de trading
Qualidade de previsão e desempenho de trading estão relacionados, mas não são idênticos. Um modelo calibrado pode perder ao pagar preços que já refletem sua informação. Um modelo mal calibrado pode ganhar dinheiro brevemente por sorte ou por uma posição concentrada. Relate ambas as camadas e evite reduzir a avaliação a uma manchete de leaderboard.
| Pergunta | Métrica | Falha que captura |
|---|---|---|
| As probabilidades foram úteis? | Brier score, log loss, calibração | Previsões confiantes, mas imprecisas |
| As ações foram lucrativas após a execução? | P&L líquido, ROI, edge executável | Boas previsões compradas a preços ruins |
| O resultado foi concentrado? | P&L por venue, categoria e tempo | Um evento ou regime carregando a execução |
| O risco foi controlado? | Drawdown, exposição, número de posições | Lucro criado por concentração excessiva |
| O modelo foi seletivo? | Negociações, passes e taxas de rejeição | Relatório com seleção a dedo sem um denominador |
| A execução foi reproduzível? | Hashes de prompt, modelo, fita e livro | Um resultado que não pode ser replicado de forma independente |
Compare modelos sem mudar as regras no meio do jogo
- Dê a cada modelo a mesma fita de mercado congelada, o mesmo conjunto de ferramentas, schema de saída e limites de portfólio.
- Use os mesmos timestamps de decisão, latência de execução, motor de execução e regra de marcação final.
- Separe falhas de provedor, saída inválida e rejeições por regras de risco de perdas de mercado.
- Registre o custo de tokens e do modelo junto com o desempenho; um ganho marginal pode não justificar um custo de inferência muito maior.
- Repita execuções estocásticas ou use configurações determinísticas onde houver suporte e relate a variância.
- Mantenha páginas de modelos nomeados e alegações atualizadas porque versões e disponibilidade de modelos mudam.
Classifique as falhas em vez de ocultá-las
Esses resultados significam coisas diferentes. Tratar um timeout do provedor como um passe confiante infla a seletividade; descartar uma ordem não executada superestima o desempenho executável; e reparar silenciosamente uma saída malformada do modelo dá a um modelo ajuda humana que os outros podem não receber. A avaliação deve definir cada classe antes da execução e aplicá-la mecanicamente.
Publique o funil completo: mercados elegíveis, mercados mostrados, ações propostas, passes, saídas inválidas, rejeições por guardrails, rejeições de execução, execuções parciais e posições concluídas. Esse denominador permite distinguir um modelo cauteloso de um não confiável.
| Classe de falha | Exemplo | Como relatar |
|---|---|---|
| Falha de informação | Fato futuro, campo de liquidação ou cotação posterior entrou no contexto | Invalide o ciclo ou a execução afetada |
| Falha do provedor | Timeout, limite de taxa ou modelo indisponível | Conte separadamente de um passe de mercado |
| Falha de schema | Ação inválida, ID de mercado ausente ou probabilidade não analisável | Armazene a resposta bruta e a rejeição |
| Rejeição por risco | O tamanho solicitado excedeu caixa, exposição ou limites de preço | Relate como uma proposta do modelo rejeitada por guardrails |
| Rejeição de execução | Sem livro oportuno, sem profundidade abaixo do limite ou execução zero | Mantenha no denominador de trading |
| Perda de mercado | Decisão válida executada e liquidada contra o lado selecionado | Inclua normalmente no P&L e na pontuação de previsão |
O registro mínimo de reprodutibilidade
Para cada execução, preserve o provedor do modelo e o slug exato do modelo, os templates de prompt, as definições de ferramentas, o schema de saída estruturada, a configuração de amostragem e as instruções do cliente. Registre o início e o fim históricos, o intervalo de decisão, o lookback, as venues, as categorias, o caixa inicial, os limites de exposição, a latência de execução e o método de marcação final.
Para cada ciclo de decisão, preserve o timestamp da decisão, a versão da fita, o tempo as-of da fita, a contagem de mercados elegíveis, o hash de entrada, o portfólio antes e depois, o uso do modelo e o estado de erro. Para cada negociação proposta, armazene sua tese e probabilidade juntamente com a probabilidade de mercado observada, confiança, preço limite, tamanho solicitado, código de rejeição e o livro histórico usado para qualquer execução.
Modelos de provedores podem ser atualizados por trás de um nome estável, então uma reexecução exata ainda pode diferir posteriormente. Um registro durável não pode eliminar essa variância de plataforma, mas pode revelá-la. Onde seeds determinísticos ou versões fixadas não estiverem disponíveis, repita o mesmo teste vezes suficientes para relatar a dispersão entre execuções em vez de apresentar uma amostra favorável.
- Slug do modelo, provedor, prompt, ferramentas, schema e configurações de amostragem.
- Fronteira histórica, universo de mercado, intervalo de decisão e lookback.
- Limites de portfólio, latência de execução, motor de execução e marcação final.
- Hashes de entrada e de livro vinculados a cada decisão e execução.
- Uso de tokens, custo do modelo, saídas inválidas e todos os motivos de rejeição.
- Variância entre execuções repetidas quando o modelo ou provedor é estocástico.
Faça um teste prospectivo antes de fazer uma alegação de desempenho de IA
Um teste histórico de IA ainda pode se beneficiar da memória do modelo, do ajuste de prompt do pesquisador e da experimentação repetida. O próximo passo mais limpo é um período forward em papel bloqueado. Congele o prompt ou a regra extraída, comece depois que a configuração for final, precifique cada ação a partir do livro exibido ao vivo e publique o denominador completo.
DepthFeed Paper Trading fornece o caminho forward disponível para regras determinísticas e sinais de bots externos. Ele usa caixa virtual e não faz pedidos em exchanges ao vivo. Essa distinção deve permanecer visível em qualquer lugar onde um fluxo de trabalho de IA for descrito.
O que o DepthFeed oferece hoje
Hoje, pesquisadores podem usar um modelo de IA para criar ou refinar uma estratégia explícita, reproduzir essa regra congelada no Backtest Lab contra livros registrados de mercados de predição, comparar três premissas de execução, inspecionar risco e negociações individuais e mover sobreviventes compatíveis para o paper trading ao vivo. Os servidores de dados históricos API e MCP também suportam pesquisa de agentes personalizados fora do dashboard.
O DepthFeed atualmente não anuncia um backtest público autônomo de modelo em loop API nem execução de trades de IA ao vivo. O fluxo de trabalho mais restrito é intencional e testável: o modelo propõe; a evidência de mercado registrada avalia; o paper trading fornece o registro forward.
Key takeaways
- 01Geração de ideias com IA e replay de modelo em loop com IA são produtos diferentes e exigem evidências diferentes.
- 02Bloqueie liquidação, linhas futuras, busca atual e fatos posteriores em cada decisão histórica.
- 03Congele o modelo, o prompt, as ferramentas, o schema, o universo e as restrições de portfólio antes de comparar resultados.
- 04Armazene passes, rejeições, chamadas do modelo e fronteiras de entrada, bem como execuções lucrativas.
- 05Replique caixa e posições sequencialmente e, em seguida, execute contra a profundidade registrada após uma latência definida.
- 06Relate calibração, P&L, risco, concentração, custo de inferência e reprodutibilidade separadamente.
- 07Use um período forward em papel bloqueado antes de fazer qualquer alegação de desempenho de IA.
Uma estratégia gerada por IA não é um backtest. O modelo, a fronteira de informação, o protocolo de decisão, o estado do portfólio e a execução realizável precisam ser controlados no relógio histórico.
Começar grátis