De la idea de trading al sistema de reglas

Tienes una idea: compra cuando el RSI caiga con fuerza. Eso suena a una regla terminada, pero es solo el comienzo. Una estrategia de trading necesita, además de la condición de entrada, reglas de salida y reglas para la gestión de la operación, y precisamente esas faltan por completo en una idea pura como esta. Si las construyes de todos modos, el resultado en la prueba suele comportarse de forma distinta a lo que esperabas, simplemente porque una gran parte del conjunto de reglas necesario todavía no estaba definida.

Este artículo te muestra el camino desde la idea de trading hasta el conjunto de reglas completo: de qué consta, qué proceso documentado existe para ello y por qué una búsqueda de parámetros más amplia por sí sola no da como resultado una mejor estrategia. Al final sabrás qué preguntas deberías hacerle a tu propia idea antes de mandarla a construir.

Idea de trading y conjunto de reglas: por qué una regla de RSI no basta

Una estrategia de trading es, en esencia, un conjunto de reglas de si-entonces: si se cumplen determinadas condiciones, el software ejecuta determinadas acciones. Esto vale para casi cualquier estilo de estrategia, por ejemplo seguimiento de tendencia, reversión a la media o algo completamente distinto. Los estilos se diferencian sobre todo en cómo están construidas las reglas, no en que sean o no reglas de si-entonces.

Un conjunto de reglas completo consta de tres tipos de componentes: órdenes de entrada, que abren una posición, órdenes de salida, que la cierran, y comandos para la gestión de la operación, por ejemplo el arrastre de un trailing stop. Tu idea del RSI solo aporta el primer componente, la condición de entrada. Sin reglas de salida y sin reglas de gestión de la operación sigue siendo un fragmento, muy lejos de un conjunto de reglas completo.

El camino documentado del borrador inicial a la estrategia terminada

En la documentación del producto hay un flujo estándar descrito para convertir una idea en una estrategia: importas o cargas datos de prueba, configuras en el builder cosas como el tipo de estrategia, los indicadores, los tipos de orden y los criterios de ranking, dejas que el build se ejecute y evalúas después las estrategias que surgieron, las retesteas o las optimizas más. Ese es un camino descrito, no una obligación. No tienes que seguirlo paso a paso exactamente así.

En una versión documentada anterior, esto funcionaba algo distinto. Ahí primero se configuraban los datos de prueba con una división en In Sample y Out of Sample para la evolución genética, después se definían el tipo de estrategia, los indicadores y los tipos de orden, y solo al final se configuraban las opciones de ranking para filtrar las estrategias con una ganancia demasiado baja. Esta descripción vale para una versión más antigua del producto, las versiones posteriores pueden ordenarlo de otra manera. Así que no tomes una sola ruta de menú como fija para siempre. Pero la idea de fondo sigue igual: primero definir los datos y los componentes, después construir, después revisar.

Una idea se convierte en plantilla: el camino a través del AlgoWizard

Un camino documentado y concreto para convertir una idea simple en una estructura construible pasa por el AlgoWizard. Ahí creas una Strategy nueva, la pones en modo plantilla y construyes la condición a partir de una referencia de precio elegida contra un indicador, por ejemplo una media móvil con un rango de parámetros definido. Así tu idea de RSI se convierte en una estructura con la que el software realmente puede trabajar.

Un punto que deberías conocer: mientras la Strategy está en modo plantilla, según la documentación no puedes hacerle backtest. El modo solo sirve para construir la estructura. Solo puedes comprobarla cuando lo abandonas.

Bloques que el software combina por ti

No todos los bloques de tu conjunto de reglas tienen que estar fijados a mano. La documentación describe las llamadas Random Groups: ajustes para la construcción de estrategias que se toman de un archivo de configuración y que permiten al software elegir al azar qué bloques de un grupo se usan realmente, en lugar de que tú prescribas cada bloque individual.

Eso es práctico cuando quieres permitir varias variantes razonables de una regla sin configurar cada una a mano. Cómo afecta exactamente esto a una estrategia concreta depende de cómo configures los grupos. Los Random Groups te quitan la selección de los bloques. El control después sigue siendo tuyo: revisa qué bloques acabaron realmente en una estrategia construida.

Por qué más parámetros no significan automáticamente más calidad

Una conclusión errónea con la que nos encontramos una y otra vez en nuestras pruebas: más parámetros, más grados de libertad, más combinaciones posibles, eso debería llevar a mejores estrategias. Las estrategias reales suelen tener bastantes más parámetros que un ejemplo simple, y el número de combinaciones de parámetros posibles va desde unos pocos miles hasta miles de millones o billones. Probar cada una de ellas es sencillamente inviable, sin importar cuánto tiempo de cómputo tengas disponible.

Muchos parámetros no son malos en principio. Pero el espacio de búsqueda que le abres al Builder debería ser una decisión consciente, no una que simplemente crece porque hay bloques adicionales disponibles.

Cuando el backtest se ve bien pero no dice nada sobre el futuro

Un error de razonamiento muy extendido es suponer que una búsqueda grande cubre de todos modos todo lo relevante. Si dejas que una búsqueda de estrategias admita demasiadas combinaciones de parámetros, StrategyQuant X puede devolver una estrategia cuyo backtest se ve bien, pero que en el trading real puede comportarse de otra manera. Este patrón está documentado como sesgo de minería de datos: si el espacio de búsqueda se vuelve demasiado grande en relación con los datos disponibles y las condiciones de prueba, crece el peligro de que el software encuentre patrones aleatorios en los datos históricos en lugar de una regla que represente algo que se repite.

Esto nos lleva al punto más importante de todo este proceso. Un backtest y la cantidad de combinaciones de parámetros revisadas solo describen cómo se comportó un conjunto de reglas sobre datos pasados o qué tan grande era un espacio de búsqueda. Ninguna de las dos cosas dice nada sobre cómo se comportará la estrategia con datos de mercado futuros que todavía no has visto. Lo que se veía bien en el pasado sigue siendo una observación del pasado, nada más.

Qué deberías revisar en tu propia idea

Tres preguntas valen la pena antes de dejar que se construya tu siguiente idea, aunque este artículo no las responde por ti:

• ¿Qué valores predeterminados llena realmente el software cuando dejas abierto un campo de exit o de gestión de operaciones? Míralo con detalle en tu propia compilación, en lugar de suponerlo.
• ¿A partir de qué umbral te advierte el programa que una estrategia tiene demasiado pocas operaciones o que parece poco adecuada para el trading real? Vale la pena prestar atención a esas advertencias en lugar de hacer clic para cerrarlas.
• ¿Qué tan cerca se mantiene una generación de estrategias asistida por IA o basada en chat de lo que realmente introdujiste? Compara el resultado línea por línea con tu idea original.

Estas preguntas forman parte de tu propia revisión. Nadie te las quita, y este artículo tampoco inventa respuestas para ellas.

Construir un conjunto de reglas significa conocer cada una de las decisiones que, de otro modo, se toman en silencio por ti: entrada, salida, gestión de operaciones y el alcance de tu búsqueda de parámetros. Un backtest te muestra cómo se comportaron esas decisiones en el pasado. No te muestra qué pasará después.

Este artículo tiene fines educativos y no es asesoramiento de inversión. Los resultados pasados, incluidos los de backtests, no garantizan resultados futuros. Operar con instrumentos financieros conlleva riesgos y puedes perder dinero.