In-sample e out-of-sample: o teste cego em 7.846 regras do Dow

Atualizado em 09/08/2026

O que a pesquisa mostra: Sullivan, Timmermann e White testaram 7.846 regras de trading em 100 anos do Dow Jones: ajustando o data snooping pelo bootstrap, a melhor regra deixou de ser lucrativa no período out-of-sample, e os autores leem isso como evidência de eficiência crescente. Sullivan, Timmermann & White (1999), Data-Snooping, Technical Trading Rule Performance, and the Bootstrap (Journal of Finance, 54(5):1647-1691)

In-sample é a fatia da série histórica em que você calibra o algoritmo, mexendo no período da média, na distância do stop e no filtro de horário até a curva do teste ficar de pé. Out-of-sample é a fatia que fica trancada durante toda essa calibração e só abre no fim, para medir o que o sistema faz diante de preços que ele nunca viu. A diferença toda está no acesso.

O teste mais duro já publicado sobre essa separação usou 7.846 regras técnicas. Sullivan, Timmermann e White rodaram todas elas em 100 anos do índice Dow Jones e corrigiram o resultado pelo bootstrap, um procedimento que estima quanta performance aparece só porque você testou muita regra ao mesmo tempo. Feita a correção, a regra campeã deixou de ser lucrativa no período out-of-sample. A campeã de 7.846.

O caminho até esse resultado é sempre parecido. Você monta o algoritmo, roda o Backtest nos dados do passado e a tela devolve uma curva de capital subindo quase em linha reta, aí o código vai para a conta real e come capital logo no primeiro mês de operação.

O nome disso é Curve Fitting, sobreajuste em português. O algoritmo decorou o ruído do período em que foi calibrado. Ruído não se repete.

A raiz do problema é metodológica. Quem chega da ciência de dados aprende a separar treino e teste em qualquer ordem, porque em classificação de imagem a ordem dos exemplos não carrega informação, e essa liberdade acaba na série de preço, onde média, variância e cauda mudam conforme o ciclo de juros, o fluxo estrangeiro e a liquidez do livro de ofertas. A ordem cronológica vira parte do experimento.

As três janelas de dados, e o que cada uma faz

A validação começa dividindo o histórico. São três partições, e elas não se tocam.

O In-Sample (IS) é a janela de otimização. É o laboratório. O algoritmo enxerga esses dados, a otimização roda por cima deles e a saída é o conjunto de parâmetros calibrado.

O Out-of-Sample (OOS) é a janela de teste cego, e cego aqui é literal, porque o otimizador não pode ter enxergado um único candle desse pedaço enquanto procurava parâmetro. O OOS existe para medir robustez em dados inéditos. Usar o resultado dele para melhorar o modelo destrói a janela, e é esse o erro que a seção sobre a queima do OOS detalha adiante.

O Holdout Set é a terceira reserva. Fica sob bloqueio até o fim do desenvolvimento. Abre uma vez, e só.

O molde que vem da ciência de dados é a proporção de setenta por cento para treino e trinta por cento para teste. Dá para escrever essa divisão com precisão. Seja P(t) a série de preços no intervalo T_{total}; a divisão estática escolhe um ponto de corte \tau no calendário:

O bloco de treino T_{IS} vai do início da série até \tau, e o bloco de validação T_{OOS} fica com o que sobra até o fim dos dados. Duas linhas de código resolvem. O problema mora na premissa embutida nelas.

A premissa embutida é a estacionariedade. As propriedades estatísticas da série ficariam paradas no tempo. Preço não faz isso. O efeito prático é que a função densidade de probabilidade dos retornos medida na janela de otimização não coincide com a medida na janela de teste:

A leitura da equação é direta. A distribuição dos retornos R_t no in-sample, f_{IS}, difere da distribuição dos mesmos retornos no out-of-sample, f_{OOS}. Calibre o algoritmo para extrair lucro de um ambiente de juros baixos e ele vai encontrar juros altos e inflação do outro lado do corte, aplicando a mesma lógica a um mercado que trocou de regime no meio do caminho.

O tamanho do in-sample decide qual erro você vai cometer

Escolher o comprimento da janela de otimização é escolher entre dois erros, e a estatística chama esse dilema de compromisso entre viés e variância, que no algoritmo de trading aparece como duas doenças bem distintas.

In-sample longo demais, dez anos de dados intradiários contínuos, produz viés. O modelo é obrigado a achar um conjunto de parâmetros que sirva em 2014 e em 2024 ao mesmo tempo, então ele converge para uma média morna que descreve a década inteira e não descreve bem nenhum dos regimes que formam essa década. Ele nasce velho.

In-sample curto demais, três meses, produz variância. O algoritmo se ajusta ao ruído recente e às anomalias daquele trimestre, parece promissor por algumas semanas e derrete quando o fluxo institucional muda de lado, porque o que ele aprendeu foram os tiques do período, sem estrutura por baixo.

A saída é parar de raciocinar em calendário e passar a raciocinar em regime de mercado, porque uma janela de treino honesta contém mercado de alta, mercado de baixa e lateralização com choque de volatilidade dentro dela. Se o seu in-sample pegou só a alta financiada por estímulo governamental, o algoritmo aprende que comprar toda queda funciona, e leva essa regra para a conta real como se ela fosse permanente.

Anomalia publicada em paper sofre o mesmo desgaste. O drift pós-balanço medido por Bernard e Thomas apareceu em 41 de 48 trimestres entre 1974 e 1985 e encolheu depois disso.

O que a separação de dados não resolve

Três crenças sobre o assunto atrapalham mais do que a falta da técnica em si.

A primeira: separar dados não garante lucro futuro. Mesmo o modelo mais bem validado vai enfrentar Drawdowns (rebaixamentos de capital) em conta real, porque o mercado produz eventos sem precedente no histórico registrado. Nenhum teste cobre o inédito.

A segunda: validar não se reduz a recortar o calendário civil, otimizando de janeiro a dezembro e testando no ano seguinte, um corte que ignora sazonalidade, rolagem de contrato futuro e choque de liquidez concentrado em datas conhecidas. O estresse operacional contínuo fica de fora da conta.

A terceira é a mais cara das três. O desenvolvedor testa no OOS, vê resultado ruim, volta ao código, mexe no parâmetro, testa de novo na mesma janela e repete o ciclo até o resultado fechar positivo. Isso tem nome técnico: data snooping. O papel do teste cego é o contrário. Ele derruba hipótese fraca cedo, antes de o capital entrar.

Day trade e swing trade pedem janelas de tamanhos diferentes

A frequência de operação manda aqui. Quanto mais rápido o algoritmo toca o mercado, mais rápido os dados históricos dele perdem validade.

Para day trade, usar in-sample de cinco a dez anos é erro de método. A microestrutura do livro de ofertas de uma década atrás não descreve a fila de ordens de hoje, porque mudaram os participantes, o custo de corretagem e a latência de execução. Nesse cenário o in-sample vive em meses recentes, o out-of-sample cabe em semanas e a re-otimização é constante.

Swing trade e position operam ineficiências que levam semanas ou meses para se corrigir, então aqui o in-sample precisa engolir ciclo macroeconômico inteiro, com aperto monetário e afrouxamento dentro da mesma janela de treino. A tabela abaixo parametriza essa relação.

Dado de tick antigo engana. Usar o livro de ofertas de 2016 para calibrar uma operação intraday de 2026 tende a produzir falso positivo estatístico, porque a estrutura que gerou aqueles preços já não existe mais.

Walk-forward ancorada: como a janela caminha

A Anchored Walk-Forward Analysis (AWFA) troca o corte único por uma sequência de cortes que simula a passagem do tempo: ela otimiza no que já aconteceu, opera às cegas o pedaço seguinte, avança e repete o ciclo até acabar a série.

Por que ancorada e não a versão rolante, que descarta o começo da série a cada passo? Porque o ponto de origem fixo mantém as crises antigas dentro do treino em todas as iterações, enquanto uma janela rolante de dois anos aplicada a 2026 já esqueceu 2008, e o parâmetro que ela devolve nunca viu um evento daquele tamanho. A âncora não se move.

Por que a AWFA e não a divisão 70/30? Porque a divisão única entrega um resultado só, colhido num recorte específico do calendário, enquanto a sequência ancorada entrega vários resultados fora da amostra medidos em regimes diferentes. Um número pode ser sorte. Dez seguidos são comportamento.

Na metodologia ancorada, a janela de otimização expande e mantém a origem parada no passado, enquanto a janela de teste cego desliza para a frente. Para cada passo k, o in-sample expansivo é:

O segmento de validação daquela iteração começa exatamente onde o in-sample termina, sem sobreposição de um único candle entre os dois:

Terminadas as iterações, você concatena os retornos de todas as janelas OOS_k, e o resultado é uma curva de capital construída inteiramente sobre dados que o otimizador não podia ver no instante em que escolheu cada parâmetro. A curva concatenada é o veredito. Se ela se sustenta, o modelo mostrou robustez em mais de um regime.

A calibração depende de três variáveis. A tabela abaixo diz o que cada uma controla.

O tamanho da posição sai do out-of-sample, nunca do in-sample

A validação não termina no veredito de aprovar ou reprovar o algoritmo, porque o número que sai dela alimenta o Position Sizing (tamanho da posição) que vai ser usado na conta real.

Existe uma degradação esperada entre as duas janelas. O nome dela é haircut. Um Índice de Sharpe de 2.0 medido no in-sample não se repete no teste cego, e essa queda é normal, porque no in-sample o otimizador escolheu a dedo os parâmetros que se deram bem naquele pedaço específico de história.

Existe um erro caro aqui. É dimensionar risco pelo drawdown máximo do in-sample. Aquele rebaixamento foi minimizado por construção, então ele subestima o estresse que a conta real entrega, e quem calcula lote em cima dele começa a operar mais exposto do que imagina. A conta nasce errada.

O dimensionamento honesto usa outra base. São as métricas já degradadas do out-of-sample iterativo. A régua que eu uso aqui é essa: Monte Carlo em trades e em parâmetros, variação de 30% em cima dos parâmetros para ver se a estratégia quebra, corte no percentil 95 do drawdown simulado e de dois a três meses de conta simulada antes do dinheiro real entrar.

Estratégia que vira negativa quando você troca a média de quinze pela de nove estava sobreajustada desde o começo. Eu, particularmente, não gosto de reotimizar robô que degradou: prefiro um teto de drawdown tirado do Monte Carlo e a troca da peça quando o teto é batido.

Como o out-of-sample queima

Contaminação de dados derruba tudo isso. Duas contaminações respondem pela maioria dos casos.

A primeira é o Look-Ahead Bias, o viés de antecipação. Ele nasce de erro lógico no código, quando o algoritmo usa uma informação que ainda não existia no instante em que a decisão foi tomada, como usar o preço de fechamento do dia para decidir uma entrada na abertura daquele mesmo dia. O backtest fica excelente. A execução real nunca reproduz aquele preenchimento.

A segunda é o Data Snooping, e é dele que sai a queima do out-of-sample: você testa, o resultado vem negativo, você mexe no parâmetro e testa de novo nos mesmos dados OOS. Pronto, a janela virou in-sample estendido. E não tem volta.

A conta que descreve o estrago é a de testes múltiplos. A probabilidade de aprovar um modelo por sorte cresce com o número de tentativas na mesma janela:

Aqui \alpha é o nível de significância e N é o número de tentativas ou ajustes feitos testando na mesma janela OOS. Com \alpha de 5%, bastam 14 iterações (N=14) para a chance de encontrar um backtest lucrativo que seja puro ruído estatístico ultrapassar os 50%. Quatorze rodadas de ajuste.

O teste out-of-sample iterativo falhou de forma consistente. A hipótese principal cai. O rigor manda formular outra ineficiência do zero, em vez de forçar adaptações num modelo já reprovado, e eu detalho o critério que aplico antes do primeiro backtest em o que separa vantagem estatística de sorte.

Três crenças que reprovam no teste cego

São três mitos, e todos custam capital. A otimização de parâmetros costuma ser tratada como ajuste visual de curva, e o preço disso é dinheiro alocado em algoritmo com expectativa matemática negativa, então a tabela abaixo põe lado a lado o que se repete em fórum de trading e o que a estrutura dos dados impõe.

O protocolo, fase por fase

Quatro portões, e nenhum é opcional. Pular um deles não acelera nada. Só adia a descoberta do defeito para o momento em que ele custa caro, já com dinheiro real na mesa.

O Holdout Set entra nesse fluxo como validador final, então, se o algoritmo sobreviveu ao in-sample expansivo e ao out-of-sample iterativo, ele ainda precisa encarar um bloco de dados oculto e intocado até o teste anterior ao deploy.

1. ✅ Fase 1: Seleção e Saneamento de Dados. Ajuste os splits, agrupamentos e proventos no caso de ações, alinhe os vencimentos e faça o roll-over no caso de contratos futuros e separe o Holdout Set antes de olhar qualquer gráfico. Passa quando o banco histórico espelha o feed da corretora; reprova quando a série tem lacuna ou preço fantasma.

2. ✅ Fase 2: Treino In-Sample (IS). Defina a hipótese com o menor número de parâmetros que der, insira slippage e corretagem de forma realista no simulador e otimize buscando estabilidade de drawdown antes de lucro máximo. Passa quando o retorno ajustado ao risco se mantém em regimes variados; reprova quando a curva sobe sem correção nenhuma, o que indica superajuste.

3. ✅ Fase 3: Execução Out-of-Sample (OOS). Desloque a janela pelo método iterativo da AWFA, meça a degradação de performance entre as janelas e respeite a proibição de voltar à Fase 2 com base no que você viu no OOS. Passa quando a degradação do Índice de Sharpe é previsível e tolerável; reprova quando a estratégia entra em colapso e perde viabilidade.

4. ✅ Fase 4: Validação Holdout Final. Execute o código já estabilizado na reserva inviolável de dados, uma única vez. Passa quando desempenho e métricas de risco ficam parecidos com os do OOS iterativo, e aí o modelo está pronto para o deploy; reprova quando aparece degradação catastrófica, e nesse caso a hipótese inteira é descartada.

Perguntas frequentes sobre validação de algoritmos

Qual a melhor proporção IS OOS para trading?

Não existe proporção fixa que sirva para tudo. O que decide é o conteúdo da janela. O in-sample precisa ser longo o bastante para conter ciclo de alta, de baixa e de lateralização, e o out-of-sample precisa refletir as condições mais recentes do ativo que você vai operar.

Como evitar o curve fitting na criação de robôs de investimento?

Reduzindo os graus de liberdade do modelo. Cada parâmetro otimizável, seja período de média, alvo, stop ou filtro de horário, multiplica as combinações que o otimizador pode varrer, e quanto mais combinações existirem, maior a chance de uma delas descrever o ruído daquele período com precisão acidental. Menos parâmetros, menos ruído decorado.

O que acontece se a estratégia falhar no teste Out-of-Sample?

Ela é reavaliada na estrutura ou descartada. Voltar ao código para ajustar regra e forçar resultado positivo na mesma janela cega destrói a validade estatística do teste, porque a janela deixa de ser cega no instante em que o resultado dela guia uma alteração. Descartar sai barato. O algoritmo ajustado até passar cobra a conta depois, com dinheiro real.

Posso testar os mesmos dados OOS mais de uma vez?

Metodologicamente, a resposta é não. A janela perde a propriedade de teste cego na primeira execução cujo resultado guiou uma alteração no código, e cada rodada nova nos mesmos dados aumenta a chance de aprovar ruído. Para testar de novo, você precisa de dados novos.

Qual a diferença estatística entre backtest e teste Out-of-Sample?

Backtest é o nome da simulação inteira em dados históricos. O teste out-of-sample é uma parte isolada dessa simulação, rodada em dados que não influenciaram nenhuma decisão de construção do modelo, e é justamente essa condição de não influência que dá valor ao número final. Todo OOS é backtest. Nem todo backtest tem OOS.

Quantos anos de dados históricos preciso para criar um robô quantitativo?

Depende da frequência operacional. Position e swing trade pedem janelas de 10 a 15 anos, o suficiente para abranger ciclo econômico inteiro, com aperto monetário e afrouxamento no mesmo conjunto de dados. Day trade e High-Frequency Trading (HFT) vivem em micro-regimes que mudam em semanas, então meses de dado tick-by-tick valem mais do que uma década de candle diário.

O que é a Análise Walk-Forward no mercado financeiro?

É a validação iterativa em que o modelo simula a própria adaptação ao longo do tempo: a janela de otimização avança, a janela de teste cego rola para a frente logo atrás dela, e o resultado final é a costura de várias fatias out-of-sample consecutivas.

Por que a divisão cronológica simples é considerada perigosa no trading?

Porque o mercado é não-estacionário. Cortar a série pelo meio do calendário civil pode empurrar todas as mudanças severas de política macroeconômica para um lado só do corte, e aí o teste cego mede um regime que o treino nunca viu, ou repete o regime que o treino já esgotou. Nos dois casos o número engana.

O que é a deflação do Índice de Sharpe?

É a penalidade estatística aplicada ao Sharpe em função do número de testes feitos até chegar naquele resultado, e a lógica é esta: quanto mais combinações de parâmetro o desenvolvedor experimenta no mesmo conjunto de dados, maior a probabilidade de o melhor número ter vindo do acaso, então o Sharpe reportado precisa ser descontado por essa contagem. Sharpe sem número de tentativas é número solto.

Qual o papel do conjunto Holdout (Holdout Set) na validação final?

Ele é o último portão. Fica separado desde a Fase 1 e não é tocado durante a otimização nem durante o walk-forward, então chega ao fim do projeto como o único pedaço de história ainda intacto. Roda uma vez, antes do deploy. Se o desempenho ali destoar do OOS iterativo, o projeto volta para a mesa.

Indicadores defasados (lagging) prejudicam o In-Sample?

Se usados sozinhos, sim. Indicador derivado de preço passado carrega atraso por construção, e empilhar vários deles na otimização deixa o modelo bom em descrever o movimento que já aconteceu e lento para detectar ponto de inflexão (turning points) no out-of-sample.

Custos friccionais (slippage) devem ser incluídos no In-Sample ou Out-of-Sample?

Nos dois, com o mesmo critério. Omitir spread, corretagem e o impacto do slippage infla a curva do in-sample e ainda estraga a comparação entre as janelas, porque a degradação medida no OOS passa a misturar dois efeitos diferentes: a perda de vantagem real e o custo que nunca foi contabilizado.

O que fazer antes de ligar o algoritmo

Dividir a série é a parte fácil. O que consome validade é o número de vezes que você volta à janela cega depois de ver o resultado dela, e essa contagem não aparece em nenhum relatório de backtest, em nenhuma plataforma. Ninguém publica esse número.

Degradação entre a janela de otimização e a janela de validação é esperada, e o trabalho da engenharia é medir o tamanho dessa queda e dimensionar o capital para aguentá-la, porque aceitar esse número no laboratório custa bem menos do que descobrir o mesmo número com dinheiro na mesa.

Cinco decisões resumem o protocolo. Todas acontecem antes do primeiro contrato enviado à corretora.

• Trate curva de capital sem correção como suspeita de Curve Fitting e vá atrás do defeito antes de comemorar.
• Separe de 15 a 20% do histórico mais recente e lacre esse pedaço como Holdout Set, antes de qualquer otimização.
• Use Anchored Walk-Forward Analysis (AWFA) nas séries não-estacionárias, que é o caso de qualquer preço de mercado.
• Interrompa a pesquisa quando a performance despencar na transição do In-Sample para os blocos do Out-of-Sample iterativo.
• Conte quantas vezes o mesmo conjunto de dados foi recompilado e testado, e desconte o Índice de Sharpe por essa contagem.

Referências e Literatura Quant

• Sullivan, Timmermann & White (1999). Data-Snooping, Technical Trading Rule Performance, and the Bootstrap (Journal of Finance, 54(5):1647-1691). link.
• Sobre Overfitting em Backtests: Bailey, D. H., Borwein, J. M., Lopez de Prado, M., & Zhu, Q. (2014), “Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting“, mostra como o sobreajuste em backtests leva a desempenhos enganosos e a falsas expectativas de lucro.
• Deflação do Índice de Sharpe: Lopez de Prado, M. (2018), “The Deflationary Gap of the Sharpe Ratio“, explora a degradação do Índice de Sharpe em cenários de múltiplos testes e a importância de ajustes para refletir a performance real.
• Não-Estacionariedade e Retornos de Ativos: Cont, R. (2001), “Empirical properties of asset returns: stylized facts and statistical issues“, detalha as propriedades empíricas dos retornos de ativos, incluindo a não-estacionariedade e suas implicações para modelos financeiros.
• Otimização e Tamanho da Janela In-Sample: Khandani, A. E., Lo, A. W. (2011), “What is the optimal length of an in-sample window for technical trading strategies?“, investiga a escolha do tamanho ideal da janela de otimização para estratégias de trading técnico, considerando a estabilidade dos parâmetros.
• Validação e Data Snooping: White, H. (2000). “A Reality Check for Data Snooping“. Apresenta uma metodologia para verificar a significância estatística de estratégias de trading, controlando o viés introduzido pelo “bisbilhotar dados” (data snooping).