Mejorar un sistema no significa eliminar sus pérdidas
Supongamos que tu estrategia entra correctamente, respeta su riesgo y pierde cinco operaciones seguidas.
La reacción emocional puede ser inmediata: “Necesito otro filtro”.
Pero todavía no sabes eso.
Una estrategia con ventaja puede tener operaciones perdedoras, rachas negativas y drawdowns. Si intentas crear una regla específica para evitar cada pérdida histórica, terminarás construyendo un sistema que sabe perfectamente qué habría tenido que hacer ayer.
Y eso no significa que sepa qué hacer mañana.
Este es precisamente uno de los problemas del overfitting en trading.
Cuantas más configuraciones, parámetros y filtros pruebas para después quedarte con la combinación que mejor funcionó, más oportunidades tienes de encontrar algo que parece extraordinario simplemente porque encajó muy bien con ese histórico concreto.
Por eso yo separaría dos preguntas que muchas veces se mezclan:
¿El sistema tiene un problema?
Y, solo después:
¿Qué modificación podría resolver ese problema?
Cambiar esas dos preguntas de orden es una de las mejores defensas contra la sobreoptimización.
Primero diagnostica qué está fallando
No todas las desviaciones de resultados justifican modificar las reglas.
| Lo que observas | Qué podría estar ocurriendo | Lo que evitaría hacer |
|---|---|---|
| Varias pérdidas consecutivas | Variación normal del sistema | Añadir un filtro solo para eliminar esa racha |
| Resultados peores en una condición concreta | Puede existir una dependencia del régimen de mercado | Excluir esa condición después de verla sin plantear una hipótesis |
| Mucho más slippage del esperado | El modelo de ejecución puede ser demasiado optimista | Cambiar las entradas para esconder el coste |
| Incumplimientos frecuentes de reglas | Puede ser un problema de ejecución del trader | Modificar una estrategia válida para adaptarla a errores operativos |
| Degradación repetida de una métrica | Puede justificar investigación | Buscar parámetros hasta recuperar el backtest original |
Esto conecta directamente con el trabajo de revisión de operaciones que acabas de hacer.
Tu journal y las estadísticas del sistema deberían ayudarte a distinguir entre tres cosas muy diferentes:
- pérdidas previstas por el propio sistema;
- errores de ejecución;
- evidencia de que alguna hipótesis merece ser revisada.
La diferencia importa muchísimo.
Si el sistema decía que debías entrar y la operación perdió, eso no demuestra que la regla esté mal.
Si el sistema decía que no debías entrar y tú entraste, cambiar el sistema para evitar ese resultado sería todavía peor: estarías intentando arreglar en el modelo un error que ocurrió en la ejecución.
Cómo mejorar un sistema de trading sin ajustarlo al pasado
1. Congela la versión que ya tienes
Antes de modificar nada, guarda la versión actual.
Llamémosla Sistema v1.0.
Conserva sus reglas, parámetros y resultados. Esa versión será tu punto de comparación.
Si empiezas a cambiar filtros, stops, horarios y condiciones simultáneamente sin conservar el sistema anterior, después será muy difícil saber qué produjo realmente la diferencia.
Además, existe otro beneficio: puedes volver atrás.
No todo cambio que parece prometedor termina siendo una mejora.
2. Escribe la hipótesis antes de probar la solución
Esta parte me parece especialmente importante.
Imagina que observas que el sistema tiene peores resultados cuando la volatilidad es extremadamente baja.
Una mala forma de trabajar sería empezar a probar:
- ATR de 8, 9, 10, 11, 12…
- distintos horarios;
- varios stops;
- una media móvil;
- otro indicador;
- filtros por día de la semana.
Y continuar hasta encontrar la combinación que produzca el backtest más atractivo.
Una forma mucho más limpia sería escribir primero algo parecido a esto:
Hipótesis: la estrategia necesita un nivel mínimo de movimiento del mercado para que su ventaja potencial supere el ruido y los costes de ejecución.
Ahora ya sabes qué estás intentando comprobar.
Y, sobre todo, puedes descubrir que estabas equivocado.
Eso es bueno.
Una hipótesis que puede ser rechazada es mucho más útil que un proceso en el que sigues buscando hasta encontrar algo que confirme lo que querías ver.
3. Añade los menos grados de libertad posibles
Cada parámetro, filtro o condición adicional le da al sistema otra oportunidad de adaptarse al histórico.
Piensa en algo tan sencillo como cuatro parámetros con cinco valores posibles cada uno.
Tendrías:
5 × 5 × 5 × 5 = 625 combinaciones.
Ahora imagina ocho parámetros con cinco alternativas cada uno:
5⁸ = 390,625 combinaciones.
Esto no significa que tengas 390,625 estrategias completamente independientes. Muchas configuraciones estarán relacionadas entre sí.
Lo importante es entender la magnitud del problema: un sistema aparentemente sencillo puede darte una cantidad enorme de posibilidades entre las que elegir retrospectivamente.
Y si pruebas suficientes posibilidades, encontrar una combinación muy buena deja de ser tan sorprendente.
Por eso, al trabajar la optimización de parámetros de una estrategia, no buscaría simplemente “el mejor número”.
Me preguntaría:
¿Qué función cumple este parámetro dentro de la lógica del sistema?
Si no puedes responder eso y su única justificación es “porque fue el que dio más beneficio en el backtest”, yo tendría cuidado.
Más complejidad no equivale a más conocimiento.
Cada variable nueva debería justificar qué problema resuelve.
4. Busca una zona estable, no el mejor número
Aquí aparece una diferencia muy útil entre un pico y una meseta.
Supongamos, como ejemplo hipotético, que un sistema utiliza un stop expresado como múltiplo del ATR y obtenemos estos dos tipos de comportamiento:
| Stop | Resultado A | Resultado B |
|---|---|---|
| 1.4 ATR | +0.12 R/operación | +0.02 R/operación |
| 1.5 ATR | +0.14 R/operación | +0.04 R/operación |
| 1.6 ATR | +0.15 R/operación | +0.28 R/operación |
| 1.7 ATR | +0.13 R/operación | +0.03 R/operación |
| 1.8 ATR | +0.12 R/operación | -0.01 R/operación |
El resultado A me resulta bastante más interesante.
No porque +0.15 R por operación sea automáticamente suficiente. No estoy proponiendo ningún umbral universal.
Me interesa porque el comportamiento cambia poco cuando movemos ligeramente el parámetro.
En B tenemos algo muy distinto.
Exactamente 1.6 ATR ofrece un resultado espectacular, pero los valores cercanos son muchísimo peores.
¿Podría existir una razón real para que justo 1.6 funcionara mucho mejor?
Sí.
Pero necesitaría evidencia.
No asumiría que hemos descubierto una propiedad secreta del mercado únicamente porque el optimizador encontró un máximo.
Este tipo de preguntas se trabaja con más profundidad en la lección sobre análisis de sensibilidad.
Aquí me basta con que te quedes con la intuición:
prefiero una mejora razonable dentro de una zona estable que una mejora extraordinaria dependiente de un número exacto.
5. No uses los mismos datos para descubrir y confirmar la mejora
Hay una trampa muy fácil de cometer.
Encuentras un problema usando un histórico.
Modificas el sistema viendo ese mismo histórico.
Y después utilizas exactamente los mismos datos para demostrar que la modificación funciona.
Parece que has seguido un proceso de investigación, pero existe un problema: el conjunto con el que estás “validando” también participó en las decisiones.
Es como estudiar un examen teniendo las respuestas delante y después utilizar ese mismo examen para demostrar cuánto aprendiste.
Por eso necesitamos separar los datos utilizados para desarrollar de los datos reservados para comprobar.
Esa lógica ya la trabajamos en In-Sample vs Out-of-Sample.
Pero aquí aparece un matiz especialmente importante cuando estás mejorando un sistema.
Un out-of-sample puede dejar de comportarse como un verdadero periodo no visto si haces esto:
- pruebas la versión v1.1;
- consultas el out-of-sample;
- no te gusta;
- cambias otra regla;
- pruebas v1.2;
- vuelves a mirar el mismo out-of-sample;
- modificas otro parámetro;
- vuelves a probar.
Después de suficientes iteraciones, ese conjunto de datos también está influyendo en tus decisiones.
Puede que nunca hayas optimizado directamente sobre él, pero has empezado a adaptarte a lo que te está diciendo.
Por eso separar muestras es necesario, pero no convierte automáticamente un proceso de optimización en robusto.
6. Intenta romper la mejora
Este cambio de mentalidad me parece buenísimo.
Normalmente alguien modifica una estrategia y pregunta:
“¿Cómo demuestro que ahora es mejor?”
Yo intentaría trabajar al revés:
“¿Qué pruebas razonables puedo hacer para demostrar que esta supuesta mejora era solo una casualidad?”
Por ejemplo:
- mueve ligeramente los parámetros;
- utiliza supuestos de costes menos favorables;
- separa distintos periodos;
- revisa diferentes regímenes de mercado;
- comprueba si la mejora depende de unas pocas operaciones excepcionales;
- analiza qué ocurre cuando la ejecución empeora ligeramente;
- comprueba si quitar una condición hace que todo el resultado desaparezca.
No necesitas que todas las pruebas produzcan exactamente el mismo beneficio.
Eso tampoco sería realista.
Lo que buscas es que la lógica no se desintegre en cuanto dejas de darle al sistema las condiciones exactas con las que fue construido.
Ese es precisamente el terreno de la robustez de un sistema de trading, que ya trabajaste en el módulo anterior.
Si el sistema necesita recalibrar parámetros periódicamente, una capa adicional de validación puede ser el Walk-Forward Analysis.
No voy a rehacer aquí toda esa metodología porque tiene su propia lección. Lo que importa ahora es entender por qué encaja en este proceso: puede ayudarte a comprobar qué ocurre cuando las decisiones de calibración y evaluación avanzan cronológicamente en lugar de depender de un único ajuste retrospectivo.
7. Promueve la nueva versión solo después de verla fuera del laboratorio
Una modificación puede superar el backtest y seguir teniendo problemas prácticos.
Por ejemplo:
- una frecuencia de operaciones distinta de la esperada;
- spreads mayores;
- más slippage;
- órdenes que no se ejecutan como asumía el modelo;
- diferencias entre datos históricos y ejecución;
- dificultades para seguir las reglas en tiempo real.
La ejecución también forma parte del sistema.
Por eso el paso natural antes de tratar la modificación como definitiva es someterla a un forward test.
El objetivo del forward testing no es conseguir unas cuantas operaciones ganadoras para declarar que “ya funciona”.
Es observar qué ocurre cuando el sistema empieza a recibir información que no existía cuando definiste las reglas.
Y hay otra distinción importante: una cuenta demo puede servir para comprobar la mecánica de ejecución y seguir una estrategia sin arriesgar capital, pero eso no significa que replique exactamente todos los efectos de operar con dinero real.
Si quieres utilizar Pepperstone como plataforma para llevar esta fase a la práctica, puedes consultar Pepperstone y la promoción disponible al abrir tu cuenta mediante nuestro enlace.
Yo utilizaría esta etapa para comprobar que las reglas pueden ejecutarse como esperabas. No para asumir que unos cuantos resultados positivos ya validan el sistema.
Un ejemplo: de una buena idea a un sistema sobreoptimizado
Vamos con un escenario completamente hipotético.
Tenemos un sistema con 320 operaciones históricas.
Su expectativa media es de:
+0.16 R por operación.
Durante la revisión encontramos que en periodos de volatilidad muy baja el rendimiento empeora de forma repetida.
Hasta aquí solo tenemos una observación.
No una solución.
Planteamos entonces esta hipótesis:
El setup necesita un nivel mínimo de movimiento para que el desplazamiento potencial compense suficientemente el ruido y los costes.
Ahora aparecen dos caminos.
Camino 1: investigar la hipótesis
Creamos una versión nueva utilizando una condición de volatilidad sencilla.
La regla se define antes de comprobar cómo afecta al resultado final.
En los datos utilizados para desarrollo, la expectativa pasa de:
+0.16 R a +0.23 R por operación.
Bien.
Pero eso todavía no demuestra demasiado.
Probamos entonces ambas versiones en datos que no participaron en la modificación.
Supongamos que obtenemos:
- versión antigua: +0.11 R;
- versión nueva: +0.13 R.
La mejora es muchísimo menor.
¿Es decepcionante?
No necesariamente.
De hecho, un resultado más modesto fuera de muestra puede decirnos bastante más que una mejora espectacular dentro de muestra.
Después movemos ligeramente el umbral de volatilidad.
La estrategia no produce exactamente lo mismo, pero continúa mostrando un comportamiento parecido.
Eso tampoco demuestra que el sistema vaya a producir +0.13 R en el futuro.
No sabemos eso.
Pero la evidencia tiene una estructura más interesante: la mejora no necesita que todo sea exactamente perfecto para seguir existiendo.
Camino 2: perseguir el backtest
Ahora hacemos algo distinto.
Probamos varios ATR.
Después diferentes stops.
Luego horarios.
Después días de la semana.
Añadimos otro indicador.
Probamos diferentes configuraciones.
Seguimos hasta encontrar esta combinación hipotética:
- ATR 14.37;
- stop de 1.73 ATR;
- evitar cierta franja horaria;
- excluir una condición concreta de los martes;
- añadir un segundo filtro.
Conseguimos:
+0.42 R por operación.
Es espectacular.
Hasta que llega la prueba con datos nuevos:
-0.03 R por operación.
Lo importante no es que el primer sistema sea obligatoriamente bueno ni que el segundo sea obligatoriamente malo.
Lo que cambia es la calidad de la evidencia.
En el primer proceso partimos de una hipótesis y preguntamos si sobrevive.
En el segundo partimos de una enorme cantidad de posibilidades y elegimos retrospectivamente la combinación que mejor explica el pasado.
Ese detalle cambia todo.
La modificación también debe sobrevivir a los costes reales
Hay otra forma de “mejorar” un sistema que conviene vigilar: aumentar muchísimo la frecuencia de operación.
Imagina que una modificación hace que el sistema pase de 50 a 180 operaciones al mes.
El beneficio bruto aumenta.
Puede parecer una mejora extraordinaria.
Pero ahora necesitas preguntar:
¿Qué ocurre después de costes?
Con más operaciones también pueden aumentar:
- spread;
- comisiones;
- slippage;
- impacto de ejecución;
- financiación, cuando corresponda.
Una ventaja pequeña puede sobrevivir perfectamente en un backtest que utilice costes demasiado optimistas y desaparecer cuando introduces condiciones más realistas.
Por eso una mejora debería evaluarse después de costes, no únicamente antes.
Si el beneficio desaparece cuando introduces una estimación razonable de la ejecución, yo no intentaría arreglar inmediatamente el problema añadiendo otros cinco parámetros.
El coste era información.
Te estaba diciendo algo sobre la calidad real de la modificación.
Lleva un control de versiones
Hay una práctica sencilla que evita muchísimo caos: tratar cada modificación importante como una versión distinta del sistema.
No necesitas montar una infraestructura complicada.
Necesitas poder reconstruir qué hiciste.
Por ejemplo:
Sistema v1.0
Reglas originales.
Sistema v1.1
Se añade filtro de volatilidad.
Motivo: investigar el deterioro observado durante periodos de muy baja volatilidad.
Sistema v1.2
Se cambia el cálculo del filtro después de comprobar un problema específico.
Y para cada versión conviene conservar al menos:
- la hipótesis que motivó el cambio;
- la regla exacta modificada;
- los datos utilizados para desarrollarla;
- los datos reservados para validación;
- los costes asumidos;
- las métricas antes y después;
- los resultados fuera de muestra;
- lo observado posteriormente en forward testing.
Así puedes responder una pregunta que parece trivial, pero no siempre lo es:
¿Por qué existe esta regla?
Si dentro de seis meses encuentras una condición como:
No operar los miércoles entre las 10:15 y las 11:05.
…y nadie puede explicar de dónde salió salvo diciendo que “mejoraba el backtest”, yo tendría bastantes preguntas.
No necesariamente está mal.
Quizá existe una razón estructural perfectamente válida.
Pero el sistema no debería convertirse en un museo de reglas creadas para esquivar pérdidas históricas concretas.
Una mejora pequeña y estable puede valer más que una mejora espectacular
Este es quizá el punto menos intuitivo de toda la lección.
Imagina dos modificaciones.
Modificación A
Aumenta la expectativa histórica un 12%.
Cuando mueves ligeramente sus parámetros, el comportamiento sigue siendo parecido.
También mantiene parte de la mejora fuera de muestra.
Y sobrevive cuando empeoras moderadamente los supuestos de costes.
Modificación B
Aumenta la expectativa histórica un 80%.
Parece increíble.
Pero necesita una combinación exacta de parámetros.
Si cambias ligeramente uno, la ventaja desaparece.
Fuera de muestra apenas mejora.
Y con costes algo peores deja de ser rentable.
Si solo miras el número máximo del backtest, B parece muchísimo mejor.
Pero ese no es el problema que intentamos resolver.
Estamos intentando construir un sistema con alguna posibilidad de comportarse razonablemente en un futuro que no será idéntico al periodo que utilizamos para diseñarlo.
Yo no buscaría el backtest más impresionante.
Buscaría la explicación más sencilla capaz de producir evidencia suficientemente estable.
Eso no garantiza resultados futuros.
Pero reduce una de las formas más peligrosas de autoengaño en trading sistemático: confundir precisión histórica con capacidad de generalización.
No tengas miedo de rechazar una mejora
Esto también forma parte del proceso.
Puedes dedicar tiempo a una hipótesis perfectamente razonable y descubrir que:
- la mejora desaparece fuera de muestra;
- depende demasiado de un parámetro exacto;
- no compensa los costes;
- aumenta demasiado la complejidad;
- funciona solo en un periodo muy concreto;
- simplemente no aporta suficiente frente al sistema original.
Eso no convierte la investigación en un fracaso.
Has aprendido algo sobre el sistema.
De hecho, conservar una versión sencilla después de rechazar tres modificaciones innecesarias puede ser un resultado mucho mejor que terminar con diez filtros porque cada uno consiguió mejorar alguna métrica del pasado.
Un trader sistemático no debería sentirse obligado a terminar cada investigación con una regla nueva.
A veces la mejor modificación es ninguna.
Cuando pases del test a la ejecución, vuelve a medir
Supongamos que la nueva versión supera las pruebas.
El trabajo todavía no terminó.
Ahora conviene comparar lo que realmente ocurre con lo que suponía tu modelo.
Por ejemplo:
- número real de operaciones;
- precio teórico frente a precio ejecutado;
- spread;
- slippage;
- órdenes no ejecutadas;
- costes;
- horarios;
- diferencias entre señales y ejecución.
Ahí es donde una mejora estadística se enfrenta por primera vez a la mecánica real del trading.
Y hay algo que me parece importante: si los resultados reales se separan del backtest, no empieces modificando inmediatamente la estrategia.
Primero averigua por qué.
Puede que el problema no esté en la señal.
Puede estar en el modelo de costes, los datos, la ejecución o la forma de trasladar las reglas a la plataforma.
Si quieres utilizar Pepperstone para esta parte del proceso, puedes revisar las condiciones actuales de Pepperstone y consultar la promoción disponible desde nuestro enlace.
Recuerda que las promociones y sus condiciones pueden cambiar. Yo comprobaría siempre las condiciones vigentes antes de abrir o financiar una cuenta.
¿Cómo sé que ya estoy sobreoptimizando?
No existe una línea matemática universal que diga:
A partir del parámetro número cinco estás sobreoptimizando.
Sería cómodo, pero no funciona así.
Yo empezaría a preocuparme cuando aparecen varias de estas señales al mismo tiempo:
- cada pérdida genera una regla nueva;
- ya no puedes explicar económicamente o estructuralmente por qué existe un filtro;
- necesitas parámetros extremadamente específicos;
- pequeños cambios destruyen los resultados;
- cada nueva versión mejora mucho dentro de muestra y poco fuera de ella;
- pruebas alternativas hasta conseguir que la métrica vuelva a ser buena;
- decides primero qué resultado quieres y después buscas reglas capaces de producirlo;
- el sistema se vuelve progresivamente más complicado sin una mejora proporcional de la evidencia.
La clave no es contar parámetros mecánicamente.
Es preguntarte cuánto margen le has dado al sistema para aprenderse el ruido del histórico.
¿Optimizar parámetros es malo?
No.
Optimizar y sobreoptimizar no son sinónimos.
Un parámetro puede necesitar calibración porque diferentes valores representan comportamientos genuinamente distintos del sistema.
El problema aparece cuando utilizas el optimizador como una máquina para encontrar retrospectivamente el número que produce el resultado más atractivo y después tratas ese máximo como si fuera evidencia independiente.
Yo buscaría tres cosas:
lógica, estabilidad y validación.
No precisión extrema.
Un parámetro de 18 puede tener sentido.
Un parámetro de 18.3742 también podría tenerlo en algún contexto.
Pero cuanto mayor sea la precisión necesaria para conservar el resultado, mejor debería ser tu explicación de por qué el mercado tendría que respetar precisamente esa frontera.
¿Cada cuánto debería modificar un sistema?
No cambiaría un sistema después de cada mala semana.
Tampoco después de cada operación perdedora.
Pero eso no significa que debas ignorar cualquier degradación hasta que el daño sea enorme.
Yo prefiero un proceso con dos componentes:
revisiones periódicas y condiciones previamente definidas que justifican investigar.
Por ejemplo, puedes decidir de antemano qué desviaciones de ejecución, costes, frecuencia o comportamiento estadístico merecen análisis.
Eso reduce un problema bastante humano: empezar a rediseñar el sistema justo cuando una racha negativa te hace sentir que necesitas hacer algo.
Investigar no obliga a modificar.
Y modificar no obliga a aceptar la nueva versión.
Una forma práctica de decidir si aceptar una modificación
Antes de promover una versión nueva, yo intentaría responder estas preguntas:
- ¿Qué problema específico estoy intentando solucionar?
- ¿La modificación fue planteada antes de ver su resultado final?
- ¿Puedo explicar por qué debería funcionar más allá de “el backtest mejora”?
- ¿Estoy añadiendo la mínima complejidad necesaria?
- ¿El resultado depende de un parámetro exacto o existe una zona razonablemente estable?
- ¿Sobrevive fuera de los datos utilizados para construirla?
- ¿Sobrevive a supuestos de costes algo menos favorables?
- ¿El beneficio depende de unas pocas operaciones excepcionales?
- ¿Puedo ejecutar realmente esa regla?
- ¿La mejora sigue teniendo sentido cuando observo datos nuevos?
No existe una cantidad de “sí” que garantice que la modificación funcionará.
Ese no es el objetivo.
Las preguntas sirven para aumentar la calidad del proceso y hacer más difícil que una mejora aparente entre al sistema únicamente porque quedaba bonita en el histórico.
La regla que me quedaría
No intentes demostrar que tu cambio funciona. Intenta demostrar que no funciona.
Somételo a datos nuevos.
Mueve los parámetros.
Empeora razonablemente los costes.
Revisa distintos periodos.
Comprueba la ejecución.
Busca dónde se rompe.
Si después de todo eso la modificación sigue teniendo sentido, tienes algo mucho más interesante que un backtest bonito.
Tienes una hipótesis que ha sobrevivido a intentos razonables de refutarla.
Eso no elimina la incertidumbre ni garantiza resultados futuros.
Pero es una forma mucho más seria de mejorar un sistema.
Si quieres llevar ese proceso a una plataforma de trading, puedes consultar Pepperstone desde nuestro enlace y revisar las condiciones disponibles para tu cuenta. Primero valida el proceso; el capital viene después.
Y ahora queda una pregunta distinta.
¿Qué ocurre cuando ya no estamos hablando de mejorar una regla, sino de decidir si el sistema completo ha dejado de merecer capital?
Ese es exactamente el siguiente paso del curso: cuándo dejar de utilizar un sistema de trading.
