Backtesting de bots de trading: cómo interpretar resultados y detectar sesgos

El backtesting de bots de trading es una prueba que aplica reglas automatizadas a datos históricos para observar cómo se habrían comportado bajo determinadas condiciones. Puede ayudar a detectar errores lógicos, comparar versiones y formular preguntas, pero no convierte el pasado en una predicción. El resultado depende de la calidad de los datos, las reglas elegidas, los costes incluidos y la forma en que se separó la información usada para diseñar el sistema de aquella reservada para validarlo.

Esta distinción es importante porque una simulación visualmente convincente puede esconder supuestos favorables. La CFTC advierte que la inteligencia artificial no puede anticipar el futuro ni los cambios repentinos del mercado. También recomienda considerar el efecto de comisiones, diferenciales y costes de suscripción al evaluar afirmaciones sobre automatización. Por eso, una prueba histórica debe leerse como evidencia limitada y reproducible, no como una promesa.

Qué es una prueba histórica y para qué sirve

Una prueba histórica reconstruye decisiones hipotéticas con datos de un periodo anterior. El sistema recibe precios, horarios u otras variables disponibles y aplica reglas predefinidas. Después produce registros que permiten revisar cuándo habría emitido una señal, qué condición la activó y cómo se habría calculado el resultado.

Su utilidad principal es técnica. Permite comprobar si las reglas se ejecutan en el orden esperado, si existen contradicciones y si una modificación cambia el comportamiento. También ayuda a localizar periodos problemáticos, como jornadas con datos incompletos, movimientos abruptos o baja liquidez. Una prueba bien documentada puede servir para auditoría y comparación entre versiones.

No obstante, el ejercicio ocurre dentro de un modelo. La simulación simplifica la ejecución real, la disponibilidad de datos y la respuesta de los sistemas. Una cifra final resume muchas decisiones metodológicas y no permite juzgar por sí sola la calidad de la prueba. Para entenderla hay que revisar cómo se construyó.

Datos de entrenamiento, validación y prueba fuera de muestra

Un error frecuente consiste en usar el mismo periodo para diseñar reglas y luego presentarlo como evidencia independiente. Cuando las decisiones se ajustan repetidamente hasta coincidir con los datos conocidos, el sistema puede aprender peculiaridades del pasado que no representan una relación estable. Este fenómeno se conoce como sobreajuste.

Una práctica de evaluación más clara separa los datos en bloques. El primer bloque sirve para explorar y formular reglas. Otro bloque se reserva para comprobar decisiones sin reajustarlas cada vez que aparece un resultado incómodo. Una prueba fuera de muestra usa datos que no participaron en el diseño. No elimina la incertidumbre, pero reduce la posibilidad de confundir adaptación al pasado con capacidad general.

También conviene ordenar los bloques en el tiempo. Mezclar observaciones futuras dentro del periodo utilizado para construir una regla produce fuga de información. El sistema termina utilizando datos que, en una situación real, todavía no habrían estado disponibles. La documentación debe explicar el corte temporal y qué variables se conocían en cada momento.

Sesgos que pueden inflar un resultado

El sesgo de selección aparece cuando se eligen solo activos, horarios o periodos favorables. Si se prueban muchas variantes y se publica únicamente la mejor, el lector no ve cuántos intentos fallaron. La cantidad de pruebas importa porque aumenta la probabilidad de encontrar por azar una combinación atractiva.

El sesgo de supervivencia ocurre cuando el conjunto histórico conserva solo elementos que continuaron existiendo. Así desaparecen activos o fuentes que dejaron de operar, aunque habrían formado parte de la decisión original. El sesgo de anticipación surge cuando una variable incorpora información posterior a la fecha simulada.

También existe sesgo en la limpieza de datos. Eliminar observaciones extremas puede parecer razonable, pero esas observaciones quizá representen justamente los escenarios que ponen a prueba los controles. Cada corrección debe conservar una regla explícita, la razón del cambio y una copia de los datos originales.

Costes y fricciones que deben incluirse

Una simulación que ignora costes describe un entorno distinto del real. Las comisiones pueden aplicarse por operación, periodo o servicio. El diferencial entre precios de compra y venta introduce otra fricción. El deslizamiento representa la diferencia entre el precio supuesto y el precio que podría haberse obtenido cuando cambian la liquidez o la velocidad de ejecución.

También existen costes técnicos: datos, infraestructura, mantenimiento, supervisión y recuperación ante incidentes. Algunos son fijos y otros aumentan con la actividad. El artículo sobre costes de un bot de trading aporta un marco complementario para revisar fricciones y resultados. La prueba histórica debe declarar qué componentes incorporó y cuáles dejó fuera.

El objetivo no es adivinar una cifra universal. Es evitar que el resultado se presente como comparable con una situación que incluye fricciones diferentes. Una prueba responsable muestra varios supuestos razonables y explica cómo cambia la conclusión cuando los costes aumentan.

Métricas que necesitan contexto

Una tasa de aciertos elevada no explica el tamaño de las pérdidas, la duración de las posiciones ni la exposición acumulada. Dos sistemas pueden acertar con frecuencia y aun así comportarse de forma muy distinta. Del mismo modo, una rentabilidad acumulada no revela cuánto capital estuvo expuesto ni qué caída ocurrió durante el recorrido.

Conviene revisar la distribución de resultados, la peor secuencia observada, el tiempo de recuperación, la concentración por periodo y la sensibilidad a pequeños cambios. Si modificar ligeramente una regla transforma por completo el resultado, el comportamiento puede ser frágil.

La lectura crítica se amplía en cómo interpretar una tabla de rentabilidad de trading. Ese contenido ayuda a separar métricas descriptivas de conclusiones sobre el futuro.

Qué documentación vuelve revisable una prueba

Un informe útil identifica la versión del bot, la fecha de la prueba, el periodo analizado y el origen de los datos. Debe describir reglas, parámetros, horarios, supuestos de ejecución, costes, tratamiento de errores y criterios de exclusión. Los registros deben permitir reconstruir una decisión sin depender de una captura aislada.

También es importante conservar un historial de cambios. Si una regla se modifica después de observar un resultado, la modificación debe quedar documentada antes de volver a probar. Así se distingue una hipótesis previa de una explicación creada después del hecho.

El NIST AI Risk Management Framework propone incorporar consideraciones de confiabilidad al diseño, uso y evaluación de sistemas de inteligencia artificial. Aunque no es una norma específica para bots de trading, su énfasis en evaluación, documentación y gestión continua del riesgo resulta útil como marco general.

Señales de alerta al leer una presentación

Una presentación merece cautela cuando solo muestra el mejor periodo, omite los intentos descartados o no identifica la fuente de los datos. También cuando combina resultados simulados y observados sin diferenciarlos, recorta periodos difíciles o atribuye todo el resultado al algoritmo sin explicar costes.

Otra señal es la ausencia de registros. Una gráfica o cifra no sustituye el detalle necesario para reproducir el cálculo. Conviene revisar qué información pedir ante afirmaciones sobre bots de trading y comparar la explicación con el documento técnico.

Las expresiones absolutas y la presión para decidir rápido no aportan evidencia. Una comunicación responsable reconoce incertidumbre, limita el alcance de la prueba y permite una revisión independiente.

Cómo usar el backtesting como control, no como conclusión

El valor del backtesting aumenta cuando forma parte de un proceso. Primero se define la hipótesis y se registran los supuestos. Después se ejecuta la prueba, se revisan errores y se reserva información para validación. Los resultados se comparan con escenarios alternativos, incluidos costes mayores, datos faltantes y retrasos.

El paso siguiente no consiste en extrapolar automáticamente. Consiste en decidir si la evidencia justifica una evaluación adicional y qué riesgos continúan abiertos. La supervisión debe incluir registros de versiones, alertas y criterios de pausa. En registros y monitoreo en bots de trading se explica cómo conservar trazabilidad ante una anomalía.

Preguntas frecuentes

¿Un backtesting demuestra que un bot funcionará igual en el futuro?

No. Describe una simulación bajo datos y supuestos específicos. El mercado, la liquidez, los costes y la infraestructura pueden cambiar. Su función es ayudar a evaluar reglas y riesgos, no establecer un resultado futuro.

¿Qué significa prueba fuera de muestra?

Es una evaluación realizada con datos que no se usaron para elegir o ajustar las reglas. Ayuda a reducir el sobreajuste, aunque no elimina la incertidumbre ni sustituye el monitoreo posterior.

¿Por qué deben incluirse comisiones y deslizamiento?

Porque afectan el resultado disponible después de ejecutar operaciones. Excluirlos puede hacer que la simulación represente condiciones diferentes de las que se observarían en un entorno real.

¿Qué registro conviene conservar de una prueba histórica?

La versión del sistema, fechas, fuente de datos, reglas, parámetros, costes, exclusiones, resultados completos y cambios posteriores. Esa trazabilidad permite revisar la prueba y comparar versiones.