La cross-validation puede hacer que una estrategia de trading parezca testeada cuando el test set ya ha sido tocado. La filtración casi nunca es obvia: el modelo entrena con muestras cuyos resultados se solapan con las barras futuras usadas para juzgar la muestra de test.
Eso importa porque las etiquetas de trading no son etiquetas limpias de aula. Un trade abierto ahora puede juzgarse por lo que ocurre durante la próxima hora, día o semana. Si una muestra cercana de entrenamiento usa parte de esa misma ventana futura, el backtest no es plenamente out-of-sample. Solo lleva bata de laboratorio.
Qué debería hacer la cross-validation
La cross-validation es una forma de testear si un modelo sobrevive a datos con los que no entrenó. Divides los datos en folds, entrenas con algunos folds, testeas con otro fold, luego rotas el fold de test y promedias los resultados.
En problemas normales de machine learning, eso puede funcionar bien. La foto de un gato en una fila no suele depender de la fila siguiente. Una serie de precios sí. Los mercados están ordenados en el tiempo, y las etiquetas de trading a menudo usan barras futuras para decidir si un setup ganó, perdió, expiró o tocó un umbral de drawdown.
Esa es la diferencia entre validación útil y una máquina ordenada de leakage.
Dónde filtra la cross-validation en trading
La cross-validation en trading filtra cuando el fold de entrenamiento contiene información conectada con el camino futuro del fold de test. La causa más común son las etiquetas solapadas.
Imagina un sistema que entra el lunes y etiqueta el trade por lo que ocurre durante las tres sesiones siguientes. Una muestra de test que empieza el miércoles puede compartir parte de su ventana de resultado con una muestra de entrenamiento del lunes o martes. Al modelo no se le enseña exactamente el trade del miércoles, pero sí entrena con datos que incluyen el mismo movimiento de mercado.
Eso basta para embellecer el resultado. La filtración puede aparecer por la etiqueta objetivo, por indicadores rolling, por filtros de régimen o por trades repetidos de un mismo evento de mercado.
| Fuente de filtración | Qué sale mal | Tratamiento más limpio |
|---|---|---|
| Etiquetas de trade solapadas | Muestras de train y test dependen de las mismas barras futuras | Quitar muestras de entrenamiento que se solapan con la ventana de test |
| Indicadores rolling | Una feature puede calcularse con datos demasiado cercanos al fold de test | Construir features solo con información disponible en el momento de decisión |
| Entradas agrupadas | Varios trades son versiones de un mismo evento de mercado | Tratar el grupo como una exposición o separarlo por tiempo |
| Mezcla aleatoria de filas | Se destruye el orden temporal | Usar splits conscientes del tiempo |
Es un primo de look-ahead bias, pero más sutil. El código puede no mirar explícitamente el cierre de mañana. Puede simplemente entrenar demasiado cerca de la muestra de test.
Purging y embargo, en lenguaje claro
Purging elimina muestras de entrenamiento cuya ventana de resultado se solapa con el fold de test. Embargo añade un pequeño buffer sin entrenamiento después del fold de test para que las muestras adyacentes no filtren información de vuelta al entrenamiento.
Purging maneja el solapamiento directo. Si un trade de entrenamiento y un trade de test se juzgan usando algunas de las mismas barras futuras, el trade de entrenamiento se elimina para ese fold.
Embargo maneja el borde después del fold de test. Aunque las etiquetas no se solapen directamente, los mercados pueden seguir conectados en serie. Un buffer corto reduce la probabilidad de que el training set aprenda el aftermath inmediato del evento de test.
El flujo es simple:
1. Define la ventana de etiqueta de cada trade o setup.
2. Elige un fold de test en orden temporal.
3. Purga cualquier muestra de entrenamiento cuya ventana de etiqueta se solape con ese fold de test.
4. Aplica un embargo como buffer después del fold de test.
5. Entrena solo con lo que queda.El objetivo no es pulcritud académica. El objetivo es mantener honesto lo "no visto".
Por qué debería importarle a un trader de prop firm
A un trader de prop firm le importa porque una puntuación de validación contaminada puede subestimar el riesgo de drawdown y exagerar la estabilidad. Una estrategia que parece robusta en una validación contaminada puede ser el mismo sistema overfit con mejor papeleo.
El daño es práctico. Si el leakage hace que el modelo parezca más suave de lo que es, el trader puede aumentar demasiado el sizing, aceptar demasiados trades correlacionados o confiar en una regla que solo funcionó porque el test estaba contaminado. Así es como un sistema puede verse bien en un informe y aun así fallar un límite de pérdida diaria o pérdida máxima.
Esto se conecta directamente con out-of-sample testing. Un único test reservado es útil, pero solo si la sección reservada no influyó en la selección del modelo. La cross-validation puede añadir evidencia, pero solo cuando los folds están construidos para series temporales.
Checklist práctica de auditoría
Un informe útil de validación en trading debería explicar cómo evitó leakage. Si no puede, asume que la puntuación es más blanda de lo que parece.
Haz estas preguntas antes de confiar en la curva:
| Pregunta | Qué quieres ver |
|---|---|
| ¿Los splits respetan el tiempo? | El entrenamiento ocurre antes, o claramente lejos, del fold de test |
| ¿Están definidas las ventanas de etiqueta? | Cada trade tiene inicio, momento de decisión y ventana de resultado |
| ¿Se usó purging? | Se eliminaron ventanas de resultado solapadas entre train y test |
| ¿Se usó embargo? | Un buffer impide que muestras posteriores al test filtren información |
| ¿Se incluyeron costes? | Spread, comisión, slippage y swap se descuentan antes de juzgar el edge |
| ¿El hold-out final quedó intacto? | La selección del modelo terminó antes de la última revisión out-of-sample |
La última línea importa. La cross-validation ayuda a elegir y estresar un método. No debería reemplazar un hold-out final intacto. Si los mismos datos ayudan a elegir el modelo y coronar al ganador, el resultado sigue teniendo selection bias.
Dónde realbacktesting pone el límite
realbacktesting es un estudio de software de trading para cTrader, construido para hacer los backtests reproducibles en vez de meramente impresionantes. El método público usa ejecución intrabar M1, barras M1 de broker de cTrader + spread medido por tick de 2021-2026, spread real por símbolo, comisión real, swap, 1 bps de slippage y una base modelo de 80,000 EUR. El camino de drawdown se comprueba contra un 30% out-of-sample hold-out. El método está explicado en la página de metodología.
Esos detalles no garantizan un resultado en real. Hacen que el test sea más difícil de maquillar. El trader aún debe re-ejecutar el backtest en su propio cTrader, con los costes de su broker, y revisar si el comportamiento encaja con las restricciones de la cuenta.
Para sistemas de prop firm, la pregunta de validación no es "¿la curva se ve bien?" Es si la estrategia sobrevive las reglas bajo las que realmente va a operar. El contexto de fondeo está explicado en la página de fondeo, y el estándar más amplio de prueba está cubierto en cómo verificar un backtest de cTrader.
Preguntas frecuentes
¿La cross-validation normal es válida para trading?
La cross-validation normal suele ser demasiado optimista para trading porque los folds aleatorios pueden mezclar periodos y solapar ventanas de resultado. Trading necesita validación consciente del tiempo, y las etiquetas solapadas necesitan purging.
¿Qué es purged cross-validation?
Purged cross-validation elimina muestras de entrenamiento cuyas ventanas de resultado se solapan con el fold de test. Está diseñada para impedir que el modelo aprenda información conectada con las mismas barras futuras usadas para puntuar el test set.
¿Qué es un embargo en validación de trading?
Un embargo es un buffer sin entrenamiento colocado después del fold de test. Reduce leakage desde muestras que ocurren justo después del periodo de test y que todavía pueden estar conectadas con el mismo evento de mercado.
¿Purged cross-validation reemplaza el out-of-sample testing?
No. Purged cross-validation mejora el proceso de validación, pero un hold-out final out-of-sample intacto sigue siendo la revisión final más limpia. El modelo no debería tener oportunidades repetidas de adaptarse a ese segmento final.
La idea que queda
Si el fold de test no fue genuinamente no visto, la puntuación de validación no es evidencia. Es una forma más pulida de memorizar el pasado.