Validar tu proceso
Tienes una página con tu versión 1.0. Ahora toca averiguar si sirve, y averiguarlo de una forma que no te engañe. Esta lección junta lo que los módulos 12 y 14 enseñaron por separado y lo aplica a tu proceso: qué demuestra el backtest, qué añade el forward, cuándo la muestra empieza a decir algo y qué preguntas hay que hacerle al journal.
- Qué pregunta responde cada fase de validación y en qué orden se hacen
- Por qué se validan el sistema y el operador por separado, y con qué métrica cada uno
- Cómo saber si tu muestra es suficiente para decidir algo, y qué hacer mientras no lo es
- Qué cambios en el proceso están justificados por los datos y cuáles son ruido
Qué significa validar
Validar no es demostrar que el proceso gana. Es reunir evidencia suficiente para tomar una decisión razonable: seguir igual, cambiar algo concreto o descartarlo. Un proceso puede ser bueno y tener un mes malo; puede ser malo y tener un mes bueno. La validación existe para que no decidas por el último mes.
En este curso, validar un proceso es recorrer una escalera de pruebas — backtest, forward test, primera fase en real — en la que cada peldaño responde a una pregunta distinta y en la que la decisión de subir, repetir o bajar se toma según criterios escritos antes de empezar el peldaño.
Hay dos cosas que se validan y que conviene separar desde el principio, porque se miden distinto:
- El sistema: ¿tiene esperanza positiva el setup, ejecutado según las reglas, en el mercado y la ventana que elegiste? Se mide en R: Win rate, R medio de ganadores y perdedores, Esperanza matemática, Drawdown máximo en R.
- El operador: ¿ejecutas el proceso tal como está escrito? Se mide en adherencia: el porcentaje de operaciones (y de no operaciones) en las que se cumplieron todas las reglas.
La mayoría de los procesos que se abandonan en los primeros meses no se abandonan porque el sistema fuera malo. Se abandonan porque nadie midió la adherencia, la ejecución fue irregular, los resultados fueron ruido y el operador concluyó que 'el setup no funciona'. Sin adherencia medida, ningún resultado dice nada del sistema.
Un resultado sin adherencia conocida es una anécdota. Con adherencia conocida es un dato.
Peldaño uno: backtest
El Backtesting responde a una sola pregunta: ¿tiene el setup, con estas reglas cerradas, esperanza positiva en el pasado reciente de este mercado? No responde nada sobre ti, y no responde si el futuro se parecerá al pasado. El módulo 12 explicó cómo hacerlo con replay y hoja de registro; aquí se aplica a tu versión 1.0.
Tres condiciones para que el backtest de tu proceso valga algo:
- Reglas cerradas antes de empezar. Las cinco líneas del setup y las reglas de riesgo tal como están en la versión 1.0. Si a mitad del backtest descubres que 'con un filtro más iría mejor', anótalo y termina el backtest con las reglas originales. Cambiarlas sobre la marcha es Overfitting con otro nombre.
- Regímenes distintos. Que la muestra incluya semanas de tendencia, semanas de rango, semanas de alta y de baja Volatilidad. Un setup de continuación probado solo en un trimestre alcista fuerte parecerá excelente y morirá en el primer mes lateral.
- Registro completo, incluidas las operaciones que el proceso habría rechazado y por qué. El no trade también se valida: si tu regla 'sin sesgo claro en 1H, no opero' hubiera evitado quince pérdidas y tres ganancias, tienes un dato a favor de la regla.
En FUNESMA79 el backtest de una versión del proceso se da por terminado cuando cubre al menos tres meses de gráfico con los regímenes anteriores presentes, y se acepta para pasar a forward si la esperanza en R es positiva y el drawdown máximo en R es soportable con el riesgo por operación fijado. Son criterios de este sistema, no umbrales universales: los tuyos deben estar escritos antes de abrir el replay.
Peldaño dos: forward test
El Forward test responde a dos preguntas que el backtest no puede: ¿ejecutas el proceso en tiempo real, con la incertidumbre de no saber qué vela viene después? Y ¿se parecen los resultados en vivo a los del backtest? Es el primer peldaño en el que se mide al operador, y por eso es el que más información nueva aporta.
Se diseña como un bloque: duración fijada de antemano en semanas o en operaciones, reglas idénticas a las del backtest, journal completo con los campos del módulo 12 más los de adherencia. Al terminar el bloque, y no antes, se comparan tres cosas:
- Adherencia. Si está por debajo del umbral que fijaste (el módulo 14 sugería que menos de nueve de cada diez es señal de que el problema no es el sistema), el siguiente paso no es real: es otro bloque de forward centrado en las reglas que se rompen.
- Distribución de resultados. Win rate y R medio del forward frente a los del backtest. No tienen que ser iguales — el forward suele ser peor porque incluye dudas y entradas tardías — pero deben ser reconocibles. Si el backtest daba un R medio de ganadores de 1,8 y el forward da 0,7, algo distinto está ocurriendo y hay que saber qué antes de seguir.
- Racha de pérdidas. Si el bloque no incluyó una racha del tamaño que tu win rate hace normal (el módulo 10 lo explica), no sabes cómo ejecutas en ella, y el forward no ha terminado por mucho que la curva sea bonita.
Muestra suficiente
La pregunta '¿cuántas operaciones necesito?' no tiene un número, y quien te dé uno está simplificando. El Sample size necesario depende del win rate del setup y de la dispersión de sus resultados: un setup con win rate cercano al 50% y R:R estable necesita menos operaciones para estimar su esperanza que uno con win rate del 30% y ganadores muy dispersos, porque en el segundo cada ganador pesa mucho y una muestra corta puede no contener ninguno o contener tres.
Lo que sí puedes hacer, sin estadística avanzada, es reconocer cuándo la muestra todavía no es suficiente:
- Si quitar las dos mejores operaciones cambia el signo de la esperanza, la muestra no basta.
- Si la muestra no contiene al menos una racha de pérdidas del tamaño que el módulo 10 dice que es normal para tu win rate, la muestra no basta.
- Si todas las operaciones son del mismo régimen de mercado, la muestra no basta aunque sean muchas.
- Si el win rate cambia más de diez puntos al añadir las últimas diez operaciones, la muestra no basta.
Mientras la muestra no basta, la regla es simple y difícil: no se cambia el proceso. Se sigue ejecutando la misma versión y se anotan las ideas de mejora en una lista aparte. Cambiar el proceso con veinte operaciones porque 'está claro que el filtro X ayudaría' es la forma más común de no tener nunca una muestra de nada.
Existen métodos cuantitativos para estimar el tamaño de muestra necesario y el intervalo de confianza de una esperanza — se usan en investigación cuantitativa y en la validación de sistemas algorítmicos. Son útiles, pero para un operador discrecional que empieza suelen dar una falsa sensación de precisión: la adherencia irregular introduce más ruido que el que esos métodos asumen. Antes de refinar la estadística, estabiliza la ejecución.
Un operador lleva 35 operaciones en forward con su setup de continuación: win rate 46%, R medio de ganadores 1,6, esperanza +0,20R por operación. Quita las dos mejores (+3,1R y +2,8R) y la esperanza pasa a +0,03R. Conclusión correcta: el sistema puede tener esperanza positiva, pero todavía no lo sabe. Sigue con la misma versión hasta completar el bloque. Conclusión incorrecta: 'funciona, paso a real con tres contratos'.
Qué te dice el journal (y qué cambiar)
El Journal es donde se separan las tres fuentes de pérdida, y esa separación decide qué se cambia. Al revisar un bloque completo, cada operación perdedora se clasifica en una de tres:
- Pérdida del sistema: setup válido, todas las reglas cumplidas, el mercado fue a otro sitio. Es el coste normal de operar. No se cambia nada por una pérdida así ni por diez seguidas, salvo que el conjunto del bloque diga que la esperanza es negativa.
- Pérdida del operador: una regla rota — entrada anticipada, stop movido, tamaño incorrecto, tercera operación cuando el máximo eran dos. No dice nada del sistema. Lo que se cambia, si se cambia algo, es un protocolo, y el módulo 13 trata cómo.
- Pérdida de diseño: todas las reglas cumplidas, pero la regla en sí produjo una operación que, vista en el gráfico, no tenía sentido — por ejemplo, un stop máximo en puntos que obliga a colocar la invalidación dentro de la zona en vez de detrás. Es la única categoría que justifica cambiar el proceso, y solo cuando se repite.
Con esa clasificación, los cambios de versión se justifican solos. Si el 70% de las pérdidas son del operador, la versión 1.1 no toca el setup: toca los protocolos. Si hay un patrón de pérdidas de diseño, la versión 1.1 cambia esa regla y solo esa, y vuelve al backtest para comprobarla. Si casi todas son del sistema y la esperanza del bloque es negativa con adherencia alta, el setup se descarta con la conciencia tranquila: ha sido medido.
Un cambio por versión. Si cambias el filtro de contexto, el tipo de entrada y el stop máximo a la vez y el siguiente bloque mejora, no sabes cuál de los tres lo hizo, y si empeora, tampoco. La validación es lenta por diseño; intentar acelerarla es la forma más rápida de no terminarla nunca.
En FUNESMA79 la revisión que decide cambios de versión es la semanal con el journal completo, nunca la de fin de sesión. Al final de la sesión se anota; al final de la semana se clasifica; al final del bloque se decide.
Ejemplo: un bloque de forward revisado
Una operadora termina su primer bloque de forward: seis semanas, 28 operaciones con su setup de continuación tras sweep en MNQ. Resultado neto -1,4R. Su primera reacción es que el setup no funciona. Antes de decidir nada, clasifica.
Adherencia: 24 de 28 operaciones con todas las reglas cumplidas, 86%. De las 15 perdedoras, 9 son del sistema (setup válido, mercado en contra), 4 del operador (dos entradas antes del cierre de confirmación, una tercera operación del día, un stop movido tres puntos) y 2 de diseño (el stop máximo de 30 puntos la obligó a colocar la invalidación dentro del rango barrido en lugar de bajo su mínimo, y ambas fueron barridas por dos puntos antes de que el precio hiciera lo esperado).
Las 4 operaciones del operador suman -4R. Sin ellas, el bloque es +2,6R con una adherencia del 100%. Decisión: no toca el setup. La versión 1.1 añade un protocolo — la orden de entrada se coloca solo tras el cierre de la vela de confirmación, con una alarma en lugar de vigilancia continua — y anota la regla del stop máximo como candidata a revisar en el siguiente bloque, porque dos casos no son un patrón. Repite el forward con la 1.1. Todavía no sabe si el sistema tiene esperanza positiva. Sabe algo mejor: qué está midiendo y qué no.
Error frecuente
Validar el resultado en vez de validar el proceso. Se mira la curva en R al final de cada semana, se cambia algo cuando baja y se sube de tamaño cuando sube. El proceso muta cada pocos días, la muestra de cada versión nunca supera las diez operaciones, y al cabo de seis meses el operador ha probado quince variantes y no sabe nada de ninguna.
La alternativa es aburrida: una versión, un bloque completo, una clasificación de pérdidas, un cambio. Y repetir. La validación no premia la creatividad; premia la paciencia de ejecutar la misma cosa hasta que los datos digan algo.
Antes de cambiar el proceso
- El bloque actual ha terminado con la duración fijada de antemano
- La adherencia está medida y por encima de mi umbral
- Cada pérdida está clasificada: sistema, operador o diseño
- La muestra pasa las cuatro comprobaciones de suficiencia (mejores operaciones, racha, regímenes, estabilidad del win rate)
- El cambio propuesto responde a un patrón repetido de pérdidas de diseño, no a una operación
- Es un solo cambio, tiene número de versión y fecha, y vuelve a backtest si toca el setup
- La decisión se toma en la revisión semanal, no al cerrar la sesión
Ejercicio
Escribe el protocolo de validación de tu versión 1.0 antes de empezar a probarla: duración del backtest y regímenes que debe cubrir; criterio en R y en drawdown para pasar a forward; duración del bloque de forward; umbral de adherencia; qué comparas entre backtest y forward y qué diferencia consideras aceptable. Una página, con fecha, firmada.
Después coge tus últimas veinte operaciones registradas, en demo o replay, y clasifica cada pérdida como sistema, operador o diseño. Suma el R de cada categoría. Si la del operador es la mayor, tu siguiente versión toca protocolos, no setup. Si no puedes clasificar porque el journal no tiene los datos necesarios, ese es el primer cambio: el journal, antes que cualquier regla.
Qué debes recordar
- Validar es reunir evidencia para decidir con criterios escritos antes, no demostrar que el proceso gana.
- Sistema y operador se miden por separado: esperanza en R y adherencia. Sin adherencia conocida, el resultado es una anécdota.
- Backtest: reglas cerradas, regímenes distintos, registro completo. Forward: bloque de duración fijada; compara adherencia, distribución y racha con el backtest.
- Mientras la muestra no basta — mejores operaciones, racha, regímenes, estabilidad — no se cambia el proceso; las ideas van a una lista aparte.
- El journal separa pérdidas de sistema, de operador y de diseño; solo las de diseño repetidas justifican cambiar reglas, y un cambio por versión.