A otimização walk-forward tem fama de ser a forma honesta de ajustar uma estratégia, e merece-a — sobretudo quando comparada com otimizar usando todos os dados e ficar a admirar o resultado. Mas esta técnica tem modos de falha discretos, e todos produzem o mesmo resultado: um relatório de validação que diz «robusta», anexado a uma estratégia que não o é. Eis os 3 modos contra os quais tivemos de nos precaver, organizados pelos estragos que deixam.
Falha 1: as janelas comunicam entre si
A forma errada: ajustar com os dados de janeiro a junho, validar em julho e depois deixar que algo de julho influencie uma segunda passagem — repetir a execução depois de ver o resultado fora da amostra, fazer um «pequeno ajuste» à grelha de parâmetros ou normalizar uma variável com base na série completa. Cada uma destas ações parece inofensiva. Em conjunto, transformam a janela fora da amostra em dados dentro da amostra, com atraso.
O estrago: um Sharpe fora da amostra que, de forma misteriosa, acompanha o Sharpe dentro da amostra. Os verdadeiros resultados fora da amostra são ruidosos e dececionantes; uma relação IS/OOS suspeitamente suave significa que a informação está a fluir para trás. Monitorizamos explicitamente o rácio: um Sharpe dentro da amostra superior a 3x o Sharpe fora da amostra sinaliza a execução, e um resultado fora da amostra igual ou inferior a zero reprova-a, por mais bonito que seja o resultado dentro da amostra.
Falha 2: escolher métricas entre janelas
Executar 3 janelas walk-forward, obter 3 resultados ruidosos e depois resumir: Sharpe médio? Mediana? Excluir a pior janela por causa de uma «mudança de regime»? Cada escolha acrescenta um grau de liberdade, e um otimizador determinado (humano ou Bayesiano) encontrará o resumo que faz esta estratégia parecer melhor. 75 ensaios Optuna por janela são 75 oportunidades de ajustar ao ruído, multiplicadas pelo número de resumos que se estiver disposto a considerar.
O estrago: uma estratégia que passa a validação e depois apresenta em produção o desempenho da janela pior, porque essa foi a única honesta. A nossa regra: a agregação fica definida na configuração antes da execução, o orçamento de ensaios é fixo e o analista consulta os resultados de cada janela com a dispersão à vista. Uma estratégia que precisa do resumo mais favorável para passar, não passa.
Falha 3: o holdout que deixou de o ser
Um holdout só funciona 1 vez. Na segunda avaliação de uma estratégia com esse conjunto — depois de um ajuste de parâmetro, de uma alteração ao sinal ou de um «vamos só confirmar» — já não é um holdout; passou a ser um conjunto de validação usado às escondidas. Parece fácil preservar 15 dias intocados, até a pressão para iterar apertar e voltar a verificar parecer inofensivo.
O estrago é subtil: os resultados do holdout melhoram ao longo das iterações da mesma estratégia. Não há razão para que dados novos fora da amostra favoreçam a iteração 3 em detrimento da 1; quando isso acontece, o holdout foi explorado. Impomos mecanicamente uma única utilização: o holdout é avaliado 1 vez por execução do pipeline, o resultado fica registado e uma estratégia que precise de outra tentativa volta a passar por todo o processo — incluindo novas janelas. Tem de conservar pelo menos 70% do Sharpe walk-forward fora da amostra, e não há uma segunda tentativa.
O sinal que resiste aos 3 modos de falha
Antes de tudo isto, fazemos uma análise de sensibilidade simples: ajustamos cada parâmetro em ±20% e observamos as métricas. Uma vantagem real degrada-se gradualmente; uma coincidência cai a pique. É o teste mais barato do pipeline e veta estratégias que teriam passado por tudo o que descrevemos acima — porque um precipício nos parâmetros é o aspeto do sobreajuste antes de lhe darmos oportunidade de se esconder nos mecanismos de validação.
Nada disto torna a otimização segura. Torna os modos de falha evidentes — que é o máximo que se pode honestamente exigir de um processo de validação.
← Todos os artigos
