Qué es exactamente el look-ahead bias
Piensa en la información que tenía disponible tu sistema en cada instante.
Podemos representarlo así:
Decisión en t = función de la información disponible hasta t
Si llamamos al conjunto de información conocida en ese momento:
No hay problema mientras todas las variables utilizadas pertenezcan realmente a . Pero si la decisión depende de un dato de , de o de cualquier información que todavía no se había publicado, el backtest está utilizando el futuro.
El problema no es simplemente académico. Estás midiendo una estrategia que no podría haberse ejecutado de la misma forma en tiempo real.
Por eso conviene tener muy presente qué estamos haciendo cuando realizamos un backtest: no intentamos fabricar la curva histórica más atractiva posible. Intentamos reconstruir, con unas reglas y unos supuestos concretos, qué habría podido hacer realmente el sistema utilizando únicamente la información disponible en cada momento.
Un backtest es evidencia, no garantía. Y si la simulación conoce el futuro, ni siquiera tenemos una evidencia limpia.
Por qué el look-ahead bias puede hacer que una estrategia parezca mucho mejor
Supongamos que trabajas con velas de una hora.
Tu regla dice:
Comprar cuando el cierre de la vela esté por encima de una media móvil de 20 periodos.
A las 10:00 termina una vela en 1.1050 y, con ese cierre definitivo, aparece la señal.
Hasta aquí no hay ningún problema.
Ahora imagina que el backtest registra la entrada también a 1.1050, exactamente en ese cierre.
Aquí hay una pregunta que debes hacerte: ¿cuándo conociste que 1.1050 iba a ser el cierre definitivo?
Después de que la vela terminara.
Por tanto, no puedes utilizar el cierre definitivo para confirmar la señal y simultáneamente asumir que ya estabas ejecutado a ese mismo precio, salvo que estés modelando de manera explícita algún mecanismo real de ejecución que lo permita con información disponible antes del cierre.
En un modelo sencillo basado en velas, una secuencia mucho más defendible sería:
cierre de la vela t → cálculo de la señal → orden ejecutable a partir de t+1
No significa que siempre debas entrar exactamente en la apertura siguiente. Dependerá del sistema y de cómo simules órdenes y ejecución. Lo importante es que el orden temporal sea posible.
Ese pequeño desfase puede cambiar muchísimo los resultados de algunas estrategias.
Y esta es precisamente la razón por la que antes de confiar en cualquier curva de equity necesitas tener claras las reglas del sistema de trading. Si la regla no especifica cuándo se conoce la señal y cuándo puede ejecutarse, el backtest está dejando una puerta abierta a interpretaciones retrospectivas.
Dónde suele aparecer el look-ahead bias
Lo complicado es que rara vez aparece una línea de código diciendo usar_el_futuro = True.
Normalmente entra por detalles bastante más inocentes.
| Dónde aparece | Ejemplo del problema | Qué habría que revisar |
|---|---|---|
| Señal y ejecución | Usar el cierre de la vela para crear una señal y asumir una entrada anterior o al mismo cierre definitivo | Separar momento de cálculo y momento de ejecución |
| Índices de datos | Acceder accidentalmente a la vela siguiente | Comprobar shifts, índices y offsets |
| Estadísticas globales | Normalizar cada dato utilizando la media de todo el periodo histórico | Utilizar únicamente observaciones disponibles hasta ese momento |
| Indicadores | Un indicador histórico cambia cuando aparecen nuevas velas | Revisar repainting y comportamiento en tiempo real |
| Datos de mayor temporalidad | Una vela diaria completa aparece disponible dentro de velas intradía anteriores a su cierre | Trabajar con datos confirmados en el momento correcto |
| Datos macro o fundamentales | Asignar un dato al trimestre que describe aunque se publicara semanas después | Usar fecha real de disponibilidad y datos point-in-time |
| Machine learning | Entrenar o normalizar usando observaciones futuras respecto al periodo evaluado | Separar temporalmente entrenamiento, transformación y prueba |
| Backtesting manual | Ver lo que ocurre a la derecha del gráfico antes de decidir si el setup era válido | Ocultar el futuro y avanzar vela a vela |
La documentación de Freqtrade da ejemplos muy concretos de este problema: un shift() negativo puede leer velas futuras y calcular una media, un máximo o un mínimo sobre todo el dataframe puede hacer que cada señal histórica utilice datos posteriores. La propia documentación recomienda limitar esos cálculos a ventanas históricas cuando corresponda.
Aquí hay una diferencia importante entre tener datos históricos buenos y tener datos históricamente disponibles. Puedes profundizar en la preparación de datos históricos para backtesting, porque un dataset puede ser técnicamente limpio y seguir siendo incorrecto para una simulación si no respeta cuándo pudo conocerse cada dato.
El fallo más fácil de cometer: conocer el cierre antes de que exista
Quiero detenerme aquí porque es uno de los errores que más fácilmente pasan desapercibidos.
En una vela histórica ves cuatro datos perfectamente definidos:
open, high, low y close.
Pero cuando esa misma vela estaba formándose en tiempo real, las cosas eran distintas. Al abrir conocías el open. Después, el high, el low y el close iban cambiando a medida que entraban nuevas operaciones.
Solo al terminar la vela conocías sus valores definitivos.
TradingView explica precisamente esta diferencia: en una vela histórica los valores son finales, mientras que durante una vela en tiempo real el high, el low y el close todavía pueden cambiar.
Por eso una estrategia puede engañarte si históricamente actúa como si ya conociera el máximo, mínimo o cierre final de una vela antes de que esta haya terminado.
Un ejemplo extremo lo deja muy claro.
Imagina una regla hipotética que dijera: “compra en el mínimo de cada vela y vende en el máximo”.
El backtest sería maravilloso.
También sería imposible.
Nadie conoce el mínimo definitivo de una vela antes de saber que todos los precios posteriores estarán por encima de él. Y nadie conoce el máximo definitivo hasta que ya sabe que no habrá otro precio superior durante esa vela.
El look-ahead bias suele ser menos evidente que esto, pero el principio es exactamente el mismo.
Si tu sistema está pensado para Forex o CFDs, este es también un buen momento para separar el precio teórico de la ejecución que más adelante encontrarás en una plataforma. Pepperstone permite probar sus plataformas mediante cuentas demo, entre ellas MT4, MT5, TradingView y cTrader. La propia compañía advierte que una demo sirve para probar ejecución y estrategias, pero puede no reproducir exactamente las condiciones de una cuenta live. Puedes consultar también la promoción disponible mediante nuestro enlace.
Una media móvil puede ser correcta y otra utilizar el futuro
Este ejemplo me parece especialmente útil porque demuestra que el problema no depende de utilizar indicadores “malos”.
Imagina que quieres saber si el precio está por encima de su media.
Una implementación podría calcular:
donde representa todo el historial del backtest.
Si estás calculando una señal en 2019 pero la media utiliza también datos de 2020, 2021 y 2022, acabas de filtrar el futuro hacia 2019.
En cambio, una media móvil de 20 periodos calculada en t con:
solo utiliza información contemporánea y pasada.
Lo mismo ocurre con muchas transformaciones aparentemente inocentes: normalizar con la media y desviación estándar de todo el dataset, obtener el mínimo y máximo global para escalar variables o seleccionar características después de estudiar el periodo completo.
La regla mental es sencilla: si cambias los datos del futuro, el valor que tu sistema había calculado en el pasado no debería cambiar.
Ese test es mucho más potente de lo que parece.
Si modificas todas las velas posteriores al 1 de junio y de repente cambia una señal que supuestamente se generó el 15 de mayo, tienes una pista muy seria de que existe una dependencia indebida del futuro.
Repainting y look-ahead bias no son exactamente lo mismo
Aquí conviene separar conceptos.
Un indicador que repainta modifica alguno de sus valores o señales históricas cuando llega nueva información. Eso puede convertir un gráfico histórico en algo mucho más limpio de lo que vio el trader en tiempo real.
Pero repainting no es automáticamente sinónimo de look-ahead bias.
Hay comportamientos que cambian durante una vela abierta porque el precio todavía no está confirmado. Eso puede ser perfectamente normal. El problema aparece cuando tu backtest histórico termina asignando a una barra información que en ese instante todavía no era accesible.
En Pine Script, por ejemplo, TradingView advierte explícitamente que ciertas solicitudes de datos de temporalidades superiores pueden introducir look-ahead bias si permiten utilizar valores futuros en barras históricas. También explica que esos resultados no pueden reproducirse igual en tiempo real porque el futuro todavía no existe.
No necesitas convertirte en especialista en Pine Script para quedarte con lo importante: comprueba que tus indicadores entregaban en tiempo real la misma información histórica sobre la que estás testeando.
El timestamp del dato no siempre es la fecha en la que podías conocerlo
Este es uno de los matices que más mejora un backtest serio.
Supongamos que una empresa cierra su trimestre el 31 de marzo.
Eso no significa que el 31 de marzo pudieras conocer todas las cifras definitivas de ese trimestre. El reporte puede publicarse semanas más tarde.
Si tu base de datos coloca el beneficio trimestral sobre el 31 de marzo y tu estrategia empieza a utilizarlo desde ese día, has metido información futura.
Lo mismo puede suceder con datos económicos que después se revisan.
El backtest correcto necesita responder dos preguntas diferentes:
¿A qué periodo pertenece el dato?
y
¿desde qué momento pudo conocerlo realmente el mercado?
Para trading sistemático, la segunda pregunta es la que determina cuándo puedes introducir ese dato en una decisión.
Por eso los datasets point-in-time son tan importantes en sistemas que trabajan con fundamentales, macroeconomía o universos de activos que cambian. No basta con descargar hoy la versión más limpia del pasado; necesitas reconstruir qué se sabía entonces.
Un periodo Out-of-Sample también puede tener look-ahead bias
Este error merece su propia sección porque conecta directamente con lo que acabas de estudiar en el curso.
Separar In-Sample y Out-of-Sample evita que evalúes el sistema exactamente sobre el mismo periodo que utilizaste para desarrollarlo.
Pero imagina que haces esto:
Entrenas con 2018-2022 y pruebas sobre 2023.
Parece correcto.
Ahora supón que antes de hacer la separación normalizaste todas las variables utilizando la media y la desviación estándar de 2018-2023.
El conjunto de entrenamiento ya ha recibido información estadística procedente de 2023.
La frontera temporal existe en el archivo, pero no en el proceso.
Con modelos predictivos esto puede volverse especialmente sutil. La documentación de scikit-learn señala que las divisiones tradicionales aleatorias pueden ser inadecuadas para series temporales porque permiten estructuras de entrenamiento y evaluación que no respetan el orden temporal; TimeSeriesSplit está diseñado precisamente para mantener esa secuencia. La misma documentación define data leakage como la inclusión inadvertida de conocimiento del conjunto de prueba durante el entrenamiento.
No hace falta profundizar ahora en validación de modelos. Quédate con esto: la división temporal debe respetarse en toda la cadena de procesamiento, no únicamente en el último paso del backtest.
Cómo detectar look-ahead bias antes de confiar en los resultados
Yo no empezaría mirando el Sharpe, el profit factor o el drawdown. Primero comprobaría si el backtest tenía derecho a realizar las operaciones que dice haber realizado.
La mejor auditoría consiste en reconstruir la línea temporal de cada decisión. Para cada señal necesitas saber qué datos la alimentan, cuándo estuvieron disponibles, cuándo terminó su cálculo y cuál es el primer precio al que razonablemente podría ejecutarse la orden.
Una prueba especialmente buena consiste en ejecutar el sistema de dos maneras.
Primero, procesa todo el historial de una sola vez, como suele hacer un backtest vectorizado.
Después, repite el cálculo avanzando cronológicamente y permitiendo que el sistema vea únicamente los datos disponibles hasta cada fecha.
Para una estrategia causal, las señales históricas confirmadas deberían coincidir. Si la versión que conoce todo el dataframe consigue señales que desaparecen cuando simulas la llegada secuencial de los datos, toca investigar.
Freqtrade aplica una idea relacionada en su herramienta de análisis de look-ahead: ejecuta backtests adicionales y compara indicadores y señales para detectar valores que cambian cuando se restringe la información disponible. La documentación también advierte que estas pruebas pueden producir falsos positivos o falsos negativos en determinados casos, por lo que una herramienta automática ayuda, pero no sustituye entender la lógica temporal del sistema.
Y si haces el proceso visualmente, vale la pena distinguir las particularidades del backtesting manual frente al automático. En el manual, dejar visible lo que ocurrió después puede introducir más propiamente hindsight bias —sesgo retrospectivo—, pero el resultado práctico se parece mucho: terminas tomando una decisión histórica con conocimiento que el trader real no tenía.
¿Mover todas las señales una vela soluciona el problema?
No.
Puede solucionar un caso concreto: cuando una señal solo queda confirmada al cerrar la vela t pero el backtest está atribuyendo a esa misma vela un rendimiento que en realidad no habría podido capturar.
Desplazar la posición para que empiece en t+1 puede corregir esa alineación.
Pero no arregla un indicador que utiliza datos futuros, una normalización calculada con todo el dataset, cifras macro revisadas, un dato fundamental introducido antes de su publicación ni un modelo entrenado accidentalmente con información posterior.
Aplicar un shift(1) a todo sin entender por qué es parecido a tapar una luz roja del tablero con cinta adhesiva. Quizá desaparece el síntoma. El problema puede seguir ahí.
Cómo prevenirlo desde que diseñas el sistema
Para mí, una buena solución no consiste en buscar el look-ahead bias al final. Consiste en hacer difícil introducirlo desde el principio.
Esta es la auditoría temporal que usaría antes de aceptar un backtest:
- Define cuándo queda confirmada cada señal. “Durante la vela” y “al cierre de la vela” no son lo mismo.
- Define el primer momento realista de ejecución. El precio utilizado por el backtest debe existir después de que la decisión pueda tomarse.
- Comprueba cada variable. Pregunta qué fecha representa y cuándo estuvo realmente disponible.
- Evita cálculos sobre todo el dataset cuando simulan decisiones históricas. Las ventanas deben contener solo información permitida.
- Procesa temporalmente entrenamiento y validación. Cualquier normalización, selección de variables o ajuste debe respetar esa frontera.
- Compara cálculo batch contra cálculo secuencial. El pasado no debería cambiar porque hayas añadido datos futuros.
- Prueba a alterar deliberadamente el futuro. Si cambia una señal ya confirmada del pasado, investiga antes de continuar.
- No uses un buen resultado como prueba de que no hay sesgo. De hecho, cuanto más extraordinario sea el backtest, más me interesa revisar sus supuestos.
Hay una idea especialmente importante en el último punto. Un backtest aparentemente mediocre puede estar bien construido. Y uno espectacular puede estar completamente roto.
La calidad del resultado no demuestra la calidad del proceso.
Cuando más adelante empieces a estudiar cómo evaluar si un backtest es bueno, las métricas tendrán sentido solo después de haber revisado primero que el experimento era válido.
Look-ahead bias, survivorship bias y overfitting: no son el mismo problema
Es fácil mezclarlos porque los tres pueden hacer que un sistema histórico parezca mejor de lo que realmente es.
El look-ahead bias rompe el reloj: utiliza información que todavía no existía.
El survivorship bias cambia la muestra: analiza el pasado dejando fuera determinados activos o entidades que no llegaron hasta el presente. Ese es precisamente el siguiente sesgo que vamos a estudiar.
El overfitting es otra cosa: el sistema termina demasiado adaptado a las particularidades y al ruido de los datos históricos.
Pueden coexistir.
Puedes tener una estrategia sobreoptimizada que, además, utilice información futura y, además, trabaje con una muestra sesgada. Resolver uno de los problemas no limpia automáticamente los otros.
Por eso en esta parte del curso estamos desmontando los errores por separado. Si intentáramos resumirlos todos bajo “el backtest puede engañar”, sabrías la frase, pero no sabrías dónde buscar el fallo.
El forward testing ayuda a detectar diferencias, pero no limpia un backtest contaminado
Más adelante llegarás al forward testing, donde el sistema tendrá que enfrentarse a información que llega de verdad en tiempo real.
Eso puede revelar una pista muy valiosa: una estrategia que cambia radicalmente entre histórico y tiempo real merece una auditoría seria de datos, repainting, ejecución y look-ahead.
Pero tampoco caería en el extremo contrario.
Que veinte o treinta operaciones de forward test se parezcan al backtest no demuestra que todo el historial esté libre de sesgos. El forward test es otra capa de evidencia, no una máquina capaz de arreglar retrospectivamente una simulación mal construida.
Cuando llegues a esa fase, puedes utilizar una cuenta demo para comprobar cómo se comportan tus reglas sin empezar directamente con capital real. Pepperstone ofrece cuentas demo en varias plataformas y señala expresamente que las condiciones demo no tienen por qué reproducir exactamente la operativa live. Si quieres valorar esa opción para más adelante, puedes consultar Pepperstone y la promoción disponible mediante nuestro enlace. Si resides en México, revisa durante el alta qué entidad contractual te corresponde y qué condiciones se aplican, porque Pepperstone indica que su documentación legal varía según la entidad con la que se registre cada cliente.
La pregunta que debería acompañarte en cada backtest
Si solo te quedas con una regla de esta lección, que sea esta:
¿Podría haber conocido realmente esta información en el instante en que mi backtest dice que tomó la decisión?
Hazte esa pregunta sobre la vela, el indicador, el dato fundamental, la media estadística, el modelo, la temporalidad superior y el precio de ejecución.
Si la respuesta es no, el resultado posterior deja de importarme.
No intentaría arreglar primero el profit factor ni optimizar parámetros. Primero corregiría el reloj.
Y desde aquí el siguiente paso del curso es natural: aunque tu sistema no mire hacia el futuro, todavía puedes estar probándolo sobre una versión demasiado favorable del pasado. Eso es lo que veremos con el survivorship bias o sesgo de supervivencia.
