Como criar um algoritmo de trading com ChatGPT ou Claude, testar se é lucrativo e evitar o sobreajuste

Um projeto completo de pesquisa de trading, com uma resposta que você pode examinar

“Crie um robô de trading lucrativo para mim” reúne três trabalhos: inventar uma regra, implementá-la e estabelecer se merece receber capital. Um assistente pode produzir código convincente e deixar o primeiro e o terceiro trabalhos sem resposta. Aqui nós os separamos: fixamos uma estratégia simples, executamos um estudo histórico documentado e publicamos os registros que sustentam o resultado.

O projeto é um sistema de rompimento do Bitcoin, diário e apenas comprado. Sua hipótese econômica é modesta: tendências persistentes podem, ocasionalmente, compensar o custo de repetidos rompimentos que falham. A parte desconfortável integra a própria ideia. Um seguidor de tendências pode perder na maioria das operações e depender de poucos grandes ganhos. Por isso, examinamos a distribuição dos lucros e prejuízos das operações, além do saldo final da conta.

A investigação separa regras da estratégia, observações de mercado, execuções simuladas e resultados da conta. Preservamos a atribuição da fonte, a entrada diária, 15 testes executáveis e os registros completos dos experimentos. As seções abaixo explicam os cálculos e mostram exemplos de operações e contabilidade que afetam a conclusão.

Este é um estudo de engenharia assistida por IA, não um experimento de perguntar a um chatbot qual ativo vai subir. O código foi desenvolvido no Codex. Não submetemos a mesma tarefa a ChatGPT e Claude, não medimos seu desempenho de investimento e não usamos um modelo de linguagem para escolher operações durante a execução. Depois de escrito, o algoritmo segue regras determinísticas.

Para acompanhar uma investigação focada na conciliação entre implementações, leia Backtesting em Python e Pine Script: por que os resultados diferem.

Comece com uma especificação que não deixe ambiguidades favoráveis ao lucro

A descrição de uma estratégia deve resolver os detalhes capazes de mudar a lista de operações. “Comprar a máxima de 55 dias” é insuficiente: um pavio conta, o candle atual entra no canal e seria possível usar um candle diário encerrado para comprar ao seu preço de abertura anterior? Nossa regra exige um fechamento confirmado acima das máximas anteriores e espera a abertura seguinte.

A especificação e o procedimento de avaliação foram escritos antes de este fluxo de trabalho calcular o desempenho. Duas alterações nos dados vieram primeiro: a troca da fonte e uma resposta à falta de uma observação de quatro horas. Ambas estão preservadas nos registros da pesquisa. Não mudamos a regra de negociação para melhorar seu resultado. Esse registro é uma sequência interna de decisões de pesquisa, não um pré-registro com marca temporal independente nem um experimento prospectivo.

A fronteira de execução presumida é idealizada. O fechamento diário concluído e a abertura diária seguinte são contíguos em um mercado cripto contínuo; uma implementação real precisa de tempo para receber os dados, calcular e enviar a ordem. Cinco pontos-base de slippage são uma premissa, não evidência de que essa latência e esse tamanho de ordem possam ser executados naquele preço.

A inspeção dos dados mudou o estudo antes do início do backtest

A entrada é um arquivo histórico de BTC-USDT publicado por humblefool06 no Hugging Face, com declaração de licença CC BY 4.0. Fixamos a revisão 9f491eb5340dd6a24f27fde24edf098e1e785443, preservamos o cartão do conjunto de dados do publicador e registramos hashes SHA256. A TensorParadigm agregou os candles de quatro horas em candles diários UTC. Registramos essa atribuição e a transformação nos registros da pesquisa. [1] [9]

As verificações de cobertura encontraram a ausência do componente das 12:00 UTC de 19 de fevereiro de 2020. Excluímos esse dia e todo o histórico anterior, em vez de inventar um preço. Por isso, a entrada normalizada começa em 20 de fevereiro de 2020; o desenvolvimento começa em 1 de maio, após 71 candles completos de aquecimento. Todas as 2,354 observações diárias preservadas contêm exatamente seis componentes. Ordenação de timestamps, duplicatas, valores finitos e consistência OHLC foram verificados antes do cálculo de desempenho.

Um hash identifica os bytes utilizados; não estabelece que os preços do publicador sejam corretos. Não conciliamos de forma independente esse arquivo de terceiros com os registros da exchange. Um estudo de investimento mais forte repetiria a análise em um feed obtido independentemente e investigaria as divergências. Reprodutibilidade e precisão da fonte são requisitos relacionados, mas distintos.

Reservamos a expressão “avaliação histórica reservada” para o último segmento da regra fixa. São dados históricos de um mercado cuja trajetória geral já é conhecida. Além disso, o exercício secundário de walk-forward reutiliza depois datas sobrepostas. Não há uma amostra final globalmente intocada em todas as análises deste artigo. Chamá-la de teste independente ao vivo exageraria o desenho do estudo.

Peça ao assistente que elimine ambiguidades antes de escrever o robô de trading

ChatGPT e Claude podem ajudar a transformar uma especificação de pesquisa em código, explicar um registro contábil e propor testes. Codex e Claude Code podem trabalhar dentro de uma base de código, editar arquivos e executar comandos. Suas capacidades de engenharia documentadas justificam experimentá-los neste fluxo de trabalho; não estabelecem qual produto escreve a estratégia mais lucrativa. [3] [4]

Forneça a especificação fixa ao assistente e exija que ele identifique escolhas ainda não resolvidas antes da implementação. Neste estudo, as escolhas importantes incluem rompimentos estritos ou inclusivos, janelas de candles anteriores, execução na abertura seguinte, orçamento de caixa incluindo a comissão e tratamento de uma posição final aberta. Uma resposta confiante que invente qualquer uma dessas escolhas silenciosamente é uma implementação defeituosa.

Implemente a especificação fixa de estratégia anexada. Primeiro identifique qualquer ambiguidade capaz de alterar sinais, execuções, dimensionamento ou resultado apresentado. Não acrescente filtros nem otimize parâmetros. Informe quando cada dado de entrada fica disponível. Separe lógica de sinais, execução, contabilidade e relatórios. Antes de calcular o desempenho histórico, crie testes sintéticos de temporalidade e conciliação de caixa. Entregue o código completo, as premissas e um registro dos experimentos.

O prompt abaixo é uma especificação reutilizável de pesquisa, não a transcrição de uma comparação controlada entre modelos. Mantenha um registro de experimentos com modelo e versão, arquivos fornecidos, alterações aceitas e todas as variações posteriores da estratégia. Caso contrário, “uma ideia” pode se transformar discretamente em dezenas de oportunidades não registradas de encontrar um backtest favorável.

Construa o backtest em Python em torno da ordem dos eventos

O loop diário do mecanismo tem uma ordem deliberada: executar a ordem pendente de ontem na abertura de hoje, marcar a conta no fechamento de hoje e então calcular a decisão de hoje. Isso impede que um fechamento diário seja usado para obter uma execução anterior no mesmo candle. Ambos os canais excluem o candle da decisão. Estes trechos abreviados mostram os dois cálculos mais sujeitos a erros de implementação.

# Called at the completed close, after any pending open fill.
entry_level = max(b.high for b in bars[index-entry_lookback:index])
exit_level = min(b.low for b in bars[index-exit_lookback:index])

if not quantity and bar.close > entry_level:
    pending = {"side": "BUY", "signal_date": bar.date}
elif quantity and bar.close < exit_level:
    pending = {"side": "SELL", "signal_date": bar.date}
# Execute pending only on the NEXT loop iteration, at that bar's open.

O dimensionamento da entrada inclui a comissão dentro do orçamento de 90%. Com comissão c e preço desfavorável de compra P, a quantidade é 0.9 × caixa / [P × (1 + c)]. Descontar a taxa depois de comprar com 90% do caixa gastaria mais que o orçamento especificado. O slippage já está refletido em P; subtrair novamente seu valor financeiro estimado seria cobrá-lo duas vezes.

commission = commission_bps / 10000
slippage = slippage_bps / 10000
fill_price = bar.open * (1 + slippage)  # adverse BUY fill
qty = allocation * cash / (fill_price * (1 + commission))
notional = qty * fill_price
fee = notional * commission
cash -= notional + fee

Executamos 15 testes sintéticos. Eles cobrem perturbação de dados futuros, exclusão do candle atual, rompimentos estritos, execuções na abertura seguinte, slippage desfavorável, dimensionamento incluindo comissão, resultado de operações encerradas, patrimônio com posição aberta, referência com o mesmo orçamento, sinais finais não executados, isolamento do aquecimento, dados inválidos e cálculos de bootstrap. Esses testes estabelecem propriedades específicas de temporalidade e contabilidade. Não demonstram vantagem no mercado.

Uma invariável útil revela mais que um gráfico atraente: mudar preços posteriores à data t não pode alterar uma decisão ou execução anterior a t. Outra é a conciliação exata, dentro da tolerância de ponto flutuante: patrimônio inicial + resultado líquido das operações encerradas + resultado marcado da posição aberta = patrimônio final. O programa verifica essa identidade para cada conta que simula.

Uma implementação Pine Script, com diferenças declaradas

Também escrevemos uma implementação Pine Script da mesma ideia de entrada e saída por canais anteriores em um gráfico diário padrão. Ela usa candles confirmados e agenda ordens comuns para o candle seguinte. O emulador de corretora das estratégias do TradingView e suas configurações determinam as execuções simuladas; os dados do gráfico e as premissas intrabar podem importar. [2]

Não compilamos esse complemento no TradingView nem obtivemos um resultado do Strategy Tester. Todos os números de desempenho deste artigo vêm do mecanismo Python. O código Pine foi revisado como código, uma verificação mais limitada que sua execução.

Há duas diferenças intencionais. A configuração de slippage do Pine usa um número fixo de ticks, enquanto Python usa cinco pontos-base proporcionais ao preço; nossa versão Pine usa zero ticks e, portanto, não reproduz o modelo principal de custos. O dimensionamento nativo de 90% do patrimônio no Pine também difere do nosso orçamento de 90% do caixa incluindo a comissão de entrada. Essas diferenças impedem afirmar que os retornos das contas sejam equivalentes.

Para comparar os dois mecanismos adequadamente, alinhe primeiro feed, fronteiras UTC, histórico de aquecimento, janela de datas, convenção de quantidade e taxas. Compare as datas dos sinais e o registro de execuções antes dos retornos. Se as operações forem diferentes, um saldo final parecido é uma coincidência, não uma validação.

O resultado real: lucrativo na amostra, abaixo da referência de manutenção

O algoritmo fixo transformou 10,000 USDT em 11,154.96 USDT nos 943 dias do período reservado. Seu retorno de 11.55% é acumulado nesse intervalo, não anualizado. O drawdown máximo medido nos fechamentos diários foi de 29.72%. Encerrou oito operações, ganhou em três e terminou sem posição. Portanto, o resultado líquido positivo não depende de uma posição final com lucro não realizado nesse segmento específico.

A referência investiu 90% de seu caixa inicial, incluindo a comissão de entrada, na primeira abertura do período e manteve a posição. Rendeu 43.66%, com drawdown de 51.05% nos fechamentos diários. Não houve rebalanceamento contínuo para 90%. A estratégia teve exposição média diária investida de 33.62%; a referência permaneceu investida, e sua alocação variou com o preço. Drawdown menor acompanhado de retorno menor é uma troca entre objetivos, não evidência de alfa nem uma comparação com riscos equivalentes.

Cada coluna abaixo é uma conta separada, iniciada sem posição. Não componha os três retornos em um histórico contínuo: os reinícios e as posições finais diferem. As durações também são distintas, portanto os percentuais não podem ser comparados como taxas anuais.

O resultado de 2023 mostra por que resumos de operações podem enganar. Suas quatro operações encerradas perderam 669.03 USDT, mas a conta ganhou 1,654.60 USDT porque uma posição aberta tinha resultado marcado de 2,323.63 USDT, líquido do custo de entrada. Não provisionamos uma comissão hipotética de saída. Um fator de lucro de 0.66 nas operações encerradas e um retorno positivo da conta inteira podem estar ambos corretos.

Audite uma operação perdedora antes de confiar na conta vencedora

O primeiro sinal de entrada do período reservado ocorreu em 2 de janeiro de 2024. A estratégia comprou na abertura bruta de 3 de janeiro, de 44,946.91 USDT, ajustada para cima em cinco pontos-base, chegando a 44,969.383455. Com orçamento total de entrada de 9,000 USDT, adquiriu aproximadamente 0.19993623 BTC. O nocional de entrada foi de 8,991.008991 USDT, e a comissão, de 8.991009 USDT.

Um sinal de saída em 22 de janeiro levou a uma execução em 23 de janeiro. A abertura bruta de 39,568.02 passou a 39,548.23599 após o slippage desfavorável de venda. O nocional vendido foi de 7,907.125205 USDT; após a comissão de 7.907125 USDT, o recebimento foi de 7,899.218080 USDT. Subtraia o custo original de entrada de 9,000 USDT: prejuízo líquido de 1,100.781920 USDT. Somados os 1,000 USDT de caixa intocados, a conta, agora sem posição, tinha 8,899.218080 USDT.

Esse registro é uma verificação de implementação melhor que um percentual arredondado. Ele expõe o momento dos sinais, os preços desfavoráveis, as bases das comissões e a diferença entre retorno da operação sobre o caixa comprometido (−12.23%) e variação da conta (−11.01%). Se um assistente não consegue conciliar esses valores, otimizar mais apenas sofisticará um cálculo pouco confiável.

Os custos importam, mas aqui a concentração do lucro importa mais

Na execução principal do período reservado, as comissões efetivamente modeladas somaram 171.19 USDT. A diferença desfavorável de preço em relação às aberturas brutas, ponderada pelas quantidades, foi de 85.59 USDT. Este último número é um diagnóstico em relação à referência de execução: os preços desfavoráveis já o incorporam. A soma dos nocionais comprados e vendidos foi de 17.12 vezes o capital inicial, mostrando por que um pequeno custo por lado pode se acumular.

Executamos novamente as mesmas regras com três configurações presumidas de custos. A execução sem custos rendeu 13.99%; a principal, 11.55%; e a de custos maiores, 9.16%. São simulações separadas. Os custos alteram a quantidade comprada e o caixa disponível para reinvestimentos posteriores, portanto a diferença entre os saldos finais não é simplesmente a soma das comissões e do slippage da execução principal.

As três operações encerradas vencedoras ganharam 5,244.53 USDT; as outras cinco perderam 4,089.57 USDT. O lucro líquido foi de 1,154.96 USDT. Essa dependência de poucos ganhos pode ser coerente com o seguimento de tendências, mas oito operações oferecem pouca evidência sobre a regularidade com que eles voltarão a ocorrer. Subtrair os três melhores resultados é um diagnóstico de concentração, não uma conta contrafactual válida que pudesse ter evitado essas operações sem mudar o dimensionamento posterior.

Os custos fixos estão fora desses retornos. Em uma conta real, desconte os custos de dados, software, uso de modelos e hospedagem efetivamente atribuíveis ao processo e depois considere os impostos segundo as regras aplicáveis. Uma regra diária determinística não precisa de uma chamada à API de um LLM a cada candle. Evite acrescentar uma despesa recorrente a um cálculo que código comum pode realizar.

Evite o sobreajuste registrando a busca, não admirando o vencedor

O sobreajuste costuma começar antes da execução de um otimizador formal. Experimente outro ativo, mude a data inicial, acrescente um filtro, examine o resultado e guarde a versão atraente: cada escolha amplia a busca efetiva. Um holdout convencional pode virar dado de desenvolvimento após inspeções repetidas. A pesquisa sobre sobreajuste de backtests trata desse problema de seleção; ela não concede um certificado geral a qualquer fluxo que use uma divisão entre treino e teste. [5]

Fixamos nove configurações de desenvolvimento: janelas de entrada de 40, 55 e 70 dias, cruzadas com janelas de saída de 10, 20 e 30 dias. A tabela mostra todos os retornos líquidos. A regra 55/20 permanece a principal, independentemente da classificação. Várias configurações geram operações idênticas, portanto nove linhas não são nove confirmações independentes.

As nove foram lucrativas nesse intervalo de desenvolvimento. É um contexto útil sobre essa pequena vizinhança de parâmetros, mas não estabelece um ótimo nem robustez entre ativos e regimes. As cinco operações encerradas da regra principal no desenvolvimento são uma base particularmente escassa para alegações sobre parâmetros. Não estimamos uma probabilidade formal de sobreajuste de backtest nem um nível de significância ajustado pela seleção.

Em seu projeto, preserve as tentativas que não chegaram à tabela final. Se você examina a amostra posterior e depois muda a regra, descreva a estratégia revisada honestamente: ela utilizou aquela amostra. Um novo nome de arquivo não restaura a barreira de informação.

Revise esta especificação de estratégia, o registro de experimentos e o código em busca de informação futura, reutilização do conjunto de teste e seleção não registrada. Rastreie a disponibilidade dos dados de entrada e o momento das execuções. Construa um conjunto mínimo de teste que exponha cada possível bug de implementação. Separe bugs de premissas de modelagem e hipóteses de investimento. Não mude parâmetros para melhorar o desempenho. Identifique quais conclusões não são sustentadas pela amostra.

O teste walk-forward avalia um procedimento de seleção — e ainda pode perder

Um experimento secundário faz outra pergunta: e se um pesquisador selecionasse, a cada ano, uma das nove variantes com dados passados? Em cada etapa, o treinamento começa em 1 de maio de 2020 e termina no dia 31 de dezembro anterior ao teste. Seleciona-se a variante de maior retorno líquido; os desempates favorecem o menor drawdown e, em seguida, a ordem dos períodos de entrada e saída. Ela é avaliada no ano seguinte, sem novos ajustes dentro daquela etapa. A divisão cronológica preserva a direção do fluxo de informação. [6]

O algoritmo selecionado perdeu 4.02% em 2025 e 14.24% de janeiro a julho de 2026. Um procedimento de seleção pode respeitar corretamente a ordem temporal e ainda decepcionar. Otimizar o retorno passado não oferece evidência de que a configuração escolhida dominará o mercado seguinte.

Cada etapa começa sem posição e com 10,000 USDT. São contas de teste reiniciadas de forma independente, não uma conta que carrega continuamente posições e patrimônio entre os anos. A etapa de 2026 é parcial. Não multiplique seus retornos para formar um histórico equivalente ao de uma operação ao vivo.

As datas de teste de 2024–2026 se sobrepõem ao segmento histórico reservado principal, e as janelas posteriores de treinamento incluem anos anteriores de teste. Este é um diagnóstico explicitamente secundário, não outro holdout intocado nem uma replicação independente do resultado em destaque.

Análise de Monte Carlo: descreva a incerteza que você realmente simulou

Usamos um bootstrap circular de blocos de comprimento fixo, um método de reamostragem para observações dependentes. A entrada são os 943 retornos diários líquidos da carteira na execução principal fixa, incluindo dias em caixa e custos. Para cada comprimento de bloco de 1, 10 e 30 dias, geramos 5,000 trajetórias com o mesmo horizonte de 943 dias, usando a semente 20261018. Os blocos podem passar do fim da amostra para seu início; o último é truncado no comprimento necessário. [7]

Cada trajetória simulada compõe os retornos sorteados e calcula seu próprio drawdown. Isso não simula novos preços de BTC, não recalcula os sinais de rompimento nem refaz os custos de negociação em uma nova sequência. Reorganiza retornos de carteira já observados. Um bloco de um dia descarta a ordenação serial; blocos maiores preservam trechos locais, mas não o regime histórico inteiro. Nenhum acrescenta uma crise ausente dos dados de entrada.

As frações simuladas de perda terminal vão de 39.68% a 42.66%. São saídas condicionais deste experimento de reamostragem, não estimativas da probabilidade de a estratégia perder dinheiro nos próximos 943 dias. A sensibilidade ao comprimento dos blocos merece ser preservada, em vez de se escolher a coluna mais tranquilizadora.

Com 5,000 trajetórias, o erro-padrão de Monte Carlo da fração de perdas é de aproximadamente 0.69–0.70 ponto percentual, calculado como √[p(1−p)/5,000]. Ele mede o ruído de uma simulação finita. Não inclui a incerteza sobre a fonte de dados, a regra de negociação, os regimes futuros ou a adequação das premissas de reamostragem. Executar um milhão de trajetórias reduziria o ruído de simulação sem oferecer mais histórico de mercado. Apresentar o erro de Monte Carlo separadamente da incerteza estudada é uma prática padrão de simulação. [8]

Audite o resultado e faça uma pergunta melhor para a próxima pesquisa

A implementação Python usa a biblioteca padrão para calcular a partir de observações diárias normalizadas. Os registros da pesquisa preservam relatórios por período, as nove variantes de desenvolvimento, os resultados secundários de walk-forward e os resumos do bootstrap. As revisões da fonte e os hashes identificam as observações utilizadas nos cálculos.

Uma auditoria útil começa pelo patrimônio final de 11,154.96 USDT do período reservado e pela primeira operação perdedora descrita acima. Concilie cada sinal, execução, comissão e mudança de caixa antes de interpretar o retorno final. Os cálculos mantêm a precisão completa; as tabelas arredondadas do artigo são apresentação, não dados substitutos para cálculos posteriores.

Depois, decida de que evidência sua pergunta precisa. Para investigar a precisão do feed, obtenha uma base independente. Para investigar a execução, registre horário da decisão, envio, confirmação, preço e quantidade executada sob restrições de ordem realistas. Para investigar um processo revisado de seleção de parâmetros, escreva a regra de seleção antes de avaliar outro período cronológico. São experimentos distintos e devem continuar distintos no registro.

Compare os sinais de estratégia com timestamp, ordens enviadas, execuções confirmadas e posições conciliadas nestes arquivos. Identifique a primeira divergência. Classifique-a como dados, temporalidade, dimensionamento, execução ou contabilidade e sustente cada constatação com IDs dos registros. Não reajuste a estratégia. Entregue uma tabela de conciliação e o menor exemplo reproduzível de qualquer bug.

Se seu objetivo é um diário de trading ou um scanner de setups, aplique a mesma disciplina. Armazene a versão da regra e o setup com timestamp antes do resultado; preserve sinais ignorados e rejeitados, além das operações. Peça a um assistente que concilie o diário com o registro de execuções e explique divergências. Uma história posterior à operação é menos útil que uma decisão registrada cujo resultado futuro possa ser medido.

Use apenas as definições de setup e informações registradas antes de cada decisão. Inclua sinais executados, ignorados e rejeitados. Concilie as operações efetivas com o registro de ordens. Apresente aderência, erros recorrentes de execução e resultados por categoria de setup previamente especificada. Separe padrões descritivos de evidência suficiente para alterar uma regra. Sinalize registros ausentes e amostras pequenas.

Chamaríamos este de um algoritmo de trading lucrativo?

No sentido estrito da contabilidade histórica, sim: a conta principal do período reservado ganhou 1,154.96 USDT após as comissões e o slippage presumidos. No sentido de investimento mais forte — um algoritmo com vantagem demonstrada, repetível e que mereça ser colocado em operação —, a evidência é insuficiente. Oito operações encerradas em um único arquivo cripto de terceiros não estabelecem essa conclusão.

A decisão também depende do mandato. Um leitor que buscasse retorno acumulado maior que o da referência de manutenção não o obteve no período em destaque. Um leitor incapaz de tolerar drawdown próximo de 30% nos fechamentos diários rejeitaria a trajetória observada. São avaliações contra possíveis exigências de investidores, não limites de aceitação que teríamos especificado secretamente antes de ver os resultados.

Um próximo passo útil é um teste prospectivo simulado, com a versão congelada, data de início registrada antes da chegada dos sinais e um plano para conciliar cada decisão com o mercado executável. Registre todas as revisões propostas sem substituir silenciosamente a versão testada. A execução simulada ainda exige premissas realistas; uma operação real pequena, se escolhida mais tarde, responde a perguntas adicionais sobre execuções e operação efetivas.

O valor prático de ChatGPT, Claude, Codex ou Claude Code é permitir que uma pessoa construa e examine essa estrutura de pesquisa mais rapidamente. Ela pode trazer uma resposta indesejada. Neste projeto, produziu uma conta histórica lucrativa, drawdowns relevantes, retorno abaixo da referência de manutenção e um pequeno número de operações decisivas. Publicar esses fatos é mais útil que pedir a um assistente uma descrição mais persuasiva da estratégia.