Los editores del portal QuantStart escribieron
material sobre lo que debe saber cuando comience a desarrollar su propio sistema para probar estrategias comerciales. Examinamos algunos de los problemas planteados en el artículo anterior en el blog, por lo que esta vez preparamos un recuento adaptado de tesis sobre los problemas que enfrentan los desarrolladores, cuál es la diferencia entre los backtests de diferentes tipos y cuáles son sus pros y sus contras.
¿Qué es Backtester?
Backtest es la aplicación de las reglas de una estrategia comercial a un conjunto de datos históricos sobre los precios de los instrumentos financieros. La esencia del enfoque es que si desarrollamos un mecanismo para determinar el momento de entrar y salir de una posición (comprar / vender), por ejemplo, acciones de una determinada cartera, y aplicar las reglas resultantes a los datos históricos, esto dará una idea de la productividad de la estrategia comercial "en el pasado ".
Alguien dijo una vez que "todos los modelos están equivocados, pero algunos son útiles". Esta frase es genial para backtesting. Los sistemas para pruebas históricas de estrategias financieras ayudan a determinar si vale la pena aplicar el conjunto de reglas existente al comercio real. Si sabemos cómo podría comportarse una estrategia en el pasado, ayudará a filtrar estrategias malas sin la necesidad de pérdidas financieras reales.
El problema es que el resultado del backtesting no tiene nada que ver con los resultados del comercio real en el intercambio. Esto es solo un modelo de realidad. Un modelo que a menudo contiene muchos supuestos.
Hay dos tipos principales de probadores de prueba: for-loop e impulsados por eventos.
Al desarrollar tales sistemas, siempre existe la necesidad de un compromiso entre la precisión y la complejidad de la implementación. Estos dos tipos de evaluadores representan la gama completa de opciones para tal compromiso.
Retos de backtesting
Las pruebas en datos históricos conllevan muchas dificultades. Todos ellos están conectados con el hecho de que todo el proceso es solo una simulación de la realidad. Estos son solo algunos de ellos:
- Pruebas dentro de la muestra : surge un problema al utilizar los mismos datos para entrenar modelos comerciales y para sus pruebas adicionales. En este caso, la productividad mostrada se deprecia significativamente, porque el resultado se logra en un sistema de datos previamente conocido. En realidad, los datos a menudo diferirán significativamente de la capacitación. De hecho, esta es una forma de reciclaje.
- Error de los supervivientes : los índices bursátiles (por ejemplo, S & P500) se caracterizan por un proceso de cotización y exclusión cuando ciertas acciones e instrumentos financieros aparecen o se excluyen de ellos. Si estos cambios no se tienen en cuenta durante las pruebas de respaldo, entonces una estrategia que no tiene en cuenta las acciones de las empresas que fueron excluidas del índice debido a la baja capitalización puede considerarse exitosa. Para evitar tales problemas cuando se ejecutan las pruebas de respaldo durante largos períodos de tiempo, debe usar datos que no estén sujetos al error del sobreviviente.
- Errores de predicción (sesgo de anticipación) : los datos del futuro también pueden afectar el resultado del backtest. Por ejemplo, considere el caso cuando se calcula un índice de regresión lineal en un cierto intervalo de tiempo. Si este indicador se usa en la misma muestra, resulta que los datos del futuro penetraron en él, lo que significa que la productividad resultante de la estrategia se deprecia significativamente. Los analizadores orientados a eventos ayudan a resolver este problema.
- Cambio en las condiciones del mercado : los parámetros del mercado financiero no son estacionarios. Esto significa que los procesos que resultan en movimientos del precio de las acciones no dependen de parámetros que sean constantes a lo largo del tiempo. Este hecho complica la generalización de los modelos parametrizados (muchas estrategias comerciales son casos especiales de tales estrategias), lo que lleva al hecho de que la efectividad de la estrategia en los datos históricos es mucho mejor que en el comercio real.
- Costos de transacción : muchos probadores de pruebas cíclicas no tienen en cuenta ni siquiera la información más básica sobre los costos de transacción, como diversas tarifas y cargos. A menudo, los autores de artículos científicos pecan que prefieren no inclinarse ante tales pequeñeces. Encontrar una estrategia que sea muy rentable en condiciones ideales sin costo es muy fácil. El problema es que cuando se opera en condiciones reales, tales estrategias pueden ser muy poco rentables. Es extremadamente importante tener en cuenta el diferencial, la situación del mercado, las diversas tarifas, el deslizamiento (en transacciones con activos altamente volátiles, el precio real de la transacción puede diferir ligeramente del que se esperaba al realizar la solicitud, tanto en la dirección favorable como en la negativa).
También hay otros problemas que no se discuten a menudo, pero que sin embargo son extremadamente importantes para crear un analizador de calidad. Entre ellos están:
- Los datos de OHLC son información sobre el precio de apertura, el precio más alto de un instrumento financiero durante la sesión de negociación, su valor más bajo y el precio de cierre del período de negociación (gráfico de apertura-alto-bajo-cierre, OHLC). Por lo general, se importa de fuentes como Yahoo Finance. En este caso, podría ser una combinación de diferentes fuentes de datos. Esto significa que será difícil obtener valores extremos (incluidos precios altos y bajos) para un sistema de comercio en tiempo real. Esto también debe tenerse en cuenta en el modelo comercial.
- Limitaciones capacitivas : el backtesting es tentador para usar un suministro infinito de dinero. En realidad, la cantidad de fondos disponibles para el comercio siempre es limitada (al igual que la cantidad posible de fondos prestados para el comercio de margen). También es importante no olvidarse del límite de volumen de negociación diario promedio (Volumen diario promedio, ADV), especialmente para acciones con bajo contenido de líquidos, cuando el riesgo es alto de que el sistema de negociación conduzca a un cambio real en el precio. Este efecto de mercado también debe considerarse.
- Selección de referencia : es necesario responder a la pregunta de si la referencia se seleccionó correctamente con la cual se comparará la estrategia probada. Por ejemplo, si intercambia futuros de productos básicos que son neutrales para el índice S & P500, ¿vale la pena usar este índice como punto de referencia? Es probable que una canasta de otros fondos de productos básicos sea una opción más apropiada.
- Robustez : si cambia la hora de inicio de la estrategia durante el backtest, ¿cuánto afecta esto al resultado? Para las estrategias a largo plazo, la hora de inicio de su trabajo no debería afectar seriamente la productividad; no importa si el backtest comenzó el lunes o el jueves. Si es demasiado sensible a las condiciones iniciales, esto significa que no hay forma de predecir su posible productividad al comienzo del comercio real.
- Reentrenamiento y variación : ya hemos mencionado los problemas de reciclaje anteriores, pero este es un problema más amplio inherente a todos los métodos supervisados de aprendizaje automático. Este problema solo puede resolverse mediante el uso cuidadoso de técnicas de validación cruzada. E incluso en este caso, uno debe ser extremadamente cuidadoso al adaptar estrategias al ruido en los conjuntos de datos de prueba.
- Tolerancia psicológica: la psicología a menudo se ignora al crear sistemas de comercio automatizados, porque su influencia debe minimizarse mediante algoritmos. Sin embargo, las personas siguen siendo humanas, incluso cuando comercian no con las manos, sino con la ayuda de robots. Como resultado, esto puede afectar los resultados. Por ejemplo, si durante una prueba retrospectiva una reducción de un depósito del 50% puede parecer un riesgo aceptable, entonces en realidad la pérdida de la mitad del valor de los activos resulta ser una experiencia mucho más traumática. No es fácil resistir acciones no planificadas en tal situación.
Eso es todo con los problemas de las pruebas en el historial, ahora pasamos a la descripción de los sistemas mismos para tales pruebas.
Dos tipos de probadores de espalda
Primero, considere los sistemas cíclicos. Este es el tipo de backtester más simple que se describe con mayor frecuencia en varias publicaciones de blog de finanzas.
Loop Backtest
Funcionan así: el sistema simplemente itera a través de cada día de negociación (o barra OHLC), realiza cálculos relacionados con el precio del activo deseado (por ejemplo, calcula los precios de cierre promedio móvil) y luego realiza la operación correspondiente (ingresando una posición larga o corta). Otras iteraciones continúan. En el proceso, la información sobre el rendimiento se almacena para generar un gráfico (curva de equidad) como resultado.
Así es como se ve el pseudocódigo de dicho algoritmo:
for each trading bar: do_something_with_prices(); buy_sell_or_hold_something(); next_bar();PythonCopy
Como puede ver, el sistema es extremadamente simple, lo que hace que estos probadores de respaldo sean una excelente opción para obtener las primeras estimaciones sobre las perspectivas del sistema de negociación.
Pros
El backtester cíclico es muy sencillo de implementar utilizando casi cualquier lenguaje de programación, y lo hace rápidamente. Esto es útil cuando desea probar el efecto de muchos parámetros diferentes.
Contras
La principal desventaja son los resultados poco realistas. A menudo, en los probadores cíclicos ni siquiera hay una funcionalidad básica para contabilizar los costos de transacción, debe implementarse por separado. También se usan comúnmente las órdenes de MERCADO.
Además, la posibilidad de reutilizar código para un sistema productivo y de prueba es mínima, por lo que debe volver a escribirla. Esto aumenta la probabilidad de errores de software.
Los probadores de bucle invertido son propensos a errores de predicción. Deben usarse exclusivamente como herramienta de filtrado para rechazar estrategias obviamente fracasadas. Al mismo tiempo, es importante mantenerse extremadamente escéptico respecto de las estrategias que han mostrado buenos resultados. Es importante recordar que en la vida real, las estrategias rara vez funcionan mejor que durante un backtest.
Sistemas orientados a eventos
Los sistemas de este tipo están en el lado opuesto del espectro. Están mucho más cerca de la realidad. Por lo general, trabajan en bucles while enormes, durante los cuales los "eventos" se buscan constantemente en una "cola de eventos" especial, que incluye:
- garrapatas : la aparición de nuevos datos de mercado;
- eventos de señalización : la aparición de señales comerciales;
- evento de pedido : un pedido para completar una transacción está listo para enviarse al sistema de intermediario;
- evento de transacción : recibo del agente de información sobre la ejecución de la aplicación.
Cuando se reconoce un determinado evento, se transmite al módulo correspondiente en la infraestructura del sistema de negociación para su posterior procesamiento y potencialmente genera nuevos eventos que nuevamente caen en la cola.
El pseudocódigo de dicho analizador es el siguiente:
while event_queue_isnt_empty(): event = get_latest_event_from_queue(); if event.type == "tick": strategy.calculate_trading_signals(event); else if event.type == "signal": portfolio.handle_signal(event); else if event.type == "order": portfolio.handle_order(event); else if event.type == "fill": portfolio.handle_fill(event) sleep(600);
Como puede ver, el sistema depende en gran medida del módulo de procesamiento de cartera: este es el verdadero corazón de los sistemas orientados a eventos.
Pros
Los evaluadores de este tipo tienen muchas ventajas:
- Reducción de la probabilidad de errores de pronóstico : debido a la estructura, que supone una transmisión de mensajes por fases, es menos probable que ocurran errores de pronóstico en los sistemas orientados a eventos, al menos a nivel comercial. Sin embargo, la probabilidad de que ocurra aún se conserva, ya que los errores pueden estar contenidos en el modelo mismo.
- Capacidad para reutilizar código : para usar la estrategia en el comercio real, solo necesita reemplazar el módulo de procesamiento de datos y el motor de ejecución de órdenes. La descripción de la estrategia, el módulo de gestión de riesgos y la gestión de posiciones, un código para evaluar la productividad del sistema; todo esto se puede utilizar sin cambios. Esto reduce la probabilidad de nuevos errores.
- Nivel de cartera : las estrategias basadas en eventos hacen que sea más fácil pensar a nivel de cartera. En última instancia, esto hace que sea más fácil hacer cambios en la estrategia y desarrollar métodos de cobertura.
- Gestión de riesgos "correcta" : en tales sistemas es más fácil "modular" la gestión de riesgos. Un operador puede usar fácilmente técnicas como el criterio de Kelly, y también incluir varias alertas, establecer límites (por ejemplo, sobre la volatilidad).
- Implementación y monitoreo remotos : el principio modular de escribir código simplifica su implementación en la nube o de acuerdo con el esquema de colocación de intercambio.
Contras
Las ventajas de los sistemas orientados a eventos son comprensibles, pero existen ciertas desventajas. Entre ellos están:
- Código complejo : desarrollar un sistema totalmente cubierto por pruebas llevará semanas y meses de trabajo en modo de tiempo completo.
- Orientación a objetos : el diseño modular del sistema requiere un enfoque orientado a objetos para la programación. Entonces, necesitamos un lenguaje que respalde estos principios. Las pruebas unitarias no serán más fáciles.
- Umbral de entrada alto : un recién llegado a la programación no podrá crear dicho sistema. Se requerirá una importante experiencia en ingeniería, lo que hará posible lidiar con la escritura de código, la implementación de registros, la realización de pruebas unitarias, la implementación de control de versiones y prácticas de integración continua.
- Baja velocidad : un enfoque en el que los mensajes dentro del sistema se transmiten secuencialmente dentro de sus diferentes niveles, reduce la velocidad de ejecución de las aplicaciones en comparación con el enfoque cíclico vectorizado. Calcular varias combinaciones de parámetros puede llevar mucho tiempo.
Otros materiales financieros y bursátiles de ITI Capital :