Aula 8
Validação Estatística de Métodos
O overfitting de backtest é o equivalente estatístico de atirar setas contra uma parede e desenhar círculos à volta dos buracos. O padrão existiu — mas não era previsível. Se treinares 10.000 modelos aleatórios contra dados históricos da Primeira Liga, alguns vão mostrar ROI de +20% por pura sorte estatística. O desafio não é encontrar um backtest que funciona — é saber se funciona por razões reais ou por ruído.
Modo de falha
O backtest que desaparece em produção
O cenário é clássico: um analista desenvolve um método que mostra ROI de +18% em 200 entradas de backtest. Empolgado, começa a aplicar o método em tempo real. Após 50 entradas reais, o ROI é -5%. O que aconteceu? O método foi otimizado para o ruído específico daquele período histórico. As condições que geraram o edge no backtest não se repetiram — porque nunca foram condições reais, apenas coincidências estatísticas.
Diagrama 8.1
Sinais de Alerta de Overfitting em Backtest
Os 3 Sinais Clássicos de Overfitting
1. ROI muito elevado em backtest. Qualquer método que mostre ROI > 15% num mercado eficiente como Match Odds da Primeira Liga deve ser imediatamente suspeito. O mercado tem margens de 5-7% e é razoavelmente eficiente — ROIs sustentáveis estão tipicamente entre 3-10%. ROI de 20%+ é sinal de que o modelo está a capturar ruído, não sinal.
2. Múltiplas condições específicas. Se o método funciona “quando o Benfica joga em casa, à noite, com árbitro X, após vitória por +2 golos, contra equipas do meio da tabela, em outubro” — estás a sobreajustar. Cada condição adicional reduz o tamanho da amostra e aumenta a probabilidade de correlação espúria. O princípio da Navalha de Occam aplica-se aqui: o método mais simples é geralmente o mais robusto.
3. Win rate melhora monotonicamente com a adição de condições. Um sinal subtil mas revelador: se adicionares condições ao teu filtro e o win rate melhora sempre, é porque estás a remover casos onde o método falha em vez de refinar a lógica subjacente. Um método real deve mostrar uma relação não monotónica — algumas condições pioram o resultado porque removem casos positivos também.
Framework de Validação em 3 Partes
A forma mais robusta de validar um método é dividir os dados em três conjuntos independentes e impor uma regra rígida: nunca olhar para os dados de teste até ao final.
Código 8.1
Validação Cruzada Temporal (Walk-Forward)
01
split_method
=
Walk-Forward Validation
02
train_window
=
3 épocas (2021-2024)
// dados de treino
03
test_window
=
1 época (2024-2025)
// dados isolados
04
step
=
avança 1 época, retreina
05
total_folds
=
3 janelas deslizantes
06
roi_fold_1
=
+6.2%
07
roi_fold_2
=
+4.8%
08
roi_fold_3
=
+5.1%
09
roi_medio
=
+5.4%
// consistente entre folds — sinal real
Testes Estatísticos de Significância
Um backtest com ROI positivo não é suficiente — precisas de saber se esse resultado poderia ter acontecido por sorte.
Teste Binomial para Win Rate
O teste binomial responde a: “se a minha probabilidade real de acertar fosse 50% (ou outra baseline), qual a probabilidade de observar este número de acertos por acaso?”
Fórmula 8.1
Teste Binomial — Significância da Win Rate
Onde n é o número total de entradas, k é o número de vitórias, p é a probabilidade esperada (normalmente 50% para odds ~2.00, ou a probabilidade implícita média ajustada). O resultado é o p-value: quanto mais baixo, maior a confiança de que o resultado não é aleatório.
Leitura de p-value:
- p < 0.05: significância estatística — o resultado muito provavelmente não é aleatório
- p < 0.01: forte significância
- p > 0.10: o resultado pode ser sorte — precisas de mais entradas
Teste de Wald-Wolfowitz (Runs Test)
Este teste verifica se a sequência de vitórias e derrotas é aleatória. Se o método tem tendência para agrupar vitórias em certas fases e derrotas noutras, isso sugere que o desempenho depende de condições de mercado que variam ao longo do tempo — e não de um edge estável.
Exemplo de mercado
Sequência suspeita — detectada pelo Runs Test
Um método aplicado a jogos do Braga na Primeira Liga mostra 200 entradas com win rate de 54%. Mas a sequência revela 8 vitórias seguidas no início da época e 10 derrotas seguidas no meio.
Win rate global: 54%. Runs test: z = -2.31, p = 0.021 — rejeita aleatoriedade.
A sequência não aleatória sugere que o método depende de uma condição que varia sazonalmente (ex.: início de época vs. período de acumulação de jogos europeus). O edge não é estável ao longo do tempo — o método precisa de incorporar a variável sazonal.
Ignorar o runs test e assumir que o método é estacionário. Métodos que dependem de condições temporais específicas são menos fiáveis e mais difíceis de dimensionar.
Fórmula 8.2
Simulação Monte Carlo do Lucro Esperado
Gera 10.000 cenários possíveis onde o número de vitórias varia de acordo com a distribuição binomial. Compara o lucro real com a distribuição simulada. Se o lucro real estiver no percentil 95+, o resultado é muito provavelmente real. Se estiver abaixo do percentil 80, o resultado pode ser sorte.
Código 8.2
Simulação Monte Carlo em Python
01
n_simulacoes
=
10.000
02
n_entradas
=
200
03
win_rate
=
0.55
// WR observado no backtest
04
odd_media
=
2.00
05
lucro_real
=
+15.2 unidades
06
percentil_lucro
=
92.3%
// acima de 90% = confiança razoável
07
lucro_mediano_sim
=
+10.0 unidades
08
intervalo_90perc
=
-18.0 a +38.0 unidades
A Curva de Aprendizagem do Win Rate
Uma das formas mais informativas de validar um método é traçar a curva de win rate acumulado à medida que o número de entradas aumenta:
| Entradas | Variação típica do WR | Interpretação |
|---|---|---|
| 1-50 | 30-70% | Ruído puro — qualquer valor aqui é enganador |
| 51-100 | 45-65% | Começa a convergir, mas ainda volátil |
| 101-200 | 48-58% | Sinal começa a emergir |
| 201-500 | ±3% do valor real | Zona de confiança razoável |
| 500+ | ±1% do valor real | Confiança elevada |
Regra prática: Com 150 entradas começas a ter confiança mínima. Com 500 entradas tens confiança sólida. Qualquer decisão baseada em menos de 100 entradas é essencialmente especulação com uma camada fina de análise.
Sinais de Alerta Finais
Antes de aplicares capital a qualquer método validado, verifica estes sinais:
-
Win rate em backtest > 20 pontos percentuais acima do win rate em produção. Uma diferença grande sugere que o backtest capturou ruído que não se repetiu.
-
A performance do método depende de 1-2 outliers. Remove as 2 melhores entradas do backtest. Se o ROI cai de +12% para +2%, o método não é robusto.
-
Win rate varia drasticamente entre épocas. 60% na época 2022/23, 48% na 2023/24, 62% na 2024/25 — esta oscilação sugere que o método captura padrões específicos de cada época, não um edge transversal.
-
Lucro concentrado em menos de 10% das entradas. Se 90% do lucro vem de 10% das entradas, o método está a depender de acontecimentos raros — e a variância vai ser brutal.
Checklist de decisão
Checklist: Validação de Método
- Separei os dados em Treino (60%), Validação (20%) e Teste (20%) antes de começar?
- O teste binomial mostra p-value < 0.05?
- A simulação Monte Carlo coloca o lucro real acima do percentil 90?
- O método tem pelo menos 150 entradas no backtest?
- A performance é consistente entre épocas diferentes?
- Removi os 2 melhores resultados — o ROI mantém-se positivo?
- O win rate estabilizou (±3%) nas últimas 200 entradas?
Resumo
- Overfitting de backtest é o erro mais perigoso do analista quantitativo — transforma ruído em falsa confiança
- Divide os dados em Treino (60%), Validação (20%), Teste (20%) — e nunca olhes para o teste até ao fim
- Usa teste binomial e simulação Monte Carlo para avaliar significância estatística
- O runs test (Wald-Wolfowitz) deteta sequências não aleatórias que revelam dependência temporal
- 150+ entradas são o mínimo para começar a distinguir sinal de ruído
- Sinais de alerta: dependência de outliers, variação entre épocas, lucro concentrado em poucas entradas