Protocolo de cambios de un sistema de trading: cómo modificarlo sin contaminar la validación
Un sistema vivo necesita ajustes; un sistema creíble necesita que esos ajustes sean rastreables. Sin un protocolo mínimo, cada retoque diluye la evidencia reunida durante el proceso de validación y deja al operador sin base para decidir si el último resultado pertenece realmente al sistema… o a su última ocurrencia.
1. Por qué un cambio sin protocolo resta valor
Cuando se altera una regla significativa —entrada, salida, filtro o tamaño— se crea, de facto, otra versión. Si los resultados antiguos se mezclan con los nuevos:
- La identidad del sistema se vuelve ambigua: no sabes qué lógica produce qué curva.
- La comparabilidad desaparece: mejoras y retrocesos se atribuyen a la versión equivocada.
- La decisión operativa queda sin fundamento: avanza quien grita más, no quien demuestra más.
Es el mismo problema de autoengaño descrito en sesgos de backtesting, pero trasladado al ciclo de mejora.
2. Cuándo debe abrirse una nueva versión
2.1 Criterio práctico
Versiona siempre que el cambio afecte a la frecuencia de señales, al perfil de riesgo o al modo de gestionar posiciones. Si el backtest variaría de forma apreciable, no es un ajuste “cosmético”.
2.2 Ejemplos típicos que exigen versión
- Sustituir un cierre fijo por un objetivo dinámico.
- Agregar un filtro de tendencia que descarta parte del universo operativo.
- Modificar la lógica de tamaño: de riesgo fijo a riesgo porcentual.
Unas comillas aclaratorias en la documentación son refinamiento —y deberían registrarse—, pero no crean versión si no cambian el resultado esperado.
3. El protocolo, pieza a pieza
La plantilla puede ser tan sencilla como una hoja de cálculo o la sección “Cambios” en tu diario de trading, siempre que incluya:
- Identificador de versión — v2, v2.1… breve y secuencial.
- Regla afectada — texto anterior → texto nuevo (copia-pega, sin interpretaciones).
- Motivo operativo — hipótesis que explica la modificación (p.ej. reducir ambigüedad en salidas).
- Fecha de activación — día y momento a partir del cual toda prueba usa la versión nueva.
- Ámbito fijo de comparación — periodo, mercado y métricas que se mantendrán constantes para medir el efecto.
- Evidencia separada — backtests y forward/resultados reales etiquetados con la versión; nada se fusiona hasta que una decisión lo apruebe.
Con ese estándar, cualquier lector puede reconstruir qué cambió, cuándo y con qué consecuencia, igual que ocurre al documentar el sistema base.
4. Mantener comparabilidad sin frenar la mejora
4.1 Un cambio cada vez
Probar varias modificaciones simultáneas impide atribuir efectos. Pon las propuestas en cola y avanza de forma incremental.
4.2 Evidencia antigua ≠ prueba de la versión nueva
Re-backtestear toda la historia con la regla nueva convierte el pasado en presente y destruye el contraste. La comparación debe basarse en:
- Backtest actualizado de la versión nueva (etiquetado).
- Backtest histórico de la versión previa (conservado).
- Misma ventana y mismos activos para ambos.
4.3 Medir antes de fusionar
Solo cuando la versión modificada acumule evidencia —histórica y, preferiblemente, un bloque de forward— se aplica el filtro de criterios de validación para decidir si sustituye o se descarta. Mientras tanto: convivencia ordenada, no mezcla.
5. Errores costosos y cómo evitarlos
- Reacción a rachas cortas — Pausa y revisa; no rediseñes sobre dos malas semanas.
- Curva Frankenstein — Suma de resultados de varias versiones sin etiquetas.
- Justificación estadística débil — “Mejora el profit factor” sin aislar qué parte del cambio lo provoca.
- Registro incompleto — No poder explicar un año después por qué la v3 empezó tal día.
6. Encaje del protocolo en el flujo global
El protocolo conecta fases, no las reemplaza:
- Antes — Sistema base claro (ver backtesting manual y métricas).
- Durante — Cada versión genera su propia evidencia.
- Después — La decisión de avanzar, pausar o descartar se toma con el mismo estándar que ordena el paso a real.
Así, la evolución del sistema suma claridad en lugar de añadir ruido y evita que los sesgos —o la prisa— sustituyan al criterio.
FAQs
¿Cuándo debo crear una nueva versión?
Cuando la modificación cambia la lógica de entrada, salida, filtros o gestión de riesgo de forma que el backtest se alteraría de manera significativa.
¿Puedo reaprovechar el histórico de la versión anterior?
Sólo como referencia. No debe sumarse al rendimiento de la versión nueva: la comparación se hace en paralelo, bajo idénticas condiciones.
¿Y si el cambio solo aclara una ambigüedad?
Regístralo, pero no es necesario crear versión si las señales y métricas no varían. Aun así, deja constancia para futuras auditorías.
¿Cuánta evidencia necesita una versión para ser evaluada?
Al menos: backtest completo con la misma muestra y un bloque definido de forward o ejecución real en tamaño reducido. Sin esa base, la comparación es prematura.
En TNT Bolsa trabajamos para que cada ajuste sume evidencia y no confusión. Un protocolo de cambios sencillo protege tu sistema y tu criterio operativo.
