¿Qué significa realmente que un backtest sea bueno?
Yo no utilizaría “bueno” como sinónimo de “rentable”.
Un backtest puede mostrar ganancias históricas y estar mal construido. También puede tener métricas menos espectaculares y, sin embargo, aportar evidencia mucho más útil sobre el comportamiento de una estrategia.
Piensa en cuatro niveles:
Primero, el test debe ser válido. Las reglas tienen que poder reproducirse, los datos deben ser adecuados y la estrategia no puede utilizar información que en tiempo real todavía no habría conocido.
Después, la evidencia debe ser suficiente. Diez operaciones ganadoras no demuestran prácticamente nada. Pero tampoco existe un número mágico de operaciones que convierta automáticamente una prueba en fiable.
Luego, el comportamiento económico del sistema tiene que tener sentido. Hay que estudiar conjuntamente ganancias, pérdidas, expectancy, drawdown, distribución de resultados y costes.
Y finalmente hay que preguntarse si el resultado parece pertenecer a la estrategia o al periodo histórico concreto que utilizaste para construirla.
Un backtest que falla en el primer nivel no mejora porque tenga un profit factor enorme.
Ese punto merece quedarse claro: la calidad del proceso va antes que la calidad aparente del resultado.
Si necesitas refrescar la base, aquí explicamos desde cero qué es el backtesting y para qué sirve.
Las preguntas que yo haría antes de aceptar un backtest
Esta es una forma práctica de evaluarlo sin caer en el error de buscar una sola métrica milagrosa.
| Qué revisar | Qué quieres encontrar | Señal de alerta |
|---|---|---|
| Reglas | Criterios definidos y reproducibles | Reglas ambiguas o modificadas después de ver resultados |
| Datos | Histórico adecuado al mercado y estrategia | Datos incompletos, ajustados incorrectamente o contaminados |
| Muestra | Suficientes operaciones y contextos de mercado | Pocas operaciones o todas concentradas en un solo régimen |
| Costes | Spread, comisiones y otras fricciones razonables | Resultado calculado como si operar fuera gratis |
| Métricas | Rentabilidad y riesgo coherentes entre sí | Una métrica espectacular ocultando debilidades |
| Out-of-sample | El comportamiento no desaparece al usar datos no utilizados para diseñar | Colapso fuera de la muestra original |
| Proceso de desarrollo | Pocos grados de libertad y lógica defendible | Decenas de ajustes hasta encontrar la curva perfecta |
No necesitas que todo sea perfecto. Eso prácticamente no existe.
Lo que buscas es que no haya una explicación obvia y sencilla por la que el resultado histórico sea artificialmente bueno.
1. Comprueba primero que el backtest no esté haciendo trampa sin querer
Antes de mirar cuánto ganó, yo revisaría cómo se generaron esas ganancias.
Supongamos que tu sistema produce un 35% anualizado en el histórico. Suena interesante.
Pero descubres que entra al precio de cierre de una vela utilizando como señal ese mismo cierre, aunque en la ejecución simulada actúa como si la información hubiera estado disponible antes.
La rentabilidad deja de importarme.
Tienes un problema de look-ahead bias: la simulación está utilizando información futura. Puedes ver el problema con más detalle en la lección sobre look-ahead bias en backtesting.
Otro ejemplo aparece al probar estrategias sobre acciones.
Si haces el test utilizando únicamente las empresas que existen actualmente, puedes estar eliminando compañías que quebraron, fueron excluidas o desaparecieron de tu universo durante el periodo analizado. Eso puede introducir sesgo de supervivencia.
Y hay un problema todavía más básico: los propios datos.
Huecos, precios incorrectos, ajustes deficientes, una granularidad que no permite representar la ejecución o un histórico distinto del mercado que realmente quieres operar pueden transformar el resultado.
Por eso esta evaluación presupone que ya sabes cómo preparar buenos datos históricos para un backtest.
La idea es sencilla: un cálculo preciso sobre datos incorrectos sigue dando una respuesta incorrecta.
2. Pregunta si tienes suficiente evidencia, no solamente suficientes trades
Aquí aparece uno de los atajos que menos me gustan:
“Con 100 operaciones ya es válido.”
O 200. O 500.
No existe una cifra universal que convierta un backtest en fiable.
El número necesario depende, entre otras cosas, de la variabilidad de los resultados, la frecuencia de la estrategia y cuánto quieres inferir a partir de esa muestra.
Además, 200 operaciones no siempre contienen la misma información.
Imagina dos sistemas.
El primero realizó 200 trades casi todos durante unos meses de fuerte tendencia.
El segundo produjo 200 operaciones distribuidas durante años, incluyendo tendencia, lateralidad y periodos de distinta volatilidad.
El contador dice “200” en ambos casos. La evidencia no es igual.
Esta cuestión tiene suficiente profundidad como para tener su propia lección: cuántas operaciones necesita un backtest.
Aquí quédate con una regla más útil: cuanto menor y más homogénea sea tu muestra, menos confianza deberías depositar en una métrica aparentemente precisa.
3. Los costes deben formar parte del sistema
Un sistema no opera en un mercado sin fricciones.
Según el instrumento y la forma de operar, tendrás que representar razonablemente elementos como spread, comisión, slippage o financiación.
La importancia depende muchísimo de la estrategia.
Si haces pocas operaciones con objetivos amplios, una pequeña diferencia de coste puede tener un impacto reducido.
Si tu sistema busca movimientos muy pequeños y opera cientos o miles de veces, esa misma fricción puede destruir buena parte de la ventaja histórica.
Por eso no me interesa únicamente saber que un backtest es rentable.
Quiero saber:
¿Sigue siendo rentable después de pagar por ejecutar lo que la simulación dice que ejecuta?
Y aquí conviene acercar el backtest al entorno en el que realmente pretendes operar.
Pepperstone, por ejemplo, ofrece MetaTrader 5, cuyo Strategy Tester permite simular y optimizar estrategias automatizadas. Eso no hace fiable un backtest por sí mismo —ninguna plataforma puede hacerlo—, pero sí te permite trabajar con una herramienta preparada para este tipo de pruebas.
Si Pepperstone encaja con los mercados y la operativa que estás estudiando, puedes revisar sus condiciones y consultar la promoción disponible mediante nuestro enlace. Antes de trasladar cualquier resultado histórico, comprueba siempre qué costes y condiciones corresponden realmente al instrumento y tipo de cuenta que utilizarías.
4. Mira las métricas como un sistema, no como un concurso
Este es probablemente el error más común al evaluar resultados.
Buscar “el número bueno”.
Un win rate alto.
Un profit factor por encima de cierta cifra.
Una rentabilidad concreta.
Un drawdown inferior a determinado porcentaje.
Yo lo veo de otra manera: cada métrica responde una pregunta distinta y solo tiene sentido dentro del conjunto.
Por ejemplo, imagina un sistema hipotético con:
- 80% de operaciones ganadoras;
- ganancia media de 250 MXN;
- pérdida media de 1,000 MXN.
Su esperanza matemática antes de costes sería:
0.80 × 250 − 0.20 × 1,000 = 0 MXN por operación.
Tiene un win rate de 80%.
Y no tiene una ventaja positiva en este ejemplo.
Después de costes, la expectativa sería negativa.
Por eso decir “un buen backtest debe tener más de 60% de aciertos” no tiene sentido sin conocer qué ocurre cuando gana y cuando pierde.
Lo mismo pasa con el profit factor.
Un valor elevado puede ser interesante, pero me convencería mucho menos si procede de 25 operaciones que si aparece sobre una muestra amplia y razonablemente diversa. Y tampoco me gustaría que unas pocas operaciones extraordinarias explicaran prácticamente todo el beneficio.
Ya aprendiste a leer estas relaciones en la lección de métricas de backtesting. Aquí el trabajo consiste en comprobar que las métricas cuentan una historia compatible entre sí.
5. Pregunta de dónde viene el beneficio
Este análisis suele revelar cosas que una cifra agregada oculta.
Supongamos que el backtest termina con una ganancia de 300,000 MXN.
Ese número por sí solo me dice muy poco.
Querría saber si:
- el resultado está repartido entre muchas operaciones o depende de tres trades excepcionales;
- la estrategia produjo beneficios durante distintas etapas o únicamente en un periodo concreto;
- existen rachas de pérdidas compatibles con lo que podrías soportar;
- el drawdown está relacionado de forma razonable con el rendimiento obtenido;
- el sistema depende de un mercado extraordinariamente favorable.
No necesitas exigir que gane cada año, cada mes o en cada condición.
Eso sería poco realista.
Una estrategia de seguimiento de tendencia, por ejemplo, puede tener dificultades cuando el mercado permanece lateral durante bastante tiempo. El problema no es necesariamente que tenga periodos malos.
El problema aparece cuando descubres que todo lo que parecía una ventaja depende de una circunstancia demasiado específica que seleccionaste retrospectivamente.
6. El drawdown no es una métrica secundaria
Hay backtests que parecen muy atractivos hasta que dejas de mirar rentabilidad y empiezas a mirar el camino necesario para obtenerla.
Dos estrategias podrían terminar con el mismo beneficio y haber exigido experiencias completamente distintas.
Una puede mostrar caídas relativamente contenidas.
La otra puede haber sufrido una pérdida desde máximos tan grande que habría resultado operativamente inviable para el capital, el apalancamiento o el perfil de riesgo del trader.
Por eso no existe un “drawdown bueno” universal.
Hay que ponerlo en relación con:
la rentabilidad, la volatilidad de los resultados, el tamaño de posición, las rachas de pérdidas y el nivel de riesgo que realmente podrías mantener sin romper el sistema.
Además, recuerda algo incómodo: el máximo drawdown histórico es el peor que apareció en esa muestra, no el peor que puede existir en el futuro.
Un backtest no conoce todavía las pérdidas que no ocurrieron durante su periodo histórico.
7. Separa los datos utilizados para construir de los utilizados para comprobar
Si modificas una estrategia mirando continuamente el mismo histórico, ese histórico deja de funcionar como examen.
Se convierte en material de estudio.
Por eso es tan importante distinguir entre datos in-sample, utilizados durante el desarrollo, y datos out-of-sample, reservados para comprobar cómo se comporta la estrategia ante información que no utilizaste para elegir sus reglas.
Lo explicamos con detalle en In-Sample vs Out-of-Sample.
Aquí la pregunta es muy concreta:
¿El sistema conserva una lógica económica razonable cuando sale de los datos que utilizaste para construirlo?
No esperes necesariamente resultados idénticos.
De hecho, que el out-of-sample sea algo peor que el in-sample puede resultar perfectamente comprensible: el periodo de desarrollo, por definición, ha influido en las decisiones que tomaste.
Lo que me preocuparía es otra cosa.
Un sistema brillante in-sample que se desintegra en cuanto toca datos no utilizados durante el desarrollo.
Eso no demuestra automáticamente que no exista ninguna ventaja, pero obliga a revisar seriamente lo que estás viendo.
8. Pregunta cuántas versiones tuviste que probar para conseguir esa curva
Esta parte es especialmente importante.
Imagina que pruebas una media de 10 periodos.
No funciona.
Pruebas 11.
Después 12.
Luego cambias el stop.
Después el objetivo.
Después añades un filtro horario.
Después quitas los lunes.
Después cambias el activo.
Y sigues probando hasta que aparece una combinación fantástica.
¿Cuál es el problema?
Que ya no estás preguntando si una hipótesis funciona.
Estás buscando qué configuración explica mejor el pasado.
Cuantas más alternativas pruebas y más libertad tienes para escoger retrospectivamente al ganador, mayor es el riesgo de seleccionar una combinación favorecida por azar. El problema del backtest overfitting y del sesgo de selección está bien documentado en la literatura cuantitativa.
Esto no significa que no puedas modificar una estrategia.
Significa que debes recordar cuántos intentos precedieron al resultado que finalmente enseñas.
Una curva espectacular después de probar 300 variantes me impresiona bastante menos que esa misma curva nacida de una hipótesis clara y pocos grados de libertad.
Puedes profundizar en el problema en nuestra lección sobre overfitting en trading.
No existen los números mágicos para aprobar un backtest
Si buscas en internet, encontrarás reglas muy cómodas:
“Profit factor superior a X.”
“Al menos X operaciones.”
“Drawdown inferior a X%.”
“Win rate mínimo de X%.”
El problema es que parecen objetivas mientras eliminan precisamente lo que necesitas entender: el contexto.
Un profit factor de 1.3 podría esconder una estrategia interesante con muchísimas observaciones, bajos costes y un comportamiento estable.
Otro de 2.5 podría proceder de 18 operaciones y desaparecer al añadir un pequeño slippage.
Una muestra de 500 trades puede ser informativa en un sistema y sorprendentemente pobre en otro.
Y un drawdown del 15% puede resultar razonable para cierto diseño de riesgo e inaceptable para otro.
Los umbrales pueden servir como filtros internos.
Lo que no deberían convertirse es en leyes universales.
Un ejemplo: el backtest espectacular frente al backtest creíble
Imagina estos dos resultados hipotéticos.
El Backtest A gana 180% en el periodo analizado. Tiene 65 operaciones, no incluye costes, todos los parámetros fueron elegidos utilizando el mismo histórico y no existe una prueba out-of-sample.
El Backtest B gana 27%. Tiene varios cientos de operaciones, incluye costes razonables, utiliza reglas definidas y mantiene una expectativa positiva —aunque menor— en un periodo que no se utilizó durante el desarrollo.
¿Cuál me interesa más estudiar?
El B.
No porque 27% sea una rentabilidad “buena” ni porque el sistema vaya a funcionar en el futuro.
Me interesa porque tengo mejores motivos para creer que estoy observando el comportamiento de una estrategia y no un artefacto del proceso de backtesting.
Esa es una diferencia enorme.
El backtest A vende mejor.
El B investiga mejor.
Mi checklist final para decidir si un backtest merece avanzar
Yo me haría estas preguntas antes de dedicar más tiempo a un sistema:
- ¿Las reglas estaban suficientemente definidas antes de evaluar los resultados?
- ¿Los datos representan razonablemente el mercado que quiero estudiar?
- ¿He evitado información futura y otros sesgos evidentes?
- ¿La muestra contiene suficiente información para el tipo de estrategia?
- ¿Los costes y supuestos de ejecución son razonables?
- ¿La ventaja sigue existiendo al combinar win rate, payoff, expectancy, costes y riesgo?
- ¿Entiendo el drawdown y las rachas de pérdidas que produjo?
- ¿El beneficio depende demasiado de unas pocas operaciones o de un único periodo?
- ¿Existe evidencia fuera de los datos utilizados durante el desarrollo?
- ¿Cuántas decisiones, parámetros y variantes tuve que probar para llegar a este resultado?
Si varias respuestas son “no sé”, yo no intentaría compensarlo mirando otra vez la rentabilidad.
Intentaría resolver primero esas incertidumbres.
¿Cuándo considero que el backtest ha pasado esta fase?
No cuando demuestra que el sistema “funciona”.
Un backtest no puede darte esa certeza.
Para mí, supera esta etapa cuando puedes decir algo mucho más modesto, pero también mucho más útil:
“La prueba parece suficientemente limpia, amplia y coherente como para que merezca la pena someter el sistema a validaciones más exigentes.”
Ahí termina realmente esta lección.
Hasta ahora has aprendido a construir la prueba, reconocer sus sesgos y leer sus métricas. A partir de aquí cambia la pregunta.
Ya no quieres saber únicamente cómo funcionó una configuración concreta.
Quieres empezar a comprobar qué pasa cuando dejas de tratar esa configuración como algo sagrado.
Ese es exactamente el objetivo de la siguiente lección: cómo hacer un análisis de sensibilidad de un sistema de trading.
Si además tienes previsto que Pepperstone sea tu entorno posterior de ejecución, puedes revisar Pepperstone y consultar la promoción disponible al abrir tu cuenta desde nuestro enlace. Lo importante en esta fase es que cualquier coste o condición que uses en tus pruebas se parezca cada vez más a aquello que después tendrás que ejecutar de verdad.
