¿Qué métrica deberías mirar: exactitud, precisión o recall? Elegir bien empieza por entender el problema

En una entrada anterior vimos que no existen métricas buenas o malas para los modelos de clasificación, sino preguntas mal planteadas. Cada métrica mide algo distinto: el promedio de aciertos, la fiabilidad al predecir, la capacidad para no dejar escapar casos importantes…

Pero, una vez entendido eso, a la hora de evaluar un modelo de clasificación, surge la siguiente pregunta práctica:

¿Cuál debería usar en mi caso particular?

Y aquí es donde muchos proyectos tropiezan. No porque no sepan calcular métricas, sino porque intentan elegir la métrica mirando el modelo… en lugar de mirar el problema. El problema nos va a decir si lo importante son los aciertos, la fiabilidad o la capacidad para no dejar escapar casos, no el modelo.

Elegir una métrica no es una decisión técnica aislada. Es una decisión sobre qué tipo de error estás dispuesto a aceptar y cuál no.

El primer paso no es técnico: es estratégico

Antes de importar funciones de evaluación o calcular nada, conviene responder a una pregunta muy simple:

¿Qué error sería más grave en este sistema?

No el más frecuente. No el más incómodo. El más grave. Porque no todos los errores tienen el mismo impacto en el problema que se desea resolver. Un falso positivo puede ser molesto. Un falso negativo puede ser peligroso. Y a veces ocurre justo al revés.

En Analytics Lane

Nuevo test de normalidad interactivo en el laboratorio de Analytics Lane

La métrica adecuada no depende del algoritmo. Depende de las consecuencias de este en nuestro problema.

Caso 1: Cuando equivocarte al actuar es muy caro

Imagina un sistema que bloquea automáticamente operaciones con tarjetas bancarias por posible fraude.

Si el sistema bloquea una tarjeta legítima:

• el usuario se enfada
• el banco recibe reclamaciones
• la confianza disminuye

En este caso, el problema no es dejar pasar algún fraude ocasional. El problema es actuar sin motivo suficiente.

Aquí la pregunta clave es:

“Cuando digo que hay fraude, ¿suele ser verdad?”

Esa es exactamente la pregunta que responde la precisión.

Cuando el coste de un falso positivo es alto, la precisión debe ser una métrica central. No implica ignorar el resto, pero sí priorizar la fiabilidad al actuar.

Caso 2: Cuando no actuar es lo verdaderamente peligroso

Ahora cambiemos de escenario. Un sistema que detecta posibles tumores en imágenes médicas.

Si el sistema no detecta un tumor real:

• el diagnóstico se retrasa
• el tratamiento se complica
• el riesgo aumenta

Aquí el error más grave no es alarmar de más. Es no detectar lo que está ahí.

La pregunta relevante cambia:

“De todos los casos que realmente son problemáticos, ¿cuántos detecto?”

Eso es exactamente lo que mide el recall.

En contextos donde el coste de perder un caso es alto, el recall se convierte en la prioridad.

Caso 3: Cuando el problema está equilibrado

Hay situaciones en las que:

• las clases están más o menos equilibradas
• el coste de equivocarse en un sentido u otro es similar
• el modelo no activa acciones drásticas

Por ejemplo, clasificar noticias por categoría, ordenar comentarios por tema o etiquetar imágenes.

En estos casos, mirar el promedio de aciertos puede ser razonable. Aquí la exactitud tiene sentido como métrica de referencia general.

Pero, incluso en estos casos, conviene revisar que el modelo no esté funcionando bien para unas clases y mal para otras.

Caso 4: Cuando necesitas equilibrio entre no equivocarte y no dejar pasar nada

Muchos problemas no presenta casos extremos en cuanto a los tipos de errores. No se trata solo de evitar falsos positivos ni solo de detectar todo. Se trata de encontrar un punto intermedio.

Por ejemplo:

• sistemas de moderación de contenido
• detección de spam
• recomendaciones sensibles

Aquí puede tener sentido mirar una métrica que combine precisión y recall, como el F1-score, para asegurarte de que no estás sacrificando completamente uno en favor del otro.

Pero hay que recordar que el equilibrio no siempre es neutral. A veces, el problema puede exigir inclinarse ligeramente hacia uno de los dos lados.

Una pregunta más útil que cualquier métrica

Hay una forma muy práctica de decidir qué métrica priorizar. Preguntarse:

Si este sistema se equivoca 100 veces, ¿qué tipo de error preferiría que cometiera?

• ¿Que moleste 100 veces sin motivo?
• ¿Que deje pasar 100 casos importantes?
• ¿Que reparta los errores de forma equilibrada?

La respuesta a esa pregunta casi siempre señala la métrica que debería tener más peso en la evaluación.

Cuando el problema no es solo técnico, sino humano

Las métricas no viven en el vacío. Viven en sistemas donde hay personas. Un modelo con recall altísimo puede ser ignorado si genera demasiadas alertas. Un modelo con precisión altísima puede ser irrelevante si casi nunca interviene.

Por eso, elegir métricas también implica pensar en:

• la experiencia del usuario
• la tolerancia al error
• la confianza en el sistema

A veces, el mejor modelo en métricas no es el mejor modelo en uso real.

No se trata de elegir una sola métrica

Otro error frecuente es buscar “la métrica correcta” como si fuera única. En la práctica, lo más sensato suele ser:

• elegir una métrica principal alineada con el objetivo
• complementarla con otras que aporten contexto

Por ejemplo:

• priorizar recall, pero vigilar la precisión
• priorizar la precisión, pero controlar el recall
• usar la exactitud como referencia general

Las métricas no deben competir entre sí. Deben ayudarnos a entender distintas dimensiones del comportamiento del modelo.

La tentación de elegir la métrica más favorecedora para el modelo

Hay una trampa muy humana que puede aparecer al seleccionar la métrica. Cuando entrenamos un modelo y vemos varias métricas, es tentador destacar aquella en la que mejor sale. Por ejemplo, una exactitud del 90 % porque las clases están muy desbalanceadas. Es fácil justificarlo después: “esta es la más adecuada para el problema, porque…”.

Pero, si la métrica no fue elegida antes de entrenar, la decisión pierde objetividad. Se escogió el mejor número, pero no la métrica más adecuada.

La decisión sobre qué métrica importa más para nuestro problema debería tomarse antes de ver los resultados. Porque en ese momento es cuando aún estamos pensando en el problema, no en defender el modelo.

Elegir bien es entender el sistema completo

Al final, elegir una métrica no es una cuestión matemática. Es una cuestión de diseño del sistema.

Implica preguntarse:

• ¿Qué decisiones se toman con este modelo?
• ¿Qué ocurre cuando se equivoca?
• ¿Quién sufre las consecuencias?
• ¿Qué error es más tolerable?

La métrica adecuada no es la más sofisticada ni la más popular. Es la que mejor refleja el tipo de error que realmente importa en tu contexto.

Conclusiones: la métrica correcta es la que responde a tu pregunta real

Si en la primera entrada vimos que cada métrica responde a una pregunta distinta, en esta la conclusión es clara:

La métrica correcta no depende del algoritmo.
Depende del problema que estás intentando resolver.

Elegir métricas no es un trámite técnico. Es una decisión estratégica sobre cómo defines el éxito de tu modelo a la hora de resolver el problema para el que se creó.

Y cuando esa definición es clara, las métricas dejan de ser números aislados y se convierten en herramientas útiles para construir sistemas mejores.

Nota: La imagen de este artículo fue generada utilizando un modelo de inteligencia artificial.