Pruebas posteriores exitosas de estrategias de negociación algorítmicas - Parte I

Este artículo continúa la serie sobre el comercio cuantitativo, que comenzó con la Guía para principiantes e Identificación de estrategias.

El backtesting algorítmico requiere conocimiento de muchas áreas, incluyendo psicología, matemáticas, estadísticas, desarrollo de software y microestructura de mercado/intercambio. No podría esperar cubrir todos esos temas en un artículo, por lo que voy a dividirlos en dos o tres piezas más pequeñas. ¿Qué discutiremos en esta sección? Comenzaré definiendo el backtesting y luego describiré los conceptos básicos de cómo se lleva a cabo.

En los artículos siguientes veremos los detalles de las implementaciones de estrategias que a menudo apenas se mencionan o se ignoran. También consideraremos cómo hacer que el proceso de backtesting sea más realista al incluir las idiosincrasias de un intercambio comercial. Luego discutiremos los costos de transacción y cómo modelarlos correctamente en un entorno de backtest. Terminaremos con una discusión sobre el rendimiento de nuestras backtests y, finalmente, proporcionaremos un ejemplo de una estrategia cuántica común, conocida como un comercio de pares de inversión media.

Comencemos discutiendo qué es el backtesting y por qué deberíamos llevarlo a cabo en nuestra negociación algorítmica.

¿Qué es el Backtesting?

El comercio algorítmico se distingue de otros tipos de clases de inversión porque podemos proporcionar expectativas más confiables sobre el rendimiento futuro del rendimiento pasado, como consecuencia de la abundante disponibilidad de datos.

En términos simples, el backtesting se lleva a cabo exponiendo su algoritmo de estrategia particular a un flujo de datos financieros históricos, lo que conduce a un conjunto de señales comerciales. Cada operación (que queremos decir aquí como un viaje de ida y vuelta de dos señales) tendrá una ganancia o pérdida asociada. La acumulación de esta ganancia / pérdida durante la duración de su backtest de estrategia conducirá a la ganancia y pérdida total (también conocida como P&L o PnL). Esa es la esencia de la idea, aunque por supuesto el diablo siempre está en los detalles!

¿Cuáles son las razones clave para backtesting de una estrategia algorítmica?

• Filtración - Si recuerdan del artículo sobre Identificación de Estrategia, nuestro objetivo en la etapa inicial de investigación era establecer una línea de estrategia y luego filtrar cualquier estrategia que no cumpliera con ciertos criterios.
• Modelado - Las pruebas de retroceso nos permiten probar (¡seguramente!) nuevos modelos de ciertos fenómenos de mercado, como los costos de transacción, el enrutamiento de pedidos, la latencia, la liquidez u otros problemas de microestructura del mercado.
• Optimización - Aunque la optimización de la estrategia está llena de sesgos, las pruebas de retroceso nos permiten aumentar el rendimiento de una estrategia modificando la cantidad o los valores de los parámetros asociados con esa estrategia y recalculando su rendimiento.
• Verificación - Nuestras estrategias a menudo se obtienen de fuentes externas, a través de nuestro pipeline de estrategia. La prueba posterior de una estrategia asegura que no se haya implementado incorrectamente. Aunque rara vez tendremos acceso a las señales generadas por estrategias externas, a menudo tendremos acceso a las métricas de rendimiento como la relación Sharpe y las características de reducción. Por lo tanto, podemos compararlas con nuestra propia implementación.

El backtesting proporciona una serie de ventajas para el comercio algorítmico. Sin embargo, no siempre es posible realizar un backtest directo de una estrategia. En general, a medida que aumenta la frecuencia de la estrategia, se vuelve más difícil modelar correctamente los efectos de la microestructura del mercado y los intercambios. Esto conduce a backtests menos confiables y, por lo tanto, a una evaluación más complicada de una estrategia elegida. Este es un problema particular donde el sistema de ejecución es la clave para el rendimiento de la estrategia, como con los algoritmos de ultra alta frecuencia.

Desafortunadamente, las pruebas de retroceso están plagadas de prejuicios de todo tipo.

Prejuicios que afectan a las pruebas de retroceso de la estrategia

Hay muchos sesgos que pueden afectar el rendimiento de una estrategia de backtesting. Desafortunadamente, estos sesgos tienden a inflar el rendimiento en lugar de restarle importancia. Por lo tanto, siempre debe considerar una backtest como un límite superior idealizado del rendimiento real de la estrategia. Es casi imposible eliminar los sesgos del comercio algorítmico, por lo que es nuestro trabajo minimizarlos lo mejor que podamos para tomar decisiones informadas sobre nuestras estrategias algorítmicas.

Hay cuatro sesgos principales que quiero discutir: sesgo de optimización, sesgo de prospección, sesgo de supervivencia y sesgo de tolerancia psicológica.

Bias de optimización

Este es probablemente el más insidioso de todos los sesgos de backtest. Implica ajustar o introducir parámetros comerciales adicionales hasta que el rendimiento de la estrategia en el conjunto de datos de backtest sea muy atractivo. Sin embargo, una vez en vivo, el rendimiento de la estrategia puede ser marcadamente diferente.

El sesgo de optimización es difícil de eliminar ya que las estrategias algorítmicas a menudo involucran muchos parámetros. Los parámetros en este caso pueden ser los criterios de entrada / salida, los períodos de retroceso, los períodos de promedio (es decir, el parámetro de suavización de la media móvil) o la frecuencia de medición de volatilidad. El sesgo de optimización se puede minimizar manteniendo el número de parámetros al mínimo y aumentando la cantidad de puntos de datos en el conjunto de capacitación. De hecho, uno también debe tener cuidado con este último ya que los puntos de capacitación más antiguos pueden estar sujetos a un régimen previo (como un entorno regulatorio) y, por lo tanto, pueden no ser relevantes para su estrategia actual.

Un método para ayudar a mitigar este sesgo es realizar un análisis de sensibilidad. Esto significa variar los parámetros de forma incremental y trazar una "superficie" de rendimiento. Un razonamiento sólido y fundamental para las elecciones de parámetros debe, con todos los demás factores considerados, conducir a una superficie de parámetros más suave. Si tienes una superficie de rendimiento muy brusca, a menudo significa que un parámetro no refleja un fenómeno y es un artefacto de los datos de prueba. Hay una vasta literatura sobre algoritmos de optimización multidimensional y es un área de investigación muy activa.

El prejuicio por el futuro

El sesgo prospectivo se introduce en un sistema de backtesting cuando los datos futuros se incluyen accidentalmente en un punto de la simulación donde esos datos no habrían estado disponibles. Si estamos ejecutando el backtest cronológicamente y alcanzamos el punto de tiempo N, entonces el sesgo prospectivo ocurre si se incluyen datos para cualquier punto N + k, donde k>0.

• Errores técnicos - Las matrices/vectores en el código a menudo tienen iteradores o variables de índice.
• Cálculo de parámetros - Otro ejemplo común de sesgo prospectivo ocurre al calcular parámetros óptimos de la estrategia, como con regresiones lineales entre dos series de tiempo.
• Maxima/Minimum - Ciertas estrategias de negociación utilizan valores extremos en cualquier período de tiempo, como la incorporación de los precios altos o bajos en los datos de OHLC. Sin embargo, dado que estos valores máximos/mínimos solo se pueden calcular al final de un período de tiempo, se introduce un sesgo prospectivo si estos valores se usan durante el período actual. Siempre es necesario retrasarse en valores altos/bajos por al menos un período en cualquier estrategia de negociación que los utilice.

Al igual que con el sesgo de optimización, uno debe tener mucho cuidado para evitar su introducción.

Prejuicio de la supervivencia

El sesgo de supervivencia es un fenómeno particularmente peligroso y puede conducir a un rendimiento significativamente inflado para ciertos tipos de estrategias.

Como ejemplo, considere probar una estrategia en una selección aleatoria de acciones antes y después del colapso del mercado de 2001. Algunas acciones de tecnología se declararon en bancarrota, mientras que otras lograron mantenerse a flote e incluso prosperaron. Si hubiéramos restringido esta estrategia solo a las acciones que superaron el período de caída del mercado, estaríamos introduciendo un sesgo de supervivencia porque ya nos han demostrado su éxito. De hecho, este es solo otro caso específico de sesgo de prospección, ya que la información futura se incorpora al análisis pasado.

Hay dos maneras principales de mitigar el sesgo de supervivencia en sus pruebas de estrategia:

• En el caso de los datos de acciones, es posible comprar conjuntos de datos que incluyen entidades retiradas de la lista, aunque no son baratos y solo tienden a ser utilizados por empresas institucionales. En particular, los datos de Yahoo Finance NO son libres de sesgo de supervivencia, y esto es comúnmente utilizado por muchos comerciantes de algo minoristas. También se puede operar en clases de activos que no son propensas a sesgo de supervivencia, como ciertas materias primas (y sus derivados futuros).
• Utilice datos más recientes - En el caso de las acciones, utilizar un conjunto de datos más reciente mitiga la posibilidad de que la selección de acciones elegida sea ponderada a "supervivientes", simplemente porque hay menos probabilidades de que la lista general de acciones se elimine en períodos de tiempo más cortos. También se puede comenzar a construir un conjunto de datos personales libres de sesgos de supervivencia recopilando datos desde el punto actual en adelante. Después de 3-4 años, tendrá un conjunto sólido de datos de acciones libres de sesgos de supervivencia con los que probar otras estrategias.

Ahora vamos a considerar ciertos fenómenos psicológicos que pueden influir en su rendimiento comercial.

Prejuicios de tolerancia psicológica

Este fenómeno en particular no se discute a menudo en el contexto de la negociación cuantitativa. Sin embargo, se discute extensamente con respecto a los métodos de negociación más discrecionales. Tiene varios nombres, pero he decidido llamarlo "sesgo de tolerancia psicológica" porque capta la esencia del problema. Al crear backtests durante un período de 5 años o más, es fácil ver una curva de tendencia al alza, calcular el rendimiento anual compuesto, la proporción de Sharpe e incluso las características de extracción y estar satisfecho con los resultados.

Si se producen reducciones históricas del 25% o más en las pruebas de retroceso, entonces con toda probabilidad verá períodos de reducción similar en el comercio en vivo. Estos períodos de reducción son psicológicamente difíciles de soportar. He observado de primera mano cómo puede ser una reducción prolongada, en un entorno institucional, y no es agradable, incluso si las pruebas de retroceso sugieren que se producirán tales períodos. La razón por la que lo he denominado bias es que a menudo una estrategia que de otro modo sería exitosa se detiene del comercio durante los períodos de reducción prolongada y, por lo tanto, dará lugar a un bajo rendimiento en comparación con una prueba de retroceso. Por lo tanto, aunque la estrategia es de naturaleza algorítmica, los factores psicológicos aún pueden tener una influencia significativa en la rentabilidad.

Paquetes de software para pruebas de retroceso

El panorama de software para backtesting de estrategias es vasto. Las soluciones van desde software sofisticado de grado institucional completamente integrado hasta lenguajes de programación como C ++, Python y R, donde casi todo debe escribirse desde cero (o obtener plugins adecuados).

• Habilidad de programación - La elección del entorno se reducirá en gran parte a su capacidad para programar software. Yo diría que tener el control de la pila total tendrá un mayor efecto en su P&L a largo plazo que externalizar tanto como sea posible al software del proveedor. Esto se debe al riesgo negativo de tener errores externos o idiosincrasias que no puedes solucionar en el software del proveedor, que de otro modo se solucionarían fácilmente si tuvieras más control sobre tu stacktech. También quieres un entorno que logre el equilibrio adecuado entre la productividad, la disponibilidad de la biblioteca y la velocidad de ejecución.
• Capacidad de ejecución/interacción con el bróker - Ciertos programas de backtesting, como Tradestation, se relacionan directamente con un corredor. No soy fanático de este enfoque ya que reducir los costos de transacción a menudo es un componente importante para obtener una relación Sharpe más alta. Si estás vinculado a un corredor en particular (y Tradestation te obliga a hacerlo), entonces tendrás más dificultades para hacer la transición a un nuevo software (o un nuevo corredor) si surge la necesidad.
• Personalización - Un entorno como MATLAB o Python le da una gran flexibilidad a la hora de crear estrategias algo ya que proporcionan fantásticas bibliotecas para casi cualquier operación matemática imaginable, pero también permiten una amplia personalización cuando sea necesario.
• Complejidad de la estrategia - Ciertos programas no son adecuados para el cálculo de números o la complejidad matemática. Excel es uno de esos programas. Aunque es bueno para estrategias más simples, no puede realmente hacer frente a numerosos activos o algoritmos más complicados, a la velocidad.
• Minimización de sesgos - ¿Una pieza particular de software o datos se presta más a los sesgos comerciales?
• Velocidad de Desarrollo - Uno no debería tener que pasar meses e meses implementando un motor de backtest. El prototipo solo debería tomar unas pocas semanas. Asegúrese de que su software no esté obstaculizando su progreso en gran medida, solo para obtener algunos puntos porcentuales adicionales de velocidad de ejecución. C ++ es el elefante en la habitación aquí!
• Velocidad de ejecución - Si su estrategia depende completamente de la puntualidad de ejecución (como en HFT/UHFT) entonces un lenguaje como C o C++ será necesario.
• Costo - Muchos de los entornos de software con los que puede programar estrategias de trading algorítmicas son completamente gratuitos y de código abierto. De hecho, muchos fondos de cobertura utilizan software de código abierto para todas sus pilas de trading de algo. Además, Excel y MATLAB son relativamente baratos e incluso hay alternativas gratuitas a cada uno.

Ahora que hemos enumerado los criterios con los que debemos elegir nuestra infraestructura de software, quiero repasar algunos de los paquetes más populares y cómo se comparan:

Nota: Solo voy a incluir software que esté disponible para la mayoría de los profesionales minoristas y desarrolladores de software, ya que este es el público lector del sitio.

Comparación de software de pruebas de retroceso

Excel de MS

Descripción: WYSIWYG (what-you-see-is-what-you-get) software de hojas de cálculo.

Ejecución: Sí, Excel se puede vincular a la mayoría de las corredurías.

Personalización: las macros VBA permiten una funcionalidad más avanzada a expensas de ocultar la implementación.

Complejidad de la estrategia: las herramientas estadísticas más avanzadas son más difíciles de implementar, al igual que las estrategias con muchos cientos de activos.

Minimización de sesgos: el sesgo de prospección es fácil de detectar a través de la funcionalidad de resaltado de células (suponiendo que no haya VBA).

Velocidad de desarrollo: Rápida implementación de estrategias básicas.

Velocidad de ejecución: velocidad de ejecución lenta, adecuada solo para estrategias de baja frecuencia.

Costo: Barato o gratuito (dependiendo de la licencia).

Otras opciones: OpenOffice

Matlab (en inglés)

Descripción: Entorno de programación diseñado originalmente para matemáticas computacionales, física e ingeniería. Muy adecuado para operaciones vectorizadas y aquellas que involucran álgebra lineal numérica. Proporciona una amplia gama de complementos para el comercio cuántico. En uso generalizado en fondos de cobertura cuantitativos.

Ejecución: sin capacidad de ejecución nativa, MATLAB requiere un sistema de ejecución separado.

Personalización: Una gran variedad de complementos comunitarios para casi todas las áreas de las matemáticas computacionales.

Complejidad de la estrategia: muchos métodos estadísticos avanzados ya disponibles y bien probados.

Minimización de sesgos: es más difícil detectar sesgos de previsión, requiere pruebas extensas.

Velocidad de desarrollo: los scripts cortos pueden crear pruebas de retroceso sofisticadas fácilmente.

Velocidad de ejecución: Suponiendo un algoritmo vectorizado / paralelo, MATLAB está altamente optimizado.

Costo: alrededor de 1.000 USD por una licencia.

Otras opciones: Octave, SciLab

Python

Descripción: Lenguaje de alto nivel diseñado para la velocidad de desarrollo. Amplia gama de bibliotecas para casi cualquier tarea programática imaginable. Ganando una mayor aceptación en la comunidad de fondos de cobertura y bancos de inversión. No tan rápido como C / C ++ para la velocidad de ejecución.

Ejecución: los complementos de Python existen para corredores más grandes, como Interactive Brokers.

Personalización: Python tiene una comunidad de desarrollo muy saludable y es un lenguaje maduro.

Complejidad de la estrategia: Existen muchos complementos para los algoritmos principales, pero no tan grande como una comunidad cuántica que existe para MATLAB.

Minimización de sesgos: existen los mismos problemas de minimización de sesgos que para cualquier lenguaje de alto nivel.

Velocidad de desarrollo: La principal ventaja de Python es la velocidad de desarrollo, con robustas capacidades de prueba incorporadas.

Velocidad de ejecución: No tan rápido como C ++, pero los componentes de computación científica están optimizados y Python puede hablar con el código nativo de C con ciertos complementos.

Costo: Libre y de código abierto

Alternativas: Ruby, Erlang y Haskell

R

Descripción: Entorno diseñado para métodos estadísticos avanzados y análisis de series temporales. Amplia gama de conjuntos de herramientas estadísticas, econométricas y gráficas nativas. Gran comunidad de desarrolladores.

Ejecución: R posee complementos para algunos corredores, en particular Interactive Brokers.

Personalización: R se puede personalizar con cualquier paquete, pero sus puntos fuertes se encuentran en los dominios estadístico/econométrico.

Complejidad de la estrategia: en su mayoría útil si se realizan estrategias econométricas, estadísticas o de aprendizaje automático debido a los complementos disponibles.

Minimización de sesgos: nivel similar de posibilidad de sesgo para cualquier lenguaje de alto nivel como Python o C ++. Por lo tanto, se deben realizar pruebas.

Velocidad de desarrollo: R es rápido para escribir estrategias basadas en métodos estadísticos.

Velocidad de ejecución: R es más lento que C++, pero sigue siendo relativamente optimizado para operaciones vectorizadas (como con MATLAB).

Costo: Libre y de código abierto

Alternativas: SPSS y Stata

C++

Descripción: Lenguaje maduro de alto nivel diseñado para la velocidad de ejecución. Amplia gama de finanzas cuantitativas y bibliotecas numéricas. Más difícil de depurar y a menudo tarda más en implementarse que Python o MATLAB. Extremadamente prevalente tanto en el lado de compra como de venta.

Ejecución: La mayoría de las API de corretaje están escritas en C++ y Java.

Personalización: C/C++ permite el acceso directo a la memoria subyacente, por lo que se pueden implementar estrategias de frecuencia ultra alta.

Complejidad de la estrategia: C++ STL proporciona una amplia gama de algoritmos optimizados.

Minimización de sesgos: el sesgo de prospección puede ser difícil de eliminar, pero no más difícil que otros lenguajes de alto nivel.

Velocidad de desarrollo: C++ es bastante versátil en comparación con Python o MATLAB para el mismo algoritmo.

Velocidad de ejecución: C/C++ tiene una velocidad de ejecución extremadamente rápida y se puede optimizar bien para arquitecturas computacionales específicas.

Costo: Varios compiladores: Linux/GCC es gratuito, MS Visual Studio tiene licencias diferentes.

Alternativas: C#, Java, Scala

Las estrategias HFT y UHFT se escribirán en C/C++ (en estos días a menudo se llevan a cabo en GPU y FPGAs), mientras que las estrategias de equidad direccional de baja frecuencia son fáciles de implementar en TradeStation, debido a la naturaleza todo en uno del software / corretaje.

Mi preferencia personal es para Python, ya que proporciona el grado adecuado de personalización, velocidad de desarrollo, capacidad de prueba y velocidad de ejecución para mis necesidades y estrategias. Si necesito algo más rápido, puedo drop in a C++ directamente desde mis programas de Python. Un método preferido por muchos comerciantes cuánticos es crear prototipos de sus estrategias en Python y luego convertir las secciones de ejecución más lentas a C++ de manera iterativa.

En los próximos artículos sobre backtesting vamos a echar un vistazo a algunas cuestiones particulares en torno a la implementación de un sistema de backtesting de comercio algorítmico, así como cómo incorporar los efectos de los intercambios comerciales.

Más.