La optimización walk-forward tiene fama de ser la forma honesta de ajustar una estrategia, y se la merece — comparada con optimizar sobre todos los datos y quedarse admirando el resultado. Pero la técnica tiene modos de fallo silenciosos, y todos producen el mismo artefacto: un informe de validación que dice "robusta" grapado a una estrategia que no lo es. Estos son los tres contra los que hemos tenido que blindarnos, ordenados por los destrozos que dejan.
Fallo uno: las ventanas tienen fugas
La forma incorrecta: ajustas sobre enero-junio, validas sobre julio y luego dejas que algo de julio influya en una segunda pasada — una reejecución después de ver el número out-of-sample, un "retoque pequeño" a la rejilla de parámetros, una feature normalizada sobre la serie completa. Cada cosa parece inocente. Juntas convierten la ventana out-of-sample en datos in-sample con retardo.
Los destrozos: un Sharpe out-of-sample que misteriosamente sigue al Sharpe in-sample. Los resultados out-of-sample reales son ruidosos y decepcionantes; una relación IS/OOS sospechosamente suave significa que la información está fluyendo hacia atrás. Vigilamos el ratio de forma explícita — un in-sample más de 3x superior al out-of-sample marca la ejecución, y un out-of-sample igual o menor que cero la mata por bonito que sea el in-sample.
Fallo dos: metric shopping entre ventanas
Corres tres ventanas walk-forward, obtienes tres resultados ruidosos y luego resumes: ¿Sharpe medio? ¿Mediana? ¿Descartar la peor ventana por "cambio de régimen"? Cada elección es un grado de libertad, y un optimizador decidido (humano o bayesiano) encontrará el resumen bajo el cual esta estrategia luce mejor. Setenta y cinco trials de Optuna por ventana son setenta y cinco oportunidades de ajustar ruido, multiplicadas por cuantos resúmenes estés dispuesto a considerar.
Los destrozos: una estrategia que pasa la validación y luego entrega en real el rendimiento de la peor ventana, porque la peor ventana era la única honesta. Nuestra regla: la agregación se fija en la configuración antes de la ejecución, el presupuesto de trials se fija, y el analista lee los resultados por ventana con la dispersión a la vista. Una estrategia que necesita el resumen amable para aprobar, no aprueba.
Fallo tres: el holdout que dejó de serlo
Un holdout funciona exactamente una vez. La segunda vez que una estrategia se evalúa contra él — tras un empujón a un parámetro, un retoque a la señal, un "vamos solo a comprobarlo" — ya no es un holdout; es un conjunto de validación lento. Quince días intactos suenan triviales de preservar hasta que llega la presión de iterar y volver a comprobar parece inofensivo.
Los destrozos son sutiles: resultados de holdout que mejoran a lo largo de las iteraciones de la misma estrategia. Los datos out-of-sample frescos no tienen ninguna razón para premiar la iteración tres por encima de la uno, y cuando lo hacen, el holdout ha sido minado. Imponemos el disparo único de forma mecánica: el holdout se evalúa una vez por ejecución del pipeline, el resultado se escribe en el registro, y una estrategia que necesite otro intento vuelve a pasar por todo el circuito — ventanas nuevas incluidas. Debe conservar al menos el 70% del Sharpe out-of-sample del walk-forward, y no hay una segunda tirada de ese dado.
La señal que sobrevive a los tres
Antes de todo eso, corremos un barrido de sensibilidad sencillo: movemos cada parámetro ±20% y observamos las métricas. Un edge real se degrada con elegancia; una coincidencia se cae por un precipicio. Es el test más barato del pipeline y veta estrategias que habrían pasado sin despeinarse por todo lo anterior — porque un precipicio de parámetros es la cara que tiene el sobreajuste antes de que le des ocasión de esconderse en la maquinaria de validación.
Nada de esto hace que la optimización sea segura. Hace que los modos de fallo sean ruidosos — que es lo máximo que honestamente se le puede pedir a un proceso de validación.
← Todos los artículos