He estado en reuniones donde alguien presenta una gráfica, sonríe, y suelta la frase: “el modelo tiene un 99 % de accuracy”. La sala asiente. A veces aplaude. A veces se firma un presupuesto. La frase tiene algo de himno: suena a meta alcanzada, a problema resuelto, a noches en scikit-learn que por fin dan fruto. Yo, sentado al otro lado, suelo callar. Y mientras todos celebran, hago la cuenta que casi nunca se hace en voz alta: ¿qué estaba midiendo exactamente ese 99 %? ¿Y qué se quedó fuera?
Un 99 % que no detecta nada
El ejemplo que más uso en clase es el cribado de cáncer de mama. Programa español, datos reales. De cada 10.000 mujeres que pasan la prueba, 40 tienen cáncer. La mamografía acierta 34 de esos 40 y se equivoca con 398 mujeres sanas, a las que cita para una segunda prueba. Sensibilidad real: 85 %. Falsas alarmas: 4 %. Accuracy global: 99,6 %.
Ahora imagínate otro sistema. Uno mucho más simple. Uno que, sin mirar las placas, dice “sin cáncer” a las 10.000 mujeres. Su accuracy es también 99,6 % —más alta que la de la mamografía, de hecho— y no detecta un solo tumor. Ninguno. Cero de cuarenta.
Eso es la paradoja de la exactitud. Cuando la clase que te importa es rara —menos del 5 % de los casos—, la accuracy premia ignorarla. No es un fallo del modelo. Es un fallo de la pregunta. La métrica ha hecho exactamente lo que le pediste: contar aciertos sobre el total. Lo que no te ha dicho es que el coste de los errores estaba colocado todo en el mismo lado. Y ese lado, en sanidad, es el de las personas que se van a casa sin diagnóstico.
Cuando el baseline bate a tu modelo
En el libro trabajamos con Telco Churn: 7.043 clientes de una teleco, 26,5 % en riesgo de abandonar. Si entrenas un modelo y le pides predecir, la opción más barata —“este cliente no se va”— ya te da un 73,5 % de accuracy sin entrenar nada. Una semana de trabajo para superar al “no hace nada” y, sin embargo, ese 73,5 % sigue siendo un modelo inútil: no previene una sola baja, solo confirma lo que ya sabías sobre los que se quedan.
Aquí aparece el matiz que distingue a un técnico de un comercial con PowerPoint. Una métrica alta en un dataset desequilibrado no es un resultado, es una ausencia de resultado. La pregunta correcta no es cuánto acierta el modelo, sino cuánto de lo que te importa está fallando. Y eso se mide con otras herramientas: recall cuando no puedes permitirte perder positivos (cáncer, fraude, fuga de clientes), precision cuando cada falsa alarma cuesta dinero o reputación, F1 cuando necesitas moverte entre ambas sin trampas. En sklearn, todo eso vive en classification_report y en la matriz de confusión, dos funciones que tardas diez minutos en aprender y que cambian la conversación con tu jefe de forma permanente.
Con Telco Churn, el contraste es inmediato:
from sklearn.metrics import classification_report
y_pred_nada = ["no_abandona"] * len(y_true) # baseline: siempre predice la clase mayoritaria
print(classification_report(y_true, y_pred_nada))
# precision recall f1-score
# no_abandona 0.74 1.00 0.85
# abandona 0.00 0.00 0.00
# accuracy 0.74El 74 % de accuracy sigue ahí, orgulloso. Pero la fila de abajo te dice la verdad: el modelo no detecta a ningún cliente en riesgo. Si la dirección te pide “predecir quién se va para retenerlo”, ese 74 % no es una respuesta: es la confirmación de que no has empezado.
La métrica que destruyó el negocio
En la UT08 cuento también la historia de una plataforma de vídeo que optimizó su sistema de recomendaciones para maximizar el tiempo de visualización. El modelo hacía lo que le habían pedido: los usuarios pasaban más horas dentro. Seis meses después, los medios publicaban que el algoritmo empujaba sistemáticamente hacia contenido extremo. Más tiempo en la app, menos calidad de lo que se veía, más personas enfadándose en columnas de opinión.
Es la Ley de Goodhart en estado puro: cuando una métrica se convierte en objetivo, deja de ser una buena métrica. Y no es un caso raro. YouTube optimizó tiempo en pantalla y radicalizó su feed. Un minorista online optimizó ventas cruzadas y descubrió que los clientes compraban más y devolvían más. Una universidad optimizó “tasa de aprobados” y bajó el nivel del examen.
En todos los casos, el modelo funcionó. La pregunta estaba mal hecha.
La decisión que no es técnica
Cuando enseño esto en clase, suelo cambiar el orden del temario. Antes de tocar fit, antes de hablar de árboles o de GradientBoosting, dedico media hora a escribir en la pizarra dos frases: “qué errores me importan más” y “qué consecuencias asumo si me equivoco”. Es la parte menos vistosa del curso. La que más cuesta defender delante de una clase que quiere ver código corriendo. Pero es, con diferencia, la que más dinero ahorra después.
Elegir la función objetivo no es una decisión técnica. Es una decisión sobre el problema. El algoritmo solo ejecuta; la métrica define qué significa “bien” en tu proyecto. Y esa definición la firmas tú, no el modelo. Si firmas a ciegas, el modelo cumplirá. Y tú cargarás con el coste de no haber pensado qué le estabas pidiendo.
La siguiente vez que escuches un porcentaje alto —un 99, un 95, un 85—, no preguntes cuánto es. Pregunta a qué se le llama “éxito” en ese número. Verás cómo cambia la conversación: la cifra seguirá siendo la misma, pero el significado que tiene para el negocio deja de ser un eslogan y vuelve a ser una herramienta. Y muchas veces descubrirás que quien defendía ese número con tanta convicción no lo había mirado de cerca: lo había heredado de una presentación anterior, de un notebook que ya no corre, de un compromiso firmado antes de entender qué estaba midiendo.
Una métrica mal elegida no produce errores. Produce la ilusión de no cometerlos.
La UT08 — Modelado y Machine Learning de Análisis de Datos con Python trabaja este punto antes de entrenar nada: matriz de confusión, sensibilidad, precision, F1 y la pregunta clave de cada proyecto —qué error te puedes permitir—.
¿Has visto alguna vez un 99 % que escondía el problema real?