Cómo leer un backtest sin engañarte.

El error de método está en el primer segundo: casi todo el mundo mira la curva antes que las condiciones. Y la curva es precisamente lo único del documento que está diseñado para convencerte. Una vez la has visto subir, todo lo que leas después lo interpretarás buscando confirmarla.

Antes de mirar el resultado, hay cuatro cosas que determinan si el resultado significa algo:

• Periodo y regímenes. Qué años cubre y qué ocurrió en esos años. Un backtest que solo abarca mercado alcista no ha probado nada excepto que el sistema sabe estar largo.
• Número de operaciones. Con cuarenta operaciones no hay conclusión estadística posible, por mucho que el gráfico ocupe diez años.
• Costes aplicados. Qué spread, qué comisión, qué deslizamiento se han descontado y con qué justificación.
• Cuántas variantes se probaron. Esta es la que nadie publica y la que más importa. Volveremos a ella.

Si estas cuatro respuestas no están en el documento, no hace falta seguir leyendo. No porque el sistema sea malo — puede no serlo — sino porque el documento no permite juzgarlo. Y un documento que no permite juzgar es, funcionalmente, publicidad.

Hay una familia de errores que aparecen una y otra vez, y que comparten una característica: todos empujan en la misma dirección. Ninguno hace que el backtest parezca peor de lo que es. Eso ya debería decirte algo sobre su origen.

Sesgo de anticipación (look-ahead). El sistema usa, sin que nadie lo pretenda, información que no estaba disponible en el momento de decidir. El caso clásico es calcular una señal con el cierre de la vela y ejecutar a ese mismo cierre. Media hora de información futura basta para convertir un sistema mediocre en uno espectacular.

Sesgo de supervivencia. El histórico contiene solo lo que sigue existiendo. Si pruebas sobre los activos que hoy cotizan, has eliminado de la muestra a todos los que quebraron. El pasado, visto desde el presente, siempre parece más benigno de lo que fue para quien lo vivió.

Sesgo de selección de periodo. Empezar el backtest en 2013 en vez de en 2007 no requiere ninguna justificación explícita, y transforma el resultado. La pregunta que lo detecta es simple y casi nunca se hace: ¿por qué empieza exactamente ahí?

Datos limpios. El histórico que compras viene sin gaps de fin de semana problemáticos, sin cortes de conexión, sin los cinco minutos en que el bróker dejó de aceptar órdenes. La realidad operativa tiene esos huecos; el fichero CSV no.

Ninguno de estos sesgos requiere mala fe. Ese es justamente el problema: aparecen solos, y solo se detectan si alguien los busca activamente. Un backtest en el que nadie ha buscado sus propios errores es un backtest optimista por construcción.

Un backtest publicado suele venir con una tabla de métricas. La mayoría son ciertas y casi ninguna es informativa por separado. Estas son las tres que más confusión generan.

Rentabilidad total. Es el número más grande y el menos útil. No dice a qué riesgo se obtuvo, en qué periodo ni con qué recorrido. Una rentabilidad del 300% en cinco años con caídas del 60% por el camino es una cifra distinta de la misma rentabilidad con caídas del 10%, aunque el titular sea idéntico.

Porcentaje de aciertos. Intuitivamente parece la métrica de calidad, y es de las más manipulables. Un sistema que cierra ganancias pequeñas rápido y deja correr las pérdidas produce un porcentaje de aciertos altísimo y una curva que un día se desploma. La aritmética es directa: acertar el 90% con ganancias de 1 y perder el 10% con pérdidas de 10 da un resultado neto de cero antes de costes, y negativo después.

Profit factor. Ganancia bruta dividida entre pérdida bruta. Es mejor que las anteriores, pero se dispara con pocas operaciones y es especialmente sensible a una sola operación excepcional. Si el profit factor de un backtest baja de 2,4 a 1,1 al quitar la mejor operación del histórico, lo que estás mirando no es un sistema: es una anécdota.

Las métricas que sí resisten son menos fotogénicas: el drawdown máximo y su duración, la estabilidad del resultado a lo largo de subperiodos, y la relación entre rentabilidad y caída. Si te interesa el fondo del asunto, el artículo sobre drawdown desarrolla por qué esa métrica manda sobre la rentabilidad.

Esta es la distinción que separa un backtest que informa de uno que solo describe. Los datos que se usaron para construir las reglas son in-sample: dentro de muestra. Los que se apartaron y no participaron en ninguna decisión de diseño son out-of-sample: fuera de muestra.

El resultado in-sample no es una predicción. Es una descripción de lo que ya sabías cuando escribiste las reglas. Puede hacerse arbitrariamente bueno con suficiente esfuerzo: siempre existe una combinación de parámetros que ajusta perfectamente cualquier serie histórica concreta. Que exista no significa que sirva para nada.

El resultado out-of-sample es la primera información real del proceso. Es la primera vez que las reglas se enfrentan a datos que no las vieron nacer. Y por eso la pregunta más incisiva que puedes hacerle a alguien que te enseña un backtest no es sobre la curva, sino sobre el procedimiento: ¿qué parte de estos datos no participó en el diseño, y cuántas veces miraste esa parte antes de dar el sistema por bueno?

Porque ahí está la trampa fina: si miras el out-of-sample, ajustas y vuelves a mirar, ya lo has contaminado. Ha dejado de ser fuera de muestra y se ha convertido en dentro de muestra con pasos extra. Esa contaminación silenciosa es la puerta de entrada del sobreajuste, y es tan común que se ha normalizado.

Ni siquiera un out-of-sample limpio cierra el asunto. Es la razón por la que la validación seria no acaba en el backtest: continúa con forward-test en demo durante un mínimo de tres meses, después con capital propio otros tres meses como mínimo, y termina con una revisión técnica que compara lo observado contra lo que el backtest había anunciado. Cada etapa cuesta más y engaña menos.

Después de tanta advertencia, la pregunta natural es qué aspecto tiene uno bueno. La respuesta desconcierta a mucha gente: uno bueno se parece bastante a uno decepcionante.

Tiene periodos malos visibles. Meses planos, años mediocres, caídas que tardan en recuperarse. Una curva sin zonas incómodas no es evidencia de calidad; es evidencia de ajuste.

Declara lo que no cubre. Dice qué costes ha asumido, qué supuestos de ejecución usa y qué situaciones no están modeladas. La honestidad técnica se reconoce por la densidad de limitaciones declaradas, no por la ausencia de ellas.

Muestra el efecto de mover los parámetros. Si al cambiar un umbral un 10% el resultado se desploma, el sistema vive en un pico estrecho de la superficie de parámetros y ese pico casi con seguridad es ruido. Un sistema robusto tiene resultados parecidos en toda una vecindad de configuraciones. Lo que quieres ver no es el mejor punto: es la meseta.

Se presenta subordinado al histórico real. Un operador serio enseña el backtest como contexto y el track record verificable como evidencia, no al revés. Si el backtest ocupa diez páginas y la operativa real media línea, la jerarquía del documento te está diciendo dónde está el problema.

Reduce todo lo anterior a cuatro preguntas y hazlas siempre en este orden. Qué parte de los datos no participó en el diseño. Cuántas variantes se probaron antes de quedarse con esta. Qué costes se han descontado y de dónde salen. Y qué histórico real, verificable por un tercero, respalda la simulación.

Ninguna de las cuatro es hostil, y las cuatro son incómodas de responder para quien no tiene respuesta. Esa incomodidad, más que el contenido de la respuesta, es lo que suele acabar informándote.

Y sí: aplícanoslas también a nosotros. Este artículo no está aquí para que aprendas a auditar a los demás y nos des a nosotros un pase. VERTEX debe pasar el mismo filtro, con las mismas preguntas y sin descuento por afinidad. Si al terminar de leer decides que no tienes evidencia suficiente para exponer capital, has usado bien el artículo. Preferimos eso a lo contrario.

El complemento natural de esta lectura es backtest vs cuenta real, que explica por qué la brecha entre simulación y operativa es estructural. Nuestro histórico observado está en transparencia, y el enfoque que hay detrás, en metodología.