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.
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