Más allá del IS/OOS: diseño de ventanas walk-forward

Conclusión: si el OOS es un solo tramo, sigue siendo "una única prueba"

Dividir los datos en un periodo de optimización (IS) y otro de validación (OOS) es un primer paso válido para sospechar de la sobreoptimización. Pero si la división se hace una sola vez, el resultado del OOS solo indica "cómo le fue en ese tramo concreto".

Nuestra conclusión es la siguiente: dividir el OOS en varias ventanas, validar avanzando en el tiempo y mirar si cada ventana es rentable, no solo el total. Aunque el total sea positivo, si el beneficio se concentra en ciertas ventanas, la evaluación queda en suspenso.

La debilidad de la división fija

El punto de corte condiciona el resultado

En una división fija, es el desarrollador quien decide dónde cortar. Si el OOS coincide por casualidad con un periodo de tendencia clara, la lógica parecerá mejor de lo que es. Si coincide con el periodo opuesto, se descartará una lógica utilizable. En ambos casos, el resultado depende de una sola elección: el punto de corte.

Si miras el OOS una y otra vez, deja de ser OOS

Hay otro problema, y está en el comportamiento del desarrollador. Si el resultado del OOS es malo, se ajustan los parámetros y se vuelve a mirar el OOS. Al repetirlo, en la práctica estás eligiendo lo que encaja con el OOS. En apariencia son datos no usados, pero en realidad se han empleado para optimizar. Es un error que también podemos cometer nosotros mismos, y solo se evita con un procedimiento que lo impida.

Cómo construir las ventanas walk-forward

El walk-forward toma un "periodo de optimización" y el "periodo de validación inmediatamente posterior" como una ventana, y la repite desplazándola hacia adelante en el tiempo. El tramo de validación siempre queda en el futuro respecto al de optimización, y se obtienen varios OOS.

Criterio para decidir la longitud de la ventana

Es más seguro decidir la longitud de la ventana por el número de operaciones que por los años del calendario. Si el tramo de validación contiene muy pocas operaciones, que salga en positivo o en negativo lo decide el azar. Cuanto mayor sea el tiempo de permanencia y menor la frecuencia operativa de la lógica, más largo debe ser el tramo de validación.

Procedimiento para revisar ventana por ventana

1. Coloca las ventanas de modo que los tramos de validación no se solapen
2. Optimiza en cada ventana y aplica los parámetros obtenidos únicamente al tramo de validación inmediatamente posterior
3. Registra por cada tramo de validación el resultado, el PF, el número de operaciones y el drawdown máximo
4. Comprueba cuántas ventanas tienen PF de 1.0 o más y en qué épocas caen las ventanas con pérdidas
5. Comprueba si, excluyendo la ventana con mayor beneficio, el total restante sigue siendo positivo
6. Observa si los parámetros elegidos en cada ventana saltan de forma errática

Hay tres puntos clave en la revisión:

• Que las ventanas rentables no estén concentradas en unas pocas
• Que la pérdida de las ventanas con pérdidas no sea desproporcionada frente al beneficio de las rentables
• Que los parámetros óptimos de ventanas contiguas no cambien de forma extrema

Consideramos que no es necesario que todas las ventanas sean rentables. Un sistema de seguimiento de tendencia suele perder en las ventanas de periodos sin dirección. Lo que debe preocupar es no poder explicar por qué se pierde en una ventana, y que la profundidad de la pérdida supere lo previsto.

Límites y precauciones

Sin suficientes operaciones, la ventana no se sostiene

El backtest de ATLAS tiene 1193 operaciones en 7.5 años de validación, así que, aun dividido en varias ventanas, cada una conserva un número razonable de operaciones. En cambio, el backtest de ETHEREUM EA tiene 154 operaciones en 7.5 años de validación. Si se corta una lógica de baja frecuencia como esta en ventanas pequeñas, cada ventana queda con muy pocas operaciones y que sea rentable o no apenas sirve como criterio. Solo cabe hacer ventanas más gruesas o tomar la evaluación por ventana como mera referencia.

Las cifras publicadas son valores de todo el periodo

El PF y el porcentaje de acierto que figuran en el ranking de resultados reales son valores del periodo de validación completo. No son resultados por ventana, así que solo con ellos no se puede determinar si hay sobreoptimización. Conviene leerlos con esa salvedad.

El propio diseño de las ventanas también se puede optimizar

Si cambias la longitud o el número de ventanas y eliges la combinación que mejor aspecto da al resultado, eso también es sobreoptimización. Es condición previa fijar el diseño de las ventanas antes de ejecutar la validación y no moverlo después. Desde fuera, prácticamente no hay forma de comprobar que esa condición se haya respetado.

Aun así, el futuro es incierto

Superar el walk-forward no garantiza que el EA responda a mercados que no existieron en el pasado. En el forward test que operamos en cuentas demo, varios EA presentan resultados negativos. Son cuentas demo, no resultados de cuenta real, y el tiempo transcurrido desde el inicio es corto, por lo que no estamos en fase de sacar conclusiones ni de los buenos resultados ni de los malos. Los métodos de validación son una herramienta para reducir los errores, no una promesa de acierto.

Resumen

• En la división fija IS/OOS, el resultado depende del punto de corte y de cuántas veces se revisa el OOS
• El walk-forward crea varios tramos de validación y los comprueba avanzando en el tiempo
• Lo que se mira no es el total, sino el resultado de cada ventana: se revisan la concentración de beneficios y la estabilidad de los parámetros
• Cuanto menos operaciones tiene una lógica, más inestable es el juicio al dividirla en ventanas
• El diseño de las ventanas se fija de antemano. Aunque se supere, no se conoce el resultado futuro

También hemos recopilado nuestra forma de plantear la validación en el compendio de conocimientos.