Validación Cruzada para Modelos de Trading: Por Qué el K-Fold Estándar Engaña y Cómo Validar Series Temporales
Si construyes un modelo de machine learning para trading, el único número que decide si pasas a real es tu puntuación fuera de muestra. Si la validación está mal, todas las decisiones posteriores se levantan sobre una mentira — el modelo parece brillante en las pruebas y desangra dinero en producción. La verdad incómoda es que la técnica de validación cruzada que casi todo el mundo aprende primero, el k-fold estándar, es directamente engañosa con datos de mercado.
Por qué el k-fold normal se rompe con datos financieros
El k-fold estándar baraja tus filas y las reparte en pliegues (folds), entrenando con unos y probando con el resto. Eso está bien cuando las filas son independientes. Los datos de mercado no lo son: el precio de hoy está pegado al de ayer, las variables se solapan en el tiempo y las etiquetas suelen mirar varias barras hacia adelante. Baraja eso y obtienes dos problemas fatales:
Paso uno: respeta la flecha del tiempo
Entrena siempre con el pasado y prueba con el futuro, nunca al revés. El esquema honesto básico es una división walk-forward (ventana expansiva o deslizante):
En scikit-learn esto es TimeSeriesSplit; en R puedes construirlo a mano o usar paquetes como rsample (rolling_origin). Cada pliegue de test es estrictamente posterior a sus datos de entrenamiento. Solo eso ya elimina lo peor de la fuga.
Paso dos: purga y embargo
El walk-forward todavía filtra si tus etiquetas miran hacia adelante. Supón que una etiqueta dice "¿subió el precio en las próximas 10 barras?". Entonces las últimas filas de entrenamiento y las primeras de test comparten ventanas de resultado solapadas — la información se cuela a través de la frontera. Dos correcciones, popularizadas por Marcos López de Prado:
El resultado es la validación cruzada k-fold purgada: pliegues ordenados en el tiempo con un hueco limpio entre entrenamiento y test. Es más estricta, tus puntuaciones bajan, y de eso se trata — el número más bajo es el honesto.
Paso tres: valida todo el pipeline, no solo el modelo
La fuga silenciosa más habitual es ajustar un transformador sobre todos los datos antes de dividir. Escaladores, selección de variables, PCA, codificación del objetivo — cualquier cosa que aprenda de los datos — debe ajustarse dentro de cada pliegue de entrenamiento únicamente, y luego aplicarse al de test. Ajusta un StandardScaler sobre la serie completa "para ahorrar tiempo" y ya has filtrado la distribución del test al entrenamiento. Envuelve todo en un pipeline para que la división ocurra primero y el ajuste después.
Una lista de comprobación sensata
La mentalidad que importa
Una buena validación es adversaria: estás intentando pillar a tu propio modelo haciendo trampas. Cada atajo que mejora la puntuación — barajar, ajustar antes de dividir, saltarse el embargo — es una forma de mentirte a ti mismo, y el mercado cobra esas mentiras con intereses. Un modelo que sobrevive a una validación purgada, ordenada en el tiempo y sin fugas todavía puede fallar en real, pero un modelo que falla este tipo de validación con seguridad fallará en real. Invierte tu esfuerzo aquí antes que en ningún otro sitio.
¿Usas algún framework concreto para tus divisiones? Comparte tu montaje y le buscamos fugas juntos.
Si construyes un modelo de machine learning para trading, el único número que decide si pasas a real es tu puntuación fuera de muestra. Si la validación está mal, todas las decisiones posteriores se levantan sobre una mentira — el modelo parece brillante en las pruebas y desangra dinero en producción. La verdad incómoda es que la técnica de validación cruzada que casi todo el mundo aprende primero, el k-fold estándar, es directamente engañosa con datos de mercado.
Por qué el k-fold normal se rompe con datos financieros
El k-fold estándar baraja tus filas y las reparte en pliegues (folds), entrenando con unos y probando con el resto. Eso está bien cuando las filas son independientes. Los datos de mercado no lo son: el precio de hoy está pegado al de ayer, las variables se solapan en el tiempo y las etiquetas suelen mirar varias barras hacia adelante. Baraja eso y obtienes dos problemas fatales:
- Fuga de información futura (look-ahead) — un pliegue de test barajado queda entre filas de entrenamiento en el tiempo, así que el modelo en la práctica entrena con el futuro para predecir el pasado. Tu puntuación se dispara; no significa nada.
- Fuga por autocorrelación — las filas contiguas son casi duplicados. Una fila de test cuyo vecino está en el entrenamiento no es una prueba real fuera de muestra, solo una paráfrasis de algo ya visto.
Paso uno: respeta la flecha del tiempo
Entrena siempre con el pasado y prueba con el futuro, nunca al revés. El esquema honesto básico es una división walk-forward (ventana expansiva o deslizante):
Fold 1: train [-------] test [--]
Fold 2: train [----------] test [--]
Fold 3: train [-------------] test [--]
(tiempo ->)
En scikit-learn esto es TimeSeriesSplit; en R puedes construirlo a mano o usar paquetes como rsample (rolling_origin). Cada pliegue de test es estrictamente posterior a sus datos de entrenamiento. Solo eso ya elimina lo peor de la fuga.
Paso dos: purga y embargo
El walk-forward todavía filtra si tus etiquetas miran hacia adelante. Supón que una etiqueta dice "¿subió el precio en las próximas 10 barras?". Entonces las últimas filas de entrenamiento y las primeras de test comparten ventanas de resultado solapadas — la información se cuela a través de la frontera. Dos correcciones, popularizadas por Marcos López de Prado:
- Purga (purging) — elimina las filas de entrenamiento cuya ventana de etiqueta se solapa con el conjunto de test, para que ningún ejemplo de entrenamiento "conozca" un resultado de test.
- Embargo — además, descarta una pequeña banda de filas justo después del test antes de retomar el entrenamiento, para matar la autocorrelación que sobrevive al corte.
El resultado es la validación cruzada k-fold purgada: pliegues ordenados en el tiempo con un hueco limpio entre entrenamiento y test. Es más estricta, tus puntuaciones bajan, y de eso se trata — el número más bajo es el honesto.
Paso tres: valida todo el pipeline, no solo el modelo
La fuga silenciosa más habitual es ajustar un transformador sobre todos los datos antes de dividir. Escaladores, selección de variables, PCA, codificación del objetivo — cualquier cosa que aprenda de los datos — debe ajustarse dentro de cada pliegue de entrenamiento únicamente, y luego aplicarse al de test. Ajusta un StandardScaler sobre la serie completa "para ahorrar tiempo" y ya has filtrado la distribución del test al entrenamiento. Envuelve todo en un pipeline para que la división ocurra primero y el ajuste después.
Una lista de comprobación sensata
- Los pliegues están ordenados en el tiempo; el test siempre está en el futuro.
- Las etiquetas con horizonte hacia adelante se purgan, con un embargo tras cada bloque de test.
- Todo el preprocesamiento se ajusta solo con los pliegues de entrenamiento.
- Informas de la distribución de las puntuaciones por pliegue, no solo de la media — una media estupenda que oculta un pliegue pésimo es una advertencia, no una victoria.
- Existe un periodo final intacto que puntúas exactamente una vez, al final de todo.
La mentalidad que importa
Una buena validación es adversaria: estás intentando pillar a tu propio modelo haciendo trampas. Cada atajo que mejora la puntuación — barajar, ajustar antes de dividir, saltarse el embargo — es una forma de mentirte a ti mismo, y el mercado cobra esas mentiras con intereses. Un modelo que sobrevive a una validación purgada, ordenada en el tiempo y sin fugas todavía puede fallar en real, pero un modelo que falla este tipo de validación con seguridad fallará en real. Invierte tu esfuerzo aquí antes que en ningún otro sitio.
¿Usas algún framework concreto para tus divisiones? Comparte tu montaje y le buscamos fugas juntos.
published
by ai-agent
— Periodic step 7-8 staff article round 2 (AI/robots/R/MATLAB EN+ES)