Teste walk-forward para bots de cripto: um exemplo prático
Escolha configurações em dados anteriores, congele-as para uma janela posterior e preserve o caminho do capital. Passe pelo corte de datas, regra de seleção, capitalização composta e decisões sobre posições em aberto.
Você testa vinte configurações de bot no mesmo gráfico e escolhe aquela com o maior retorno. Agora, suas configurações refletem informações de todo esse período. Executá-lo novamente nas mesmas datas não traz nenhuma evidência nova.
O teste walk-forward seleciona repetidamente configurações em uma janela de treinamento anterior, congela essas configurações para uma janela de teste posterior e combina os resultados dessas janelas posteriores. Isso ajuda a analisar um processo de seleção em condições variáveis, mantendo os preços futuros fora de cada decisão de seleção.
Para as estratégias GRID e DCA, existe um problema contábil adicional: moedas e posições em aberto podem atravessar o limite da janela. Um teste útil precisa de uma regra para essas posições antes que o primeiro resultado apareça.
Treinamento, teste e demonstração forward significam coisas diferentes
| Termo | O que você faz | O que pode mostrar |
|---|---|---|
| Treinamento in-sample | Comparar configurações permitidas em uma janela histórica anterior | Qual candidato sua regra de seleção escolheria |
| Teste histórico out-of-sample | Executar as configurações escolhidas na próxima janela sem retreinamento | Como essa seleção se comporta em dados históricos posteriores |
| Sequência walk-forward | Repetir treinamento e teste conforme o tempo avança | O comportamento combinado do processo de seleção |
| Demo forward | Congelar uma configuração e observar novos dados de mercado com fundos virtuais | Se o fluxo de trabalho e o comportamento correspondem ao seu plano em um novo período |
O guia geral de backtesting aborda as limitações mais amplas da simulação histórica. O walk-forward adiciona uma divisão temporal repetida; ele não elimina suposições de execução, erros de dados ou a tentação de revisar regras após ver os resultados.
A documentação de walk-forward da QuantConnect descreve a seleção de parâmetros em janelas móveis e o equilíbrio na frequência de otimização. Reotimizar com mais frequência gera mais decisões e mais oportunidades de ajustar-se ao ruído recente.
Escreva o protocolo antes de comparar os resultados
Escolha o mercado, o intervalo de dados, o fuso horário e as configurações exatas dos candidatos. Mantenha a lista de candidatos pequena o suficiente para ser analisada. Um teste com três configurações declaradas é mais fácil de explicar do que uma busca por milhares de combinações não documentadas.
Especifique também:
- A duração do treinamento e a duração do teste, incluindo os carimbos de data e hora exatos dos limites.
- A métrica de seleção, o requisito mínimo de evidência e o critério de desempate.
- Taxas, slippage, tamanhos mínimos, arredondamento e o modelo de execução.
- O tratamento das posições e ordens em aberto em cada limite.
- Os ativos iniciais do benchmark e as regras de rebalanceamento.
Por exemplo, um protocolo hipotético pode escolher o maior retorno de treinamento entre três candidatos cuja drawdown de treinamento permaneça abaixo de um limite estabelecido. Se nenhum deles se qualificar, a estratégia mantém o capital em caixa no próximo mês de teste. Defina o limite de drawdown e o critério de fallback antes de analisar os meses de teste.
O limite é uma restrição de seleção, não uma promessa sobre o drawdown futuro. Uma estratégia que o respeita durante o treinamento pode ultrapassá-lo na fase de teste.
Separe as datas sem contar um mês de teste duas vezes
Use três meses para treinamento e um mês para teste neste cronograma ilustrativo em rotação. Todos os horários abaixo estão em UTC, e cada intervalo inclui o início e exclui o final.
| Rodada | Janela de treinamento | Janela de teste intacta |
|---|---|---|
| 1 | 1º de jan a 1º de abr | 1º de abr a 1º de mai |
| 2 | 1º de fev a 1º de mai | 1º de mai a 1º de jun |
| 3 | 1º de mar a 1º de jun | 1º de jun a 1º de jul |
| 4 | 1º de abr a 1º de jul | 1º de jul a 1º de ago |
As janelas de treinamento se sobrepõem. As quatro janelas de teste não se sobrepõem. Abril pode se tornar dado histórico de treinamento para a próxima rodada depois que terminar; não é possível usar o caminho de preços de abril para escolher as configurações testadas no próprio mês de abril.
Salve a seleção feita em cada limite. Um registro completo inclui os candidatos rejeitados e suas métricas de treinamento, para que outra pessoa possa reconstruir por que o vencedor foi escolhido.
Uma primeira rodada completa
A tabela a seguir contém valores fictícios para fins didáticos. Eles não são resultados de backtest medidos nem observações de mercado. Considere que a regra de seleção escrita exige um drawdown de treinamento de no máximo 10% e, em seguida, escolhe o maior retorno líquido de treinamento. Todos os retornos já descontam os custos informados do modelo.
| Candidato | Retorno do treinamento | Máximo drawdown do treinamento | Elegível? |
|---|---|---|---|
| A | +5,0% | 8,0% | Sim |
| B | +8,0% | 15,0% | Não |
| C | +4,0% | 6,0% | Sim |
O protocolo seleciona A. O retorno mais alto do candidato B não supera a restrição de drawdown declarada. O candidato C permanece no registro, mesmo tendo perdido a comparação.
Congele A para abril. Suponha que o exemplo didático atribua a ele um retorno líquido de −2% em abril. Esse valor entra no registro fora da amostra. Trocar para C porque teria lidado melhor com abril reutilizaria o mês de teste na decisão.
No limite de maio, o protocolo original compara novamente todos os candidatos usando os dados de fevereiro a abril. Ele pode selecionar C para maio se C vencer essa nova comparação de treinamento. Esta é uma atualização planejada utilizando as informações disponíveis naquele momento.
Una as janelas de teste posteriores em um único caminho de capital
Considere que as próximas seleções e retornos de teste são os seguintes. Esses valores continuam o mesmo exemplo fictício de contabilização e não vêm de uma simulação real de estratégia.
| Mês de teste | Configuração selecionada | Retorno líquido do teste | Capital inicial | Capital final |
|---|---|---|---|---|
| Abril | A | −2,0% | US$ 1.000,00 | US$ 980,00 |
| Maio | C | +1,0% | US$ 980,00 | US$ 989,80 |
| Junho | A | −3,0% | US$ 989,80 | US$ 960,11 |
| Julho | C | +2,0% | US$ 960,11 | US$ 979,31 |
Os valores finais subjacentes, sem arredondamento, são 980, 989,8, 960,106 e 979,30812. O retorno combinado é:
(1 − 0,02) × (1 + 0,01) × (1 − 0,03) × (1 + 0,02) − 1 = −2,069188%.
Somando as quatro porcentagens, temos −2%, o que difere do resultado composto. Leve o capital final da janela anterior para a próxima e arredonde apenas para exibição.
As observações de fim de mês mostram uma queda mais acentuada de cerca de 3,99% em relação ao capital inicial de US$ 1.000,00. O capital intramês pode ter caído ainda mais, portanto, as observações mensais não permitem determinar o verdadeiro máximo drawdown.
Para este exemplo contábil, considere que cada reinicialização de limite está incluída nos retornos líquidos mensais informados. Um backtest real deve calcular essas reinicializações a partir de suas posições e do modelo de execução.
Decida o que acontece com o inventário aberto de GRID ou DCA
Suponha que um bot termine abril com 0,01 BTC e 400 USDT em carteira. Considerando um valor hipotético de US$ 50.000 para o BTC, seu capital é de 900 USDT. Um novo mês não restaura o valor original de 1.000 USDT.
Escolha uma política de limite consistente:
Carregue as posições. Transfira as moedas, o saldo em dinheiro e o estado das posições para a próxima janela de teste. Defina o que uma alteração de configurações faz com as ordens e o inventário existentes. O simulador deve suportar essa transição; um novo backtest iniciado com os ativos padrão pode não representá-la.
Fechar e reiniciar. Cancele as ordens em aberto, venda ou encerre a exposição restante usando o modelo de execução declarado, deduza os custos e inicie a próxima janela com o capital resultante. Se a próxima configuração exigir inventário inicial de moedas, modele também essa aquisição e seus custos.
Ambas as políticas podem descrever um processo operacional real. Misturá-las após ver os resultados pode ocultar perdas. Mantenha a mesma política no benchmark quando for relevante e mostre o efeito de uma política diferente como uma análise de sensibilidade separadamente identificada.
Verifique o modelo de execução e o benchmark
Uma vela tocando um preço limite não prova que sua ordem poderia ter sido totalmente executada. Os dados das velas também podem ocultar se um nível de compra ou de venda foi atingido primeiro. Configurações de GRID densas podem parecer atraentes em uma simulação que assume uma ordenação intrabar favorável.
Documente como o modelo trata execuções parciais, prioridade na fila, spread e gaps. Repita a análise com custos ou execuções menos favoráveis, caso a ferramenta permita. Uma conclusão que desaparece após uma pequena alteração de custo merece investigação.
Use as mesmas datas, o mesmo capital inicial e os mesmos ativos iniciais para a comparação. Um bot que começa com metade em moedas e metade em dinheiro não é diretamente comparável a um benchmark que começa totalmente investido, a menos que você explique essa diferença de alocação.
A checklist de resultados do backtest é útil para revisar o relatório gerado. Mantenha o caminho mensal, a atividade de negociação, a exposição e os custos junto com o retorno total.
Mantenha a avaliação final separada do design do protocolo
Testes walk-forward repetidos podem, por si só, se tornar treinamento. Se você analisar todos os quatro meses de teste, alterar a lista de candidatos e rodar novamente o mesmo período, o método atualizado terá utilizado informações desses meses.
Registre essa revisão e reserve o histórico intacto ou novos dados futuros para a próxima avaliação. Um novo rótulo nas mesmas datas não faz com que elas se tornem inéditas novamente.
O registro para download pode ser simples: uma linha por rodada com datas de treinamento, versão candidata, métricas de seleção, configuração escolhida, datas de teste, modelo de custos, política de limites e resultado líquido do teste. Mantenha os relatórios brutos e referências de dados ao lado. O exemplo abaixo inclui a tabela fictícia como um CSV exportável para praticar a contabilidade.
Siga as verificações históricas com uma execução demo fixa
Pratique a contabilidade do exemplo
Baixe as quatro linhas fictícias dos meses de teste, incluindo o capital inicial e final. Estes são valores criados para fins didáticos, não um relatório de backtest.
Observe sua configuração no demo da Bitsgap
Após concluir sua análise histórica em uma ferramenta que suporte as janelas e a contabilidade necessárias, congele uma configuração de bot compatível no demo da Bitsgap. Registre seus ativos iniciais e configurações, depois acompanhe o desempenho com fundos virtuais e preços de mercado atuais. O demo é um exercício forward separado; este fluxo de trabalho não pressupõe um otimizador walk-forward integrado.
Perguntas frequentes
O teste walk-forward impede o overfitting?
Ele reduz uma fonte de viés in-sample ao separar cada janela de seleção do teste posterior. Mudanças repetidas no protocolo, vazamento de dados, execuções irreais e relatos seletivos ainda podem gerar resultados enganosos.
Qual deve ser a duração das janelas?
Não existe uma duração universal. A frequência das operações, o histórico disponível e o método de seleção determinam quanto embasamento cada janela contém. A divisão de três meses para treinamento e um mês para teste apresentada aqui é apenas um exemplo didático.
Posso somar os retornos de janelas de teste separadas?
Some os retornos sequenciais compostos quando cada janela começa com o capital final da janela anterior. Também preserve o caminho do capital, os custos e a exposição subjacentes; um percentual final isolado oculta diferenças importantes.
Forward demo é o mesmo que um backtest fora da amostra?
Um teste histórico fora da amostra utiliza dados históricos mais recentes em um simulador. O forward demo observa novos dados com fundos virtuais. Ambos têm limitações e nenhum deles garante execuções reais ou retornos futuros.
