Exactitud, precisión, recall… y los errores que cometemos al interpretarlas en proyectos reales

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:

• La exactitud responde a “¿cuánto acierto en promedio?”
• La precisión responde a “cuando digo que algo es positivo, ¿cuántas veces tengo razón?”
• El recall responde a “de todos los positivos reales, ¿cuántos logro detectar?”

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.

Error 1: Usar una sola métrica, el error más habitual

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

En Analytics Lane

Nuevo test de normalidad interactivo en el laboratorio de Analytics Lane

¿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:

• La exactitud mira el promedio global.
• La precisión mira la fiabilidad de los positivos predichos.
• El recall mira la cobertura de los positivos reales.
• El F1 intenta equilibrar precisión y recall.

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:

• Modelos con alta exactitud pero que no detectan casos críticos.
• Modelos con buena precisión pero que dejan escapar la mayoría de los casos relevantes.
• Modelos optimizados para F1 que no están alineados con el coste real del negocio.

Siempre se debe tener en cuenta que una métrica es un resumen. No es un diagnóstico completo.

Error 2: Confundir mejora numérica con mejora real

Otro error muy común es asumir que, si el número mejora, el modelo mejora. Imagina que un modelo pasa de:

• Precisión: 0.78 → 0.82
• Recall: 0.65 → 0.60

¿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:

• Se optimiza una métrica de validación sin revisar el impacto en producción.
• Se mejora el F1 pero aumentan los falsos positivos de forma inasumible.
• Se reduce el error promedio pero empeora el rendimiento en un subgrupo crítico.

Las métricas no son el objetivo final. Son indicadores intermedios. El objetivo final es resolver un problema real con costes reales.

Error 3: Ignorar el desbalanceo de clases

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á:

• Exactitud: 98%

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:

• 80/20
• 85/15
• 90/10

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:

• El modelo parezca sólido.
• Los cuadros de mando se vean bien.
• Las decisiones se tomen con confianza.

Hasta que el modelo empieza a fallar justo donde importa. En contextos como:

• Detección de fraude
• Diagnóstico médico
• Mantenimiento predictivo
• Seguridad

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.

Error 4: Optimizar métricas sin entender el coste del error

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:

• La exactitud penaliza igual un falso positivo que un falso negativo.
• El F1 no distingue el coste real del negocio.
• Incluso precisión y recall, aunque separan tipos de error, no incorporan directamente su impacto económico.

En proyectos reales, el error no es simétrico. Por ejemplo, en un sistema de spam:

• Falsos positivos → pierdes correos legítimos.
• Falsos negativos → dejas pasar spam.

En un sistema de detección de cáncer:

• Falsos negativos → riesgo vital.
• Falsos positivos → pruebas adicionales.

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.

Error 5: No considerar el umbral de decisión

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:

• Si probabilidad > 0.5 → positivo.
• Si probabilidad ≤ 0.5 → negativo.

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:

• Umbral alto → mayor precisión, menor recall.
• Umbral bajo → mayor recall, menor precisión.

En proyectos reales, es común:

• Evaluar el modelo con un umbral.
• Desplegarlo con otro.
• O peor: cambiar el umbral en producción sin reanalizar métricas.

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.

Error 6: Comparar métricas entre conjuntos de datos diferentes

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:

• Comparaciones injustas entre modelos.
• Expectativas irreales.
• Decisiones de inversión mal fundamentadas.

Una métrica sin contexto no es información. Es ruido.

Error 7: Sobreinterpretar pequeñas diferencias

Este error es algo que puede provocar grandes pérdidas de tiempo sin sentido. Por ejemplo, un modelo tiene:

• F1 = 0.812

Otro modelo:

• F1 = 0.819

¿Es mejor el segundo? Tal vez. Pero:

• ¿Es estadísticamente significativo?
• ¿Es estable en validación cruzada?
• ¿Es consistente en diferentes periodos de tiempo?

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.

Error 8: Olvidar que las métricas cambian en producción

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:

• Cambia el comportamiento de los usuarios.
• Cambian los patrones de fraude.
• Cambia el mercado.
• Cambian las políticas.

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:

• Medir una vez.
• Celebrar.
• Y no volver a medir.

Las métricas no son una auditoría puntual. Son un proceso continuo.

Error 9: Creer que las métricas sustituyen al juicio humano

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í:

• Ser opaco (un problema en sectores regulados).
• Ser difícil de explicar.
• Generar decisiones difíciles de defender.
• No alinearse con valores organizativos.

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.

Una forma más madura de usar métricas

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:

• Usar varias métricas complementarias.
• Entender el coste real del error.
• Analizar el desbalanceo.
• Ajustar el umbral según objetivos.
• Validar en múltiples escenarios.
• Monitorizar en producción.
• Evitar decisiones basadas en diferencias mínimas.

No se trata de complicar innecesariamente. Se trata de respetar la complejidad del problema.

Conclusiones: medir bien es pensar bien

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.