Close
Cuando desarrollamos sistemas de trading algorítmico en StrategyQuant X, una de las preocupaciones principales es lo que conocemos como sobreajuste (overfitting). Hablamos de sobreajuste cuando el algoritmo encuentra beneficios en el ruido aleatorio del mercado en lugar de en patrones repetibles. Este whitepaper expone los métodos estadísticos que utilizamos en Club PQtrader para identificar aquellos sistemas que con mayor probabilidad han descubierto patrones reales y que, por tanto, tienen más opciones de seguir siendo rentables en el futuro. La efectividad de cada test se evalúa de forma individual y combinada, demostrando por qué cualquier desarrollador serio en SQX debe aplicarlos en serie si quiere maximizar sus probabilidades de encontrar sistemas ganadores.
El verdadero problema al que nos enfrentamos los desarrolladores de sistemas algorítmicos no es encontrar estrategias que se comporten bien sobre los datos históricos de entrenamiento. Eso, con la potencia de cómputo actual y herramientas como StrategyQuant X, es relativamente sencillo. El reto real es descubrir sistemas que sigan funcionando sobre datos futuros que la máquina nunca ha visto.
Es peligrosamente fácil sobre-optimizar y “sobreajustar” una estrategia: añadir parámetros innecesarios, retocar el diseño basándose en lo que vemos en el out-of-sample, o directamente no separar datos out-of-sample. Estos errores son tan habituales en traders novatos como en veteranos. Este artículo es un resumen de la metodología que aplicamos en Club PQtrader para superar el problema del sobreajuste, y a la vez una introducción para cualquier desarrollador que quiera profundizar en este campo.
Una vez definido y comprendido el problema, exponemos las técnicas que usamos para evitarlo. Explicamos la importancia de tener datos hold-out auténticos (nunca antes vistos) y cómo nos ayudan a seleccionar los sistemas más sólidos. Pero el periodo hold-out por sí solo no basta: es necesario combinarlo con varios tests estadísticos adicionales que SQX nos proporciona de forma nativa.
Hay que comprobar que pequeños cambios en el mercado no provocan grandes cambios en el resultado del sistema (estabilidad de parámetros). Hay que manipular los datos de precio y otras variables como spread y comisiones para asegurarnos de que el sistema soporta condiciones adversas (Monte Carlo). Y hay que verificar que el sistema no fracasa en mercados similares al original.
En PQtraders defendemos un enfoque sistemático y reproducible. La metodología no es un secreto: es una serie de filtros que cualquiera con SQX puede aplicar. Lo que marca la diferencia es la disciplina para no saltarse ningún paso, y la honestidad para tirar a la basura aquellas estrategias que no superen la prueba final.
Figura 1. Equity curve de un sistema robusto: continuidad entre desarrollo, validación OOS y hold-out.
Robusto, adjetivo:
Que tiene fuerza o vigor.
Fuertemente formado o construido.
Capaz de funcionar sin fallos bajo un amplio rango de condiciones.
Una vez terminado, debemos poder confiar en que el algoritmo funcionará en un futuro desconocido. No podemos saber qué retos traerá ese futuro, así que tenemos que construir el sistema sólidamente y someterlo a estrés en una variedad de situaciones de mercado, de modo que su probabilidad de fracaso sea baja.
La regla de oro: para tradear un sistema, hay que confiar en él. Para confiar en él, tiene que ser robusto.
Cuando desarrollamos un sistema algorítmico en SQX, el sobreajuste es probablemente el problema más peligroso y, desde luego, uno de los más difíciles de superar. Es peligroso porque, contra-intuitivamente, cuanto mejor parece el sistema sobre los datos de desarrollo, peor suele comportarse después en datos no vistos o en cuenta real.
El pasado nunca es idéntico al futuro en los mercados financieros. Lo que ha ocurrido antes no se repetirá de forma exacta; los mercados pueden tener similitudes con el pasado, pero nunca igualdad. Y aquí está la clave: queremos que el sistema reconozca similitudes generales con el pasado y sepa aprovecharlas de forma genérica.
«Prefiero estar genéricamente acertado que precisamente equivocado.» — J. M. Keynes
Si afinamos un sistema hasta exprimir el último punto de rendimiento sobre el periodo de desarrollo, lo que la máquina aprende son métodos muy específicos para tradear ese mercado concreto: maximiza lo que el desarrollador quiere y minimiza lo que no quiere. Suena bien, y precisamente por eso es peligroso. Lo que parece mejora es solo especialización en un mercado que ya es pasado. El robot se vuelve excelente operando un mercado que ha analizado millones de veces, pero incapaz de aplicar esas mismas reglas en un mercado que nunca ha visto.
Una analogía útil: imagina un alumno que prepara un examen de matemáticas resolviendo una y otra vez problemas extremadamente complejos, mucho más allá de lo que se le va a exigir. Memoriza el método (rote learning) y los resuelve a la perfección. Llega el examen, le ponen problemas más sencillos basados en principios fundamentales, y no es capaz de resolverlos porque nunca aprendió a aplicar los principios generales.
Los ordenadores quieren memorizar mercados para maximizar su rendimiento. Pero no pueden memorizar mercados futuros porque aún no se han formado. Por eso fracasan, igual que el estudiante del ejemplo, en cuanto se enfrentan a algo que no han visto antes.
Patrón típico: una equity curve perfectamente ascendente durante el periodo de entrenamiento que se desploma de forma inmediata en cuanto entra en datos no vistos. Es la firma clásica del sobreajuste, y es exactamente lo que tenemos que evitar.
Figura 2. Ejemplo de sistema sobreajustado: rendimiento casi perfecto en in-sample y colapso inmediato en datos no vistos.
El término out-of-sample se usa con definiciones distintas según la fuente. A veces se refiere a datos de test, otras a datos de validación, y muchas veces se usa de una forma que en realidad ya no es out-of-sample. Para evitar ambigüedad, en este whitepaper usaremos el término hold-out para referirnos a un único bloque de datos que se utilizan una sola vez al final del proceso.
La idea es sencilla: cuando entrenamos el modelo usamos un periodo de datos. Cuando llega el momento de validar lo que hemos creado, usamos un segundo periodo completamente separado que la máquina nunca ha tocado. Por ejemplo, entrenar y desarrollar con datos del 01/2014 al 12/2022, usando esos datos una y otra vez en todos los tests. Una vez completados desarrollo y validación intermedia (incluyendo un OOS interno sobre 2023), y cuando ya tenemos el sistema más robusto y mejor desempeño posible, lo lanzamos una sola vez sobre el periodo 01/2024 a la fecha actual.
Este test sobre datos hold-out nunca vistos da una estimación estadísticamente insesgada de cómo se va a comportar el sistema en el futuro. Es, en la práctica, una máquina del tiempo. Podemos comprobar el comportamiento como si hubiera estado en demo durante todo ese periodo. En nuestro ejemplo, dos años de demo testing instantáneos. Si el resultado es consistente con los datos de entrenamiento, demuestra que el sistema está operando patrones reales del mercado y no ruido.
El resultado en datos no vistos depende de dos factores: los patrones repetibles que el sistema sí ha aprendido bien, y la suerte (buena o mala). Cuanto más largo es el hold-out, mayor es su significancia estadística. En periodos cortos, la suerte puede dominar. En periodos largos, la suerte buena tiende a compensarse con la mala, y lo que queda es el verdadero rendimiento del sistema.
Importante: el hold-out se ejecuta una sola vez, como test final. Si el sistema no cumple las expectativas, el sistema entero y todo su desarrollo van a la basura, y el proceso vuelve a empezar desde cero. El hold-out sirve para juzgar al sistema, no para mejorarlo. Si lo usamos para mejorar, deja de ser hold-out y se convierte en datos de entrenamiento, y todo lo que hagamos a partir de ahí es sobreajuste.
Estos datos son preciosos. Solo se pueden usar una vez. La calidad del sistema tiene que ser muy alta antes de entrar en hold-out. Todos los demás tests descritos en este artículo deben pasarse antes. Hay que estar lo más seguro posible de que ese es el sistema, porque solo hay una bala en la recámara. Una vez disparada, el sistema va a real o va a la basura.
Los años recientes (2020-2025) contienen mercados extraordinariamente diversos: pandemia, recuperación inflacionaria, ciclo agresivo de subidas de tipos, conflictos geopolíticos, ajustes en commodities y reorganización de las correlaciones tradicionales entre activos. Es un periodo hold-out durísimo y, precisamente por eso, una prueba de robustez excepcional.
«La forma de detectar el sesgo de data-snooping es bien conocida: hay que probar el modelo en datos out-of-sample y descartarlo si no pasa. Pero es más fácil decirlo que hacerlo. ¿Estamos realmente dispuestos a tirar semanas de trabajo? Pocos tenemos esa decisión. Muchos retocamos el modelo aquí o allá hasta que finalmente rinde razonablemente bien tanto en in-sample como en out-of-sample. Pero, voilà, al hacer eso acabamos de convertir los datos out-of-sample en in-sample.» — Dr. Ernest P. Chan
Es muy común encontrar valores de parámetros que parecen óptimos en backtest, pero resultan subóptimos cuando el sistema entra en producción. En Club PQtrader no buscamos solo el valor óptimo de cada parámetro, sino áreas óptimas. Veámoslo con un ejemplo: imagina un sistema que usa un indicador ATR con periodo ajustable a 14. Lo que queremos no es solo que rinda bien con 14, sino que también rinda razonablemente bien con valores cercanos como 10 o 18. Un cambio dramático en el rendimiento del sistema con un cambio pequeño de un parámetro es una señal de alarma: ese parámetro, y probablemente el sistema entero, está sobreajustado.
El sistema no tiene que rendir igual de bien con todos los valores cercanos, pero sí tenemos que verificar que un cambio de variable no provoca un colapso completo de la rentabilidad. La base estadística que utilizamos en este test está documentada en “Know Your System! – Turning Data Mining from Bias to Benefit Through System Parameter Permutation” de Dave Walton. SQX implementa este enfoque a través de su test System Parameter Permutation (SPP).
Los sistemas más robustos no son los que devuelven el beneficio más alto, sino los que ofrecen un área de variables con resultados estables. Pensándolo como un mapa topográfico, no buscamos el pico más alto, sino la mayor superficie de colinas. Sometiendo a estrés cada parámetro, reducimos la probabilidad de que el valor o el umbral de un indicador se haya descubierto por casualidad. Un rango circundante de valores con rentabilidades similares es una garantía adicional de que el sistema seguirá funcionando. Si el rendimiento cae bruscamente al alejarnos del óptimo, ese sistema está sobreajustado y debe descartarse.
Cada estrategia que pasamos por nuestro pipeline en SQX se somete a miles de permutaciones de sus variables, asegurándonos de que los parámetros seleccionados siguen siendo rentables si los movemos ligeramente respecto al óptimo.
La Walk-Forward Optimization es un método de robustez en el que los parámetros del sistema se ponen a prueba mediante un patrón rodante de optimización y backtest, generando resultados sobre datos no optimizados.
La mecánica es la siguiente: hay un periodo de optimización de los parámetros, seguido inmediatamente por un periodo de backtest sobre datos posteriores que la optimización no ha visto. Este patrón se desplaza hacia adelante en el tiempo, generando una serie de backtests con parámetros que no se han optimizado sobre el periodo en el que se evalúan.
Figura 4. Esquema de Walk-Forward Optimization: ventanas de optimización (verde) y backtest no optimizado (rojo) que rotan a lo largo del tiempo.
Es importante recordar una cosa: el sistema se ha desarrollado sobre los mismos datos que abarca la WFO. Por tanto, la WFO no convierte datos de entrenamiento en out-of-sample reales, ni sustituye al hold-out. Lo que sí hace, y muy bien, es indicarnos cómo reaccionan los parámetros al ciclo optimización-test. Si los parámetros walk-forward optimizados rinden bien a lo largo del backtest, el sistema demuestra robustez. Nos da confianza en que aguantará el funcionamiento futuro con parámetros aplicados a datos sobre los que no fueron entrenados
Lo que mide WFO: la sensibilidad de los parámetros al fallo en datos no optimizados. No es la bala de plata del sobreajuste — el sistema sigue construido sobre los mismos datos de entrenamiento que la WFO recorre. Pero sí demuestra capacidad de adaptación a un mercado que cambia constantemente, incluyendo el cambio del propio ruido del mercado.
En Club PQtrader no nos limitamos a un único test WFO. Para cada candidato sólido ejecutamos una matriz Walk-Forward (WFM) que combina decenas de configuraciones distintas de periodos de optimización y backtest. Tomamos métricas propias de cada ejecución y las comparamos con el sistema original. Solo aquellos sistemas que pasan una mayoría amplia de los tests de la matriz se consideran robustos. Si un sistema falla en un porcentaje significativo de configuraciones, descartamos el candidato. Es duro, pero los datos hablan: los sistemas que aprueban WFM amplio pasan después el hold-out con una frecuencia notablemente mayor.
Figura 5. Resultado de Walk-Forward Matrix: 152 configuraciones distintas; un sistema sólido aprueba la inmensa mayoría.
Monte Carlo toma los datos financieros sobre los que se ha desarrollado el sistema y los modifica de forma ligera pero significativa. Lo que estamos haciendo es eliminar el factor suerte (o ruido) de los resultados. Los mercados son muy ruidosos. Una noticia macro importante que mueve el mercado de forma brutal es, técnicamente, ruido: porque no es un patrón repetible. Si un sistema es demasiado potente y aprende a operar estos movimientos grandes pero ruidosos, está tratando ese ruido como si fuera un patrón legítimo. Como en realidad no lo es, el sistema se quedará pillado en el futuro cuando reconozca un ruido similar que no se confirme. Eso es exactamente sobreajuste: aprender patrones no repetibles que generan falsas señales en producción.
Monte Carlo verifica si esto está ocurriendo manipulando los datos de precio, alterando ese ruido. Se sube y baja la volatilidad, se manipulan los máximos y mínimos de las velas, se incrementa el spread, se retrasan o adelantan las entradas. Esto cambia el momento exacto de las operaciones, y un sistema robusto no debería ser muy dependiente de timings exactos. Lo mismo se hace con las salidas. Los resultados se comparan con el original: si caen dentro de la expectativa, el sistema se considera robusto. La lógica es clara: hemos cambiado los datos, pero el rendimiento aguanta.
Figura 6. Resultado típico de un test Monte Carlo: la curva azul es el sistema original; el resto son simulaciones con datos perturbados.
En Club PQtrader ejecutamos los siguientes tests Monte Carlo, cada uno con un mínimo de 1.000 repeticiones:
Cada sistema se somete a estrés en cada una de estas áreas para verificar que sigue siendo rentable bajo distintas permutaciones de las variables que intervienen en el trading real. SQX permite además calcular drawdown Monte Carlo — la métrica que utilizamos para dimensionar riesgo en cartera, no el drawdown del backtest puro.
Si un sistema se ha desarrollado sobre el Dow Jones (US30) y supera todos los tests de robustez descritos hasta aquí, también debería rendir en un mercado similar pero distinto, como el DAX (GER30) o el S&P 500 (US500). Toda estrategia es producto de los datos sobre los que se ha desarrollado, y esa dependencia es una vulnerabilidad.
En Club PQtrader ponemos un fuerte énfasis en evitar que un sistema sea excesivamente dependiente del activo sobre el que se construyó. El futuro es desconocido, así que en un esfuerzo por garantizar que nuestros sistemas sigan rindiendo en ese futuro, exigimos rentabilidad en al menos tres índices distintos antes de considerar que un sistema de índices es candidato real. Para sistemas en pares de divisas o en commodities aplicamos un criterio análogo: comportamiento estable en al menos dos o tres instrumentos correlacionados.
Solo cuando un sistema supera todos los tests anteriores — estabilidad de parámetros, WFO/WFM, Monte Carlo en sus distintas variantes y verificación en mercados similares — lo consideramos digno del paso final: el hold-out.
Hasta aquí hemos discutido las razones teóricas para realizar cada test de robustez. A continuación presentamos la evidencia estadística de su efectividad, basada en pools de estrategias generadas en SQX y filtradas mediante el pipeline descrito.
Las cifras siguientes muestran la mejora porcentual en el ratio de sistemas que sobreviven al hold-out cuando aplicamos los tests de robustez. Los puntos clave son los siguientes:
Las tablas que vienen a continuación reproducen los nombres de los filtros tal y como aparecen en SQX. Para que la lectura sea autosuficiente, este es un resumen breve de qué hace cada uno:
Antes de leer las tablas conviene aclarar qué significa que una estrategia “pase” un test. En SQX no existe una única “métrica de robustez”: cada test mide una dimensión distinta y aplica su propio umbral. Estos son los criterios concretos que utilizamos en el pipeline de Club PQtrader:
Profit Factor OOS ≥ 1,3 y un mínimo de 100 operaciones en cada segmento OOS, para que la inferencia estadística tenga sentido
«Estrategias en Databank» es el pool de partida (1.000 por activo). «Pasan Robustez» es cuántas superan el filtro correspondiente aplicando los umbrales anteriores y «Robustness Pass %» es el porcentaje resultante. «Pasan OOS 2023» es cuántas de esas también pasan un OOS adicional sobre el año 2023. «Holdout Pass %» es, sobre las que pasan OOS, el porcentaje que después supera el periodo hold-out (01/2024 – 04/2026) con beneficio. La sección «Combinaciones» muestra el embudo cuando los filtros se aplican en serie: cada «+» añade un test al anterior y el pool se reduce en consecuencia.
| Filtro o Test Aplicado | Estrategias | Pasan Robustez | Pasan OOS 2023 | Holdout Pass % |
|---|---|---|---|---|
| Estrategias Iniciales | 1.000 | — | 457 | 45,70% |
| Mercados Adicionales | 319 | — | 196 | 61,44% |
| + Spread Cero | 262 | — | 166 | 63,36% |
| + MC Slippage | 211 | — | 145 | 68,72% |
| + MC Precio | 130 | — | 100 | 76,92% |
| + MC Parámetros | 68 | — | 59 | 86,76% |
Entrenamiento: 01/2014 – 12/2022 | Validación OOS: 2023 | Hold-Out: 01/2024 – 04/2026
| Test | Estrategias en Databank | Pasan Robustez | Robustness Pass % | Pasan OOS 2023 | Holdout Pass % |
|---|---|---|---|---|---|
| Tests individuales (cada filtro aplicado por separado al pool inicial) | |||||
| Estrategias iniciales | 1.000 | — | — | 526 | 52,60% |
| Seq. Optimization | 1.000 | 982 | 98,20% | 622 | 63,34% |
| Spread Cero | 1.000 | 814 | 81,40% | 542 | 66,58% |
| Mercados Adicionales | 1.000 | 399 | 39,90% | 241 | 60,40% |
| MC Parámetros | 1.000 | 201 | 20,10% | 152 | 75,62% |
| MC Spread | 1.000 | 945 | 94,50% | 606 | 64,13% |
| MC Slippage | 1.000 | 528 | 52,80% | 352 | 66,67% |
| MC Precio | 1.000 | 649 | 64,90% | 448 | 69,03% |
| SPP | 1.000 | 238 | 23,80% | 174 | 73,11% |
| Combinaciones (filtros aplicados en serie, embudo acumulado) | |||||
| Mercados Adicionales | 399 | — | — | 241 | 60,40% |
| + Spread Cero | 313 | — | — | 200 | 63,90% |
| + MC Slippage | 197 | — | — | 133 | 67,51% |
| + MC Precio | 165 | — | — | 115 | 69,70% |
| + MC Parámetros | 59 | — | — | 47 | 79,66% |
Los resultados muestran la importancia de combinar varios tests en serie en cualquier proceso de desarrollo. Los tests individuales mejoran el ratio de aprobación, pero cuando se aplican en cadena la mejora es masiva. Cada test estresa una parte distinta del sistema. Si cualquier parte falla, el sistema no es robusto y se descarta. Si supera todos los tests, es tan robusto como se puede pretender.
El precio: de 1.000 estrategias iniciales pasamos a unas 60-70 candidatas tras la cadena completa. Es una tasa de descarte enorme — superior al 93% — pero es exactamente esa exigencia la que se traduce en sistemas que aguantan en cuenta real.
Este whitepaper ha repasado los métodos de robustness testing que utilizamos en Club PQtrader para sistemas algorítmicos. Cada test sirve para estresar un aspecto distinto del sistema, y combinados en serie ayudan a vencer el problema crítico del sobreajuste.
Respetando la importancia de los datos hold-out auténticos, conseguimos una imagen fiel de cómo se habría comportado el sistema en datos no vistos. Combinando varios tests de robustez en cadena, garantizamos que los sistemas no solo rinden bien en datos de entrenamiento, sino que siguen rindiendo en datos no vistos y en cuenta real. Estas ideas no son solo teóricamente correctas: están estadísticamente validadas sobre pools amplios de estrategias generadas aleatoriamente en SQX. Cuando un trader desarrolla sistemas siguiendo estrictamente este roadmap de robustez, sus probabilidades de éxito a largo plazo aumentan de forma drástica.
Cuando aplicamos correctamente todo el pipeline de robustez, vemos una mejora masiva en la calidad del pool de candidatos. Estos candidatos de alta calidad nos permiten seleccionar el sistema individual que pasa al hold-out con un alto grado de confianza. Tenemos confianza no solo en que el sistema rendirá bien en el forward test, sino en que seguirá rindiendo de forma consistente cuando entre en cuenta real dentro del portfolio.
El mensaje final: no existe atajo. Los desarrolladores que se saltan tests, o que reutilizan el hold-out para refinar el sistema, están tirando piedras a su propio tejado. La disciplina del proceso es lo que separa a quien tiene una equity curve bonita en el simulador de quien tiene una equity curve real, sostenida en el tiempo. La metodología es pública, las herramientas existen en SQX. Lo que toca aplicar es la disciplina.
Figura 7. Continuidad entre Desarrollo, OOS y Hold-Out tras aplicar el pipeline completo de tests de robustez.
Potencia tu desarrollo de estrategias con la mejor tecnología del mercado.
ACCEDER A STRATEGYQUANT X*Aplica el cupón al finalizar tu compra para asegurar tu beneficio exclusivo PQtrader.
