A quién va dirigido — A quien desarrolla o evalúa estrategias sistemáticas y necesita distinguir una medida obtenida sobre datos realmente no consultados de una simple continuación del proceso de optimización.
Una prueba out-of-sample (OOS) evalúa una especificación ya definida sobre datos que no contribuyeron a elegir sus reglas, variables, parámetros o criterios de selección. Su función es medir la capacidad de generalizar más allá de la muestra de desarrollo. No demuestra que el comportamiento vaya a continuar en el futuro: reduce una forma concreta de optimismo, siempre que la separación sea real.
La pureza del OOS se refiere al flujo de decisiones, no solo a una columna de fechas. Si el resultado de la prueba induce a modificar el modelo, ese segmento ya es información de desarrollo. La versión modificada necesita una nueva prueba no consultada; no es correcto retocar la estrategia y seguir llamando out-of-sample a los mismos datos.
In-sample, validación, prueba y forward no son sinónimos
| Bloque | Uso permitido | Qué lo contamina |
|---|---|---|
| Training / in-sample | Estimación y ajuste de parámetros | No está destinado a una evaluación imparcial |
| Validación | Elección entre especificaciones e hiperparámetros | Las consultas repetidas están permitidas, pero deben contabilizarse |
| Prueba final OOS | Evaluación conclusiva de una especificación congelada | Cualquier modificación guiada por su resultado |
| Walk-forward | Secuencia de ajustes y pruebas ordenados en el tiempo | Reglas rediseñadas después de ver toda la secuencia |
| Forward o paper test | Observación posterior en el tiempo, a menudo sin dinero real | Diferencias entre fills simulados, operativa y capital live |
Un OOS puede ser un holdout final, una ventana de un procedimiento rolling o una parte de una validación cruzada temporal. El nombre no especifica por sí solo el diseño. Deben documentarse el tamaño de las ventanas, el orden, el horizonte de las labels, la frecuencia de refit y el número total de decisiones tomadas a partir de los resultados.
El split no tiene una proporción universal
No existe una regla general como «70% para desarrollo y 30% para prueba». La elección depende de cantidad y calidad de los datos, frecuencia, horizonte de previsión, estabilidad del proceso, número de parámetros y necesidad de observar regímenes diferentes. Una prueba muy larga reduce los datos de desarrollo; una demasiado corta puede producir estimaciones imprecisas o representar un solo régimen.
En las series temporales, el orden importa. Un split aleatorio estándar puede introducir en training observaciones estrechamente vinculadas a las del test. Sin embargo, no debe declararse universalmente inválido: su idoneidad depende del problema y de los supuestos sobre dependencia. En finanzas, la autocorrelación, las features construidas con ventanas y las labels solapadas suelen exigir splits bloqueados o rolling, o técnicas específicas de separación.
Purging y embargo
Cuando una label utiliza un intervalo futuro —por ejemplo, el rendimiento entre la apertura y el cierre de una posición— una observación de training puede compartir parte de ese intervalo informativo con una observación de test. El purging elimina del training las observaciones cuyos intervalos de label se solapan con el test. El embargo añade un buffer temporal para reducir dependencias residuales alrededor de la frontera.
El buffer debe justificarse por el horizonte, la disponibilidad de los datos y la estructura de dependencia; un porcentaje fijo no es un principio general. Purging y embargo no corrigen survivorship bias, datos revisados, costes poco realistas, pruebas múltiples ni cambios de régimen.
Protocolo de validación
- Definir la unidad informativa. Especificar timestamps de las features, inicio y fin de la label, frecuencia y posibles solapamientos.
- Separar funciones. Asignar datos a training, validación y test antes de observar las métricas finales; no llamar «test» al bloque usado para tuning.
- Elegir el diseño. Justificar holdout, rolling origin, ventana expanding o rolling, validación cruzada bloqueada y posibles purge o embargo.
- Congelar el pipeline. Versionar transformaciones, features, universo, hiperparámetros, costes, benchmark y regla de decisión.
- Registrar todos los intentos. Contar modelos, semillas, periodos, filtros y métricas consultados, no solo la variante publicada.
- Ejecutar la prueba final. Calcular métricas netas, incertidumbre y comparación con el benchmark sin reabrir la selección.
- Clasificar el resultado. «No concluyente», «incompatible con la hipótesis» y «compatible con una verificación adicional» son juicios más correctos que un pass/fail basado en una regla universal.
- Documentar cada reutilización. Si el resultado orienta un cambio, trasladar formalmente ese periodo al patrimonio de desarrollo.
Walk-forward y prueba final
En el walk-forward, el modelo se estima utilizando solo datos anteriores a cada ventana de prueba. El procedimiento imita refits sucesivos y muestra cómo varía el resultado en el tiempo. Debe declarar si la ventana de training crece o se desplaza, el paso de avance, el horizonte probado y la cadencia de recalibración.
La concatenación de las ventanas no constituye automáticamente un track record puro. Si, después de observar el conjunto, se cambian la familia del modelo, las features, las ventanas o las reglas de parada, toda la secuencia ha participado en el desarrollo. Cuando sea posible, un procedimiento de selección interna puede acompañarse de un holdout final externo nunca consultado.
Ejemplo ilustrativo
Ejemplo declarado como ilustrativo — Un modelo mensual se reestima con una ventana móvil y se evalúa durante el mes siguiente. Las labels de las posiciones pueden extenderse varios días: antes de cada prueba se eliminan del training las que intersectan su intervalo. El investigador compara cuatro familias de modelos en la validación interna y registra las cuatro. Un bloque temporal posterior permanece sellado para la decisión final. Las duraciones forman parte del ejemplo, no son proporciones recomendadas.
El resultado debe mostrarse con dispersión entre ventanas, costes y exposiciones, no solo como métrica agregada. Una media favorable puede ocultar que casi todo el valor procede de un único periodo.
Limitaciones
- Un solo holdout puede estar muy influido por el régimen que contiene.
- Varias reservas de datos no crean nueva información independiente.
- La no estacionariedad puede hacer poco representativos tanto el training como el test.
- El propio diseño de validación es una elección de investigación y debe entrar en el registro de intentos.
- OOS, purging y walk-forward no sustituyen datos point-in-time, simulación causal, costes plausibles ni control del data snooping.
Fuentes
- Leonard J. Tashman, Out-of-sample tests of forecasting accuracy: an analysis and review, International Journal of Forecasting, 2000 — rolling origin, recalibración y múltiples periodos de prueba.
- Christoph Bergmeir y José M. Benítez, On the use of cross-validation for time series predictor evaluation, Information Sciences, 2012 — diseños de validación cruzada para predictores temporales.
- Christoph Bergmeir, Rob J. Hyndman y Bonsoo Koo, A note on the validity of cross-validation for evaluating autoregressive time series prediction, 2018 — condiciones bajo las que la validación cruzada puede ser válida para series autorregresivas.
- David H. Bailey et al., The Probability of Backtest Overfitting — selección entre configuraciones y límites del holdout simple en backtests de inversión.
- Marcos López de Prado, Advances in Financial Machine Learning — índice oficial de Wiley, Wiley, 2018 — referencia monográfica para purged K-fold y embargo; no se cita aquí como artículo revisado por pares.