Na segunda-feira, o nosso agente de investigação com IA encontrou uma estratégia de futuros de cripto com um rácio de Sharpe de 4.1. Na quinta-feira, depois de contabilizarmos as experiências e impedirmos o agente de ajustar os parâmetros com base na mesma janela de validação, o resultado era 0.8. A estratégia não tinha mudado. A nossa estimativa do que a pesquisa tinha conseguido é que tinha mudado.
Fizemos este pequeno diário de investigação porque «otimizar com cuidado» é um conselho fácil de dar e difícil de pôr em prática quando um agente consegue escrever código, lançar backtests, analisar a pontuação e voltar a tentar em poucos minutos. Eis o que correu mal, por ordem.
Segunda-feira: dar ao agente uma pergunta bem delimitada
Pedimos ao agente que testasse uma ideia simples de tendência horária num mercado líquido de futuros perpétuos: entrar quando uma média móvel curta cruzasse uma mais longa, dimensionar a posição para um objetivo de volatilidade fixo e fechar a posição perante o sinal inverso. Especificámos o instrumento, as datas, a tabela de comissões, o histórico de funding, a hipótese de execução e os intervalos de parâmetros que podia explorar.
A amostra histórica abrangia o período de 2021 a 2025. Atribuímos 2021–2023 ao desenvolvimento, 2024 à validação e reservámos 2025 como período final de teste. Esta divisão ficou definida na configuração da tarefa, para que o agente pudesse consultar os resultados do desenvolvimento e as pontuações da validação, mas não aceder aos retornos do período de teste.
O nosso primeiro erro foi permitir 300 combinações de parâmetros numa única tarefa sem registar o orçamento de pesquisa como resultado de investigação. O agente devolveu a melhor configuração: uma média rápida de 9 horas, uma média lenta de 73 horas e um objetivo de volatilidade de 0.8%. O Sharpe na validação era 4.1. Sabíamos que o agente tinha experimentado muitas configurações. Ainda não tínhamos tomado medidas para que esse facto não pudesse ser esquecido.
Terça-feira: o vencedor mudou quando voltámos a executar a tarefa
Voltámos a executar a mesma tarefa num ambiente limpo. A melhor configuração mudou e o Sharpe caiu para 2.7. Na primeira execução, uma cache de dados de mercado tinha fornecido uma série de funding atualizada; na segunda, foi usada uma versão fixada. Ambas as tarefas indicavam o mesmo intervalo de datas, mas só uma usava uma versão de dados reproduzível.
Deixámos de comparar pontuações e começámos a registar a experiência completa: revisão do código, instantâneo dos dados, comissões, funding, definições de execução, valores dos parâmetros e todas as tentativas lançadas pelo agente. Assim percebemos que o 4.1 não era uma misteriosa vantagem de mercado. Era o resultado de uma configuração numa pesquisa com 300 tentativas durante o mesmo ano de validação.
Quarta-feira: congelar a pesquisa antes de abrir o período de teste
Voltámos a executar a experiência com um instantâneo de dados fixo e uma grelha mais pequena, definida antecipadamente: 24 combinações. O agente podia ordená-las com base no período de desenvolvimento de 2021–2023. Deixámo-lo consultar 2024 uma vez, para fazer a seleção, e depois bloqueámos as definições escolhidas e o código.
A estratégia selecionada obteve um Sharpe de 0.8 na validação. No período de teste reservado de 2025, obteve 0.3, depois de contabilizados as comissões taker, o funding e o mesmo atraso de execução de 1 barra aplicado ao longo de todo o estudo. Foi uma resposta útil. Não era prova de que a estratégia fosse rentável numa conta real.
Uma observação desta semana: passámos mais tempo a chegar a acordo sobre o que significava «uma tentativa» do que a escrever o código das médias móveis. Contabilizámos cada conjunto de parâmetros alterado como uma tentativa, bem como as execuções que alteravam o sinal ou a regra de dimensionamento. Uma nova versão dos dados ou uma hipótese de execução diferente ficava registada numa execução separada, pois podia alterar a classificação tanto quanto os outros fatores.
Quinta-feira: o que faríamos de forma diferente da próxima vez
Não começaríamos com uma tarefa sem limites. Um agente de investigação precisa de um orçamento de pesquisa e de um registo do que experimentou, sobretudo quando pode usar cada resultado para decidir o que tentar a seguir. O período de teste também tem de estar protegido contra consultas informais: assim que alguém lê o resultado e altera a estratégia, esse período passa a ser mais um conjunto de validação.
Para uma pesquisa pequena, um registo de experiências pode ser simples e explícito:
| Registo | Importância |
|---|---|
| Versões do código e dos dados | Para que uma nova execução use as mesmas entradas e a mesma lógica |
| Todas as variantes experimentadas | Para compreender o vencedor no contexto da pesquisa |
| Funções dos períodos de desenvolvimento, validação e teste | Para que a pontuação final não seja reutilizada discretamente para ajustar a estratégia |
| Comissões, funding e hipóteses de execução | Para que o resultado comunicado descreva uma simulação testável |
Depois de abrir o período de teste, volte ao desenvolvimento com uma nova pergunta de investigação e preserve o resultado anterior como evidência histórica. Não continue a aperfeiçoar a mesma estratégia com base num período que ela já conhece.
O agente cumpriu a sua função: pesquisou rapidamente e encontrou uma configuração que valia a pena analisar. A nossa função era tornar a pesquisa transparente, preservar um teste intocado e tratar a pontuação como uma medição com um historial. O resultado interessante não foi 4.1 nem 0.3. Foi perceber exatamente como se chegou ao primeiro número.
← Todos os artigos
