Expediente Backtest (Parte I)
 
 

Expediente Backtest (Parte I)

 
AndyG - 9 Ago 2018
1 comentario
 

En esta serie de artículos abordaremos una de las técnicas más comunes y a la vez peor entendidas del trading cuantitativo: El backtesting o simulación histórica como instrumento para determinar la calidad y potencial inversor de una estrategia. Mostraremos los errores más comunes, las limitaciones de los métodos tradicionales y presentaremos metodologías novedosas que contribuyen a mejorar la robustez de este tipo de análisis.


1.- QUÉ ES Y QUÉ NO ES UN BACKTEST

Un Backtest es una forma de evaluar la rentabilidad de una estrategia empleando datos pasados. Los resultados obtenidos son hipotéticos y en ningún caso deben emplearse con carácter predictivo. Por ello, el backtesting no es un procedimiento de investigación científica ya que le falta un componente esencial: La imposibilidad de establecer relaciones causales entre el conjunto de variables que determinan el funcionamiento de una estrategia dada y la dinámica de los mercados.

En otras palabras, el binomio “sistema-mercado” carece de potencial predictivo mientras que, por ejemplo, el binomio “ley física-naturaleza” sí lo tiene. Un astrónomo puede utilizar leyes muy básicas de la mecánica celeste para predecir la fecha exacta de los próximos 50 eclipses de Sol, pero yo no tengo forma alguna de saber con certeza si mi flamante estrategia XYZ obtendrá un beneficio acumulado del 50% en los siguientes 3 años o se meterá, nada más comenzar a operarla, en un DD del que no saldrá nunca.

Una vez asumido que un backtest no es una herramienta de investigación científica, ¿qué utilidad podría tener para el trading cuantitativo? Enorme, pues es la única forma que tenemos de estudiar el comportamiento de un conjunto de reglas en un determinado escenario histórico.

Un backtest bien hecho permite obtener una enorme cantidad de información sobre el modelo a implementar: Su coherencia estructural, la validez de los filtros en diferentes marcoépocas, la pertinencia de los mecanismos de entrada y cierre de posiciones, los tipos de órdenes elegidos para posicionarse, etc.

 El problema es que construir un backtest que simule de manera precisa el comportamiento real de una estrategia no es tarea sencilla y en muchas ocasiones la misma estrategia evaluada con distintas plataformas, series de datos y criterios de llenado de órdenes puede generar resultados muy dispares. Así que otro de los grandes problemas del backtesting es el de la replicabilidad. Es como si los científicos, para contrastar los resultados de un experimento tuvieran que desplazarse una y otra vez al mismo laboratorio.


En definitiva:




2.- PRINCIPALES ERRORES DEL BACKTESTING

El principal error proviene de una interpretación ingenua de los resultados que llevará al inversor poco experimentado a creer que los datos procedentes de una simulación son extrapolables en el tiempo. Se trata de un sesgo cognitivo denominado “heurística de la disponibilidad” según el cual tendemos a sobreestimar los datos disponibles minimizando los riesgos que comportan.    

Así, cuando nos presentan una curva y unas estadísticas magníficas pensamos que son el  resultado de una estrategia inherentemente ganadora y que nos gustaría tenerla, en lugar de pensar que quizá dichos resultados se han obtenido por mero ensayo y error, que son el enésimo prototipo de sistema en un  ejercicio de optimización intensiva en el que previamente se han probado cientos de reglas alternativas y miles de combinaciones paramétricas.


Este es el bucle perverso del Machine Learning (ML):



Efectivamente, las estrategias se construyen empleando datos IS y el OS se utiliza solo para evaluar la performance. Hasta aquí todo correcto y nadie engaña. Sin embargo repitamos este proceso millones de veces y vayamos ordenando en un ranking las estrategias con mejor comportamiento en el OS. ¿Cómo hemos llegado a esas maravillosas estrategias que ocupan los primeros puestos de la lista y muestran unas curvas geniales? ¿Podemos decir que están libres de sobreoptimización? Sí y no.   

Formalmente no hay sobreoptimización porque el algoritmo ML está construyendo y evaluando en regiones distintas del histórico. Ahora bien, estamos ante un proceso de selección brutal en el que la máquina genera, combina y pruebe miles de reglas de trading por minuto. La mayoría dan lugar a estrategias fallidas y se descartan. Solo un pequeño porcentaje satisface los criterios de selección y van ascendiendo en el ranking. Si repetimos este proceso durante un tiempo arbitrario, al final, por la ley de los grandes números, acabaremos viendo auténticas joyas con unas estadísticas fabulosas en el OS. Ahora bien, ¿qué tenemos en nuestro zurrón: pepitas de oro o arena de playa?  

 

 Algunos de los errores o sesgos más comentados en la literatura sobre el tema son:


1) Sesgo de supervivencia (Survivorship bias).- Solo nos fijamos en aquellas empresas estrategias o programas inversores que han sobrevivido hasta el momento actual, obviando el hecho de que una proporción aún mayor se han quedado por el camino. Esto afecta a la composición de los grandes índices de acciones  y a los rankings de fondos y programas CTA. Pero también al diseño de estrategias cuantitativas que surgen como resultado de cualquier proceso intensivo de ensayo y error, sea este manual o automático. En otras palabras, el sesgo de supervivencia ocurre cuando construimos sistemas por mero data mining y nos dedicamos a seleccionar los mejores.


2) Sesgo de proximidad (Proximity bias).- Tendemos a sobrevalorar aquello que tenemos más próximo: Los últimos datos son los mejores. De este modo, a la hora de elegir un programa inversor, nos importa menos un DD histórico excesivo -y seguramente inapropiado para nuestro nivel de aversión al riesgo- que unos buenos resultados en los últimos 6 meses.


3) Sesgo de anticipación (lookahead bias).- Algunas veces, sin proponérselo, los desarrolladores acaban construyendo estrategias que echan un ojo al futuro. Por ejemplo, algunos sistemas de base diaria utilizan el valor del cierre en indicadores y filtros para posicionarse al cierre de sesión, pero eso en operativa real es imposible. La simulación más precisa  para barraras diarias sería tomar como referencia la apertura de la sesión siguiente, aun asumiendo el hueco entre sesiones en aquellos mercados que no tienen operativa nocturna. Otro ejemplo es el de entrar y salir en la misma barra, si no bajamos a un time frame inferior no hay forma de saber con certeza si dicha operación pudo realizarse.


4) Insuficientes operaciones y puntos de datos (Insufficient Sample Bias).- ¿Cuántos puntos de datos son suficientes para verificar una tendencia, para validar una pauta estacional o para construir un canal de precios mínimamente consistente? Del mismo modo, ¿Cuántas operaciones necesitamos para asignar validez estadística a los resultados de un backtest? Sabemos que los grados de libertad de una estrategia disparan el riesgo de sobreoptimización. Por tanto, cuantas más reglas y parámetros más puntos de datos son necesarios para validarla. ¿Cómo se consigue esto? Aumentando el número de operaciones o aumentando el tamaño de los históricos. Lo cual no resulta sencillo y en ocasiones puede requerir el uso de series sintéticas.


5) Sesgo del período óptimo (Optimal Period Bias).- Aquí nos enfrentamos más que al tamaño de los históricos a la diversidad de configuraciones de los mercados. Las estrategias deben ser evaluadas en escenarios de alta y baja volatilidad y en tendencias de fondo alcistas, bajistas y laterales. Es muy conveniente identificar con criterios objetivos cada régimen de los mercados y analizar en cada uno de ellos el rendimiento de la estrategia. Dado que es muy difícil desarrollar estrategias multi-régimen, una práctica habitual, aunque poco recomendable, suele ser trocear la estrategia en función de su respuesta a las distintas configuraciones. Por ejemplo, convertimos el sistema en una estrategia solo de largos cuando vemos que el rendimiento de la pata corta es muy pobre o introducimos un filtro de volatilidad para anclar la operativa a un determinado umbral. La principal objeción a esta práctica es que las reglas se deciden a posteriori; se utilizan los datos de evaluación para retocar la lógica introduciendo nuevas reglas. Recuerden: La evaluación no se hace para introducir nuevas reglas sino para analizar la robustez y consistencia del modelo.    


6) Ignorar el impacto en el mercado.- Los datos históricos no incluyen las operaciones que queremos simular. De este modo resulta imposible estimar a toro pasado el impacto que hubiera tenido nuestra operativa sobre el mercado. En productos muy líquidos y con pequeños paquetes de órdenes este impacto será a los sumo de 1-2 ticks, pero en productos menos líquidos o con paquetes grandes puede llegar a ser mucho mayor. Si operamos con órdenes a mercado esto es lo que se denomina deslizamiento y su efecto es acumulativo, y si la operativa es con órdenes limitadas, habrá un porcentaje de órdenes que nunca se llegarán a realizar o completar y esta es otra forma de deslizamiento que no pueden contemplar la plataformas y que surge como consecuencia de la pérdida de oportunidades.


7) Sesgo del espionaje de datos.- (data snooping bias) En ciencia los conjuntos de datos que se utilizan para construir una hipótesis nunca se utilizan en su contrastación. El data snooping ocurre cuando el investigador modifica la hipótesis para para acomodarla a los datos experimentales que obtiene. En trading cuantitativo este sesgo ocurre cuando mezclamos los datos históricos utilizados para construir la estrategia con los datos utilizados para evaluarla. A menudo este proceso no es intencional, surge como consecuencia la  experiencia previa del desarrollador. Así, al construir estrategias   nuevas, tiende a emplear reglas que sabe de antemano que van a funcionar con mayor probabilidad que otras porque proceden de estrategias ya evaluadas.


8) Gastos de la operativa.- Muchas veces una estrategia fracasa porque no se han simulado unos gastos realistas. Este problema es más frecuente en estrategias de alta cadencia operativa y con un beneficio medio por operación (BMO) pequeño. Cuando el BMO en operativa simulada es de unos pocos dólares el más mínimo error en la estimación de los gastos debidos comisiones y deslizamientos puede dar al traste con estrategias sobre el papel muy buenas. Algunos sistemas construidos para campeonatos tienen claramente este problema.


9) Cambios regulatorios en los mercados.- El simple hecho de ampliar el horario de contratación o disminuir el tamaño del tick en un producto tiene un impacto directo sobre la operativa. Las simulaciones se construyen bajo el supuesto de la estabilidad estructural de los mercados: “No nos van a cambiar nunca las reglas de juego”. Pero tales cosas ocurren y con relativa frecuencia.  Por ejemplo, no hace mucho vimos como el TF (e-mini Russell 2000) reducía a la mitad el tamaño del tick, afectando muy negativamente a sistemas ORB de tipo intradiario. Motivo: Disminución del BMO debido a un menor rango H-L y a que los gastos no se han reducido exactamente a la mitad. Posteriormente este futuro dejó de cotizar en exclusiva en el Nybot para cotizar también en el Globex (RTY) con la consiguiente pérdida de volumen. Podría citar muchos más casos, pero este lo he vivido muy de cerca.


10) Outliers.- Construimos una estrategia considerando un régimen del mercado extremo, con muy pocas probabilidades de repetirse en el futuro. Por ejemplo, 2008, el año de la crisis subprime, distorsiona cualquier backtest. Los mercados alcanzaron niveles de volatilidad nunca vistos y se alternaron rachas fuertemente bajistas con correcciones de considerable amplitud. Una situación así es idónea para sistemas intradiarios tipo VBO (volatility break out), ORB (opening range breakout) y MR (mean reversión).   Así que al hacer un backtest la rentabilidad fluctuará drásticamente dependiendo de si metemos  dicho año en el In-Sample o en el Out-Sample. Algunos colegas optan por omitir el 2008 en sus simulaciones. Yo no lo recomiendo, en mi opinión dicho año constituye un  stress test en sí mismo. O sea, un recordatorio de cómo podría funcionar nuestra estrategia bajo condiciones extremas. Obviamente debemos ser conscientes de que nunca se repetirán de la misma manara: No hay dos “cisnes negros” iguales.

 

Esto último nos introduce de lleno el espinoso tema de la replicabilidad de los resultados que veremos con calma en la próxima entrega.

 

Andrés A. García

© Tradingsys.Org, 2018

 

 

Comentarios

 

- excelente artículo

 
Algunos de los sesgos comentados, son realmente difíciles de evitar; el demonio está en el sego 1, porque el dataminnig hace muy difícil evaluar la consistencia interna de la regla, porqué tiene sentido lo que hace. 
 
Y esta frase: 
Recuerden: La evaluación no se hace para introducir nuevas reglas sino para analizar la robustez y consistencia del modelo.  
 
es una joya; la mejor solución es tener dos periodos de OS; el primero evalua el modelo obtenido de IS; el segundo, evalúa las correcciones a posteriori si es evidente que el modelo es mejorable (un solo lado, un cierto nivel de volatilidad, en MM, en gestión de la posición...) Hay un precio: alejar el posible patrón obtenido del momento actual del mercado.

Añadir comentario

 
Modificado por AndyG - 1 Dic 2018
 
 

Secciones

 
 

Entradas recientes

 
 

Enlaces