Axial Press — Blog

El modelo tenía un 99% de accuracy: la frase que ha costado millones

Sun, 21 Jun 2026 00:00:00 GMT

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.74

El 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?

Por qué escribí un libro de datos para FP (y no otro manual de Python)

Sun, 07 Jun 2026 00:00:00 GMT

Cada vez que alguien me pregunta a qué me dedico, la conversación termina en el mismo lugar: “¿Y no hay ya un libro de Python para datos?”. Sí, los hay. Docenas. Algunos son muy buenos. Y sin embargo, escribí otro. Esta es la historia de por qué.

El hueco que no era de Python

El problema nunca fue Python. Cualquiera puede instalar pandas y abrir un tutorial. El problema es lo que viene después: enseñar a usarlo con criterio en un aula donde el tiempo vale distinto.

En un grado universitario de cuatro años, puedes permitirte un semestre para explicar qué es una variable aleatoria antes de tocar un histograma. En Formación Profesional, el alumno tiene 128 horas repartidas en tres trimestres, un módulo con un nombre oficial que cumplir, y al otro lado una empresa esperando técnicos que abran un CSV el lunes. El manual al uso, con sus 300 páginas de teoría antes del primer read_csv, se queda corto en un sitio y sobra en el otro.

Probé los manuales que recomendaba el departamento, los que recomendaba la editorial grande, los que circulaban en foros. Eran buenos libros, pero oscilaban entre dos extremos: demasiado técnicos para quien empieza, o demasiado difusos, sin hilo conductor. No era el libro que mis alumnos necesitaban.

El 40/60 como constatación, no como eslogan

Cuando planifiqué Análisis de Datos con Python probé con una proporción cercana al 40 % de teoría y 60 % de práctica. No es una decisión estética: es lo que mejor resultado me dio para mantener a los alumnos centrados. Más teoría y se pierde el hilo entre conceptos; menos y los ejercicios se vuelven mecánica sin modelo mental.

En la práctica eso significa que cada unidad alterna un par de páginas de “por qué esto funciona así” con un notebook de tres a cinco horas de trabajo. El hilo conductor de principio a fin es Ames Housing, un dataset con más de 1.400 viviendas reales de Iowa: lo limpias, lo analizas, lo modelas. Es el mismo fichero que va enriqueciéndose a medida que ganas herramientas. Algunas unidades puntuales usan otros datasets abiertos —INE, EPA, Telco Churn— para practicar una técnica concreta, pero la espina dorsal del libro es Ames.

Esa proporción me costó descartar varios capítulos. El de combinatoria avanzada sobre árboles de decisión, por ejemplo. Era interesante. Era lo que un matemático pediría. No era lo que un técnico de grado medio necesita el día que se sienta delante de un modelo en su primer trabajo. Fuera.

Lo que es: una base para especializarte

Este libro es para quien quiere empezar con una especialización sólida en ciencia de datos, no para quien ya está dentro de una. Si tu objetivo es una carrera de investigación en machine learning, vas a necesitar bibliografía más densa; este libro te quedará corto. Pero si estás dando los primeros pasos —en FP, en un bootcamp, en transición desde otro campo:

Aquí encuentras el suelo firme sobre el que construir.

El libro está pensado para tres perfiles:

el alumno de FP que necesita aprobar un módulo, entender lo que hace y poder explicarlo en una entrevista de trabajo.
el profesor de FP que tiene 128 horas y un currículo oficial, y quiere un material que pueda defender ante un inspector sin tener que reinventar los ejercicios cada curso.
el profesional en transición que viene de otro campo (administrativo, técnico de mantenimiento, comercial con datos en Excel) y necesita pasar de “uso Excel” a “pienso en datos” sin pasar por un máster.

Funcional, en dos sentidos

La palabra funcional aparece varias veces en el libro, y a propósito juega con dos sentidos.

El primero es el de hacer: cada capítulo termina con un producto. Un notebook terminado, un mini-informe, un dashboard de Streamlit, un modelo de sklearn con sus métricas. No con un “ahora tú prueba a hacerlo” vago. Con un entregable concreto que el alumno puede enseñar, defender, o subir a un portfolio.

El segundo es el de programación funcional: desde la primera línea apenas verás bucles for. El libro adopta el estilo de los equipos de datos reales —operaciones vectorizadas, apply, agg, pipe, transform— porque es el código que reconocerás el primer día de trabajo. No es capricho estético. Es el lenguaje que comparten los profesionales del dato.

Esta es la diferencia entre un manual y un libro de oficio. El manual te enseña a usar la herramienta.

Los libros de oficio tienen una dignidad que los manuales a veces olvidan.

Una nota sobre el lenguaje

Vas a encontrar en el libro frases como “primero abre el terminal” o “esto fallará la primera vez, vuelve a leer el error”. No es un libro escrito desde arriba. Está escrito como te lo explicaría un compañero que ya ha roto esa pieza tres veces. Si en algún momento una explicación te parece demasiado directa, recuerda: el alumno al que le escribí esto no estaba aprendiendo a programar. Estaba aprendiendo a ganarse la vida con esto. Eso cambia la vara de medir.

Y si este planteamiento te resuena —libro pensado para un oficio, no para una carrera; ratio 40/60; datasets reales; entregable al final de cada capítulo— el libro completo está en Análisis de Datos con Python. Empieza por la UT1 — El Detective de Datos: el resto de unidades se pueden impartir en un curso escolar o trabajarse por libre, con prácticas resueltas para el profesorado y datasets abiertos descargables.

¿Te has encontrado alguna vez con un manual que no era para ti? ¿Qué le faltó?

análisis_final_v2_bueno_ESTE_SI.ipynb: el caos que todos creamos

Sat, 06 Jun 2026 00:00:00 GMT

Todos tenemos uno. Lo sabemos. Está en alguna carpeta, en algún escritorio, en alguna sesión de Google Colab medio olvidada. Se llama analisis_final_v2_bueno_ESTE_SI.ipynb y es el monumento más honesto que ha producido la humanidad: un fichero que grita el caos mental de quien lo creó.

Si te has sentido identificado al leer ese nombre, bienvenido. Este artículo es una sesión de terapia colectiva.

La arqueología del nombre

Pongámonos a excavar. ¿Cómo llega un fichero a llamarse así? Es una historia forense con varias capas.

Primero, lo creas con un nombre razonable: analisis.ipynb. Razonable. Limpio. Casi profesional. Pero luego la vida pasa: un compañero te pide “un cambio rápido”, llega un deadline, tu jefe quiere “solo una versión más”. Y haces lo que haría cualquier ser humano en tu lugar: creas una copia.

analisis_v2.ipynb. Hasta aquí, todo normal. Pero v2 también necesita su propia copia, y luego la “definitiva”, y luego la “que sí va”, y luego la “para el cliente”, y al final, después de un día largo, te encuentras con esta colección en tu escritorio:

analisis.ipynb
analisis_v2.ipynb
analisis_v2_bueno.ipynb
analisis_final.ipynb
analisis_final_v2_bueno.ipynb
analisis_final_v2_bueno_ESTE_SI.ipynb
analisis_final_v2_bueno_ESTE_SI_DE_VERDAD.ipynb
analisis_final_v2_bueno_ESTE_SI_DE_VERDAD_ahora_si.ipynb

Ninguna de esas versiones es la buena. Ni siquiera la que tiene más palabras: son fotos de un mismo proceso, sin contexto, sin orden y sin red de seguridad.

Y aquí está la trampa: ninguna de esas versiones es la buena. Ni siquiera la que tiene más palabras. Todas son fotos de momentos distintos de un mismo proceso, sin contexto, sin orden y sin red de seguridad.

Por qué lo hacemos (spoiler: no es vagancia)

Aquí viene la parte incómoda: nadie hace esto por pereza. Lo hacemos porque nadie nos enseñó a no hacerlo. En la carrera, en el máster, en el bootcamp, en el ciclo formativo, nos enseñan a programar, a manejar datos, a hacer modelos. Lo que casi nunca nos enseñan es a organizar el trabajo como si fuera un proyecto de ingeniería.

Y eso, en parte, tiene sentido: cuando estás aprendiendo, lo urgente es que el código corra. No importa si la carpeta es un vertedero o si el nombre es horrible: lo que importa es que el print("hola mundo") funcione y el gráfico salga.

El problema es que esa forma de trabajar se nos pega. Y el día que te toca hacer un proyecto serio — para una empresa, para un cliente, para un TFG, para un examen con nota — el caos te explota en la cara. Porque el caos, al final, siempre pasa factura. Solo que a veces tarda semanas en llegar.

El día que el caos pasa factura

Te cuento tres escenas que, sospecho, también te han pasado a ti.

Escena 1 — El correo de las 23:47. Tu jefe (o tu profe) te pide “el análisis de ventas del mes pasado”. Tú sabes que lo tienes. Lo hiciste. Lo recuerdas perfectamente. Pero no recuerdas en cuál de los ocho analisis_* está la versión buena. Y como no pusiste comentarios, ni separaste los datos del código, ni versionaste nada, pasas dos horas reabriendo ficheros hasta encontrar el que parece “el bueno”. Si es que existe.

Escena 2 — El compañero nuevo. Llega alguien al equipo. Le pasas tu carpeta de proyecto. Y entonces te mira con esa mezcla de compasión y pánico que solo provoca el código de otro. Porque no hay README, no hay estructura, no hay nada que le diga “esto es lo importante”. Tiene que abrir diez notebooks a ciegas para entender qué hace cada uno.

Escena 3 — El “lo arreglo en un momento”. Estás a punto de enviar tu trabajo. Abres el notebook. Haces “un cambio pequeño”. Lo guardas. Lo rompes. Y ahora, ¿cuál era la versión que funcionaba? No lo sabes. No guardaste copia. No hay Git. Y tu yo del pasado, ese que tenía la versión buena, no puede ayudarte porque ya no existe.

Trabajamos como si fuéramos los únicos que van a tocar ese fichero, y como si nunca más fuéramos a necesitarlo. Las dos cosas son falsas.

Las tres escenas tienen la misma raíz: trabajamos como si fuéramos los únicos que vamos a tocar ese fichero, y como si nunca más fuéramos a necesitarlo. Las dos cosas son falsas. La primera, porque tu yo del futuro te odia cada vez que hereda un proyecto así. La segunda, porque ese código va a volver, te lo garantizo, justo cuando menos te lo esperes.

La cura no es disciplina: es método

La buena noticia es que la solución no requiere heroicidad. No necesitas convertirte en una persona ordenada ni cultivar hábitos de monje. Solo necesitas una estructura mínima que trabaje a tu favor, incluso en tus peores días.

Tres ideas, ninguna nueva, todas probadas:

Una estructura de carpetas que se explique sola. Algo tan simple como data/ para los datasets, notebooks/ para los cuadernos y scripts/ para el código reutilizable. Si además metes output/ para los resultados, ya tienes el 80% del trabajo hecho. No hace falta más, ni tampoco un sistema complejo de doce carpetas: simple, predecible, repetible.
Un naming convention que no dé vergüenza. Nombres descriptivos, fechas en formato ISO (2026-06-05), versiones con números, sin adjetivos emocionales. analisis_ventas_2026q2_v03.ipynb se puede ordenar, buscar y entender dentro de un año. analisis_final_v2_bueno_ESTE_SI_DE_VERDAD_ahora_si_v2.ipynb no hay quien lo ordene, ni lo busque, ni lo recuerde.
Git, aunque sea un poco. No necesitas ser un gurú de las ramas ni entender rebase interactivo. Con cuatro comandos (add, commit, push, pull) ya tienes un historial de qué cambió, cuándo y por qué. Es la única máquina del tiempo fiable que existe para el código. Y, además, te obliga a pensar antes de guardar.

Y aquí viene el secreto a voces: estas tres cosas se enseñan el primer día de cualquier trabajo serio de datos. Quien las aprende pronto trabaja el doble de rápido que quien las aprende tarde. Y quien nunca las aprende acaba con un monumento al caos en su escritorio y con la misma escena de pánico cada trimestre.

Una pregunta para llevar

Y antes de cerrar, te dejo con la pregunta que de verdad importa:

¿Cuál es el nombre de fichero más vergonzoso que has creado tú, y qué aprendiste (o no) después?

Cuéntamelo. Prometo no juzgar: yo también guardo los míos como prueba de que todos empezamos igual.

Y si este tema te resuena y quieres empezar a montar tus proyectos con una estructura limpia desde el minuto uno, en la UT1 — El Detective de Datos del libro empezamos exactamente por aquí: el flujo de trabajo profesional, la organización de carpetas y las herramientas con las que un proyecto se entiende de un vistazo. A veces, lo más importante de un proyecto de datos no es el modelo. Es todo lo que hay alrededor del modelo.