Blog

Los backtests multi-timeframe filtran el futuro a través de una vela de temporalidad superior en formación, cuyo cierre final aún no existe. No se puede llegar a la confianza mediante revisión de código — hay que probarlo. Reproducimos exactamente la regla de vela cerrada del bot en vivo, y luego demostramos que no hay filtración con una sonda de futuro desplazado: perturbamos cada vela futura y verificamos que cada señal y operación pasada permanece idéntica bit a bit. 25/25 comprobaciones de paridad superadas, y la sonda tiene mordiente.

La ventaja de la GPU sobre la CPU crece con el tamaño del batch — de 54.5x con un combo por llamada hasta 359.6x con 61 en nuestro precómputo de indicadores multi-timeframe — porque un sweep pequeño no puede amortizar el overhead de lanzamiento de kernels y de transferencia. Descomponemos un titular de 167x en una victoria algorítmica de 27x que también ayuda a la CPU y una victoria de hardware de 6.2x, mostramos que la ventaja real de la GPU frente a la mejor CPU es solo 3.2x en single-timeframe y 6.2x en multi, y damos una guía de decisión sobre cuán ancho debe ser un sweep antes de que valga la pena apostar por una GPU.

La GPU Metal de Apple no tiene float64. Porta un backtest vectorizado a ella de forma ingenua y la tentadora WMA por suma de prefijos desborda fp32 —error relativo máximo de 211×— y aun así se ejecuta y devuelve números de aspecto plausible. La solución no es más precisión; es una formulación distinta: una convolución directa por ventanas, segura en fp32 hasta 8×10⁻⁷ y 55.9× más rápida que numba de un solo hilo. La trampa, la aritmética y cómo demostrar que no caíste en ella.

La búsqueda de profundización progresiva / multi-fidelidad (ASHA, eliminación sucesiva, Hyperband) filtra miles de configuraciones de forma barata y solo asciende a los supervivientes a la evaluación completa y costosa. Es una aceleración genuina, pero colapsa en silencio si la clasificación de baja fidelidad no coincide con la de alta fidelidad. Medimos la correlación de rango entre pliegues: en un solo pliegue, la ρ de Spearman puede ser 0.03 (clasifica casi al azar), subiendo a 0.43, 0.67, 0.78, 0.91 a medida que se acumulan los pliegues. La solución es una puerta obligatoria: medir primero ρ(barato, completo) y elevar automáticamente la fidelidad mínima hasta el primer escalón donde ρ ≥ 0.5.

Cuando un backtest es barato, un Sobol scrambled y tonto gana en throughput puro — los samplers inteligentes (TPE, CMA-ES, ASHA) pagan un impuesto de ask/tell en Python que los frena 20 veces, por lo que evalúan muchos menos puntos al mismo wall-clock y pierden. Haz que cada evaluación sea costosa (multi-TF + folds de walk-forward) y el cruce se invierte. Medimos ambos regímenes, y por qué la fidelidad de rank por fold (ρ@1 subiendo 0.03→0.43) es la condición previa para que el pruning valga la pena.

No todos los parámetros cuestan lo mismo al buscar. Los parámetros de una estrategia se dividen en un eje costoso (indicadores, recalculados sobre toda la serie) y un eje barato (umbrales de decisión, un recorrido O(n) sobre señales precalculadas). Como los indicadores son invariantes a los umbrales, los calculas una vez y barres miles de configuraciones de umbrales a ~5.600 cfg/s, aproximadamente 1.600 veces más barato que recalcular por configuración. Una re-tasación de la maldición de la dimensionalidad.

Comparamos ocho motores de backtest en un mismo barrido de parámetros idéntico: 150k barras, 80 combinaciones de cruce de HMA, con la paridad de número de operaciones fijada en 2707. Dos de los frameworks orientados a eventos más populares resultaron más lentos que un bucle de pandas escrito a mano, mientras que un motor vectorizado/compilado ejecutó el mismo trabajo unas 13,000× más rápido. Un estudio de la sobrecarga por barra que las librerías populares nunca fueron diseñadas para amortizar.