Backtesting frente a trading real: por qué difieren los resultados
Por qué el trading real difiere del backtest: ejecuciones, slippage, comisiones, latencia, calidad de datos, sesgo de anticipación y cambios de régimen, y cómo testear bien.
Casi todo trader que ha construido una estrategia ha vivido este momento: el backtest se ve genial y, tras unas semanas operando en real, el panorama es completamente distinto. Eso no significa necesariamente que la estrategia sea mala. Significa que un backtest es un modelo de la realidad, y todo modelo tiene supuestos. Este artículo repasa las principales fuentes de esa brecha y cómo reducirla.
Qué mide realmente un backtest
Un backtest aplica las reglas de una estrategia sobre datos históricos de precio y calcula qué habría pasado si las hubieras operado. En TradingView, por ejemplo, el Strategy Tester lo hace con estrategias escritas en Pine Script. El resultado es una estimación, no una grabación del pasado.
El problema es que un backtest solo "sabe" lo que hay en sus datos. Si los datos son velas de cinco minutos, no sabe qué pasó dentro de la vela. Si no configuraste comisiones, asume que operar es gratis. Si no configuraste slippage, asume que cada orden se ejecuta exactamente al precio que querías. Cada uno de esos supuestos infla el resultado.
Ejecuciones y slippage
Para la mayoría de los traders, esta es la mayor fuente de la brecha.
- Las órdenes a mercado se ejecutan al siguiente precio disponible, no al precio del gráfico en el momento de la decisión. En momentos volátiles, como la publicación del informe de empleo, la diferencia puede ser de varios ticks.
- Las órdenes limitadas garantizan el precio, pero no la ejecución. Muchos backtests asumen que si el precio tocó el nivel, la orden se ejecutó. En la realidad podías estar al final de la cola y no entrar nunca, a menudo justo en las mejores operaciones.
- Las órdenes stop se convierten en órdenes a mercado al activarse, así que pueden ejecutarse lejos del nivel.
Un ejemplo hipotético: una estrategia hace 400 operaciones al año en MNQ. Si cada operación sufre de media un tick de slippage a la entrada y otro a la salida, eso suma 800 ticks al año que nunca aparecieron en el backtest. Para una estrategia con una ventaja pequeña, eso puede ser toda la diferencia. Más en slippage y costes de ejecución.
Comisiones, tasas de mercado y costes de datos
Cada operación de futuros tiene costes: comisión del broker, tasas del mercado y regulatorias y, a veces, tarifas de plataforma. Las estrategias de frecuencia relativamente alta son especialmente sensibles. Una regla práctica sencilla: configura costes conservadores en el backtest, algo más altos de lo que esperas pagar.
Latencia
Pasa tiempo entre el momento en que se cumple una condición y el momento en que la orden llega al mercado: la vela tiene que cerrar, se envía la alerta, se recibe y procesa el webhook y la orden va al broker. Normalmente son unos pocos segundos o menos, pero en un mercado rápido incluso eso importa. Una estrategia construida para entrar exactamente al cierre de la vela siempre obtendrá en la práctica un precio algo distinto.
Calidad de los datos y sesgos
- Sesgo de anticipación (look-ahead bias): el código usa información que no estaba disponible en el momento de la decisión. Un ejemplo clásico: decidir según el cierre de una vela pero entrar en la apertura de esa misma vela. Un uso descuidado de datos de temporalidades superiores también puede provocarlo.
- Repintado (repainting): indicadores que cambian sus valores históricos a posteriori. En el gráfico la señal se ve perfecta; en tiempo real apareció y desapareció.
- Sesgo de supervivencia: relevante sobre todo en acciones, consiste en testear solo con activos que han sobrevivido hasta hoy. En futuros, el problema paralelo son los gráficos continuos (como NQ1!), que unen contratos distintos y pueden crear saltos artificiales en los días de rollover.
- Datos ausentes o erróneos: velas que faltan, horarios de sesión incorrectos o una zona horaria equivocada.
Cambios de régimen de mercado
Incluso un backtest técnicamente perfecto describe el pasado. Los mercados atraviesan periodos de volatilidad alta y baja, de tendencia y de rango. Una estrategia testeada sobre todo en un año con un carácter concreto puede comportarse de forma muy distinta en el siguiente periodo. Cuanto más largo y variado sea el periodo de test, más fiable será la imagen, pero nunca está garantizada. Un problema muy relacionado es la sobreoptimización, que tratamos en sobreoptimización en estrategias de trading.
Forward testing y simulación
La mejor manera de cerrar la brecha es una etapa intermedia: operar la estrategia en tiempo real en una cuenta de simulación, usando la misma vía de ejecución que usarás en real. Esto se llama forward testing o paper trading.
Qué revisar durante esta etapa:
- ¿Llegan las alertas a tiempo y con el formato correcto?
- ¿Cuál es la distancia media entre el precio de la señal y el precio de ejecución?
- ¿El número de operaciones se parece al que esperaba el backtest?
- ¿Hay operaciones duplicadas o ausentes, o posiciones "huérfanas"?
- ¿El comportamiento en torno a la apertura, el cierre y las publicaciones de datos es razonable?
Registra cada operación en un diario y compárala con el backtest del mismo periodo. La brecha que midas es valiosa: puedes devolverla al backtest como un supuesto de slippage realista.
Expectativas razonables
- Asume que los resultados en real serán más débiles que el backtest y planifica en consecuencia.
- Si una estrategia solo es rentable sin comisiones ni slippage, no tiene una ventaja real.
- Un periodo corto de simulación no demuestra nada en ningún sentido; sobre todo pone a prueba la infraestructura.
- El tamaño de posición al empezar en real debe ser pequeño y crecer solo cuando la ejecución se comporte como se espera.
Puntos clave
- Un backtest es un modelo con supuestos, y casi todos inflan los resultados.
- El slippage, la ejecución de órdenes limitadas y las comisiones son las mayores fuentes de la brecha.
- El sesgo de anticipación y el repintado pueden producir resultados que nunca fueron alcanzables en tiempo real.
- El forward testing en simulación, con la misma vía de ejecución, es un paso obligatorio.
- Mide la brecha real y devuélvela a tus tests.
Si operas con alertas de TradingView, WeCore te permite conectarlas a tu propia cuenta y ejecutarlas primero en modo simulación, para revisar ejecuciones, tiempos y reglas de riesgo antes de pasar a una cuenta real. Para los conceptos básicos, consulta qué es el trading algorítmico.