Tantoryn AI: cinco dias de pesquisa em ML — erros, verificações e os primeiros resultados negativos

Em cinco dias, testamos várias abordagens para encontrar sinais de trading. Rejeitamos três candidatos, tivemos de verificar um deles novamente por causa de um erro nos dados, e outro não passou na validação por razões estatísticas.

O principal resultado da semana não é um novo modelo de trading. Ainda não temos um candidato que dê base suficiente para usar seus sinais. Mas passamos a entender melhor quais abordagens não passam na validação e por quê.

Treinar um modelo e obter previsões ainda não prova que essas previsões servem para decisões financeiras.

Quatro desfechos diferentes que não devem ser confundidos

Esta semana deixou claro que um único status de “o modelo não passou” é grosseiro demais. Por trás dele há situações diferentes, e elas exigem ações diferentes.

Validação inválida — o resultado não pode ser usado por causa de um erro nos dados ou no procedimento.

Evidência insuficiente — a vantagem não foi confirmada com a confiança necessária.

Nenhuma opção admissível — as formas de aplicação testadas não atendem às condições de admissão.

Candidato rejeitado — o modelo não passou na validação e foi encerrado no ciclo atual.

Um erro nos dados significa: corrigir e verificar de novo. Evidência insuficiente não é o mesmo que ausência comprovada de sinal. A falta de uma opção admissível é um veredito negativo sobre a aptidão para uso, não sobre a estatística. E um candidato rejeitado não deve voltar ao trabalho só porque o resultado é inconveniente.

A seguir, como esses quatro desfechos apareceram na prática.

De avaliar sinais prontos a procurá-los

Antes, boa parte da nossa pesquisa em ML estava ligada à avaliação de candidatos de trading já formados. Um componente separado identificava uma situação de mercado, e depois um modelo de ML ajudava a avaliar sua qualidade.

A nova frente faz outra pergunta: um modelo consegue detectar uma oportunidade de trading diretamente a partir do estado do mercado, sem um candidato formado previamente?

É uma tarefa diferente. Os resultados de um modelo que avalia sinais prontos não podem ser transferidos automaticamente para um modelo que precisa encontrá-los sozinho.

Dividimos o trabalho em duas escalas — Intra (decisões mais frequentes em um horizonte curto) e Swing (decisões mais raras em um horizonte mais longo). Cada uma é validada separadamente: sucesso ou fracasso em uma escala não conta como evidência para a outra.

O conjunto de pesquisa inclui modelos lineares simples, métodos de extração de regras, gradient boosting e outras abordagens. O objetivo não é escolher o algoritmo mais complexo, mas entender qual abordagem fornece evidências convincentes de utilidade.

Primeiro passo: definir o que exatamente o modelo prevê

A primeira questão foi o alvo de treinamento.

É possível prever a direção do mercado. É possível estimar o retorno potencial de um movimento. É possível prever se um alvo de trading será atingido. São tarefas diferentes, e o sucesso em uma não garante o sucesso em outra.

Para a nova frente, escolhemos estimar o resultado potencial de um movimento de mercado em um horizonte fixo, já descontados os custos de trading.

Ao mesmo tempo, separamos duas coisas: o resultado que o modelo aprende a prever e o resultado que uma decisão real de trading produziria, considerando as regras de execução e de gestão da posição.

Essa distinção se mostrou relevante já na verificação preliminar. Nos dados havia situações em que a direção do movimento parecia atraente, mas uma possível posição teria sido encerrada de outra forma por causa de sua trajetória. O mercado pode acabar subindo, mas antes passar por um movimento desfavorável que teria encerrado a posição.

Acertar a direção não significa necessariamente uma operação bem-sucedida.

Um erro na preparação dos dados

Na preparação inicial dos dados de pesquisa ocorreu um erro. Parte das verificações terminava formalmente com sucesso, embora os dados não contivessem observações utilizáveis. O status técnico “concluído” não correspondia à correção real do resultado.

Não aceitamos esse conjunto de dados. Corrigimos o erro, adicionamos uma verificação da presença de observações efetivamente admissíveis e reconstruímos os dados. O resultado corrigido passou em uma nova verificação.

A lição aqui não é que um pipeline pode conter erros — isso é sabido. A conclusão mais importante é que uma verificação deve confirmar a existência de um resultado correto, e não apenas a ausência de uma exceção de software. Se todas as observações se tornaram inutilizáveis, o término bem-sucedido do programa não deve se transformar em um veredito de pesquisa positivo.

Primeiro candidato: um modelo linear simples

O primeiro candidato prático foi um modelo linear para Intra.

Foi uma escolha deliberada. Um modelo simples ajuda a verificar se há um sinal estável nos dados antes de passar para algoritmos mais complexos. Ele também cria um ponto de comparação: um futuro modelo complexo precisa mostrar valor além do que um método simples consegue detectar.

O ciclo de pesquisa incluiu preparação de dados, treinamento e validação em um período de tempo separado. A primeira validação esbarrou no mesmo erro de processamento de dados; seu resultado foi declarado inválido e a execução foi repetida após a correção.

O resultado é negativo: para o modelo linear de Intra, não foi possível encontrar uma opção admissível de tomada de decisão que atendesse às condições de seleção.

Isso não significa necessariamente que o modelo não detecte padrões estatísticos. Mas entre detectar um padrão e obter permissão para usá-lo em uma decisão de trading existe uma fronteira adicional. O candidato linear de Intra não a ultrapassou.

Segundo candidato: um modelo linear para Swing

Em seguida, testamos a mesma tarefa em uma escala mais longa. A razão do resultado negativo foi outra.

O modelo linear de Swing concluiu a validação, mas as evidências foram insuficientes para uma decisão positiva.

Aqui é importante distinguir dois desfechos. No primeiro, o modelo foi validado, mas nenhuma forma admissível de uso atende aos requisitos. No segundo, não há dados suficientes para confirmar uma vantagem com segurança.

Não é a mesma coisa. No primeiro caso, o procedimento leva a uma decisão negativa sobre a aptidão para uso. No segundo, permanece a incerteza estatística: os dados disponíveis não dão base para a admissão, mas por si só não provam a ausência total de um sinal útil.

Obtivemos justamente o segundo resultado. O candidato não foi admitido para uso posterior, mas não transformamos evidência insuficiente nem em uma afirmação de que não existem padrões, nem em um motivo para declarar o modelo um sucesso.

Terceira abordagem: modelos baseados em regras

A próxima frente foram os modelos baseados em regras — métodos que identificam combinações de condições associadas a um determinado resultado, em vez de uma previsão totalmente opaca.

Isso é potencialmente útil para analisar o comportamento do mercado: dá para ver quais padrões o algoritmo encontra. Mas interpretabilidade não é confiabilidade. Uma regra pode parecer economicamente sensata, ser fácil de explicar e, ainda assim, não ter uma vantagem estatística estável.

Por isso aplicamos a esses modelos os mesmos princípios de validação usados nos lineares.

Os resultados foram novamente negativos, mas por razões diferentes. Um candidato foi rejeitado na etapa que avalia se as evidências estatísticas são suficientes. O segundo não reuniu evidências suficientes para a admissão.

Ambos os ciclos foram encerrados. Esses resultados não provam que métodos baseados em regras sejam inúteis em geral — eles se referem aos candidatos específicos testados e às condições estabelecidas. Mas mostram por que um modelo interpretável não pode ser considerado mais confiável só porque suas decisões são mais fáceis de explicar. A explicabilidade ajuda a estudar o modelo. Ela não substitui a verificação de seu valor preditivo e econômico.

A passagem para modelos mais complexos

Depois das abordagens lineares e dos modelos baseados em regras, passamos ao gradient boosting estrutural — um método capaz de descrever dependências não lineares e interações entre features.

Isso amplia a capacidade expressiva do algoritmo, mas cria novos riscos: o modelo pode encontrar padrões complexos que não se mantêm em outros períodos de tempo. Por isso, o aumento da complexidade, por si só, não é considerado progresso.

Para Intra, a configuração da pesquisa foi preparada e aceita, e em seguida foi feita a preparação dos dados. Para Swing, ao final da semana obtivemos o resultado de uma validação separada do boosting estrutural: as evidências foram insuficientes para a admissão.

Passar para um método mais complexo não eliminou automaticamente o problema dos candidatos anteriores. O trabalho com as abordagens restantes continua. Seus resultados futuros não podem ser considerados de antemão nem positivos, nem negativos.

Por que não retreinamos cada modelo malsucedido até obter um resultado positivo

Depois de um resultado negativo, surge a vontade natural de mudar as configurações, escolher outras features, ajustar as condições de seleção, testar mais algumas variantes. Às vezes essas mudanças são justificadas.

Mas há um perigo: se a pesquisa for constantemente adaptada ao mesmo período de validação, esse período aos poucos se torna parte do treinamento. Formalmente, o modelo não recebe essas observações como dados de treino — mas o pesquisador usa os resultados da validação para escolher os próximos passos. É assim que surge o overfitting no nível de todo o processo.

Por isso separamos o desenvolvimento, a seleção de modelos e a validação independente posterior. Para novos candidatos vale um procedimento sequencial de admissão. Um resultado malsucedido não dá permissão automática para alterar o modelo repetidas vezes até aparecer uma métrica conveniente.

Em machine learning financeiro isso é especialmente importante: padrões fracos, ruído e muitas opções de ajuste facilmente produzem resultados convincentes, porém instáveis.

A relação com o nosso artigo separado

Também preparamos um artigo separado para o HackerNoon — “Quando uma AI de trading escolhe o silêncio: cautela ou ilusão de precisão?”. Ele está em revisão editorial; adicionaremos o link aqui assim que for publicado.

Ele trata de um problema diferente, mas relacionado: um modelo pode mostrar precisão muito alta se se recusar a prever em situações difíceis. Pesquisas mostram que essa melhora na métrica nem sempre significa que surgiu uma previsão mais confiável.

Mais detalhes estarão nesse artigo.

O que mudou na semana

Primeiro, a nova frente de pesquisa em ML passou do projeto para as verificações práticas.

Segundo, obtivemos e registramos os resultados negativos de vários candidatos, e os motivos da não admissão foram diferentes.

Terceiro, um erro de preparação de dados foi identificado e corrigido, e as verificações foram reforçadas para não aceitar um resultado formalmente bem-sucedido, mas na prática inutilizável.

Quarto, começou a validação de modelos mais complexos — sem supor que o aumento da complexidade trará automaticamente um resultado melhor.

Próximos passos

Continuamos a testar as abordagens restantes segundo o procedimento estabelecido.

Até o momento, os resultados dos candidatos descritos não dão base para declarar um novo modelo de trading pronto para uso. A lucratividade da nova frente também não foi confirmada. Isso não significa o fim da pesquisa — significa que expectativas preliminares não substituem evidências.

Em cinco dias, não obtivemos base para apresentar um novo modelo como bem-sucedido. Em compensação, passamos a entender com mais precisão quais abordagens ainda não passam na validação, por que isso acontece e onde é preciso manter a disciplina de pesquisa.

O trabalho não terminou. O treinamento dos modelos continua, e estamos confiantes de que, entre as abordagens restantes, surgirá um candidato que passará na validação e dará base para a aplicação.