Tu modelo tiene un 95 % de precisión. Felicidades — ese número, sin contexto, no significa casi nada. La obsesión con el rendimiento de una sola métrica es uno de los modos de fallo más comunes en proyectos de ML.
La trampa de la precisión
Imagina un modelo de detección de fraude donde solo el 1 % de las transacciones son fraudulentas. Un modelo que prediga «no es fraude» para todo logra un 99 % de precisión y es completamente inútil.
El ejemplo es obvio, pero versiones más sutiles atrapan a equipos experimentados. Clases desbalanceadas, distribution shift y métricas proxy abren brechas entre el rendimiento reportado y el valor real.
Métricas alineadas al negocio
Empieza por el resultado de negocio, no por la métrica técnica. Si construyes un sistema de recomendación, importa el impacto en ingresos y el valor de vida del cliente, no solo el CTR.
Trabaja hacia atrás desde euros o rupias. ¿Cuánto cuesta un falso positivo? ¿Y un falso negativo? Esos números deben informar directamente tus criterios de evaluación y la elección de umbrales.
Más allá del test set
El rendimiento en test set es necesario pero no suficiente. Un modelo que brilla en evaluación puede fallar de forma espectacular en producción por data drift, inputs adversariales o casos extremos no representados en tu test.
Implementa monitoreo que siga resultados de negocio junto a las métricas técnicas. Cuando divergen, tienes una alerta temprana.
El factor humano
Los mejores equipos de ML mantienen un escepticismo sano ante números impresionantes. Preguntan «¿qué podría salir mal?» antes de celebrar.
Construye una cultura donde cuestionar las métricas se premia, no se castiga. La meta es entregar valor, no maquillar el dashboard.