Imagine que puede crear automáticamente cientos de estrategias con el código perfectamente ensamblado para su plataforma de trading favorita. Imagine que puede evaluarlas y obtener en unas horas la lista de las más viables en un conjunto de mercados. Suena casi a Ciencia ficción, ¿verdad? Bien, pues aunque resulte inverosimil, esto es lo que prometen las revolucionarias propuestas que veremos en este artículo.

El proceso tradicional para construir, evaluar y mantener un portfolio de sistemas es lento y tedioso.  A menudo pueden pasar meses, incluso años, desde que surge una idea de base en nuestra "mesa de diseño" hasta que finalmente tenemos un conjunto de estrategias robustas  integradas en una cartera.  Por otra parte -y como ya hemos comentado en otros artículos- cada estrategia tiene una vida media específica; tarde o temprano dejará de funcionar: Unas veces lo hará de manera abrupta (por ejemplo en el tránsito entre marcoépocas) y otras, las más, en un lento deterioro que se hará palpable al observar su evolución en meses sucesivos.

 Sea como sea, el gestor de carteras sistemáticas deberá afrontar un ciclo de eliminación y reposición de sistemas. El problema surge cuando, debido al creciente tamaño y complejidad de la cartera y otros muchos factores, el ritmo de creación de estrategias nuevas resulta claramente para nuestras necesidades. En tales circunstancias cualquier alternativa que suponga una reducción drástica del tiempo de desarrollo siempre es bienvenida.

 En este contexto la reciente aparición de generadores automatizados de sistemas representa una solución, al menos sobre el papel, bastante apetecible. Un generador de sistemas para ser plenamente funcional tiene que cumplir las siguientes características:

a) Generalidad:  Capacidad de construir sistemas con independencia  del set de datos de entrada (por ejemplo, mercado y time frame elegidos).

b) Diversidad: De nada nos servirá un generador poco flexible y que sea incapaz de producir un repertorio de reglas o patrones de código potencialmente infinito.

c) Contrastabilidad: El programa debe ser capaz de validar y probar automáticamente los sistemas que va generando en el conjunto de datos de entrada.

d) Adaptabilidad: El repertorio de "sistemas candidato" ofrecidos como output deberá satisfacer una serie de condiciones fijadas por el operador al inicio del proceso. Es decir, la respuesta deberá adaptarse al tipo de sistema que buscamos en cada momento: intradiarios o continuos, sólo para largos o para cortos, lógica tendencial, antitendencial, etc.

e) Criterios diana: El proceso de construcción debe estar dirigido por unos indicadores de calidad que produzcan la convergencia de "sistemas candidato" hacia una solución óptima: Maximizar el beneficio medio, obtener un determinado  porcentaje de operaciones ganadoras, etc. Esto funciona de manera análoga a la obtención de parámetros óptimos en un backtest.    

f) Operatividad: El resultado deben ser sistemas plenamente funcionales. El usuario no tendrá que programar nada en absoluto; pues los indicadores necesarios, las reglas de entrada y cierre de posiciones, los filtros (incluso en algún dispositivo avanzado los modelos de gestión monetaria) serán ensamblados en el lenguaje de una  plataforma de trading o como meta-código que se procesa en una aplicación independiente y utiliza la plataforma como pasarela para interactuar con el broker y recibir el tiempo real. 

La generación automatizada de sistemas puede seguir estas tres metodologías:

•    Construcción de modelos predictivos basados en redes neuronales, en combinación con sistemas de inferencias que utilizan distintas arquitecturas lógicas, incluso lógica difusa.  Este tipo de tecnología, profusamente empleada desde hace más dos décadas, dio lugar a plataformas pioneras como BrainMaker (con versiones hasta para MS DOS) o NeoroStock y otras aún en uso como Neuroshell Trader. El problema de estas plataformas es que generan sistemas tipo "black-box", por lo que el operador no tiene acceso a la lógica subyacente ni a las reglas exactas del posicionamiento. Ha de contentarse con fijar ciertos parámetros que modulan la arquitectura de la red y el tipo de sistemas que se obtienen.

•    Desarrollo de técnicas basadas en la minería de datos. Lo que se persigue es la búsqueda de patrones recurrentes en las formaciones de precios y otras series de datos asociadas a  los mercados que permitan realizar inferencias estadísticas sobre su potencial predictivo  y, en última instancia, su implementación estructurada en forma de reglas con las que construir sistemas de trading.  Una aplicación que podemos situar en esta categoría es Price Action Lab, de Michael Harris. Autor también de varios libros sobre de técnicas de reconocimiento de patrones aplicadas al trading:  Short-Term Trading with Price Patterns (1999) y Profitability and Systematic Trading (2008).

•   La tercera aproximación recurre también a una tecnología muy consolidada en el ámbito científico; la programación genética y los algoritmos evolutivos. El Genetic Programming (GP) hunde sus raíces en los experimentos de generación automática de software empleando lenguajes de programación como el LISP, muy común en los 80 y 90 en el ámbito de la Inteligencia Artificial.  De este modo, cuando aplicamos esta tecnología al trading lo que obtenemos es el código de un sistema o conjunto de sistemas que posteriormente podremos implementar en una plataforma de trading.  En mi opinión el GP es la más interesante de las tres metodologías. Ahora ya no estamos ante una caja negra, sino que disponemos de un código cuyas reglas están a la vista y son susceptibles de ser mejoradas. 

Posiblemente la aplicación más veterana y completa para construir sistemas con esta metodología es el Trading System Lab , de Michael l. Barna. Un software capaz de crear una enorme variedad de sistemas mediante avanzadas técnicas de programación genética. Pero lo mejor es que tras construir y evaluar centenares de sistemas posibles, TSL puede generar código plenamente funcional para EasyLanguage, Java, C# y WealthLab Script Language.  Otros desarrollos posteriores, también multiplataforma y económicamente más asequibles, son Adaptrade Builder y  Strategy Quant.

GENERACIÓN AUTOMÁTICA DE SISTEMAS: VENTAJAS Y DESVENTAJAS.

El beneficio potencial de la creación automatizada de estrategias es considerable. Para empezar, ya no se requiere una larga experiencia en los mercados, ni dominar el lenguaje específico de cada plataforma. La máquina no necesita "ideas brillantes" basadas en nuestra experiencia como traders, solo unas indicaciones generales sobre el tipo de sistema a construir y los objetivos a los que queremos llegar.

 La producción automatizada contribuye a agilizar el ciclo de producción de sistemas. Y no se trata solo de obtener estrategias de forma más rápida y eficiente, sino de aumentar su diversidad. Los desarrolladores normalmente estamos condicionados por un pequeño repertorio de ideas y modelos de mercado. A veces incluso nos especializamos en un determinado tipo de cartera o estilo inversor. Pero tales ideas, aunque hayan sido ganadoras en largos períodos, se pueden convertir en un lastre al  limitar la inmensa variedad de enfoques y aproximaciones que conducen a estrategias igualmente viables y rentables.  

 Pero la flexibilidad de diseño  también tiene un precio; puede resultar difícil entender y explicar el funcionamiento de estas estrategias. Los desarrolladores nos sentimos más cómodos cuando el sistema se asienta en una determinada hipótesis o modelo de mercado. Por ejemplo, construimos sistemas tipo VBO (Volatiliy Breakout) y ORB (Opening Range Breakout) bajo la premisa de que el proceso de expansión-contracción de rango responde al movimiento natural de los mercados y eso nos ofrece mayor seguridad al operar estos sistemas, incluso cuando pasan por una larga racha perdedora.  Pero con la generación automatizada muchas veces tenemos que renunciar a las hipótesis y contentarnos con la inferencia estadística.  

 Otro problema con el que hay que lidiar es la sobreoptimización.  En el desarrollo de  estrategias se evalúan miles de reglas posibles y el proceso evolutivo va seleccionando y descartando aquellas que convergen hacia los criterios diana establecidos. Este mecanismo de ensayo y error no es muy diferente al que seguimos cuando diseñamos nosotros la estrategia: Probamos diferentes indicadores, filtros, tipos de órdenes, etc. y evaluamos en backtest cada nuevo cambio. ¿Hay alguna diferencia entre hacerlo lenta y artesanalmente o repetir el proceso en un bucle miles de veces más rápido?  

 En principio no la hay, siempre y cuando delimitemos con claridad la región del histórico utilizada para construir los sistemas (In-Sample) de la región para evaluarlos (Out-Sample). Incluso hay estudios que recomiendan intercalar entre ambas una zona de validación que serviría para hacer una primera evaluación de las reglas en un escenario próximo  y para separar meses o años las regiones IS y OS. Otros autores recomiendan situar la región de validación fuera de la "máquina", reservando la última porción de datos para una evaluación final en la plataforma de trading.

 También está el problema de la sobreoptimización inducida: Algunas plataformas permiten probar una y otra vez las estrategias generadas en la región OS, interrumpen después de n iteraciones el proceso evolutivo si no se consiguen los objetivos fijados para el para el OS y vuelven a repetir el proceso de construcción una y otra vez hasta encontrar soluciones que satisfagan dichos objetivos.  Salta a la vista que estamos ante un uso impropio de la región OS.

PROGRAMACIÓN GENÉTICA Y PRODUCCIÓN DE SISTEMAS

La PG es una rama de la Computación Evolutiva que tiene por objeto el desarrollo de programas  de forma automática.  Comparte con los Algoritmos Genéticos (AGs) la codificación de la información en un número finito de cromosomas, el uso de operadores genéticos, funciones de adaptación y la representación de los problemas en forma de árboles de expresiones. Sin embargo, y a diferencia de los AGs, el objeto de la PG no es la solución de problemas de tipo matemático o estadístico sino la creación de programas plenamente funcionales.

En el caso de la creación de sistemas de trading el algoritmo PG estará estructurado del siguiente modo:

-  Datos de entrada: Los inputs del proceso de construcción son los históricos de precios en las que se va a evaluar el sistema y las series de indicadores adicionales construidos por nosotros. También debemos especificar los criterios y los objetivos de construcción. Es decir, cómo queremos que sea el sistema (intradiario, solo para largos, con órdenes a mercado, que incluya stoploss y profit targets, etc.) y qué objetivos debe satisfacer (Beneficio anual > 25%,  DrawDown < 15%, Fiabilidad> 45%, pérdida máxima < 1.500€, número de operaciones 300-800, SQN >3, etc.). Por último, el algoritmo genético también incorpora algunos parámetros como el tamaño de la población, número de generaciones, profundidad del árbol de búsqueda y tasas de cruzamiento, mutación y reemplazo.

-  Motor GP: Incluye todos los componentes del generador de estrategias: Indicadores técnicos,  patrones, tipos de órdenes, operadores lógico-matemáticos y reglas de construcción y de la sintaxis generada. Del motor GP dependen la diversidad potencial de estrategias, la complejidad de las reglas y la calidad del código generado. Así mismo, y dado que hablamos de procesos de computación intensiva, la velocidad es un factor crítico. Lo normal es sacar el máximo partido al procesamiento en paralelo, arquitecturas de 64 bits y contar con una generosa cantidad de RAM para producir decenas de sistemas por segundo y almacenar miles de ellos.

- Proceso evolutivo: Su elemento central es la función de ajuste (fitness function) que sirve para evaluar en qué grado se aproxima cada sistema a los objetivos establecidos. También sirve como cesura, descartando aquellas lógicas que son incompatibles con las restricciones impuestas al modelo. La evaluación se realiza en la región IS y los resultados se proyectan sobre el OS. Pero esta última región no se utiliza para construir las reglas de nuevos sistemas ni influye sobre el proceso evolutivo. De lo contrario, solo obtendríamos sistemas sobreoptimizados. Como hemos visto, no se debe utilizar la información del OS para resetear la matriz evolutiva cuando tras n generaciones no se consiguen los objetivos previstos o se llega a un callejón sin salida; esta práctica genera sobreoptimización.

Resumiendo, el proceso de construcción se articula en estas cinco etapas:

o   Generación aleatoria de la población inicial.

o   Formación del árbol evolutivo.

o   Validación de la sintaxis (construcción del código).

o   Selección de candidatos (función de ajuste, evaluación).

o   Evolución genética a población n+1 (emparejamiento, mutación, etc.)

CÓMO OBTENER ESTRATEGIAS ROBUSTAS Y RENTABLES

La evaluación de estrategias generadas automáticamente no tiene por qué diferir de la empleada con las estrategias construidas por nosotros, pues el objeto de todo protocolo de evaluación, cuando se diseña rigurosamente, no es otro que acreditar la bondad del sistema en regiones inexploradas del histórico, en marcoépocas con características distintas y, si fuese preciso, en otros históricos. No obstante, al tratarse de un proceso de computación intensivo en el que se prueban miles de alternativas posibles conviene incorporar algunas salvaguardas y reforzar algunos puntos del proceso. Veámoslo:

1.- Series históricas. Como hemos dicho repetidas veces, los datos son el alimento de los sistemas. Necesitamos series de calidad y lo suficientemente grandes para contener varias configuraciones del mercado; por lo general no menos de 7-10 años.  Si en la construcción manual basta con diferenciar dos cortes del histórico: La región IS en la que se construye la lógica y la región OS en la que se evalúa el sistema, en la creación automatizada es muy recomendable dividir el histórico en tres zonas: IS, OS y Validation (VA).

- La región IS es empleada por la máquina para validar las reglas de formación y evaluarlas considerando los criterios y restricciones de la función de adaptación o ratios diana elegidos. Normalmente se recomienda destinar a esta región al menos un 50% del histórico.

- La región OS no es empleada por el motor GP, pero sí se evalúa en cada sistema para mostrar al usuario un ranking de sistemas generados en base a los criterios de selección establecidos para el OS.

- La región VA es, en realidad, un segundo OS que puede implementarse en los modos ya comentados. En mi opinión resulta más útil la propuesta de utilizar esta región "fuera de la máquina".

2.- Calidad de las reglas del sistema. ¿Confiaría usted en un sistema que incorpora reglas como estas?

If (EMA(High[190])*0,01+ATR(12)[0] > WMA(SMA(Close, 125), 110)[0]+0,31*ATR(9)[3]

&& TEMA (EMA (RSI (4) ,25) ,47) > 51,003

{EnterLongLimit (1.234,"")}

Desde el momento que entramos en la ruleta rusa de la evolución genética, al parecer todo vale. Pero no es así; nosotros, como operadores expertos, debemos frenar la proliferación de reglas completamente arbitrarias. Una forma adecuada de hacerlo es limitando la profundidad del árbol de búsqueda  y otra, aún más radical, evitando el anidamiento de indicadores y expresiones lógicas. Pero cuidado, porque esto no sale gratis y al aplicar estas restricciones se pueden obtener sistemas con resultados más pobres.

3.- Evaluación multimercado y multi-TF. Una prueba adicional de robustez es testear la estrategia en distintos intervalos temporales y mercados. Algunas plataformas pueden realizar este test automáticamente, incluso pueden generar los sistemas considerando un mercado primario y un conjunto de mercados adicionales. Cuando una lógica funciona en varios mercados y time frames está demostrando que puede capturar movimientos o patrones de precios de carácter general y no específicos de un solo mercado. Esto incrementa la robustez del sistema y aumenta la confianza de trader.

Ejemplo de portfolio de futuros sobre índices americanos construido con Adaptrade Builder.

4.- Tests de consistencia y robustez. Algunas plataformas de GP permiten realizar pruebas internas de consistencia y robustez durante el proceso de generación de estrategias. En otras ocasiones será preciso realizarlas a mano. Para las pruebas de consistencia se utilizan los llamados stress test que normalmente actúan sobre las series de datos y otros parámetros de entrada, modificando algunos de sus valores a medida que se construyen y evalúan los sistemas. En realidad, se trata de una simulación de Montecarlo aplicada a los inputs del modelo. Los tests más habituales son:

-   Cambiar aleatoriamente la secuencia de precios.

-    Aumentar o disminuir los valores de cada barra.

-    Suprimir aleatoriamente un porcentaje de barras.

-    Alterar el tamaño del spread.

-    Alterar el deslizamiento  de las órdenes en stop.

 

Para las pruebas de robustez se actúa sobre la secuencia de operaciones generada por cada sistema empleando también simulaciones de Montecarlo. Ni que decir tiene que aplicar una simulación de Montecarlo a cada sistema generado es un proceso lento y que devora gran cantidad de recursos, incluso con los ordenadores más potentes.

Ejemplo de simulación de Montecarlo con StrategyQuant:

5.-  Walk Forward (WF). Constituye a mi juicio la forma más completa de probar la robustez de una estrategia. Podemos considerar este análisis como la prueba definitiva, en la que obtendremos la información necesaria para determinar si la lógica del sistema funciona adecuadamente en los distintos cortes temporales de la región OS. Ahora no es momento de explicar cómo hace un WF, ya lo hemos visto en otros artículos. Bástenos decir que el procedimiento no tiene por qué ser distinto con los sistemas generados automáticamente. Simplemente debemos tener esta precaución: Si hemos intercalado la zona de validación (VA) entre el IS y el OS, esta región se descarta y se evalúa solo el OS. Si la zona de validación va al final entonces la región del histórico a evaluar sería OS+VA.

Aunque alguna de las citadas plataformas de GP puede hacer automáticamente un WF, prefiero realizar esta evaluación como prueba externa, utilizando las series PnL obtenidas en plataforma de trading en la que funcionará finalmente el sistema.

Por último, recordar que cuando un sistema pasa el WF y las demás pruebas de consistencia y robustez, no deberá operarse de manera inmediata. Lo adecuado será observar durante algún tiempo su funcionamiento "en modo cuarentena"; es decir en una cuenta simulada en tiempo real. De este modo podremos detectar, sin necesidad de arriesgar nuestro dinero, algunos errores de la lógica que solo se observan en tiempo real.

La segunda parte de este artículo tendrá un carácter más práctico. En ella abordaremos paso a paso el proceso de construcción de estrategias  y daremos algunos consejos fundamentales para sacar el máximo partido a estas "maravillosas" máquinas de hacer sistemas.

Andrés A. García.

© TradingSys.org , 2014.     

Si usted es ciudadano o residente en los EE.UU. debe leer la siguiente advertencia.

IMPORTANT RISK DISCLOSURE

Futures based investments are often complex and can carry the risk of substantial losses. They are intended for sophisticated investors and are not suitable for everyone. The ability to withstand losses and to adhere to a particular trading program in spite of trading losses are material points which can adversely affect investor returns.

Past performance is not necessarily indicative of future results. Data and graph above are intended to be mere examples and are for educational and illustrative purpose only, and do not represent any trading recommendation.

Please read carefully the CFTC required disclaimer regarding hypothetical results below.

 HYPOTHETICAL PERFORMANCE RESULTS HAVE MANY INHERENT LIMITATIONS, SOME OF WHICH ARE DESCRIBED BELOW. NO REPRESENTATION IS BEING MADE THAT ANY ACCOUNT WILL OR IS LIKELY TO ACHIEVE PROFITS OR LOSSES SIMILAR TO THOSE SHOWN; IN FACT, THERE ARE FREQUENTLY SHARP DIFFERENCES BETWEEN HYPOTHETICAL PERFORMANCE RESULTS AND THE ACTUAL RESULTS SUBSEQUENTLY ACHIEVED BY ANY PARTICULAR TRADING PROGRAM. ONE OF THE LIMITATIONS OF HYPOTHETICAL PERFORMANCE RESULTS IS THAT THEY ARE GENERALLY PREPARED WITH THE BENEFIT OF HINDSIGHT. IN ADDITION, HYPOTHETICAL TRADING DOES NOT INVOLVE FINANCIAL RISK, AND NO HYPOTHETICAL TRADING RECORD CAN COMPLETELY ACCOUNT FOR THE IMPACT OF FINANCIAL RISK OF ACTUAL TRADING. FOR EXAMPLE, THE ABILITY TO WITHSTAND LOSSES OR TO ADHERE TO A PARTICULAR TRADING PROGRAM IN SPITE OF TRADING LOSSES ARE MATERIAL POINTS WHICH CAN ALSO ADVERSELY AFFECT ACTUAL TRADING RESULTS. THERE ARE NUMEROUS OTHER FACTORS RELATED TO THE MARKETS IN GENERAL OR TO THE IMPLEMENTATION OF ANY SPECIFIC TRADING PROGRAM WHICH CANNOT BE FULLY ACCOUNTED FOR IN THE PREPARATION OF HYPOTHETICAL PERFORMANCE RESULTS AND ALL WHICH CAN ADVERSELY