De dónde viene la diferencia
«Los backtests son optimistas» es cierto e inútil. La diferencia tiene causas concretas, cada una comprobable en tu propio script, y están repartidas en tres lugares distintos de la documentación.
Supuestos de ejecución a nivel de barra
El tester ejecuta órdenes contra datos de barra. En vivo, ejecutas contra un libro de órdenes.
| Supuesto | Qué oculta [1] |
|---|---|
process_orders_on_close desactivado | las órdenes se ejecutan en la apertura de la barra siguiente, no donde se disparó la señal |
process_orders_on_close activado | se ejecutan al cierre de la barra de señal — mejor alineado, pero solo alcanzable si realmente puedes operar el cierre |
calc_on_order_fills desactivado | el script no se reevalúa al ejecutarse una orden, así que no se modelan secuencias intrabarra que el mercado real produciría |
pyramiding en 1 por defecto | una segunda señal se ignora, tanto en el test como en vivo |
Ninguno está mal. Son decisiones de modelado, y la cuestión es saber cuál tomaste.
La asimetría histórico/tiempo real
Una barra terminada contiene cuatro números. En una barra en formación, el máximo, el mínimo y el cierre siguen moviéndose [2]. El tester funciona sobre barras terminadas; en vivo funcionas sobre una barra que aún no ha terminado.
Ese único hecho produce la mayor parte de la divergencia normal. Una condición
que compara con high compara con un valor definitivo en el test y con uno
provisional en vivo. Una estrategia con calc_on_every_tick se ejecuta en cada
tick en vivo y solo al cierre de barra en el historial [2]: el mismo script, dos
modelos de ejecución.
Los costes, que son el factor individual más grande
La comisión y el slippage son parámetros de la declaración, y un tester sin ninguno de los dos modela un mercado que no te cobra. El slippage se fija en ticks [1], así que equivocarse de unidad escala el error con el tamaño de tick del instrumento.
Esto se trata a fondo en comisión, slippage y capital; la versión corta es que los ajustes de coste suelen explicar más de la diferencia que el momento de ejecución.
Dos que sorprenden
Tipos de gráfico no estándar. TradingView afirma con claridad que producen resultados poco realistas por defecto y que deben usarse gráficos estándar para un backtest realista [1]. Un backtest en Heikin Ashi o Renko no puede reproducirse con ejecuciones reales: las barras mismas son derivadas, no negociadas.
El límite de 9.000 órdenes. Más allá, v6 recorta en silencio las más
antiguas en lugar de dar error [3], y las recortadas devuelven na en
strategy.closedtrades.*. Un backtest largo de alta frecuencia puede por tanto
estar informando sobre un subconjunto de sus propias operaciones.
Reducir la diferencia, por orden de efecto
Ordenado por cuánto mueve cada paso el resultado, de mayor a menor.
1. Pon costes reales. Comisión y slippage de tu propia cuenta, no un número de un artículo. Esto suele explicar más de la diferencia que todo lo demás junto.
2. Prueba en un gráfico estándar. Si el backtest se ejecutó en Heikin Ashi o Renko, el resultado no es comparable con la operativa real [1] y nada más de esta lista lo arreglará.
3. Decide el modelo de ejecución a propósito. Elige
process_orders_on_close con conocimiento y no por defecto, y sé honesto sobre
si puedes operar el cierre de una barra en la temporalidad que pruebas. En un
gráfico diario, a menudo no puedes.
4. Comprueba el lookahead. Si el script usa request.security(), confirma
que no hay fuga de futuro — ver
repintado y lookahead.
Esto es binario: o la ejecución histórica tuvo información que la real no puede
tener, o no.
5. Mira el número de operaciones, no solo el rendimiento. Los costes y los supuestos de ejecución escalan con la frecuencia, así que un resultado de alta frecuencia es mucho más sensible a todo lo anterior. Una estrategia con 40 operaciones no ha sido probada, diga lo que diga su rendimiento.
6. Repite con el doble de tu estimación de coste. Una estrategia que sobrevive a eso es interesante. Una que no, te está diciendo que su resultado es la suposición de coste.
Después opera en papel, y espera que siga habiendo diferencia
La operativa en papel elimina la asimetría histórico/tiempo real [2] porque avanza sobre barras en formación, como en vivo. Lo que no elimina es tu ejecución: una ejecución en papel sigue siendo modelada, no una posición en la cola del libro.
Así que la secuencia que funciona es: backtest para descartar malas ideas barato, papel para detectar los supuestos de ejecución que el backtest ocultó, y después en vivo con tamaño pequeño para descubrir lo que realmente cuestan tus ejecuciones.
El límite honesto de todo esto
Ninguno de estos pasos hace predictivo un backtest. Un tester con costes correctos, barras estándar, un modelo de ejecución deliberado y sin lookahead sigue siendo un modelo, y el mercado no está obligado a parecerse a él.
Lo que el trabajo te compra es distinto y vale más: un test que falla con honestidad. La mayoría de las estrategias que se ven bien con los ajustes por defecto dejan de verse bien cuando los costes son reales — y descubrirlo en el tester no cuesta nada, mientras que descubrirlo en vivo cuesta la cuenta.
Tactix AI en este flujo
AlfaTactix incluye Tactix AI: usa Tactix Studio para describir tu idea en lenguaje natural y rellenar timeframes, señales, filtros y riesgo en el mismo formulario de seis pasos — o abre Tactix Guide en cualquier paso si solo necesitas explicar un campo. Revisa cada valor y luego exporta MQL5 o Pine Script desde Code Generator (form-first — no prompt-to-code sin probar).