En dos artículos anteriores hemos intentado explicar qué mide cada métrica de clasificación desde una perspectiva conceptual e intuitiva y cuál deberíamos usar para el problema que queremos resolver en cada caso, viendo a qué pregunta responde cada una de las métricas. En concreto, se han visto los siguientes puntos:
Como se puede apreciar, son preguntas distintas. Y, por tanto, las respuestas que se obtienen también son diferentes en cada caso.
Sin embargo, comprender qué mide cada métrica no es suficiente. El verdadero problema en proyectos reales no es no saber la fórmula. El problema es interpretarlas mal.
En esta tercera entrada vamos a abordar algo todavía más importante: los errores más comunes al usar e interpretar métricas en proyectos reales. Porque no existen métricas peligrosas ni erróneas. Existen interpretaciones peligrosas.
Tabla de contenidos
Este no solo es el error más frecuente, sino que también es el más dañino. Un equipo entrena un modelo. Lo evalúa. Obtiene un número. Ese número parece bueno. Y ahí termina la discusión.
“Tiene un 94% de exactitud. Está listo.”
¿Está listo para qué? ¿Para producción, una demo, un entorno regulado, decidir créditos, detectar tumores?
El problema no es que la métrica esté mal. El problema es asumir que una sola métrica resume todo el comportamiento del modelo. Como se ha visto en las entradas anteriores, cada métrica observa el modelo desde un ángulo distinto:
Usar una sola métrica es como evaluar a un estudiante únicamente por su nota media sin mirar en qué asignaturas suspende.
En proyectos reales, esto se traduce en:
Siempre se debe tener en cuenta que una métrica es un resumen. No es un diagnóstico completo.
Otro error muy común es asumir que, si el número mejora, el modelo mejora. Imagina que un modelo pasa de:
¿Ha mejorado? Depende. Si estamos detectando fraude, quizás perder recall hace que el modelo sea menos útil que el anterior. Si estamos enviando alertas médicas, quizá perder cobertura es inaceptable.
Recordemos que las métricas no tienen significado por sí solas; tienen significado dentro de un contexto. Una mejora técnica puede ser una degradación operativa.
En proyectos reales esto ocurre cuando:
Las métricas no son el objetivo final. Son indicadores intermedios. El objetivo final es resolver un problema real con costes reales.
Este es un clásico. Supongamos que el 98% de los casos son negativos y solo el 2% son positivos. Algo muy habitual, o incluso peor, en problemas reales como la detección de fraude o pruebas médicas. En este caso, un modelo que siempre predice “negativo” tendrá:
Parece bueno, pero no detecta absolutamente ningún positivo. Es un modelo completamente inútil para su propósito. Esta problemática es ampliamente conocida, pero sigue ocurriendo en proyectos reales. ¿Por qué? Porque el desbalanceo no siempre es extremo. A veces es sutil:
Y ahí es donde la exactitud empieza a engañar de una forma más sofisticada. Cuando una clase es dominante, la exactitud tiende a reflejar principalmente el rendimiento sobre esa clase.
Esto provoca que:
Hasta que el modelo empieza a fallar justo donde importa. En contextos como:
El desbalanceo no es una rareza. Es la norma. Y usar exactitud sin analizar precisión y recall es como conducir mirando solo el velocímetro.
No todos los errores valen lo mismo. Un falso positivo puede ser molesto, mientras que un falso negativo puede ser catastrófico. Por ejemplo, un falso positivo en la detección de un cáncer puede ser molesto, requerir más pruebas para descartarlo, pero un falso negativo puede evitar que el problema se trate a tiempo. O, en otros problemas, sucede al revés.
Pero las métricas estándar tratan todos los errores de la misma manera. Por ejemplo:
En proyectos reales, el error no es simétrico. Por ejemplo, en un sistema de spam:
En un sistema de detección de cáncer:
Sin una discusión explícita sobre el coste del error, las métricas pueden optimizar la dirección equivocada. El error frecuente aquí es técnico-cultural: se habla de números, pero no se habla de consecuencias.
La mayoría de los modelos no producen etiquetas directamente, sino que calculan probabilidades para después aplicar un umbral a la hora de convertirlas en una etiqueta:
Pero ese 0.5 no es una ley natural, es una simple convención. Aunque intuitiva, puede no ser la mejor elección para nuestro problema particular. Dado que cambiar el umbral modifica precisión y recall, se puede usar esto para adaptar las predicciones a nuestras necesidades:
En proyectos reales, es común:
El error aquí no es matemático. Es conceptual. Las métricas no describen el modelo en abstracto. Describen el modelo bajo un umbral concreto.
Sin analizar la curva completa (como ROC o Precision-Recall), estamos viendo solo una fotografía parcial.
Otro error muy habitual:
“Nuestro modelo tiene un F1 de 0.87, mejor que el del artículo X que tiene 0.82.”
Pero ¿es el mismo conjunto de datos? O incluso peor, ¿es el mismo problema? Las métricas dependen fuertemente de los datos. Compararlas sin contexto es como comparar la velocidad media de un coche en ciudad con la de otro en autopista.
En proyectos reales, este error se traduce en:
Una métrica sin contexto no es información. Es ruido.
Este error es algo que puede provocar grandes pérdidas de tiempo sin sentido. Por ejemplo, un modelo tiene:
Otro modelo:
¿Es mejor el segundo? Tal vez. Pero:
En muchos proyectos se elige un modelo por diferencias mínimas que pueden deberse al azar. Sin validación robusta, la precisión numérica puede dar una falsa sensación de certeza. Más decimales no significan más verdad.
Un modelo no vive en el conjunto de datos de validación. Vive en el mundo real, con los datos reales. Y no es necesario recordar que el mundo cambia:
Lo que tenía una precisión del 0.85 puede caer a 0.60 sin que el modelo “se rompa” técnicamente. En proyectos reales, uno de los errores más graves es:
Las métricas no son una auditoría puntual. Son un proceso continuo.
Las métricas son herramientas que se usan para tomar decisiones. No son quienes toman las decisiones. Es la persona quien selecciona un modelo u otro. Un modelo puede tener excelentes métricas y, aun así:
Reducir la evaluación a un número es cómodo. Pero los proyectos reales no son ejercicios académicos. La interpretación final siempre requiere criterio humano.
Después de revisar todos estos errores, quizá la conclusión parezca pesimista. Pero en realidad es lo contrario. Las métricas que hemos visto son herramientas maravillosas cuando se usan con sentido común. Esto implica no solo coger el número, sino que:
No se trata de complicar innecesariamente. Se trata de respetar la complejidad del problema.
Al final, el mayor error no es técnico. Es conceptual. Cuando interpretamos una métrica como si respondiera a una pregunta distinta de la que realmente responde, estamos construyendo decisiones sobre una base equivocada.
Las métricas no mienten. Pero pueden ser malinterpretadas. Y en proyectos reales, la diferencia entre una buena decisión y una mala no suele estar en la fórmula.
Está en la pregunta. Si sabemos qué pregunta estamos haciendo, y qué pregunta estamos ignorando, las métricas dejan de ser números aislados y se convierten en herramientas de pensamiento. Y ese es, en última instancia, el objetivo de toda esta serie no fue aprender fórmulas, sino que aprender a preguntar mejor.
Nota: La imagen de este artículo fue generada utilizando un modelo de inteligencia artificial.
En un mundo donde los datos se han convertido en el lenguaje dominante de la…
Llevas un rato analizando datos y tienes cuatro gráficos abiertos en ventanas separadas: ventas, usuarios,…
Hace poco publiqué una entrada en la que trataba de un sesgo bien documentado: aferrarse…
En un entrada previa explicamos qué son el WOE y el IV y por qué…
Seguimos evolucionando el laboratorio de Analytics Lane y hoy lanzamos la versión 1.1, disponible en:…
“El interés compuesto es la octava maravilla del mundo. El que lo entiende lo gana…
This website uses cookies.