A otimização walk-forward tem fama de ser a maneira honesta de calibrar uma estratégia, e a fama é merecida — comparada a otimizar em cima de todos os dados e admirar o resultado. Mas a técnica tem modos silenciosos de falha, e cada um produz o mesmo artefato: um relatório de validação que diz "robusto" grampeado a uma estratégia que não é. Aqui estão os três contra os quais tivemos que projetar defesas, organizados pelo estrago que deixam.
Falha um: as janelas vazam
O jeito errado: calibrar de janeiro a junho, validar em julho e então deixar qualquer coisa de julho influenciar uma segunda passada — uma reexecução depois de ver o número out-of-sample, um "ajustezinho" na grade de parâmetros, uma feature normalizada sobre a série inteira. Cada uma parece inofensiva. Juntas, transformam a janela out-of-sample em dado in-sample com atraso.
O estrago: um Sharpe out-of-sample que misteriosamente acompanha o Sharpe in-sample. Resultados OOS de verdade são ruidosos e decepcionantes; uma relação IS/OOS suspeitamente suave significa que há informação fluindo para trás. Monitoramos essa razão explicitamente — in-sample acima de 3x o out-of-sample marca a execução, e out-of-sample igual ou abaixo de zero a mata, por mais bonito que o in-sample esteja.
Falha dois: garimpar métrica entre janelas
Rode três janelas walk-forward, obtenha três resultados ruidosos e então resuma: Sharpe médio? Mediana? Descartar a pior janela por causa de "mudança de regime"? Cada escolha é um grau de liberdade, e um otimizador determinado (humano ou bayesiano) vai achar o resumo sob o qual essa estratégia parece melhor. Setenta e cinco trials do Optuna por janela são setenta e cinco chances de ajustar ruído, multiplicadas por quantos resumos você estiver disposto a considerar.
O estrago: uma estratégia que passa na validação e depois entrega ao vivo o desempenho da pior janela, porque a pior janela era a única honesta. Nossa regra: a agregação é fixada no config antes da execução, o orçamento de trials é fixo, e o analista lê os resultados por janela com a dispersão à vista. Uma estratégia que precisa do resumo simpático para passar não passa.
Falha três: o holdout que deixou de ser um
Um holdout funciona exatamente uma vez. Na segunda vez em que uma estratégia é avaliada contra ele — depois de um empurrãozinho em um parâmetro, um retoque no sinal, um "só pra conferir" — ele deixa de ser holdout; vira um conjunto de validação lento. Quinze dias intocados parecem triviais de preservar até a pressão por iteração chegar e reconferir parecer inofensivo.
O estrago é sutil: resultados de holdout que melhoram ao longo das iterações da mesma estratégia. Dados out-of-sample novos não têm motivo algum para recompensar a iteração três mais que a iteração um, e quando recompensam, o holdout foi garimpado. Impomos o tiro único mecanicamente: o holdout é avaliado uma vez por execução do pipeline, o resultado é gravado no registro, e uma estratégia que precise de outra tentativa volta a percorrer todo o percurso — janelas novas e tudo mais. Ela precisa reter pelo menos 70% do Sharpe out-of-sample do walk-forward, e não existe uma segunda rolagem desse dado.
O sinal que sobrevive aos três
Antes de tudo isso, rodamos uma varredura simples de sensibilidade: mexemos em cada parâmetro em ±20% e observamos as métricas. Uma vantagem real degrada suavemente; uma coincidência despenca de um penhasco. É o teste mais barato do pipeline e ele veta estratégias que passariam ilesas por tudo que está acima — porque um penhasco de parâmetro é a cara do sobreajuste antes de você lhe dar a chance de se esconder na maquinaria de validação.
Nada disso torna a otimização segura. Torna os modos de falha barulhentos — que é o máximo que se pode honestamente pedir de um processo de validação.
← Todos os artigos