Backtesting

Backtesting reproduce reglas sobre datos históricos y calcula el resultado que habrían obtenido bajo los supuestos elegidos. Bailey y sus coautores lo describen como una simulación histórica de una estrategia algorítmica y advierten del riesgo de falsos descubrimientos. Nuestro límite editorial es que el resultado corresponde a una versión concreta de las reglas, los datos y el modelo de ejecución. No demuestra que alguien realizara esas operaciones. Un cálculo reproducible puede revelar un error o una idea inadecuada, pero por sí solo no convierte el pasado en una previsión fiable. [1]

QuantConnect describe el sesgo que aparece cuando una simulación usa información futura, como datos contables antes de su publicación o sus revisiones posteriores. Nuestro propio contrato temporal exige registrar cuándo estuvo disponible cada dato de entrada, no solo la fecha del periodo al que corresponde. Sin un supuesto adicional, una señal de una vela cerrada no puede obtener una operación a un precio que ya no estaba disponible. En nuestro ejemplo, los precios de cierre anteriores se utilizan únicamente para el periodo siguiente y el modelo determina explícitamente su ejecución de apertura. [2]

QuantConnect advierte sobre probar únicamente valores que sobrevivieron hasta el final del periodo y aplicar retrospectivamente la composición actual de un índice. Nuestra pregunta más general es si el conjunto histórico conserva también instrumentos disponibles entonces que después desaparecieron. Deben documentarse los datos ausentes, los cambios metodológicos y la selección de mercados. En una simulación de Bitcoin, no puede suponerse automáticamente que el precio de un servicio fuera alcanzable en otro. La limpieza de datos significa trazabilidad de las correcciones, no eliminación de resultados incómodos. [2]

La documentación de QuantConnect separa la señal y la orden del modelo que determina el precio y la cantidad ejecutados. También señala la diferencia entre las ejecuciones parciales en la negociación real y el supuesto de ejecución completa de los modelos predefinidos. Nuestro requisito es describir cuándo puede ejecutarse una orden, qué ocurre si no hay suficiente liquidez y cómo se tratan los precios desactualizados. Que los datos históricos toquen un nivel de precio no demuestra por sí solo que hubiera una contraparte disponible para una orden de tamaño arbitrario. El resultado del modelo de ejecución sigue siendo un supuesto de la simulación. [3]

QuantConnect describe Slippage como la diferencia entre el precio de ejecución esperado y el real, y señala la influencia de los retrasos, la conexión y las condiciones del mercado; la desviación puede ser favorable o desfavorable. Nuestra comprobación de costes separa las comisiones, el precio de ejecución y otros posibles costes de mantenimiento o financiación. Un coste ya incorporado al precio de ejecución no debe deducirse otra vez. Un valor cero es un supuesto concreto del modelo, no una prueba de un mercado sin costes. La sensibilidad a costes peores ayuda a determinar si un pequeño beneficio histórico depende de una configuración optimista. [4]

La documentación de TimeSeriesSplit explica la división cronológica para evitar entrenar un modelo con el futuro y evaluarlo con el pasado. Nuestro requisito metodológico es fijar un periodo para diseñar las reglas y otro para validarlas después, antes de mirar los resultados. Si tras un fracaso se vuelven a ajustar las reglas según el periodo de validación, ese periodo ya ha influido en el desarrollo. La división cronológica por sí sola no resuelve las filtraciones de información del preprocesamiento, los objetivos solapados ni la selección repetida de variantes. Deben describirse tanto el procedimiento como los límites de los datos. [5]

Bailey y sus coautores muestran que buscar repetidamente la mejor configuración con los mismos datos aumenta el riesgo de falsos descubrimientos y de ajustarse al ruido del pasado. Nuestra regla para el informe es mostrar el historial de intentos, no solo la curva ganadora. Esto incluye cambios de parámetros, periodos y selección de instrumentos. Un resultado elegido después de muchas pruebas no tiene el mismo valor informativo que una regla predefinida y sin cambios. Su método para estimar la probabilidad de sobreajuste no se aplica en nuestro ejemplo sencillo ni se sustituye por una única división de los datos. [1]

NFA advierte que los resultados hipotéticos no reflejan operaciones reales, pueden aprovechar la retrospectiva y modelar de forma imperfecta la liquidez, el deslizamiento o el comportamiento ante una pérdida real. Por eso, nuestro informe debe conservar las versiones de datos y código, las reglas, los supuestos de ejecución, los costes incluidos y la lista completa de operaciones simuladas. La rentabilidad total necesita contexto de riesgo y una comparación en condiciones idénticas; no basta un gráfico atractivo seleccionado. Ni siquiera una implementación impecable de la prueba histórica garantiza su viabilidad o rentabilidad en un mercado futuro. [6]