← Volver

Lo que aprendimos midiendo mal durante meses

🌐 Versión en inglés próximamente · English version coming soon

El primer artículo de esta serie contaba cómo casi retiramos nuestro mejor bot por un error de medición. Este cuenta el resto: qué encontramos cuando decidimos auditar todo lo demás, y por qué el resultado más valioso no fue ningún bot — fue la forma de trabajar que tuvimos que construir para llegar hasta ahí.

La pregunta que empezó todo

Después de meses operando, nos hicimos una pregunta incómoda: ¿confiamos en estos números porque los verificamos, o porque nunca los cuestionamos?

La respuesta, cuando empezamos a mirar en serio, fue la segunda. Y durante dos semanas encontramos, uno detrás de otro, ocho errores distintos en cómo el sistema medía su propio desempeño. Ninguno era un fraude ni una negligencia grosera — eran el tipo de error que se acumula en cualquier sistema que crece rápido y nadie tiene tiempo de auditar hasta que hace falta.

Los ocho no apuntaban en la misma dirección: unos nos hacían ver peor de lo que éramos, otros mejor. Eso es justamente lo que los hacía difíciles de detectar — no había un sesgo consistente que nos avisara.

Los errores, en corto

Cada uno, por separado, parece un detalle técnico. Juntos, significaban que durante meses tomamos decisiones —qué estrategia mantener, cuál descartar— sobre números que no describían la realidad.

El caso que cambió cómo trabajamos

El más costoso fue el de Titan, el bot que mencionamos en el primer artículo. Lo retiramos por una ganancia marginal que resultó estar mal calculada — el error de la ventana de 12 días. Con el dato correcto, era el mejor bot del sistema.

Lo rescatamos a tiempo. Pero la pregunta que nos dejó fue peor que el error en sí: ¿cuántas veces habíamos tomado la decisión contraria — mantener algo que en realidad no funcionaba— sin que ningún bug nos avisara?

Esa pregunta es la que nos llevó a auditar todo lo demás, no solo lo que ya sospechábamos.

Lo que construimos para que no volviera a pasar

No alcanzaba con corregir los números una vez. Un sistema que se mide mal una vez puede volver a medirse mal la próxima semana, con datos nuevos. Así que además de arreglar cada error, construimos mecanismos para que el sistema avise cuando algo falla, en vez de fallar en silencio:

Ninguna de estas tres cosas genera ganancia. Todas reducen la probabilidad de que un error se convierta en una pérdida real antes de que alguien lo note.

La parte que no es sobre trading

Acá está lo que queremos dejar claro, porque es la razón por la que escribimos esto en primer lugar: el resultado financiero de ese período fue modesto. El sistema, en conjunto, sigue sin ser rentable. Una estrategia muestra evidencia temprana de funcionar, con muy pocos datos. Otra, la que rescatamos, sigue sin confirmarlo — su resultado se volvió negativo en los días siguientes, y es exactamente el tipo de dato que vamos a seguir publicando, funcione a favor o en contra.

Pero el proceso de encontrar y corregir ocho errores en un sistema que opera con dinero real, sin romper nada, verificando cada cambio antes de aplicarlo — eso es un activo que no depende de si el mercado coopera esta semana o no.

Automatizar bien no es escribir un bot que a veces acierta. Es construir algo que puedas confiar en auditar, corregir y verificar de forma sistemática, incluso cuando lo que encuentra es incómodo. Esa habilidad se traslada a cualquier sistema — de trading o de cualquier otra cosa — que dependa de datos para tomar decisiones.

Vamos a seguir midiendo, seguir publicando lo que encontremos, y seguir corrigiendo en público cuando haga falta. Es más lento que prometer resultados. Pero es lo único que, hasta ahora, demostró producir algo sólido de forma consistente.

← Volver al primer artículo: Cómo auditamos HCS Traders

HCS Traders · Este artículo describe resultados pasados con capital real. Los resultados pasados no garantizan resultados futuros.