Backtest de robô na Deriv: guia honesto

Por Equipe Codexium · Publicado em 2026-10-30 · Atualizado em 2026-11-13 · 9 min de leitura · Backtest e dados

Backtest é o teste de uma regra de operação com dados do passado. Para quem usa ou desenvolve um robô para a Deriv, é a forma mais barata de descobrir que uma ideia não funciona antes de perder dinheiro com ela. Mas o backtest também é a ferramenta que mais engana: com os mesmos dados, é fácil "provar" quase qualquer coisa. Este guia mostra como fazer um backtest honesto, passo a passo, e como interpretar o que ele diz e o que ele não pode dizer.

Um aviso logo de início: um backtest mostra como uma regra teria se comportado. Ele não prevê o futuro, e em índices sintéticos, cujos preços são gerados por um algoritmo aleatório, essa limitação é ainda mais forte.

O que é um backtest, na prática

Um backtest tem quatro peças:

1. Dados: uma série histórica de ticks ou candles do ativo, por exemplo um índice de volatilidade.
2. Regra: a lógica de decisão do robô, escrita sem ambiguidade. "Entrar quando parecer bom" não é regra; "entrar em PAR quando os últimos 3 dígitos forem ímpares" é.
3. Modelo de execução: como o contrato é aberto e fechado, qual a duração, qual o pagamento e qual o atraso entre o sinal e a entrada.
4. Gestão de risco: valor da entrada, stops de sessão, limite de operações.

O programa percorre os dados em ordem, aplica a regra a cada tick, registra cada operação simulada e, no fim, calcula métricas. A arquitetura é parecida com a de um robô real, só que lendo o passado em vez de receber ticks ao vivo. Se quiser entender essas camadas, veja como funciona um robô de trading na Deriv.

Passo 1: conseguir dados confiáveis

A API da Deriv permite pedir o histórico de ticks de um símbolo por WebSocket, em blocos. Algumas regras para não estragar o teste já na origem:

• Baixe ticks, não só candles, se a regra usa dígitos ou durações de poucos ticks.
• Guarde o horário (epoch) de cada tick e verifique se há buracos na série. Falhas de conexão criam lacunas que distorcem regras baseadas em sequência.
• Não misture símbolos. Cada índice sintético tem volatilidade própria.
• Use um volume grande: dezenas de milhares de ticks no mínimo, de vários dias diferentes.
• Armazene os dados brutos e nunca os "limpe" de um jeito que favoreça a regra.

A conexão deve usar um token apenas de leitura para essa tarefa. Para baixar histórico, você não precisa de permissão de negociação. Mais detalhes em token de API da Deriv com segurança.

Passo 2: escrever a regra antes de olhar os resultados

O erro mais comum é abrir os dados, notar algo "interessante" e então escrever uma regra que explora exatamente aquilo. Isso é ajustar a regra ao ruído. O caminho honesto é o inverso: escreva a hipótese e a regra, defina como ela será avaliada e só depois rode o teste.

Um bom registro da hipótese inclui:

• A ideia em uma frase e por que você acha que ela poderia funcionar.
• Os parâmetros exatos (duração, gatilho, tipo de contrato).
• Qual resultado faria você descartar a ideia.

Passo 3: modelar a execução com realismo

Muitos backtests parecem ótimos porque ignoram a execução real. Pontos a modelar:

• Pagamento real: use o pagamento que o contrato realmente oferece, não um valor arredondado para cima. Em contratos de cerca de 50%, um pagamento abaixo de 100% da entrada já cria expectativa negativa.
• Atraso: entre o tick que gera o sinal e a compra do contrato existe latência. Se a regra só funciona entrando no mesmo tick do sinal, ela provavelmente não funciona ao vivo.
• Início do contrato: confira em qual tick a Deriv considera o início e o fim do contrato. Um erro de um tick muda tudo em contratos de dígitos.
• Limites da plataforma: entrada mínima e máxima por contrato.

Passo 4: as métricas que importam

Taxa de acerto sozinha não diz quase nada. Um conjunto mínimo de métricas:

Compare sempre a taxa de acerto observada com a de equilíbrio e com o intervalo de incerteza. Com 1.000 operações de uma regra que na verdade acerta 50%, é comum observar algo entre 47% e 53% só por acaso (cerca de dois desvios-padrão de 1,6 ponto percentual). Uma taxa de 52% em 1.000 operações, portanto, não prova vantagem nenhuma.

Passo 5: evitar o overfitting

Overfitting é ajustar a regra até ela parecer excelente nos dados passados, capturando ruído em vez de um padrão real. Em séries aleatórias, isso é quase inevitável quando se testam muitas variações. Se você testar 100 combinações de parâmetros, algumas vão parecer vencedoras por pura sorte.

Sinais de que o backtest está sobreajustado:

• A regra tem muitos parâmetros e condições específicas ("só às terças, entre 14h e 14h20, depois de 4 ímpares").
• Pequenas mudanças nos parâmetros fazem o resultado despencar.
• O resultado é muito bom num período e ruim em outros.
• Você testou dezenas de variações e está mostrando apenas a melhor.

Passo 6: validar fora da amostra

A defesa principal contra o overfitting é separar os dados:

1. Amostra de desenvolvimento: onde você cria e ajusta a regra.
2. Amostra de validação: dados que você não olhou durante o desenvolvimento. A regra é testada uma única vez aqui, sem ajustes.
3. Teste em tempo real sem dinheiro (forward test): o robô registra os sinais em dias novos, sem operar, ou opera apenas na conta demo.

Se a regra perde a vantagem fora da amostra, a "vantagem" era ruído. Esse é o resultado mais comum, e ele é valioso: você descobriu isso sem arriscar dinheiro. Defina antes um critério de aprovação objetivo, por exemplo ficar acima da taxa de equilíbrio com folga em vários dias novos, e não mude o critério depois de ver os números.

Passo 7: simular a gestão de risco

Com a lista de operações do backtest, simule a banca com as regras de gestão que você pretende usar: entrada fixa, stop de perda e stop de ganho por sessão, limite de operações. Uma técnica útil é embaralhar a ordem das operações muitas vezes (simulação de Monte Carlo) para ver a distribuição de drawdowns possíveis. A ordem real foi apenas uma das muitas que poderiam ter acontecido.

Esse passo costuma mostrar que progressões de entrada, como o Martingale, aumentam muito o drawdown sem mudar a expectativa.

Erros que invalidam um backtest

• Olhar o futuro (look-ahead): usar, na decisão, um dado que só existiria depois do momento da entrada.
• Sobrevivência: testar só os períodos "bons" ou descartar dias com falhas.
• Ignorar o pagamento real ou arredondá-lo.
• Amostra pequena: conclusões tiradas de algumas centenas de operações.
• Testes múltiplos sem correção: escolher o melhor entre muitos resultados e tratá-lo como prova.
• Confundir padrão visual com estatística: sequências de dígitos parecem ter padrões, mas em séries aleatórias o passado não muda a chance do próximo tick.

Como ler um backtest de terceiros

Quando alguém mostra um backtest para vender um robô, faça estas perguntas:

1. Quantas operações e em qual período?
2. Qual pagamento foi considerado?
3. Houve separação entre dados de desenvolvimento e de validação?
4. Quantas variações foram testadas antes desta?
5. Qual o drawdown máximo e a maior sequência de perdas?
6. Existe resultado em tempo real, com histórico completo, incluindo perdas?

Se as respostas não vierem, trate o backtest como propaganda. Veja também como identificar sinais de golpe em robôs para a Deriv.

Um fluxo de trabalho honesto

1. Escreva a hipótese e a regra.
2. Baixe e verifique os dados.
3. Rode o backtest na amostra de desenvolvimento com execução realista.
4. Calcule as métricas e compare com a taxa de equilíbrio.
5. Rode uma única vez na amostra de validação.
6. Se passar, registre sinais em dias novos sem operar ou opere apenas na demo.
7. Simule a gestão de risco e defina stops antes de qualquer valor real.
8. Reavalie periodicamente e aceite descartar a regra.

Como o Codexium encara o backtest

No Codexium, tratamos backtest como filtro, não como vitrine. Ideias novas passam por teste com dados históricos e por registro em tempo real sem operar antes de chegar a qualquer usuário, e uma regra só segue adiante se mantiver o resultado em dias novos. Mesmo assim, nenhuma regra elimina o risco: todo contrato pode perder, e resultados passados não garantem resultados futuros. Por isso a ferramenta incentiva entradas controladas e limites de sessão.

Resumo

Um backtest honesto começa com uma regra escrita antes de olhar os dados, usa ticks confiáveis e execução realista, mede mais do que a taxa de acerto e separa desenvolvimento de validação. A maior parte das ideias não sobrevive fora da amostra, e descobrir isso cedo é exatamente o valor do processo. Use o backtest para descartar regras ruins e dimensionar riscos, nunca como promessa de resultado.

Se você testou muitas variações antes de chegar à regra final, considere também o efeito da escolha em si sobre o resultado. Veja como medir isso no guia de viés de seleção em backtest.

Depois do backtest, o próximo passo é a demo: veja como operar só em conta demo com robô com um protocolo de teste. No Codexium, a IA, o Bolli e o modo Manual operam na Conta Demonstrativa selecionada no topo do app.

Criar conta / Acessar o robô   WhatsApp

Perguntas frequentes

Backtest garante que o robô vai dar lucro?

Não. O backtest mostra como uma regra se comportou no passado, sob as premissas usadas. Ele serve para descartar ideias ruins e dimensionar riscos, não para prever resultados.

Onde conseguir dados para fazer backtest na Deriv?

A API oficial da Deriv permite consultar o histórico de ticks dos índices. Grave os dados com data e horário e confira se não há lacunas antes de testar.

Quantas operações um backtest precisa ter?

Quanto mais, melhor. Em contratos rápidos, algumas centenas de operações ainda deixam muita margem para sorte; milhares dão uma leitura mais estável.

O que é validação fora da amostra?

É testar a regra em um período de dados que não foi usado para criá-la nem ajustá-la. Se o resultado piora muito fora da amostra, a regra provavelmente foi ajustada demais ao passado.

Por que o resultado real é pior que o do backtest?

Os motivos mais comuns são overfitting, atrasos de execução, pagamentos diferentes dos simulados e erros de configuração que o teste não considerou.