Machine Learning em Trading: As 4 Armadilhas que Eu Vi na Prática

Atualizado em 21/08/2026

Machine learning em trading tem uma taxa de fracasso enorme, e a causa quase nunca é o algoritmo. López de Prado, que dirigiu times de ML em fundos bilionários, catalogou os motivos: aplicar em série financeira as mesmas práticas que funcionam em visão computacional ou recomendação de filme. O mercado é o pior caso possível pra ML: sinal fraquíssimo afogado em ruído, dados autocorrelacionados, regimes que mudam e uma amostra efetiva minúscula. Eu rodo mineração sistemática de estratégias há anos, com dinheiro real na ponta, e cada armadilha da literatura eu encontrei em algum momento na minha esteira, com número pra mostrar. Já escrevi sobre duas delas em profundidade, o PBO, a probabilidade de overfitting do backtest, e o Sharpe deflacionado por múltiplos testes. Aqui o foco é o que é específico de ML: onde o aprendizado de máquina quebra de um jeito que o backtest tradicional não quebra, e o que eu faço a respeito.

O que a pesquisa mostra: em série temporal financeira, a validação cruzada aleatória fabrica resultado falso, porque as observações são autocorrelacionadas e o embaralhamento coloca informação do futuro no treino. A correção consolidada é validar por blocos temporais com purga das observações que se sobrepõem à fronteira e embargo após o teste (López de Prado, 2018).

Armadilha 1: vazamento temporal, ou por que a validação cruzada aleatória mente

A validação cruzada padrão (k-fold) embaralha as observações e sorteia quais vão pro treino e quais vão pro teste. Em dados independentes, isso funciona. Em série temporal financeira, isso é uma máquina de fabricar resultado falso, por dois mecanismos. Primeiro, as observações vizinhas são quase cópias umas das outras (a volatilidade de hoje parece com a de ontem, um trade aberto atravessa vários candles), então o modelo “testado” em pontos sorteados já viu os vizinhos daqueles pontos no treino. Segundo, com embaralhamento o treino contém literalmente o futuro do teste. O modelo aprende o regime de 2025 e é avaliado em 2024. A acurácia sobe, e o número não significa nada.

A solução que a literatura consolidou, e que eu uso, é a de López de Prado (2018): validação com purga (remover do treino toda observação cujo horizonte se sobrepõe ao período de teste) e embargo (uma janela extra de segurança depois do teste, pra matar a autocorrelação residual). Na minha esteira isso vira um walk-forward estrito por data: seleciono os robôs numa era, meço na era seguinte, 5 dobras expandindo de 2019 a 2026, com 300 carteiras sorteadas por dobra como referência do acaso. Nunca por índice de linha, sempre por data, porque já me queimei nisso também: uma versão do meu comparador de dobras alinhava por índice em vez de data e comparava períodos diferentes achando que eram o mesmo. Vazamento temporal tem mil disfarces.

Armadilha 2: o melhor de N, quando a busca é maior do que você admite

Todo pipeline de ML em trading tem uma etapa de busca: grade de hiperparâmetros, seleção de features, arquiteturas testadas. Na mineração genética que eu uso, essa busca é explícita e gigantesca: o gerador produz centenas de estratégias por rodada, milhares no acumulado do garimpo, e só uma fração sobrevive aos filtros. Esse é o N verdadeiro do meu funil. O melhor Sharpe entre N tentativas cresce com N mesmo quando nenhuma tentativa tem vantagem real: com um build de ~3 anos, o teto do puro acaso fica em Sharpe ~1,8 com 600 tentativas e ~2,5 com 60.000. “O minerador achou 600 estratégias lucrativas” descreve o ruído funcionando como esperado.

O erro clássico, que eu cometi, é deflacionar pelo N que sobrou em vez do N que foi buscado. A minha Estação de validação usava um n_trials de mentirinha (as poucas finalistas) até uma auditoria externa apontar que o número honesto é o do garimpo inteiro, milhares. A conta muda completamente. O tratamento formal disso está no artigo do Sharpe deflacionado; a versão curta: quem não registra o tamanho real da própria busca está se enganando com precisão de duas casas decimais. Arnott, Harvey e Markowitz (2019) colocam isso como item central do protocolo deles: manter contagem de tudo que foi testado, inclusive o que foi jogado fora.

Armadilha 3: a régua quebrada, quando a métrica de proteção está errada

Essa quase ninguém conta, porque dói. Quanto mais sofisticado o pipeline, mais código de validação você escreve, e esse código também tem bugs. O meu caso: a função que calcula o PBO (via CSCV, o método de Bailey e López de Prado) estava com a direção do ranking invertida e reportava o complemento do valor certo. O painel mostrava PBO = 0,91 pra um portfólio cujo PBO real era ~0,09. Note a perversidade: 0,91 significaria overfitting quase certo, 0,09 significa processo saudável. Eu estava lendo o oposto da realidade na métrica que existe justamente pra me proteger da realidade. Só uma auditoria adversarial de código, agentes re-derivando os números de forma independente, pegou. A mesma auditoria achou mais de uma dezena de atalhos de implementação do tipo, incluindo um drawdown calculado sem o zero inicial.

A lição prática, que vale pra qualquer um que calcula métrica com código próprio: teste a direção da régua com um caso degenerado conhecido. Alimente a função com um caso obviamente overfitado e um obviamente limpo e confira se os números saem do lado certo. Depois do conserto, toda função que decide dinheiro na minha esteira ganhou teste unitário com invariante conhecido. Em ML isso é ainda mais crítico do que em backtest simples, porque a cadeia entre o dado e a decisão é mais longa: mais elos, mais lugares pra um sinal trocado passar despercebido.

Armadilha 4: o regime muda, e o modelo aprendeu o regime errado

Série financeira não é estacionária. O processo gerador dos dados muda, e um modelo treinado num regime carrega pro seguinte exatamente os vieses errados. Isso não é abstração: eu tenho o número nas minhas dobras. No walk-forward de 2019 a 2026, o controle de risco da minha esteira bateu 75 a 100% das carteiras sorteadas em 4 das 5 dobras. A dobra que falhou foi 2022 (percentil 35): o ano do trend violento de dólar, Fed contra o mundo, em que a seleção feita na era anterior tinha aprendido um mercado que deixou de existir. E o espelho disso: 2025-26 virou janela de chicote, que sabota as regras simples de tendência e poupa outras famílias de estratégia. O mesmo pipeline, avaliado em eras diferentes, conta histórias opostas.

A consequência pra ML é dura. Um modelo flexível extrai do treino muito mais estrutura que uma regra simples, e quando o regime vira, ele tem muito mais coisa errada memorizada. É por isso que a literatura de momentum de série temporal continua relevante depois de décadas enquanto modelos complexos morrem em anos: regra simples com fundamento econômico degrada devagar; padrão estatístico sem mecanismo degrada de uma vez. Minha resposta de engenharia foi parar de tratar estratégia como ativo permanente e tratar como safra: gera, valida, opera, e um disjuntor corta quando o comportamento sai do envelope. O walk-forward me mostrou que a seleção sozinha não segura um choque de regime; o desenho do sistema precisa assumir que ele vem.

Por que eu não uso ML fim-a-fim pra gerar sinal

A confissão que estrutura este artigo: depois de anos nisso, eu não uso machine learning fim-a-fim pra gerar sinal de entrada. Uso mineração sistemática de regras (busca genética sobre blocos de indicadores e padrões de preço) seguida de validação estatística dura: walk-forward por data com purga, deflação pelo N real do garimpo, PBO, bootstrap em blocos, benchmark contra carteiras aleatórias. A razão é aritmética de amostra. O varejo tem uma série de preços por mercado, meia dúzia de regimes por década, e sinal fraco. Um modelo de alta capacidade nesse dado encontra estrutura espúria mais rápido do que qualquer validação consegue descartá-la. Rodei esse filme mais de uma vez: robôs com +0,06% por trade in-sample que desabam pra ~0% quando medidos numa era que a busca nunca viu. O ML funciona. O problema é que, no meu tamanho de dado, o retorno marginal da sofisticação está todo do lado da validação, e quase nenhum do lado do modelo.

Os grandes fundos que fazem ML funcionar têm o que eu não tenho: dados alternativos em volume, centenas de mercados, times inteiros só pra infraestrutura de validação. López de Prado é explícito nisso: os fracassos vêm de aplicar a ferramenta sem o ecossistema. Pra quem opera no meu tamanho, a fronteira útil do ML está em papéis auxiliares (dimensionar posição, filtrar regime, controlar qualidade da execução), e mesmo aí só com a validação na frente. Sobre usar modelos de linguagem nesse fluxo, que é uma pergunta diferente, escrevi um artigo sobre LLMs na descoberta de estratégias: o mesmo princípio se aplica, a geração pode ser criativa, a validação tem que ser implacável.

O protocolo que ficou

Destilando as quatro armadilhas em prática, o que roda na minha esteira hoje, e que espelha em boa parte o protocolo de Arnott, Harvey e Markowitz (2019):

Mecanismo antes de otimizar. Toda família de estratégia precisa de uma razão econômica pra existir antes de eu gastar CPU nela. Padrão sem mecanismo é candidato a ruído por definição.

Validação por data, nunca por sorteio. Walk-forward com eras que a busca nunca viu, purga na fronteira, embargo depois. A validação cruzada aleatória fica proibida pra qualquer coisa com dimensão temporal.

N honesto. O número de tentativas registrado é o do garimpo inteiro, milhares, não o das finalistas. Toda métrica de significância é deflacionada por ele.

Régua testada. Função que decide dinheiro tem teste unitário com caso degenerado conhecido. A auditoria adversarial do código roda antes de qualquer conclusão virar decisão.

Assumir a morte do regime. Benchmark contra o acaso em cada era, disjuntor de perda no operacional, e a expectativa explícita de que a dobra tipo 2022 vai acontecer de novo e a seleção não vai segurar sozinha.

Nada disso é glamouroso, e é exatamente o ponto. A parte difícil de machine learning em trading nunca foi treinar o modelo. Foi sempre provar, contra a sua própria vontade de acreditar, que o resultado não é um artefato da busca. No meu caso, a prova mais valiosa que o processo já produziu foi contra mim: um Sharpe de backtest no percentil 100 de 2.000 carteiras aleatórias, e um medidor de overfitting de cabeça pra baixo. Os dois episódios estão contados em detalhe no artigo do PBO.

Os números deste artigo

Machine learning funciona em trading?

Funciona em contextos com dado abundante e validação industrial, e em papéis auxiliares (sizing, filtro de regime, execução) mesmo no varejo. Como gerador de sinal fim-a-fim com o dado que o trader individual tem, a probabilidade de o resultado ser overfitting supera em muito a de ser vantagem. A carga da prova é do modelo, e a prova é walk-forward em era nunca vista, deflacionada pelo N da busca.

Por que a validação cruzada k-fold falha em série temporal?

Porque as observações financeiras são autocorrelacionadas e o embaralhamento coloca informação do futuro no treino. O modelo é avaliado em pontos cujos vizinhos ele já viu. A correção é validar por blocos temporais com purga das observações que se sobrepõem à fronteira e embargo após o teste, como formalizado por López de Prado (2018).

Quantos dados são suficientes pra treinar um modelo de trading?

Menos do que parece haver. Uma série diária de 10 anos tem ~2.500 pontos, mas a amostra efetiva é muito menor por causa da autocorrelação, e o número de regimes independentes (o que de fato importa pra generalização) é da ordem de meia dúzia. É por isso que modelos de alta capacidade overfittam tão rápido: a razão parâmetros/informação real é péssima.

O que é o protocolo de Arnott, Harvey e Markowitz?

Uma lista de verificação de 2019 pra pesquisa quantitativa com aprendizado de máquina: estabelecer fundamento econômico antes do teste, registrar todas as tentativas (inclusive descartadas), desconfiar de resultados sem mecanismo, cuidar de dados fora da amostra de verdade e reconhecer os incentivos de quem publica o backtest. É a versão formalizada do que qualquer processo honesto de mineração precisa fazer.

Onde os fundos de ML mais erram, segundo López de Prado?

Nos pecados de processo: trabalhar por silos replicando o mesmo esforço, usar dados não estruturados sem tratamento, validação cruzada com vazamento, ignorar custos e capacidade, e sobretudo o backtest como ferramenta de pesquisa em vez de verificação final. O denominador comum é tratar finanças como um problema comum de ML, quando o dado financeiro viola quase todas as premissas dos métodos clássicos.

Referências

• López de Prado, M. (2018). Advances in Financial Machine Learning. Wiley. (Purged cross-validation, embargo, CSCV.) link.
• López de Prado, M. (2017). The 7 Reasons Most Machine Learning Funds Fail. SSRN. link.
• Arnott, R. D.; Harvey, C. R.; Markowitz, H. (2019). A Backtesting Protocol in the Era of Machine Learning. Journal of Financial Data Science, 1(1), 64-74. link.
• Bailey, D. H.; Borwein, J. M.; López de Prado, M.; Zhu, Q. J. (2017). The Probability of Backtest Overfitting. Journal of Computational Finance, 20(4). link.