Un backtest perfectamente reproducible puede ser menos fiable que uno cuyo resultado varía un poco. La repetibilidad demuestra que puedes obtener la misma respuesta dos veces; no dice nada sobre si esa respuesta depende de una instantánea de datos arbitraria, una peculiaridad de una biblioteca o un valor predeterminado oculto.
Parece un argumento en contra de la reproducibilidad, pero no lo es. Fija la ejecución para poder explicarla. Después, varía deliberadamente los supuestos que no deberían determinar el resultado. El primer paso hace que el resultado sea auditable; el segundo te dice si significa algo.
¿Qué demuestra realmente un backtest reproducible?
Si el mismo código, los mismos datos, la misma configuración y la misma semilla aleatoria producen las mismas operaciones y métricas, has controlado una fuente importante de confusión. Puedes comparar la «mejora» de un agente con su ejecución de referencia. Puedes separar la corrección de un error de un cambio en la estructura de comisiones. Un colega puede inspeccionar el mismo registro y encontrar las mismas ejecuciones.
Pero el resultado depende de todo lo que hayas fijado. Pensemos en una estrategia cripto cuyo archivo histórico contiene velas de 1 minuto. Guardas el hash del archivo, fijas el código y obtienes un Sharpe de 1.4 en cada nueva ejecución. Si más adelante el proveedor corrige varias velas, esa reproducibilidad impecable sigue describiendo el archivo antiguo. No te dice si la señal se mantiene con el historial corregido ni si esas velas estaban disponibles en esa forma en aquel momento.
El hash es útil: hace visible la dependencia. Pero no demuestra que esa dependencia sea inocua.
Fija la ejecución; pon a prueba el hallazgo
Me gusta separar dos preguntas. ¿Podemos reconstruir esta ejecución exacta? ¿Y se mantiene la conclusión de la investigación ante cambios razonables? La primera requiere un registro inmutable; la segunda, perturbaciones controladas, de una en una.
| Qué registrar | Qué variar después | Qué puede revelar |
|---|---|---|
| Versión de los datos en bruto y sumas de comprobación | Revisión del proveedor o una segunda fuente | Dependencia de valores corregidos o específicos del proveedor |
| Commit del código y versiones de los paquetes | Implementación numéricamente equivalente | Sensibilidad al orden, al redondeo o a la biblioteca |
| Comisiones, financiación y supuestos de ejecución | Un rango de costes defendible | Si un margen estrecho depende de una ejecución inusualmente favorable |
| Universo y composición en cada momento | Reglas alternativas de elegibilidad de mercados | Dependencia de decisiones de inclusión o exclusión |
Por ejemplo, supongamos que una estrategia de futuros muestra un exceso de rentabilidad anualizado del 8% en una simulación de referencia. Vuelve a ejecutarla con costes taker un 25% más altos, desplaza la financiación hasta la siguiente liquidación observada y elimina, de una en una, las dos mayores contribuciones. No son tres formas de mejorar el modelo. Son pruebas: cada una pregunta si algún detalle plausible sostiene el resultado destacado.
Mantén cada prueba separada. Si cambias los datos, la estructura de comisiones y el momento de ejecución a la vez, un resultado peor apenas te ayudará a diagnosticar la causa. Y si una prueba no es plausible, etiquétala como escenario de estrés en vez de presentarla como el resultado más probable.
No confundas la igualdad byte por byte con la verdad numérica
Algunos cálculos son sensibles al orden. La suma en coma flotante no es asociativa, así que sumar muchos valores pequeños de P&L en un orden distinto puede cambiar los últimos dígitos. Las reducciones en paralelo, el hardware y las versiones de las bibliotecas pueden afectar al resultado exacto. Por lo general no importa; a veces, un cambio numérico minúsculo invierte un umbral, modifica una posición y lleva el resto de la simulación por otro camino.
Por eso conservaría tanto los artefactos exactos como las tolerancias para las comparaciones. Registra el historial de operaciones, no solo el Sharpe final. Compara primero las decisiones y los flujos de caja; después, las métricas dentro de una tolerancia declarada. Si una diferencia de un céntimo cambia si se envía una orden, revisa ese umbral de forma explícita.
Un registro útil de la ejecución incluye la identidad de los datos y del código, la configuración, la semilla aleatoria, el entorno de ejecución y suficientes resultados intermedios para rastrear una métrica hasta las ejecuciones y los flujos de caja. Una puntuación final por sí sola no es un artefacto de investigación reproducible.
Cuándo la variación es ruido y cuándo es un hallazgo
No todo número distinto es motivo de alarma. Una pequeña variación de una métrica por un orden de reducción diferente puede dejar intactas las operaciones. Conviene revisar una operación que cambia cerca de un umbral. Si una estrategia pierde la mayor parte de su resultado cuando un proveedor revisa un pequeño tramo del historial, eso revela algo sobre su propia fragilidad, aunque la ejecución original siga siendo perfectamente reproducible.
Quienes critican las comprobaciones de robustez tienen razón en algo: es fácil seguir cambiando los supuestos hasta que una estrategia preferida parece resistente, o rechazar un resultado sólido porque falla en un escenario deliberadamente extremo. Define de antemano las variaciones plausibles, informa del conjunto completo y distingue las alternativas habituales de los escenarios de estrés. Después, conserva la referencia para que otra persona investigadora pueda reproducir exactamente lo que viste.
La reproducibilidad te da un punto de partida fiable. La pregunta útil viene después: ¿qué partes de la respuesta se mantienen cuando el entorno de esa ejecución cambia de formas razonablemente previsibles?
← Todos los artículos
