Errores frecuentes y checklist final en Custom Projects

Errores comunes al construir Custom Projects en StrategyQuant —data leakage, overfitting, mala gestión de memoria— y el checklist antes de operar en real.

Los fallos conceptuales y de configuración más habituales, y la lista de verificación antes de llevar cualquier estrategia a una cuenta real.

Cerramos la serie con los fallos que más veces echan a perder un flujo bien diseñado, y con la lista de verificación que debería pasar cualquier estrategia antes de tocar dinero real. La mayoría de estos errores no son de configuración técnica — son conceptuales, y por eso son los más fáciles de cometer sin darse cuenta.

Tabla de contenidos

Errores conceptuales

Confundir robustez con rendimiento. Una estrategia que pasa todos los filtros de robustez pero tiene un Net Profit modesto puede seguir siendo perfectamente válida. Una con un Net Profit altísimo que falla en Monte Carlo casi con toda seguridad fallará en real. Ante la duda, prioriza siempre la robustez.

Overfitting disfrazado de proceso. Generar miles de estrategias y quedarte con la que tiene el Profit Factor más alto es cherry-picking, no un embudo objetivo. El flujo tiene que funcionar como un filtro con reglas fijas y conocidas de antemano, no como una herramienta de selección subjetiva a posteriori.

Ignorar el True OOS. Los datos de validación final —el tramo de histórico completamente virgen— nunca deben verse durante el desarrollo. Si los consultas, aunque sea "solo para comprobar algo", ya has contaminado el resultado. Ese período se reserva para una única prueba final, definitiva.

Usar el Walk-Forward como sustituto del OOS. El Walk-Forward Optimization trabaja con datos históricos del mismo período general de desarrollo. El True OOS, en cambio, debe ser completamente futuro respecto a ese período — son validaciones distintas y una no sustituye a la otra.

Optimizar después del filtrado. Si vuelves a optimizar los parámetros de las estrategias que ya superaron la Walk-Forward Matrix, estás re-sobreoptimizando precisamente a las supervivientes. La optimización debe ocurrir dentro del flujo, en su tarea correspondiente, no como un ajuste manual posterior.

Errores de configuración

ErrorConsecuenciaSolución
Solapamiento entre In-Sample y Out-of-SampleFuga de datos: resultados OOS inflados y falsosDeja siempre al menos varios meses de buffer entre ambos períodos
Filtros demasiado estrictos en el BuilderEl primer filtro se queda sin ninguna estrategiaRelaja los criterios en el Builder; el filtro real llega en OOS y Monte Carlo
No limpiar los databanksEl sistema se queda sin RAM y el flujo se cuelga a mitad de procesoAñade Clear Databank o Delete Databank tras cada etapa de filtrado
No usar Automatic RetestInconsistencias de configuración entre tareasUsa Automatic Retest para pruebas adicionales sobre la misma configuración base
Muy pocas simulaciones Monte CarloResultados sin significancia estadísticaAl menos 200 simulaciones para el retest de parámetros, 500 para el de trades

IMPORTANTE

El mayor error de fondo en el desarrollo de estrategias algorítmicas es creer que "más filtros" equivale a "mejor estrategia". Los filtros solo sirven para eliminar candidatas frágiles; no pueden convertir una mala estrategia en una buena.

Checklist final antes de operar en real

Una vez que el flujo ha terminado y tienes tus estrategias en el databank final, esta es la lista de verificación antes de desplegar cualquiera de ellas en una cuenta real.

Verificación del proceso:

  • El período In-Sample y el Out-of-Sample no se solapan en ningún punto.
  • El True OOS no se ha usado como referencia en ningún momento del desarrollo.
  • El flujo ha completado al menos una iteración completa sin errores.
  • Los filtros de cada etapa son progresivamente más estrictos, no todos iguales.
  • El número de simulaciones Monte Carlo es estadísticamente suficiente.

Verificación de la estrategia individual:

  • La curva de equity en el período In-Sample tiene una pendiente positiva y consistente.
  • La curva de equity en el período Out-of-Sample se comporta de forma similar a la de In-Sample, sin un colapso evidente.
  • La distribución de operaciones no está concentrada en un puñado de trades excepcionales.
  • El Profit Factor en el percentil 5% de las simulaciones Monte Carlo sigue por encima de 1.0.
  • El mapa 3D de la Walk-Forward Matrix muestra clústeres visibles de parámetros óptimos, no dispersión aleatoria.
  • El drawdown máximo es aceptable para tu propia gestión de capital.

Verificación de la exportación:

  • Se exporta el código a la plataforma de destino (MQL4, MQL5 u otra).
  • El EA exportado se ejecuta en un backtest manual en la plataforma final y replica los resultados obtenidos en StrategyQuant.
  • Se prueba en cuenta demo durante al menos 4-8 semanas antes de pasar a cuenta real.
  • Se monitoriza el comportamiento en demo frente a la expectativa estadística del modelo.
  • Se establecen reglas de desconexión previas: por ejemplo, pausar la estrategia si el drawdown en demo supera un porcentaje determinado del esperado.

Recursos de referencia

Para seguir profundizando más allá de esta serie: la documentación oficial en strategyquant.com/doc, el canal de YouTube oficial de StrategyQuant, el foro de la comunidad en strategyquant.com/forum, el codebase de snippets personalizados en strategyquant.com/codebase, y los flujos de trabajo compartidos por la comunidad en la categoría correspondiente del sitio oficial.

Preguntas frecuentes (FAQs)

¿Cuánto tiempo hay que operar una estrategia en demo antes de pasar a real?

Como referencia orientativa, entre 4 y 8 semanas, comparando en todo momento el comportamiento real frente a lo que el modelo predice estadísticamente. Si el drawdown en demo supera con claridad al esperado según el backtest, es una señal de alarma antes de arriesgar capital real.

¿Es un error usar el mismo período para optimizar y para hacer Walk-Forward?

El Walk-Forward Optimization está pensado precisamente para trabajar con múltiples ventanas dentro del período de desarrollo general. El error no es usarlo ahí, sino tratarlo como si fuera equivalente a una prueba Out-of-Sample verdadera con datos completamente futuros — son validaciones distintas, no intercambiables.

Si una estrategia falla el checklist en un solo punto, ¿hay que descartarla directamente?

Depende de cuál. Un drawdown ligeramente por encima de tu tolerancia personal puede resolverse ajustando el tamaño de posición; una curva de equity en Out-of-Sample que colapsa frente a la de In-Sample, en cambio, es una señal de fondo sobre la propia estrategia que normalmente no se arregla ajustando parámetros externos.

¿Merece la pena repetir todo el flujo si cambio un solo filtro?

No hace falta reconstruir desde cero: gracias a Automatic Retest y a la posibilidad de ejecutar una sola tarea del flujo (Run this task only), normalmente basta con relanzar la tarea afectada y las que dependen de ella, reutilizando los databanks de las etapas anteriores que no han cambiado.

Sigue leyendo el contenido de esta serie

Esto cierra la serie. Si quieres repasar el punto de partida, vuelve al primer artículo con la visión general de qué son los Custom Projects y por qué merece la pena dominarlos.

WikiSQX - Custom Projects > Errores frecuentes y checklist final

Buscar en la wikiSQX:

Seguir a Quantified Models:

Base de conocimiento:

Índice de esta entrada: