Sesgos en backtesting: errores que contaminan la validación de un sistema
Muchos backtests parecen mejores de lo que son no por la calidad real del sistema, sino por la forma en que el trader selecciona, prueba o interpreta los datos. Y lo más peligroso es que el sesgo no siempre arruina el resultado de forma evidente: muchas veces lo vuelve lo bastante convincente como para dejar de cuestionarlo.
En TNT Bolsa tratamos los sesgos como un problema metodológico, no como un rasgo de personalidad. Puedes registrar cada operación con cuidado y aun así contaminar la prueba si eliges el periodo que más te favorece, interpretas reglas con flexibilidad o justificas excepciones después del test.
La calidad no consiste sólo en recoger datos. Consiste en crear fricción contra el autoengaño.
Qué significa hablar de sesgos en backtesting
Cuando hablamos de sesgos en backtesting no hablamos sólo de errores visibles o fallos técnicos. Hablamos de decisiones que deforman la evidencia y hacen que el resultado parezca más sólido de lo que realmente es.
Un sesgo no es sólo un error técnico
Un error técnico suele ser localizable: un dato mal cargado, un cálculo equivocado o una regla aplicada de forma incorrecta.
Un sesgo es distinto. Puede convivir con una ejecución técnicamente limpia y aparecer en decisiones como estas:
- qué casos entran y cuáles se excluyen
- cómo se interpreta una regla ambigua
- qué métricas se destacan y cuáles se minimizan
- qué explicaciones se construyen después para justificar lo ocurrido
Por eso es tan problemático: no siempre se detecta en la hoja de cálculo, sino en la lógica del proceso.
Por qué el problema no está sólo en los datos, sino en cómo se usan
Los datos, por sí solos, no garantizan limpieza metodológica. Puedes trabajar con una muestra en backtesting amplia y seguir arrastrando sesgos si:
- el periodo se eligió porque encajaba bien con la idea inicial
- se excluyeron casos incómodos sin criterio previo
- las reglas se aplicaron con más flexibilidad cuando convenía
En ese punto, el backtest deja de ser una prueba y empieza a parecerse más a una narrativa razonable, pero poco fiable.
Cómo un sesgo puede volver convincente una validación débil
La trampa habitual no suele ser inventarse resultados. Suele ser algo más sutil:
- escoger los tramos donde el sistema se comporta mejor
- dar más peso a las métricas favorables
- tratar las excepciones como casos especiales que “no cuentan”
- concluir que hay ventaja sin haber exigido realmente al sistema
Si el proceso no introduce fricción suficiente, el backtest tiende a confirmar lo que ya querías creer. Por eso esta pieza encaja dentro del marco general de la validación de sistemas de trading.
En qué partes del backtesting suelen aparecer sesgos
Los sesgos no aparecen sólo al final, cuando miras la curva o las métricas. Pueden entrar desde el primer paso.
Al definir qué sistema se va a probar
Si el sistema no existe como conjunto de reglas claras y repetibles, el sesgo entra por interpretación. Ahí el primer antídoto es simple: documentar un sistema de trading antes de mirar el histórico.
Si el sistema vive sólo en tu cabeza, siempre habrá espacio para “ajustarlo” mientras lo pruebas.
Al seleccionar qué casos entran en la muestra
Este es uno de los puntos donde más se contamina el backtest. El problema aparece cuando:
- el periodo se decide a conveniencia
- se eligen sólo ciertos activos o situaciones
- se altera la definición de qué cuenta como operación válida
La selección de casos define la evidencia. Por eso la pieza sobre muestra en backtesting es complementaria, pero distinta: allí se trabaja la base del test; aquí, cómo esa base puede contaminarse por decisiones interesadas.
Al leer resultados que confirman una idea previa
Cuando el resultado encaja con la hipótesis inicial, es fácil dejar de buscar puntos débiles. Ahí aparecen sesgos de lectura como:
- centrarse sólo en beneficio o acierto
- ignorar drawdown, duración o rachas
- dar protagonismo a las métricas favorables y suavizar las incómodas
Un orden de lectura estable, como el que se trabaja en métricas de backtest, ayuda precisamente a reducir esta interpretación interesada.
Al justificar excepciones después del test
Éste es uno de los momentos más delicados del backtesting manual. Cuando miras el histórico y piensas:
- “esta no la habría tomado”
- “en este caso habría esperado”
- “aquí el contexto era distinto”
Si esa excepción no estaba definida antes, no debería entrar después. En un proceso serio, las excepciones se escriben, se separan y se prueban como parte de una versión del sistema, no como una corrección retrospectiva.
Sesgos frecuentes que contaminan un backtest
No todos los sesgos aparecen aislados. Muchas veces se encadenan: una hipótesis inicial lleva a una selección sesgada, esa selección condiciona la lectura y la lectura termina reforzando la idea inicial.
Sesgo de confirmación
Es la tendencia a buscar evidencia que apoye la hipótesis del sistema y a tratar la evidencia contraria como ruido o excepción.
Suele notarse cuando el objetivo real del test no es entender el sistema, sino demostrar que funciona.
Selección interesada de ejemplos o periodos
Ocurre cuando el periodo, el universo o los casos del backtest no se eligen por criterio previo, sino por conveniencia.
Señales típicas:
- se evita un tramo débil “porque distorsiona”
- se priorizan periodos recientes porque “representan mejor el mercado actual”
- se modifica el rango temporal hasta que el resultado parece aceptable
Hindsight bias o lectura retrospectiva contaminada
Es el sesgo de interpretar el pasado con la ventaja de conocer el desenlace. En backtesting aparece cuando aplicas una regla con más precisión de la que realmente habrías tenido en tiempo real.
Eso hace que la prueba parezca más limpia y más obvia de lo que habría sido en ejecución real.
Cherry-picking de resultados
No es sólo enseñar el mejor tramo del sistema. También es:
- destacar la mejor métrica y omitir las débiles
- mostrar sólo operaciones ejemplares
- construir una presentación favorable en lugar de una lectura equilibrada
Sesgo de supervivencia
Cuando el enfoque lo permite, este sesgo aparece si trabajas con un universo que excluye activos, instrumentos o selecciones que no “sobrevivieron” en el tiempo. El pasado parece mejor porque ya viene filtrado.
No siempre aplica, pero cuando aplica conviene nombrarlo y tratarlo de forma explícita.
Interpretación benevolente de reglas ambiguas
Es uno de los sesgos más comunes y más invisibles. Ocurre cuando una regla admite dos lecturas y, sin darte cuenta, eliges la que mejora el resultado.
Si una regla permite demasiada flexibilidad, el backtest deja de medir un sistema y empieza a medir tu capacidad de hacerlo encajar.
Cómo detectar que un backtest está sesgado aunque el resultado parezca bueno
La pregunta útil no es sólo si puede haber sesgo, sino qué señales concretas lo delatan.
Resultados demasiado alineados con lo que se quería demostrar
Si el sistema parece demasiado limpio, demasiado estable o demasiado perfectamente adaptado a la hipótesis inicial, conviene sospechar. Un sistema real suele mostrar fricción, rachas y zonas incómodas.
Cambios de criterio que no quedaron documentados
Si no puedes reconstruir con claridad:
- qué reglas estaban vigentes
- qué periodo se eligió y por qué
- qué operaciones entraron y cuáles quedaron fuera
entonces no tienes una evidencia revisable. Tienes una reconstrucción posterior.
Reglas que se vuelven flexibles sólo cuando conviene
Una señal muy clara es esta: la regla se aplica con rigidez cuando el resultado perjudica y con flexibilidad cuando el resultado favorece.
Si la misma situación se interpreta de forma distinta según el desenlace, el test está contaminado.
Métricas o ejemplos seleccionados para reforzar una narrativa
Cuando la lectura se apoya en dos cifras favorables y evita sistemáticamente hablar de drawdown, duración, concentración del resultado o estabilidad, no estás ante una lectura limpia del sistema. Estás construyendo una explicación conveniente.
Qué relación tienen los sesgos con la muestra, las métricas y el sobreajuste
Aquí conviene separar bien conceptos para no llamar “sesgo” a cualquier problema metodológico.
Una muestra puede ser amplia y seguir estando sesgada
Una muestra grande no garantiza neutralidad. Puede seguir contaminada por selección interesada, exclusión de casos incómodos o reinterpretación de lo que cuenta como operación válida.
Una métrica puede leerse mal aunque esté bien calculada
El sesgo no siempre está en el número. Muchas veces está en lo que decides mirar, comparar o destacar. Una métrica bien calculada puede apoyar una mala conclusión si se lee sin contexto.
El sobreajuste es un problema específico, no el nombre de todos los sesgos
El sobreajuste en backtesting es el ajuste excesivo de reglas o parámetros para que el sistema encaje demasiado bien con el histórico. Es una forma concreta de contaminación, pero no engloba todos los sesgos.
Hay sesgos de selección, de interpretación y de lectura que no son sobreajuste y deben corregirse de otra forma.
Cómo reducir sesgos dentro de un proceso de validación serio
La solución no es confiar en ser más objetivo. La solución es diseñar el proceso para que el sesgo tenga menos espacio.
Documentar reglas antes de testear
El primer antídoto es documentar un sistema de trading antes de abrir el histórico. Eso reduce reinterpretaciones, excepciones improvisadas y cambios silenciosos.
Fijar qué entra y qué no entra en la prueba
Conviene dejar definidos por escrito:
- periodo
- universo, si aplica
- criterios de inclusión y exclusión
- tratamiento de los “casi cumple”
Eso no elimina el sesgo por completo, pero sí reduce mucho el margen para ajustarlo después.
Separar recogida de datos e interpretación
Un método simple que ayuda mucho es este:
- primero recoges operaciones según reglas
- después interpretas resultados en un bloque separado
Cuando mezclas registro e interpretación, empieza la negociación interna.
Revisar resultados sin buscar confirmar una idea previa
Conviene hacerse preguntas incómodas de forma sistemática:
- ¿dónde sufre el sistema?
- ¿qué tramos explican la mayor parte del resultado?
- ¿qué métricas empeoran y por qué?
La función del backtest no es aprobar una idea. Es someterla a una prueba útil.
Dejar trazabilidad de cambios y excepciones
Si cambias algo, debe quedar registrado. Si aparece una excepción, debe definirse y probarse como parte de una versión. Eso conecta después con los criterios de validación de un sistema, que sólo tienen sentido cuando el proceso deja rastro suficiente para ser revisado.
Qué señales indican que todavía no puedes confiar del todo en tu backtest
Cuando el sistema depende de demasiada interpretación
Si dos revisiones del mismo periodo generan decisiones distintas, todavía no estás validando un sistema suficientemente claro.
Cuando la lectura cambia según el resultado
Si una operación parece válida cuando gana y “dudosa” cuando pierde, la regla está dependiendo del desenlace y no del criterio previo.
Cuando el proceso no deja rastro de decisiones
Si no puedes reconstruir por qué se incluyó un periodo, por qué se excluyó una operación o qué versión del sistema se estaba probando, la evidencia no es suficientemente auditable. Y si no es auditable, no debería sostener decisiones importantes.
FAQs
¿Qué sesgos afectan a un backtesting?
Principalmente sesgos de selección, confirmación, lectura retrospectiva, cherry-picking, interpretación flexible de reglas y, cuando aplica, sesgo de supervivencia.
¿Cómo saber si un backtest está sesgado?
Si el resultado encaja demasiado bien con la hipótesis inicial, si hay cambios de criterio no documentados o si las reglas se vuelven flexibles cuando conviene, conviene sospechar.
¿Qué diferencia hay entre sesgo y error técnico en backtesting?
El error técnico es un fallo de ejecución. El sesgo puede existir aunque el test esté bien ejecutado, porque entra por selección, interpretación y lectura.
¿El sesgo de confirmación puede afectar a un sistema de trading?
Sí. Hace que busques pruebas para sostener la idea inicial y que des menos peso a la evidencia que la contradice.
¿Qué relación hay entre sesgos y sobreajuste?
El sobreajuste es una forma concreta de contaminación metodológica, pero no equivale a todos los sesgos. Hay sesgos de selección y de lectura que no pasan por optimizar parámetros.
¿Se puede tener una buena muestra y aun así un backtest sesgado?
Sí. Una muestra amplia puede seguir sesgada si fue elegida con conveniencia o si las reglas se aplicaron de forma inconsistente.
¿Cómo reducir sesgos al validar un sistema?
Documentando reglas antes de testear, fijando la muestra por escrito, separando recogida de datos e interpretación y dejando trazabilidad de cambios y excepciones.
En TNT Bolsa trabajamos para que la validación de un sistema no dependa de intuiciones ni sesgos invisibles, sino de proceso, control y lectura limpia de los datos.
