Qué significa realmente que un sistema sea robusto
Imagina dos sistemas.
El primero utiliza una media de 37 periodos y genera unos resultados extraordinarios. Cambias 37 por 36 y empeora mucho. Con 38 deja de ser rentable. En otro periodo histórico también falla.
El segundo utiliza una lógica que funciona razonablemente bien con 35, 36, 37, 38 o 39 periodos. Ninguna configuración produce una curva espectacular, pero el comportamiento general es parecido. Además, cuando lo pruebas sobre datos que no utilizaste para desarrollarlo, sigue mostrando una ventaja compatible con la hipótesis original.
Yo tendría bastante más confianza en la evidencia del segundo.
No porque sepamos que va a ganar dinero en el futuro. Eso no lo sabemos.
La diferencia es que necesitamos menos condiciones extraordinariamente específicas para explicar su resultado.
Ese es uno de los grandes problemas del overfitting en trading: puedes construir algo que explique magníficamente el pasado y que, precisamente por estar tan adaptado a él, tenga muy poca capacidad para generalizar.
Un sistema robusto debería soportar cierto grado de imperfección.
Los parámetros no tienen que ser exactos al milímetro. Los costes reales no deberían necesitar coincidir perfectamente con los supuestos del backtest. Y el resultado no debería depender de una pequeña porción excepcional de los datos.
Un buen backtest no demuestra que el sistema sea robusto
Este es uno de los errores que más me interesa evitar.
Puedes tener:
- un profit factor atractivo;
- una equity curve muy limpia;
- una expectancy positiva;
- un drawdown aparentemente controlado;
- cientos de operaciones;
y seguir teniendo un sistema frágil.
Esas métricas describen cómo se comportó una determinada configuración bajo unas condiciones determinadas.
La robustez plantea otra pregunta:
¿qué queda de ese resultado cuando dejamos de darle al sistema exactamente las mismas condiciones?
Por eso esta lección parte de que ya hiciste la evaluación básica del backtest. Si todavía estás decidiendo si sus estadísticas tienen sentido, primero revisaría cómo saber si un backtest es bueno.
Aquí hacemos algo diferente.
Yo lo resumiría así:
el backtest te presenta al candidato; las pruebas de robustez intentan encontrar motivos para descartarlo.
Ese cambio de mentalidad es muy sano.
Dejas de preguntarte:
“¿Cómo puedo demostrar que mi estrategia funciona?”
Y empiezas a preguntar:
“¿Qué tendría que ocurrir para demostrarme que esta ventaja es más débil de lo que parece?”
Qué deberías poner a prueba para evaluar la robustez
No existe un único “test de robustez” capaz de darte una respuesta definitiva.
La robustez se evalúa acumulando evidencias desde ángulos diferentes.
| Dimensión | Qué modificas | Qué quieres comprobar | Señal de fragilidad |
|---|---|---|---|
| Parámetros | Periodos, filtros, stops, umbrales | Que valores cercanos produzcan resultados razonablemente coherentes | Un único valor extraordinario rodeado de malos resultados |
| Muestra temporal | Periodos utilizados para desarrollar y validar | Que la ventaja no desaparezca al cambiar de muestra | Excelente in-sample y fuerte deterioro fuera de muestra |
| Evolución temporal | Ventanas sucesivas de desarrollo y prueba | Que la lógica sobreviva razonablemente al paso del tiempo | Dependencia extrema de una ventana concreta |
| Distribución de resultados | Secuencias y muestras de operaciones | Qué resultados alternativos son compatibles con el sistema | Riesgo potencial muy superior al observado en la curva original |
| Ejecución | Spread, comisión, slippage, retrasos, fills | Que unas fricciones peores pero razonables no destruyan la expectativa | El beneficio desaparece con cambios pequeños |
| Condiciones de mercado | Volatilidad, tendencia, rango, sesiones o activos | En qué entorno existe realmente la ventaja | La rentabilidad depende de un contexto que no estaba definido |
Fíjate en algo.
Ninguna de estas pruebas intenta demostrar que el futuro será igual al pasado.
Buscamos algo bastante más humilde y útil: que el resultado no necesite una versión demasiado perfecta del pasado para existir.
Primero: mueve los parámetros y mira la forma, no solo el mejor resultado
Supongamos que tienes una estrategia de ruptura cuyo periodo de referencia puede tomar valores entre 10 y 50.
Ejecutas diferentes configuraciones y descubres que 27 periodos produce el mejor resultado.
¿Eso es bueno?
Todavía no lo sabes.
Para mí, la información realmente interesante empieza alrededor de ese 27.
¿Qué sucede con 24?
¿Y con 25?
¿26?
¿28, 29 y 30?
Imagina dos posibles mapas de resultados.
En el primero ocurre algo parecido a esto:
- 25 periodos: +0.16R de expectativa;
- 26 periodos: +0.18R;
- 27 periodos: +0.20R;
- 28 periodos: +0.17R;
- 29 periodos: +0.15R.
En el segundo:
- 25 periodos: -0.02R;
- 26 periodos: +0.01R;
- 27 periodos: +0.31R;
- 28 periodos: -0.04R;
- 29 periodos: +0.02R.
El 27 es el mejor parámetro en ambos casos.
Pero las dos situaciones no se parecen en nada.
En el primer sistema ves una zona relativamente estable.
En el segundo tienes un pico espectacular rodeado de resultados mediocres.
Ese segundo caso me haría muchas más preguntas.
Esta es precisamente la lógica que trabajamos con más detalle en el análisis de sensibilidad.
No necesitas que todos los parámetros produzcan exactamente el mismo rendimiento. Eso sería pedir demasiado.
Buscas que pequeñas modificaciones no provoquen cambios desproporcionados.
No confundas comprobar sensibilidad con seguir optimizando
Aquí aparece una trampa muy fácil de cometer.
Realizas una prueba de sensibilidad y descubres que tu sistema funciona con un parámetro de 27, pero no con 26 ni 28.
No te gusta.
Entonces empiezas a añadir filtros hasta conseguir que también funcionen 26 y 28.
Después falla otro test.
Añades otra condición.
Y otra.
Al final puedes terminar utilizando las propias pruebas de robustez como una nueva ronda de optimización.
Eso es peligroso.
Si cada resultado negativo provoca un cambio del sistema, estás utilizando cada vez más información histórica para diseñarlo.
Por eso conviene separar mentalmente dos trabajos.
Uno es optimizar parámetros, que puede ayudarte a estudiar cómo responde el sistema y elegir configuraciones razonables.
Otro es validar.
Durante la validación deberías aceptar que una prueba puede salir mal.
Si únicamente aceptas el resultado cuando todas las pruebas se ven bonitas, puedes terminar construyendo un sistema perfectamente diseñado para aprobar tus propios exámenes históricos.
Después: comprueba que la ventaja sobreviva fuera de los datos que la crearon
Aquí entra una de las pruebas más importantes de todo el proceso: separar in-sample y out-of-sample.
El concepto es sencillo.
Los datos in-sample participan en la construcción o selección del sistema.
Los datos out-of-sample no deberían haber influido en esas decisiones.
Por eso el segundo conjunto tiene un valor especial.
Imagina que desarrollas un sistema utilizando datos de 2015 a 2022 y reservas 2023-2024 como muestra que no vas a tocar durante el desarrollo.
En el primer periodo obtienes una expectativa de +0.20R por operación.
Después desbloqueas el periodo reservado.
Hay varias posibilidades.
Si obtienes +0.16R, fantástico, aunque no necesitamos que coincida exactamente.
Si obtienes +0.08R, puede seguir existiendo una ventaja interesante que simplemente se ha degradado.
Si obtienes -0.18R, ya tenemos algo mucho más importante que investigar.
No existe un porcentaje mágico de deterioro que separe automáticamente lo robusto de lo que no lo es.
Lo que importa es entender si el comportamiento fuera de muestra sigue siendo compatible con la hipótesis que estabas probando.
Y cuidado con una reacción muy humana:
“Ese periodo fue raro.”
Claro.
Los mercados siempre encuentran formas de ser raros.
Precisamente quieres saber qué hace tu sistema cuando las condiciones dejan de parecerse a aquellas con las que fue diseñado.
El walk-forward añade información que un único corte no puede darte
Una sola división entre in-sample y out-of-sample tiene una limitación evidente: el resultado puede depender bastante del punto en el que hayas hecho el corte.
Por eso existe el Walk-Forward Analysis.
No voy a convertir esta sección en otro tutorial de walk-forward porque esa prueba tiene su propia lección dentro del curso.
Aquí lo importante es entender qué aporta al estudio de robustez.
En lugar de preguntar una sola vez:
¿funcionó después del periodo de desarrollo?
puedes observar repetidamente qué sucede cuando el sistema se calibra con información anterior y se enfrenta a información posterior.
Por ejemplo, de forma conceptual:
- desarrollas con A y pruebas en B;
- avanzas la ventana;
- desarrollas con B y pruebas en C;
- vuelves a avanzar;
- desarrollas con C y pruebas en D.
Lo interesante no es que todas las ventanas tengan que ganar.
La pregunta es otra:
¿el sistema mantiene un comportamiento razonablemente coherente cuando repetimos el proceso en distintos momentos?
Si únicamente funciona en una ventana extraordinaria y colapsa en las demás, tienes una señal de fragilidad.
Si atraviesa periodos mejores y peores pero conserva una estructura coherente con su hipótesis, la evidencia es bastante distinta.
Monte Carlo te obliga a dejar de enamorarte del camino que ocurrió
Esta es una idea especialmente importante.
Un backtest te muestra una secuencia histórica concreta.
Pero una ventaja probabilística puede producir secuencias muy diferentes.
Supongamos cinco operaciones:
+2R
-1R
+2R
-1R
-1R
El resultado total es +1R.
Ahora coloca exactamente los mismos resultados en otro orden:
-1R
-1R
-1R
+2R
+2R
Terminas igualmente en +1R.
Pero el camino psicológico y financiero es muy diferente.
En la segunda secuencia empiezas con tres pérdidas consecutivas.
Con cientos de operaciones, la diferencia entre caminos posibles puede ser enorme: rachas de pérdidas, profundidad del drawdown, tiempo de recuperación y evolución del capital pueden cambiar aunque la expectativa subyacente sea la misma.
Por eso una simulación Monte Carlo en trading puede aportar otra capa de evidencia.
No crea una ventaja.
No arregla un sistema malo.
No predice exactamente qué drawdown sufrirás.
Lo que hace es ayudarte a responder una pregunta mucho más útil:
¿qué otros caminos podrían ser compatibles con los resultados que estoy observando?
Quizá tu backtest mostró un drawdown máximo de 10R.
Si las simulaciones producen con frecuencia escenarios considerablemente peores, deberías pensar muy bien si tu gestión del riesgo está preparada para soportarlos.
El error sería asumir:
“Mi mayor drawdown histórico fue 10R, así que mi drawdown máximo futuro será 10R.”
Eso no se desprende del backtest.
La ejecución también forma parte de la robustez
Un sistema no vive dentro de una hoja de cálculo.
Tiene que ejecutarse.
Y entre el precio teórico y el resultado real aparecen fricciones:
- spread;
- comisiones;
- slippage;
- retrasos;
- liquidez;
- calidad del fill;
- gaps;
- financiación, cuando corresponda.
Imagina una estrategia con una expectativa histórica de +0.08R por operación.
Si utilizaste supuestos muy optimistas de ejecución y unas pequeñas fricciones adicionales reducen la expectativa a -0.03R, tienes un sistema con muy poco margen para equivocarte.
En cambio, imagina otro sistema con +0.18R que, después de endurecer razonablemente los costes, baja hasta +0.11R.
El resultado empeoró.
Perfecto.
Precisamente eso es lo esperable cuando ponemos una estrategia bajo presión.
La cuestión no es evitar el deterioro.
La cuestión es observar cómo se deteriora.
Esto conecta directamente con lo que acabamos de trabajar en stress testing: no quieres encontrar el escenario que haga quedar bien al sistema, sino conocer cuánto espacio existe entre las condiciones normales y el punto donde la ventaja desaparece.
Si estás preparando la fase práctica y quieres disponer de un entorno donde trabajar la ejecución antes de arriesgar capital real, puedes consultar Pepperstone y la promoción disponible mediante nuestro enlace. Una cuenta demo puede ser útil para practicar el proceso, pero no debes interpretar un resultado en demo como prueba de que obtendrás el mismo resultado con dinero real.
¿Tiene que funcionar en todos los activos para ser robusto?
No.
Y aquí tendría bastante cuidado con una definición demasiado simplista de robustez.
A veces se plantea que una estrategia verdaderamente robusta debería funcionar:
- en cualquier mercado;
- en cualquier temporalidad;
- en cualquier activo;
- en cualquier régimen.
Eso sería maravilloso.
Pero no es un requisito razonable para todos los sistemas.
Supongamos que desarrollas una metodología cuya hipótesis depende explícitamente de tendencias prolongadas.
Si la ejecutas en un entorno fuertemente lateral, podría comportarse mal.
Eso no demuestra automáticamente que el sistema esté sobreoptimizado.
Quizá simplemente está haciendo lo que su lógica dice que hará.
La cuestión importante es que esa dependencia estuviera definida antes de observar el resultado.
Un sistema puede ser especializado y robusto al mismo tiempo.
Lo que no me convencería sería algo así:
“Funcionó de 2018 a 2020 porque había tendencia.”
Después falla.
“Eso es porque había demasiada volatilidad.”
Lo ajustamos y vuelve a fallar.
“Eso es porque ahora la volatilidad es demasiado baja.”
Si siempre encontramos después una explicación para justificar cada fracaso, dejamos de probar una hipótesis y empezamos a contar historias.
Estudia si los beneficios están repartidos o dependen de unas pocas operaciones
Este análisis puede descubrir sistemas aparentemente sólidos que en realidad dependen de muy pocos eventos.
Imagina 300 operaciones.
A primera vista parece una muestra considerable.
Pero después descubres que cinco operaciones representan el 65% del beneficio total.
Eso cambia la interpretación.
No significa automáticamente que la estrategia sea mala. Algunos sistemas tendenciales, por ejemplo, pueden depender naturalmente de relativamente pocas operaciones grandes.
Pero necesitas saberlo.
Porque entonces aparecen nuevas preguntas:
¿Qué ocurre si en el futuro no capturas una de esas operaciones por un problema de ejecución?
¿Qué pasa si ese tipo de movimiento se vuelve menos frecuente?
¿La ventaja sigue siendo positiva sin los mejores trades?
¿Es esa concentración coherente con la lógica del sistema?
Aquí el número de operaciones por sí solo puede engañar.
Tener 500 trades no necesariamente significa tener 500 observaciones igualmente informativas.
Comprueba también si depende demasiado de un periodo histórico
Otro test muy sencillo consiste en dividir los resultados.
Por años.
Por trimestres.
Por regímenes.
Por niveles de volatilidad.
Por sesiones, si tiene sentido para tu sistema.
No estás buscando que todos los segmentos sean rentables. Eso sería una expectativa poco realista.
Quieres descubrir de dónde procede el rendimiento.
Imagina que un backtest de diez años tiene una expectativa positiva.
Parece bien.
Pero cuando lo descompones, descubres que prácticamente todo el beneficio se produjo durante 18 meses.
Los otros ocho años y medio estuvieron planos o fueron negativos.
El resultado agregado es correcto matemáticamente.
Pero la historia que cuenta es muy diferente.
Ahora necesitas comprender si esos 18 meses representan precisamente el régimen que el sistema intenta explotar o si simplemente encontraste un periodo excepcional que sostiene todo el backtest.
Dos sistemas buenos pueden tener una robustez muy distinta
Veamos un ejemplo hipotético.
Tenemos dos sistemas.
Sistema A
Expectancy histórica:
+0.18R por operación
Cuando modificamos parámetros cercanos, obtenemos aproximadamente entre +0.12R y +0.19R.
Fuera de muestra:
+0.11R
Las diferentes ventanas temporales producen resultados desiguales, pero la mayoría son compatibles con la hipótesis.
Cuando endurecemos los costes de ejecución:
+0.07R
Monte Carlo muestra drawdowns potencialmente bastante mayores que el histórico, pero todavía compatibles con el riesgo que habíamos previsto asumir.
Sistema B
Expectancy histórica:
+0.31R por operación
Es muchísimo mejor.
Pero empezamos a investigar.
Los parámetros cercanos producen resultados entre +0.03R y -0.08R.
Out-of-sample:
-0.09R
Un pequeño incremento del slippage elimina prácticamente toda la ventaja.
Gran parte del beneficio histórico procede de unos pocos meses.
¿Cuál era el sistema más impresionante inicialmente?
B.
¿Cuál tiene más evidencias independientes apoyando que existe algo estable detrás del resultado?
A.
Esta distinción me parece fundamental.
No estás buscando el backtest que gana el concurso de belleza. Estás intentando encontrar una ventaja que sobreviva cuando empiezas a hacer preguntas incómodas.
¿Cuánto puede empeorar un sistema y seguir siendo robusto?
No existe un porcentaje universal.
No hay una regla seria que diga:
“Si el beneficio cae menos de 20%, es robusto.”
O:
“Un sistema necesita un profit factor out-of-sample superior a 1.5.”
O:
“Debe superar el 80% de las pruebas.”
Puedes utilizar criterios internos bien definidos para comparar sistemas, pero convertir un número arbitrario en ley universal suele ser mala idea.
La tolerancia depende de muchas cosas:
- número de operaciones;
- variabilidad de los resultados;
- tamaño del edge;
- distribución de ganancias y pérdidas;
- estrategia;
- mercado;
- frecuencia;
- costes;
- riesgo;
- objetivo específico de la prueba.
Un sistema con una ventaja pequeña será naturalmente mucho más sensible a unas comisiones adicionales que otro con una ventaja grande por operación.
Un sistema de baja frecuencia puede mostrar diferencias enormes entre periodos simplemente porque tienes pocas observaciones.
Por eso yo no intentaría reducir la robustez a una sola cifra.
Buscaría coherencia entre pruebas diferentes.
No existe un “robustness score” mágico
Algunas herramientas pueden darte una puntuación o porcentaje de robustez.
Puede ser útil.
Pero únicamente si entiendes cómo se calcula.
Si un software te muestra:
Robustez: 87/100
eso no significa nada por sí solo.
¿Qué está midiendo?
¿Sensibilidad de parámetros?
¿Monte Carlo?
¿Degradación out-of-sample?
¿Drawdown?
¿Número de escenarios superados?
¿Pondera todas las pruebas igual?
¿Dónde están los umbrales?
Una métrica compuesta puede facilitar comparaciones, pero no debería sustituir la comprensión de lo que ocurrió debajo.
Para mí, es mucho más útil poder decir:
“Este sistema tiene parámetros estables, mantiene una expectativa positiva fuera de muestra, aguanta costes algo peores y sus drawdowns simulados siguen siendo compatibles con nuestro presupuesto de riesgo.”
Eso contiene información.
“Robustez 87” no necesariamente.
La trampa más sofisticada: sobreoptimizar las propias pruebas de robustez
Supongamos este proceso:
Construyes un sistema.
Falla la prueba out-of-sample.
Lo modificas.
Ahora pasa out-of-sample, pero falla sensibilidad.
Lo modificas.
Pasa sensibilidad.
Monte Carlo revela un drawdown que no te gusta.
Cambias otra regla.
Ahora pasa Monte Carlo.
Lo pruebas por años y encuentras dos periodos malos.
Introduces otro filtro.
Después de suficientes iteraciones, terminas con una estrategia que ha superado todos tus tests.
¿Es robusta?
No necesariamente.
Quizá acabas de utilizar todas las pruebas de robustez como nuevos datos de entrenamiento.
Este problema es muy fácil de subestimar.
Cada vez que observas un resultado y cambias el sistema por ese resultado, has aprendido algo de esos datos.
Ya no son completamente independientes de tu proceso de diseño.
Por eso merece la pena registrar:
- cuántas versiones probaste;
- qué cambiaste;
- por qué lo cambiaste;
- qué información conocías en ese momento;
- qué criterios habías fijado antes de mirar el resultado.
La última curva no cuenta toda la historia.
El proceso que utilizaste para llegar hasta ella también forma parte de la evidencia.
Señales de que un sistema puede ser demasiado frágil
No existe una prueba definitiva, pero sí hay patrones que me harían investigar mucho más.
Por ejemplo:
- un parámetro exacto funciona extraordinariamente bien y los valores vecinos no;
- la ventaja prácticamente desaparece fuera de muestra;
- el resultado depende de unas pocas operaciones excepcionalmente buenas;
- casi todos los beneficios proceden de un periodo muy específico;
- pequeños cambios de spread, comisión o slippage eliminan la expectativa;
- necesitas numerosos filtros para conservar la rentabilidad;
- el sistema deja de funcionar cuando cambias ligeramente las reglas de ejecución;
- cada prueba que falla termina provocando una nueva modificación hasta que consigues aprobarla.
Ninguna de estas situaciones demuestra de forma aislada que el sistema sea inútil.
Pero piensa en ellas como piezas de evidencia.
Cuantas más necesitas explicar, más débil se vuelve la hipótesis de que estás observando una ventaja relativamente estable.
Qué aspecto tiene una degradación saludable
Este concepto me parece mucho más útil que buscar “el resultado perfecto”.
Un sistema robusto puede empeorar cuando endureces las condiciones.
De hecho, normalmente debería hacerlo.
Imagina:
Backtest original:
+0.22R por operación
Parámetros ligeramente diferentes:
+0.17R
Out-of-sample:
+0.13R
Costes más conservadores:
+0.09R
Periodos de mercado poco favorables:
-0.04R
Eso no describe una estrategia perfecta.
Describe algo mucho más creíble.
Sabemos que hay condiciones en las que funciona mejor y otras en las que puede perder.
Sabemos que los costes reducen la ventaja.
Sabemos que fuera de muestra el rendimiento no coincide exactamente con el periodo de desarrollo.
Todo eso es normal.
Me preocuparía más ver un sistema que gana exactamente igual:
- con cualquier parámetro;
- en cualquier mercado;
- en cualquier periodo;
- con cualquier coste;
- sin prácticamente ningún drawdown.
Cuando un resultado histórico parece demasiado perfecto, mi reacción no es aumentar inmediatamente la confianza.
Es revisar los supuestos.
Robustez tampoco significa ausencia de drawdown
Un sistema puede ser robusto y atravesar un drawdown importante.
No confundas estos conceptos.
La robustez intenta decirte algo sobre la estabilidad de la ventaja.
El drawdown te habla del comportamiento del capital desde un máximo previo.
Están relacionados, pero no son equivalentes.
Un sistema tendencial, por ejemplo, puede tener una ventaja perfectamente razonable y sufrir largos periodos difíciles cuando el mercado alterna constantemente entre movimientos falsos.
Eso no significa automáticamente que la ventaja haya desaparecido.
Por otra parte, tampoco podemos utilizar “es normal tener drawdown” como excusa para ignorar cualquier deterioro.
La pregunta útil es:
¿este comportamiento sigue siendo compatible con lo que nuestras pruebas nos dijeron que podía ocurrir?
Esa es una pregunta mucho más seria que mirar simplemente si la cuenta está en números rojos.
Una checklist práctica para evaluar la robustez
Si tuviera que revisar un sistema antes de cerrar esta fase del proceso, me haría estas preguntas:
- ¿Las reglas están suficientemente definidas como para repetir el test sin reinterpretarlas?
- ¿Los parámetros cercanos producen un comportamiento razonablemente estable?
- ¿El sistema conserva alguna evidencia de ventaja fuera de muestra?
- ¿Los resultados sobreviven a distintos periodos históricos?
- ¿El comportamiento observado tiene sentido con la hipótesis original?
- ¿Las ganancias están razonablemente distribuidas o dependen de unas pocas operaciones?
- ¿Monte Carlo muestra escenarios de riesgo asumibles para el tamaño con el que pretendo operar?
- ¿Costes algo peores destruyen la expectativa?
- ¿El sistema depende de fills o precios poco realistas?
- ¿Sé en qué condiciones de mercado espero que funcione peor?
- ¿Estoy aceptando resultados negativos de las pruebas o modifico el sistema hasta que todo sale bien?
- ¿Puedo explicar por qué existe la ventaja sin recurrir únicamente a que “el backtest gana dinero”?
No necesitas una respuesta perfecta a las doce.
Pero cuanto mejor puedas responderlas, más sabes realmente sobre tu sistema.
Y ese es el propósito de la robustez.
No producir un certificado.
Reducir las cosas que todavía no sabes.
¿Cuándo dejar de hacer pruebas históricas?
También puedes caer en el extremo contrario.
Prueba de sensibilidad.
Otra sensibilidad.
Tres variaciones adicionales.
Otro Monte Carlo.
Otra división temporal.
Diez activos más.
Cinco niveles de slippage.
Otra optimización.
Llega un momento en el que seguir analizando el mismo histórico aporta cada vez menos información nueva.
Porque ya has visto los datos.
Los has utilizado para desarrollar el sistema, evaluar parámetros, estudiar fallos y decidir qué merece continuar.
No puedes convertir esos mismos datos en información nueva indefinidamente.
En algún momento necesitas congelar una versión.
Y “congelar” significa realmente congelarla.
Nada de cambiar el stop después de tres operaciones malas.
Nada de introducir un filtro nuevo porque viste una entrada que habría sido fácil evitar mirando el gráfico después.
Nada de mover parámetros porque el último mes no te gustó.
A partir de ahí necesitas una fuente de evidencia diferente.
Si quieres preparar esa fase con un entorno de práctica antes de poner capital real en riesgo, puedes revisar Pepperstone desde nuestro enlace y comprobar las condiciones y la promoción disponibles para tu cuenta. La práctica en demo puede ayudarte con la ejecución y el seguimiento del sistema, pero no elimina las diferencias que pueden aparecer cuando operas en condiciones reales.
Un sistema robusto sigue sin ser una garantía
Esta es probablemente la frase más importante de la lección.
Puedes hacer todo bien:
- buenos datos;
- muestra suficiente;
- reglas claras;
- out-of-sample;
- sensibilidad;
- walk-forward;
- Monte Carlo;
- stress testing;
- costes realistas;
y perder dinero después.
No existe contradicción.
Todas estas técnicas estudian la evidencia disponible.
Ninguna conoce el futuro.
Los participantes cambian.
Los mercados cambian.
La volatilidad cambia.
La microestructura puede cambiar.
Una ventaja puede debilitarse.
La propia presencia de más participantes explotando una ineficiencia puede reducirla.
Por eso un sistema robusto no debe interpretarse como:
“Este sistema está demostrado y va a funcionar.”
Yo lo interpretaría así:
“He intentado encontrar explicaciones razonables por las que este resultado fuera un accidente del pasado y, hasta ahora, la hipótesis ha sobrevivido suficientemente bien como para justificar la siguiente fase de prueba.”
Eso es bastante más humilde.
Y también bastante más útil.
El siguiente paso: dejar que lleguen datos nuevos
Hasta aquí hemos estado trabajando fundamentalmente con historia.
Incluso cuando utilizamos datos out-of-sample, esos datos ya existen.
Hay un momento en el desarrollo de un sistema en el que necesitas dejar de tocarlo y observar qué ocurre mientras llegan observaciones nuevas.
Ese cambio parece pequeño, pero conceptualmente es enorme.
Ya no puedes ajustar ayer después de conocer mañana.
No puedes elegir el mejor parámetro sabiendo cómo terminó el periodo.
No puedes evitar retrospectivamente una operación incómoda.
Tienes unas reglas.
Las congelas.
Y observas.
Ese es exactamente el trabajo de la siguiente lección del curso: qué es el Forward Testing.
Si quieres utilizar una cuenta de práctica para esa siguiente fase, puedes consultar Pepperstone mediante nuestro enlace y revisar la promoción disponible en ese momento. Antes de pasar a dinero real, revisa siempre las condiciones concretas de la cuenta, costes, ejecución y apalancamiento aplicables a tu caso.
La idea con la que quiero que cierres esta parte del curso es sencilla:
un sistema robusto no es el que obtiene el mejor resultado cuando todo sale perfecto. Es el que sigue teniendo sentido cuando empiezas a quitarle las condiciones perfectas.
Preguntas frecuentes sobre la robustez de un sistema de trading
¿Un sistema robusto puede tener periodos de pérdidas?
Sí.
Robustez no significa una equity curve que sube permanentemente.
Una estrategia con expectativa favorable puede sufrir rachas de pérdidas, drawdowns y periodos completos en los que sus condiciones favorables aparecen con menor frecuencia.
Lo importante es comprobar si ese comportamiento es compatible con lo que esperabas encontrar o si representa un deterioro que contradice la hipótesis del sistema.
¿Existe un porcentaje de robustez ideal?
No existe un porcentaje universal que separe automáticamente un sistema robusto de uno frágil.
Puedes construir métricas internas para comparar alternativas, pero necesitan una definición clara.
Yo preferiría observar directamente qué ocurre con la sensibilidad de parámetros, datos fuera de muestra, evolución temporal, distribución de resultados, costes y condiciones de mercado.
¿Un sistema debe funcionar en varios mercados para ser robusto?
No necesariamente.
Que una lógica pueda trasladarse a varios instrumentos puede ser una evidencia interesante, pero algunas ventajas dependen de características concretas de un mercado.
La pregunta es si esa especialización estaba dentro de la hipótesis inicial o la estás utilizando después para justificar un mal resultado.
¿La robustez garantiza que el sistema funcionará en real?
No.
Las pruebas de robustez reducen algunas explicaciones alternativas del buen resultado histórico. No eliminan la incertidumbre futura.
Incluso una metodología muy bien validada puede deteriorarse, sufrir una secuencia improbable o encontrarse con unas condiciones de ejecución diferentes.
Precisamente por eso el proceso continúa con forward testing.
¿Cuántas pruebas de robustez debería hacer?
Las suficientes para atacar las principales fuentes de fragilidad de tu sistema, pero no tantas como para terminar optimizando contra cada una de ellas.
La pregunta no es cuántos tests hiciste.
Es qué riesgo de error intenta detectar cada uno y si aporta información distinta de las pruebas anteriores.
