Sesgo de anticipación
Entiende cómo se filtra información futura en los backtests de estrategias de trading, por qué infla el rendimiento y cómo evitarlo.
El sesgo de anticipación (look-ahead bias) se produce cuando una simulación histórica toma una decisión usando información que no habría estado disponible en ese instante. A la estrategia se le permite, en la práctica, ver el futuro, de modo que su rendimiento simulado no puede reproducirse en trading real.
La fuga puede ser evidente, como leer el precio de mañana, o sutil, como usar una vela completa antes de que esa vela haya cerrado.
Un ejemplo sencillo
Imagina una estrategia evaluada a las 10:03 con velas de cinco minutos. La vela que cubre de 10:00 a 10:05 aún no tiene cierre, máximo, mínimo ni volumen definitivos. Si el backtest le proporciona la vela completa de las 10:05 y deja que la estrategia opere a las 10:03, la decisión contiene dos minutos de información futura del mercado.
El código puede parecer ordenado cronológicamente mientras los datos asignados a cada marca de tiempo no lo están. Por eso, prevenir el sesgo de anticipación exige revisar tanto la lógica de la estrategia como la semántica del conjunto de datos.
Fuentes habituales
Operar con un valor de cierre demasiado pronto
Una estrategia calcula un indicador a partir del cierre definitivo de una barra y asume que puede ejecutar una orden a ese mismo cierre. En un mercado real, el valor final solo se conoce cuando termina el intervalo; el siguiente precio ejecutable puede ser ya distinto.
Desplazamientos negativos o filas futuras
El código de preparación de datos etiqueta una fila con una rentabilidad futura o desplaza una columna hacia atrás. Esa etiqueta puede ser adecuada para entrenar un modelo, pero nunca debe aparecer entre las variables disponibles para la estrategia en el momento de decidir.
Normalización sobre la muestra completa
La media, la varianza, el mínimo o el máximo se calculan sobre todo el periodo de prueba y luego se usan para normalizar observaciones anteriores. La transformación incorpora conocimiento de valores que todavía no se habían producido. Ajusta las transformaciones sobre la ventana de entrenamiento permitida y arrastra hacia delante solo esos parámetros ajustados.
Conjuntos de datos desalineados
Unir velas, fundamentales, tasas de financiación o indicadores de un marco temporal superior por su fecha nominal puede hacer que un valor aparezca antes de haberse publicado o completado realmente. Alinea los datos por el momento en que estuvieron disponibles, no solo por el periodo que describen.
Información histórica revisada
Algunos conjuntos de datos se corrigen o revisan después de su primera publicación. Un backtest que use el valor final revisado asume información que una estrategia en vivo no habría visto. Los conjuntos de datos point-in-time conservan lo que se sabía en cada fecha.
Seleccionar con rendimiento futuro
Elegir una estrategia o un conjunto de parámetros porque rinden mejor a lo largo de todo el periodo del informe no es una fuga de datos a nivel de fila, pero crea la misma ventaja informativa a nivel de investigación. Reserva un periodo de validación intacto para la evaluación final.
Cómo prevenirlo
Define la disponibilidad de cada evento
Para cada entrada, registra cuándo pasa a ser utilizable por la estrategia. La marca de tiempo de una vela puede representar su hora de apertura o su hora de cierre; esas interpretaciones no son intercambiables.
Procesa los eventos de forma monótona
El reloj de la simulación solo debe avanzar. Los indicadores y el estado de la estrategia deben actualizarse a partir del evento actual y del estado pasado retenido, nunca a partir de una colección que ya contenga eventos posteriores.
Separa el momento de la señal del de la ejecución
Indica explícitamente si una señal calculada al cierre de un intervalo puede ejecutarse a ese cierre, en la apertura del intervalo siguiente o mediante un modelo de ejecución más detallado. Elige la hipótesis antes de mirar qué versión produce mejor rentabilidad.
Ajusta las transformaciones dentro del límite de entrenamiento
Cualquier umbral aprendido, escalador, selección de variables o elección de parámetros debe derivarse únicamente de sus datos de entrenamiento. Reajústalo cuando avance una ventana walk-forward en lugar de calcularlo una sola vez sobre todo el histórico.
Añade pruebas de causalidad
Una prueba útil trunca el conjunto de datos en un instante dado y verifica que todas las señales anteriores a ese corte permanecen iguales cuando se añaden datos posteriores. Si las señales históricas cambian tras añadir filas futuras, la canalización está filtrando información o recalculando mal el estado pasado.
Revisa los resultados sospechosamente suaves
Tasas de acierto muy altas, ejecuciones sistemáticamente cerca de extremos locales, drawdowns inusualmente pequeños o una gran caída del rendimiento al retrasar la ejecución un solo evento son motivos para examinar con cuidado los tiempos. Son pistas, no pruebas, pero a menudo revelan un acceso irreal a la información.
El sesgo de anticipación en los experimentos de QTSurfer
Mantén la revisión de la estrategia, la identidad de los datos, el intervalo de eventos y la configuración de ejecución unidos a cada resultado. Cuando el código de la estrategia consuma actualizaciones de ventanas o de indicadores, confirma qué evento completó el valor y qué precio puede usar de forma realista una señal emitida desde ese callback.
Compara un resultado sospechoso con una ejecución deliberadamente retrasada o con un corte de datos más estricto. El objetivo no es conservar el resultado atractivo; es establecer que cada decisión pudo tomarse con la información disponible en ese momento.
Lee Backtesting para el diseño general del experimento y la guía de backtesting de QTSurfer para el flujo de trabajo del producto.
La pregunta clave
Para cada valor que use la estrategia, pregúntate: ¿cuándo habría estado disponible por primera vez este valor exacto en el sistema en vivo? Si la decisión simulada ocurre antes, el backtest ha mirado hacia delante.