Prueba walk-forward para bots de cripto: un ejemplo práctico

Pruebas veinte configuraciones de bots en el mismo gráfico y eliges la que tiene el mayor rendimiento. Ahora, sus ajustes reflejan información de todo ese período. Ejecutarla nuevamente en las mismas fechas no te aporta evidencia nueva.

La prueba walk-forward selecciona repetidamente configuraciones en una ventana de entrenamiento anterior, las congela para una ventana de prueba posterior y combina los resultados de esas ventanas posteriores. Te ayuda a analizar un proceso de selección a través de condiciones cambiantes, manteniendo los precios futuros fuera de cada decisión de selección.

Para las estrategias GRID y DCA, existe un problema contable adicional: las monedas y las posiciones abiertas pueden sobrevivir al límite de la ventana. Una prueba útil necesita una regla para esas posiciones antes de que aparezca el primer resultado.

Entrenamiento, prueba y demo en tiempo real significan cosas diferentes

La guía general de backtesting aborda las limitaciones más amplias de la simulación histórica. Walk-forward agrega una división temporal repetida; no elimina las suposiciones de ejecución, los errores de datos ni la tentación de modificar reglas después de ver los resultados.

La documentación de walk-forward de QuantConnect describe la selección de parámetros en ventanas móviles y el equilibrio entre la frecuencia de optimización. Reoptimizar con mayor frecuencia genera más decisiones y más oportunidades de ajustarse al ruido reciente.

Escribe el protocolo antes de comparar los resultados

Elige la plataforma, el intervalo de datos, la zona horaria y la configuración exacta de los candidatos. Mantén la lista de candidatos lo suficientemente pequeña como para poder revisarla. Es más fácil explicar una prueba con tres configuraciones declaradas que una búsqueda entre miles de combinaciones no documentadas.

Especifica también:

• La duración del entrenamiento y la duración de la prueba, incluyendo las marcas de tiempo exactas de los límites.
• La métrica de selección, el requisito mínimo de evidencia y la regla de desempate.
• Comisiones, deslizamiento, tamaños mínimos, redondeo y el modelo de ejecución.
• El tratamiento de las posiciones y las órdenes abiertas en cada límite.
• Los activos iniciales de la referencia y las reglas de rebalanceo.

Por ejemplo, un protocolo hipotético podría elegir el mayor retorno de entrenamiento entre tres candidatos cuya caída máxima de entrenamiento se mantenga por debajo de un límite establecido. Si ninguno califica, la estrategia mantiene posiciones en efectivo durante el siguiente mes de prueba. Define el límite de caída máxima y la alternativa antes de revisar los meses de prueba.

El límite es una restricción de selección, no una promesa sobre la caída máxima futura. Una estrategia que lo cumple en el entrenamiento puede superarlo en la prueba.

Divide las fechas sin contar un mes de prueba dos veces

Utiliza tres meses para entrenamiento y un mes para prueba en este cronograma ilustrativo de tipo rolling. Cada marca de tiempo a continuación está en UTC, y cada intervalo incluye su inicio pero excluye su final.

Las ventanas de entrenamiento se superponen. Las cuatro ventanas de prueba no lo hacen. Abril puede convertirse en datos históricos de entrenamiento para la siguiente ronda una vez que ha finalizado; no puedes usar la trayectoria de precios de abril para elegir las configuraciones que se prueban en el propio abril.

Guarda la selección realizada en cada límite. Un registro completo incluye los candidatos rechazados y sus métricas de entrenamiento, para que otra persona pueda reconstruir por qué se eligió al ganador.

Una primera ronda completa

La siguiente tabla contiene valores inventados con fines didácticos. No son resultados de backtest ni observaciones de mercado. Supón que la regla de selección escrita exige una caída máxima en el entrenamiento de no más del 10%, y luego elige el mayor retorno neto de entrenamiento. Todos los retornos son después de los costos indicados por el modelo.

El protocolo selecciona A. El mayor rendimiento del candidato B no invalida la restricción de caída máxima declarada. El candidato C permanece en el registro aunque pierda la comparación.

Congela A para abril. Supón que el ejemplo didáctico le asigna un rendimiento neto de −2 % en abril. Ese valor se registra en la prueba fuera de muestra. Cambiar a C porque habría manejado mejor abril implicaría reutilizar el mes de prueba en la decisión.

En el límite de mayo, el protocolo original vuelve a comparar todas las candidatas usando los datos de febrero a abril. Puede seleccionar C para mayo si C gana esa nueva comparación de entrenamiento. Esta es una actualización planificada que utiliza la información disponible en ese momento.

Une las ventanas de prueba posteriores en una sola trayectoria de capital

Supongamos que las siguientes selecciones y rendimientos de prueba son los siguientes. Estos valores continúan el mismo ejemplo ficticio de contabilidad y no provienen de una simulación real de estrategia.

Los valores finales subyacentes sin redondear son 980, 989.8, 960.106 y 979.30812. El rendimiento combinado es:

(1 − 0.02) × (1 + 0.01) × (1 − 0.03) × (1 + 0.02) − 1 = −2.069188%.

Sumar los cuatro porcentajes da −2%, lo cual difiere del resultado compuesto. Lleva el capital final de la ventana anterior a la siguiente y redondea solo para mostrar.

Las observaciones de fin de mes muestran una caída máxima de aproximadamente 3,99% desde los US$1,000 iniciales. La equidad intrames podría haber caído aún más, por lo que las observaciones mensuales no pueden determinar la verdadera caída máxima.

Para este ejemplo contable, asume que cada reinicio de límite está incluido en los rendimientos netos mensuales indicados. Un backtest real debe calcular esos reinicios a partir de sus posiciones y modelo de ejecución.

Decide qué sucede con el inventario abierto de GRID o DCA

Supongamos que un bot termina abril con 0.01 BTC y 400 USDT en posiciones. Con un precio hipotético de BTC en US$50,000, su patrimonio es de 900 USDT. Un nuevo mes no lo restablece al saldo original de 1,000 USDT.

Elige una política de límites coherente:

Mantener las posiciones. Transfiere las monedas, el efectivo y el estado de las posiciones reales a la siguiente ventana de prueba. Define qué efecto tiene un cambio de configuración sobre las órdenes abiertas y el inventario existente. El simulador debe admitir esa transición; un backtest nuevo iniciado con los activos predeterminados puede no representarla.

Cerrar y reiniciar. Cancela las órdenes abiertas, vende o cierra la exposición restante utilizando el modelo de ejecución declarado, descuenta los costos y comienza la siguiente ventana con el capital resultante. Si la siguiente configuración requiere inventario inicial de monedas, modela también esa adquisición y sus costos.

Cualquiera de estas políticas puede describir un proceso operativo real. Mezclarlas después de ver los resultados puede ocultar pérdidas. Mantén la misma política en la referencia cuando corresponda y muestra el efecto de una política diferente como una verificación de sensibilidad etiquetada por separado.

Revisa el modelo de ejecución y la referencia

Que una vela toque un precio límite no prueba que tu orden se haya podido ejecutar por completo. Los datos de velas también pueden ocultar si primero se alcanzó un nivel de compra o uno de venta. Configuraciones densas de GRID pueden parecer atractivas en una simulación que asume un orden intrabar favorable.

Documenta cómo el modelo maneja las ejecuciones parciales, la prioridad en la cola, el spread y los gaps. Repite el análisis con costos o ejecuciones menos favorables si la herramienta lo permite. Una conclusión que desaparece tras un pequeño cambio en el costo merece ser investigada.

Usa las mismas fechas, el mismo capital inicial y los mismos activos iniciales para la comparación. Un bot que comienza con la mitad en monedas y la mitad en efectivo no es directamente comparable con una referencia que inicia totalmente invertida, a menos que expliques esa diferencia de asignación.

La lista de verificación de resultados del backtest es útil para revisar el informe resultante. Conserva la trayectoria mensual, la actividad de trading, la exposición y los costos junto con el rendimiento total.

Mantén la evaluación final separada del diseño del protocolo

Las pruebas walk-forward repetidas pueden convertirse en entrenamiento. Si revisas los cuatro meses de prueba, modificas la lista de candidatos y vuelves a ejecutar el mismo período, el método actualizado ha utilizado información de esos meses.

Registra esa revisión y reserva el historial intacto restante o los nuevos datos futuros para la próxima evaluación. Una nueva etiqueta sobre las mismas fechas no las vuelve a hacer no vistas.

El registro descargable puede ser sencillo: una fila por ronda con las fechas de entrenamiento, la versión candidata, las métricas de selección, la configuración elegida, las fechas de prueba, el modelo de costos, la política de límites y el resultado neto de la prueba. Conserva los reportes originales y las referencias de datos junto a este registro. El ejemplo a continuación incluye la tabla ficticia como un archivo CSV exportable para practicar la contabilidad.

Sigue las verificaciones históricas con una demo fija

Practica la contabilidad del ejemplo

Descarga las cuatro filas ficticias de los meses de prueba, incluyendo el capital inicial y final. Estos son valores inventados con fines didácticos, no un informe de backtest.

Observa tu configuración en el demo de Bitsgap

Después de completar tu análisis histórico en una herramienta que permita las ventanas y la contabilidad necesarias, congela una configuración de bot compatible en el demo de Bitsgap. Registra sus activos iniciales y ajustes, luego obsérvalo con fondos virtuales y precios de mercado actuales. El demo es un ejercicio forward independiente; este flujo de trabajo no asume un optimizador walk-forward integrado.

Preguntas frecuentes

¿La prueba walk-forward previene el sobreajuste?

Reduce una fuente de sesgo en muestra al separar cada ventana de selección de su posterior prueba. Cambios repetidos en el protocolo, filtración de datos, ejecuciones poco realistas y reportes selectivos aún pueden generar resultados engañosos.

¿Cuánto deberían durar las ventanas?

No existe una duración universal. La frecuencia de trading, el historial disponible y el método de selección determinan cuánta evidencia contiene cada ventana. La división de tres meses y un mes que mostramos aquí es solo un ejemplo didáctico.

¿Puedo sumar los rendimientos de ventanas de prueba separadas?

Compón los rendimientos secuenciales cuando cada ventana comienza con el capital final de la ventana anterior. También conserva la trayectoria del capital, los costos y la exposición subyacentes; un porcentaje final por sí solo oculta diferencias importantes.

¿La demo en tiempo real es lo mismo que una prueba fuera de muestra?

Una prueba fuera de muestra histórica utiliza datos históricos posteriores en un simulador. El forward demo observa datos nuevos con fondos virtuales. Ambos tienen limitaciones y ninguno garantiza ejecuciones reales ni rendimientos futuros.