En esta cuarta entrega de nuestra serie dedicada al backtesting nos centraremos en una cuestión clave del proceso de construcción que, en muchos casos, se minimiza o no se entiende adecuadamente: Las variables, los parámetros y los hiperparámetros que afectan a los procesos de evaluación y optimización de estrategias.

Todo sistema basado en reglas incluye muchos más parámetros y variables que los meramente optimizables. Normalmente prestamos atención solo a estos últimos y nos despreocupamos de aquellos que están incluidos en las reglas como cantidades fijas u opciones específicas de algunos indicadores. Tampoco solemos prestar atención a los parámetros que no están vinculados al sistema pero que determinan la forma en que este se optimiza y evalúa. En realidad todos ellos son relevantes ya que contribuyen a incrementar el número de resultados alternativos o “historias posibles” que puede adoptar el sistema al hacer un backtest. 

En su excelente libro, Advances in Financial Machine Learning, López de Prado afirma que la única forma de saber si los resultados procedentes de un backtest son fiables es conociendo el número de “trials” o ensayos previos que hemos realizado con todas las configuraciones posibles de la estrategia hasta llegar al resultado que se muestra. ¡Pero precisamente este es el dato que no revela ningún desarrollador! Busquen en Internet, encontrarán cientos de páginas que muestran sistemas con curvas delirantes, de una belleza obscena, y tablas de resultados que, de ser ciertos, harían palidecer por incompetentes a todos los profesionales de la industria. De hecho, lo que resulta difícil es encontrar sitios con sistemas malos o del montón, sencillamente porque no se muestran. Así que cuando vean una de estas maravillas, en lugar de quedarse embobados frente a la pantalla, pregúntense: ¿Cuántos ensayos han sido necesarios para llegar a ella? ¿Cuántas variantes con menos glamour se han descartado? ¿Cuánto data mining hay detrás de esa preciosidad?  

Dicho esto, no resultará difícil entender que cuantas más variables, parámetros e hiperparámetros  estén involucrados en la realización de un backtest mayor será la probabilidad de obtener unos resultados poco realistas. Entre otras cosas porque el desarrollador tendrá a su disposición “más historias posibles” entre las que elegir la que mejor encaje en su argumentario.  Si es listo, quizá no se decante por el mejor resultado, pero no les quepa duda de que mostrará, sobre todo si se trata de vender un producto, alguno muy por encima de la mediana, posiblemente situado en los percentiles más altos.

VARIABLES

Entendemos por variables de un sistema todos aquellos símbolos incluidos en el código que pueden ser reemplazados por valores numéricos, alfanuméricos, lógicos o de otros tipos susceptibles de alterar el comportamiento de la estrategia.  

Pongamos un ejemplo sencillo:

Entrar largo si:

EMA(High, 20) >= EMA(Close, 150) [Y] RSI(14,2) > 60 [Y] hora = 12:30.

Aquí tenemos diferentes tipos de variables:

•           Las medias exponenciales tienen 2 variables numéricas: Valores las medias corta y larga (20 y 150 barras) y otras 2 para el punto de la barra (High y Close).
•           El indicador RSI tiene 3 variables: una para el periodo, otra para el suavizado y otra para el umbral.
•           La hora de entrada es una variable temporal
•           Los operadores lógicos y matemáticos: “>=”, “>” “=” , [Y]
•         Tipos de reglas: Aquí se utilizan EMAs, pero podrían haber sido medias simples, ponderadas, Zero-Lag, etc. Con el RSI ocurre lo mismo, nada impediría utilizar otros filtros del mismo grupo como el CCI, ROC o el Estocástico. Por tanto, cada tipo de regla incorporado en realidad es otra variable.

Así que en una lógica de entrada tan simple como esta tenemos al menos 12 variables distintas. Sin embargo, desde el punto de vista de la optimización posiblemente se declaren solo 3 parámetros: Valores de las medias y nivel del filtro RSI.

Entonces, ¿Cómo se establecen las demás variables ocultas en el código? Muy sencillo: En el 99% de los casos por ensayo y error. El desarrollador va probando diferentes horarios de entrada, medias, indicadores y operadores lógicos hasta que encuentra una combinación que genera la mejor performance en un histórico dado. 

A esto alguien podrá argumentar: Mientras la estrategia se construya en una región del histórico y se evalúe en otra diferente o en otros mercados, no hay problema. Pero en realidad sí que lo hay: Nadie construye una estrategia en bloque y realiza una única evaluación.

La mayoría de los desarrolladores realizan innumerables ensayos en la región In-sample (IS) y pruebas de concepto en el Out-Sample (OS). Cierto que no es lo mismo utilizar los datos del OS para construir la estrategia que utilizarlos para verificar la lógica o evaluar nuevas versiones. Pero si nos ponemos a realizar un número ilimitado de modificaciones y pruebas de concepto, al final estaremos incurriendo en un proceso darwiniano no muy diferente al de las plataformas de machinne learning (ML). Se mire como se mire, cualquier versión final de un sistema es el resultado de innumerables ensayos (trials) tanto en el IS como en el OS.

Resumiendo, los valores de las variables ni se deducen analíticamente ni salen de manera espontánea de la cabeza del desarrollador. Son los que son debido a un proceso de selección que, en muchos casos, implica también sobreoptimización.

PARAMETROS

Los parámetros son aquellas variables susceptibles de modificación al realizar un backtest u optimizar una estrategia. Generalmente se asignan como parámetros aquellas variables que afectan en mayor medida al rendimiento o que generan mayor diversidad de cara a  implementar la estrategia en distintos time frames y mercados.

Revisando diversas publicaciones sobre el tema, en muy pocos sitios encontramos unas orientaciones básicas sobre implementación de parámetros y mucho menos una tipología de los mismos. Por lo que buena parte de lo que diremos a continuación se basa en nuestra propia experiencia.  En la mayoría de los sistemas de trading podemos distinguir 3 tipos de parámetros:

1.  Derivados de los indicadores: Suelen ser de tipo continuo y generalmente hacen referencia al número de barras empleado en el cálculo del indicador o a un umbral que se toma como referencia de activación. Por ejemplo, en un indicador clásico como el RSI encontramos estas dos variedades: Barras o sesiones del indicador y líneas o umbrales de referencia. Estas últimas suelen estar acotadas entre dos valores (0,1; 0,100; -1,1; etc.)  incluso podemos utilizar técnicas de normalización para acotar cualquier indicador entre un máximo y un mínimo. Otros indicadores basados en bandas o canales de precios incluyen parámetros de dispersión como el número de desviaciones estándar o porcentajes de ATR.
2. De tiempo: Este tipo de parámetros son comunes sobre todo en sistemas de tipo intradiario. Se utilizan para establecer el horario de operativa en un tramo específico de la sesión, para abrir y cerrar posiciones en una hora determinada (sistemas de pautas horarias) o para establecer el tiempo máximo que puede estar abierta una posición en el mercado.
3. De control: En este grupo se incluirían una serie de parámetros como el número de máximo operaciones diarias o de operaciones por lado,  fórmulas de position sizing y días de la semana o meses de operativa (en sistemas estacionales).
4. De riesgo o de R/R:   Son los que determinan el tamaño, tipo de stops y de salidas por toma de beneficios. En este grupo también estarían los que sirven para fijar el número máximo de operaciones abiertas en el nivel de sistema y de portfolio.

Todos los parámetros de un sistema afectan en mayor o menor medida al proceso de optimización y a la diversidad de resultados que pueden obtenerse al aplicar la estrategia en diferentes mercados y time frames.

Los parámetros continuos permiten establecer una horquilla operativa de valores máximo, mínimo y salto. Esta horquilla suele obtenerse por optimización, primero en la fase de diseño y luego de manera más detallada durante la evaluación In-Sample, dando lugar a los rangos paramétricos de la zona robusta. En el sistema ya mencionado, la zona robusta estaría formada, por ejemplo, por los valores 10-30 en saltos de 1 para la EMA corta y 50-300, en saltos de 10 para la larga.  Al trader sistemático con cierta experiencia no se le escapa que esta práctica es problemática por los siguientes motivos:

• Las zonas robustas se determinan en una región del histórico que puede, o quizá no, ser representativa de la totalidad del mismo.
• Los datos históricos empleados en el diseño y en la evaluación IS suelen ser anteriores a los empleados en el OS, sobre todo cuando el procedimiento de validación es del tipo Walk-Forward. Esto hace que estén alejados varios años del momento actual y, por tanto, respondan quizá a otra marco-época. 
• Con muchos parámetros y zonas robustas demasiado laxas el número de  combinaciones paramétricas y, en consecuencia, posibles ensayos (trials) al optimizar puede ser desmesurado. Por lo que el riesgo de sobreoptimización se dispara.

Lo ideal sería deducir las combinaciones paramétricas de manera analítica en lugar de emplear procesos de optimización, por ejemplo mediante técnicas de control optimo estocástico; resolviendo la función Hamilton-Jacobi-Bellman. (Véase Cartea A. et al.:  Algorithmic and High-Frequency Trading, 2015). Pero eso es demasiado complejo y no siempre es posible. Otra posibilidad para minimizar el riesgo de sobreoptimización es emplear datos sintéticos basados en las series históricas tanto para el diseño de las reglas como para el cálculo de los valores paramétricos. Pero la construcción de estas series tampoco está exentas de problemas y resulta bastante complejo justificar que las nuevas series contienen todas las propiedades de la serie original, como quizá veamos con más detalle en otros artículos.  

La selección de parámetros tampoco es una cuestión menor. Muchos autores se inclinar por incorporar el menor número posible aduciendo que, de este modo, la estrategia se mantiene simple al tiempo que se reduce el riesgo de sobeoptimizar. Pero esto no es del todo cierto; escondiendo los parámetros debajo de la alfombra, al incorporarlos como  valores fijos en las reglas, no estamos reduciendo en absoluto la complejidad estructural del sistema, sino ocultando el hecho de que dichos valores proceden de optimizaciones previas. Lo que a su vez aumentará la incertidumbre sobre el modo en que han sido obtenidos. A menudo nos hemos encontrado sistemas con muchas variables ocultas que, al ser convertidas en parámetros y optimizadas para el time frame y mercado que recomienda el desarrollador, convergen milagrosamente a los valores de referencia. En definitiva, estamos ante una mala praxis que, además, es contraproducente ya que un sistema con demasiadas variables ocultas es mucho más rígido al ser implementado en una cesta amplia de activos.

Algunos criterios a la hora de decantarse por parámetro o valores fijos son:

•   Cuando las variables están declarados como parámetros en los indicadores  deben conservarse también como parámetros en los sistemas.
• Cuando los distintos valores da la variable, incluso los muy próximos, generan una alta diversidad de resultados.
• Cuando utilizamos indicadores de marcoépoca tales como niveles globales de volatilidad o medias de contexto alcista/bajista, podemos emplear valores fijos.
• Cuando queremos establecer comportamientos fijos del sistema como un número máximo de operaciones por sesión, un horario preestablecido de operativa también podemos emplear valores fijos.
• No es buena costumbre emplear valores fijos de R/R. Por ejemplo un porcentaje máximo de pérdidas diarias. Es preferible que el usuario del sistema module este parámetro en función de su aversión al riesgo u otros factores individuales. 

Las combinaciones paramétricas generan diversidad y adaptabilidad, pero no permiten extraer alpha de una lógica defectuosa o carente de fundamento en procesos o ineficiencias de los mercados. Por ello, al evaluar una estrategia conviene diferenciar muy bien el retorno debido a la calidad de la lógica de aquel que se obtiene por mera optimización intensiva de los parámetros para un ratio diana o función objetivo.

Para evaluar esto recientemente estoy utilizando una metodología que denomino Robust Parameter Permuitation (RPP). Básicamente consiste en generar miles de curvas del equity combinando aleatoriamente los valores paramétricos de la zona robusta. Los valores de performance situados en la mediana de la distribución son los empleados como referencia para estimar la calidad de la lógica o “rendimiento medio esperado” (RME). Los valores situados varios percentiles por debajo representan las “combinaciones paramétricas de mínimo rendimiento” (PMR) y los valores de los percentiles superiores las de máximo rendimiento. Estas últimas nos darían el “rendimiento máximo potencial” (RMP) del sistema al que solo es posible llegar optimizando y que, obviamente, dará lugar a soluciones sobreoptimizadas y carentes de realismo.

 Con el cociente RME/RMP obtenemos el porcentaje de retorno debido a la calidad de la lógica. Y está, en mi opinión, constituye una forma bastante objetiva de comparar la calidad de sistemas con independencia del número de parámetros que tengan.   

HIPERPARÁMETROS

Este término, procede del machine learning (ML) y hace referencia a los parámetros empleados en la configuración del modelo de backtest o del proceso de optimización. Aunque no se utilizan para modelar los datos directamente ni sus valores se obtienen del histórico sí afectan a los resultados obtenidos. Por ejemplo, en el caso de un sistema basado en ML mediante redes  neuronales, los hiperparámetros serían el número de capas y neuronas de la red, el tipo de propagación empleado, la función de ajuste, el porcentaje de datos dedicado al entrenamiento y validación del modelo, etc. 

En el caso de los sistemas basados en reglas discretas los hiperparámetros son el conjunto de opciones que se configuran en la plataforma al realizar la simulación histórica: Tipo de backtest, plantilla horaria, modelo de llenado de órdenes, nivel de resolución, número de entradas por lado, comisiones y deslizamientos, etc.

Los hiperparámetros nos permitirán controlar el nivel de realismo de un backtest pero en ningún modo sirven para mejorar la calidad de una estrategia dada o capturar alpha en los mercados.   Sin embargo, una proliferación excesiva de hiperparámetros también contribuye a aumentar el número de configuraciones posibles,  trials o ensayos a disposición desarrollador.

El diseño y evaluación de sistemas es más un arte que una ciencia. Lo cual no quiere decir que los desarrolladores carezcan de lógica y rigor. Resulta patético comprobar cómo aquellos que nos venden con el mayor descaro formulas maravillosas para enriquecernos de la noche a la mañana fundamentan sus hallazgos en presuntas investigaciones y métodos de evaluación “científicos” extremadamente objetivos y precisos. Una de las frases que más me gustaron del citado libro de López de Prado fue esta:

“A common misunderstanding is to think of backtesting as a research tool. Researching and backtesting is like drinking and driving. Do not research under the influence of a backtest”.

 (Op. Cit. p. 151).

Se puede decir más alto, pero no más claro.

Andrés A. García.

© Tradingsys.org, 2018.