Clases desbalanceadas: evaluar un clasificador más allá de la exactitud

Un clasificador que acierta casi todos los casos puede ser inútil para la tarea que motivó su creación. En una clasificación con clases desbalanceadas, la clase frecuente puede dominar la exactitud global y ocultar que el sistema no encuentra los eventos que interesa detectar. La evaluación debe mostrar qué casos encuentra, cuáles pierde y cuántas acciones provoca.

Esto importa, por ejemplo, al priorizar incidencias poco habituales para revisión. El problema no se resuelve automáticamente equilibrando el entrenamiento: primero hay que definir la decisión que se tomará con cada predicción y evaluar sobre una población que represente el uso previsto.

Un ejemplo que cambia la lectura de la exactitud

Considera un conjunto ficticio de 1.000 incidencias, de las cuales 20 requieren atención especial y 980 no. Todos los valores de este artículo son un ejemplo aritmético construido; no representan resultados de un modelo entrenado ni un proyecto de Nexeus Big Data.

Un sistema que siempre responde «no requiere atención especial» acierta 980 veces: su exactitud es del 98 %. Sin embargo, no detecta ninguna de las 20 incidencias relevantes. Si la función del modelo es encontrarlas, esa cifra global no describe un resultado satisfactorio.

Ahora supongamos que otro sistema envía 50 incidencias a revisión. Entre ellas aparecen 16 de las 20 que realmente requieren atención especial y 34 que no la requieren. Su matriz queda así:

Resultado real	Predice atención especial	Predice atención ordinaria	Total
Requiere atención especial	16 verdaderos positivos	4 falsos negativos	20
No la requiere	34 falsos positivos	946 verdaderos negativos	980
Total	50	950	1.000

Este segundo sistema acierta 962 casos, un 96,2 %. Tiene menos exactitud global que el primero, pero identifica 16 casos relevantes que aquel ignoraba. Todavía no sabemos si es adecuado para operar: hay que valorar los cuatro casos perdidos y la capacidad de revisar las 50 alertas.

Traducir las métricas a preguntas operativas

La documentación de métricas de clasificación de scikit-learn define precisión y recall a partir de verdaderos positivos, falsos positivos y falsos negativos. En este ejemplo, la clase positiva es «requiere atención especial»; debe quedar explícita para evitar interpretar las métricas al revés.

• Precisión positiva: de los casos enviados a revisión, cuántos eran relevantes. Aquí es 16 / 50 = 32 %.
• Recall o sensibilidad positiva: de todos los casos relevantes, cuántos detectó el sistema. Aquí es 16 / 20 = 80 %.
• Exactitud: cuántas predicciones totales coinciden con la referencia. Aquí es (16 + 946) / 1.000 = 96,2 %.
• Carga de revisión: cuántos casos requieren una acción posterior. Aquí son 50. Esta cantidad no es una métrica de calidad predictiva, pero condiciona el uso del sistema.

No confundas precisión con exactitud al traducir informes. Tampoco informes solo de un promedio entre clases: entrega la matriz, el número de ejemplos de cada clase y las métricas relevantes por separado. Cuando hay muy pocos positivos, cambiar la clasificación de unos pocos casos mueve mucho el porcentaje.

Un indicador agregado, como F1, puede facilitar comparaciones, pero no reemplaza la matriz ni refleja automáticamente el coste de cada error. La elección de una métrica principal debe corresponder a la decisión del proceso.

Fijar un umbral con datos de validación

Si el modelo produce una puntuación, el umbral que transforma esa puntuación en una decisión afecta al número de alertas. No aceptes el umbral predeterminado como una regla de negocio. Tampoco supongas que la puntuación representa una probabilidad bien calibrada sin comprobarlo.

En validación, construye una tabla con varios umbrales: verdaderos positivos, falsos positivos, falsos negativos y volumen de revisión. Describe qué acción se tomaría en cada caso y qué condiciones impedirían usar ese umbral. Una cola que crece más deprisa de lo que puede revisarse puede dejar sin atención alertas correctas.

El responsable del proceso debe valorar la importancia de los casos perdidos y el trabajo asociado a las falsas alarmas. Si esos costes no están medidos, registra la incertidumbre; no inventes un ahorro económico para convertir la tabla en una conclusión comercial.

Selecciona el umbral con entrenamiento y validación según el protocolo acordado. Reserva un conjunto final que no se utilice para elegir entre modelos, variables, técnicas de balanceo o umbrales. Cambiar repetidamente el sistema para mejorar ese conjunto lo convierte de hecho en otro conjunto de validación.

Evitar que el balanceo contamine la evaluación

Aplicar sobremuestreo a todo el conjunto y dividir después puede introducir información relacionada con ejemplos de prueba en el entrenamiento. También puede alterar la proporción de clases sobre la que medimos. La documentación de imbalanced-learn explica estos errores de remuestreo y fuga de información.

Separa primero los datos según el escenario de uso. Si entrenas para predecir periodos futuros, respeta el orden temporal. Si varias filas pertenecen a una misma entidad, comprueba que la partición no permite reconocer en prueba una entidad que el sistema no conocería al operar. Estratificar por clase no resuelve por sí solo esas dependencias.

Las transformaciones aprendidas y el remuestreo deben ajustarse dentro de la parte de entrenamiento de cada partición. Evalúa sobre datos con una distribución representativa del uso previsto. Si construyes una muestra especial para estudiar errores raros, identifícala y no extrapoles directamente su precisión a toda la población.

Revisar etiquetas y segmentos antes de concluir

Una matriz presupone una referencia fiable. Comprueba cuándo se conoce el resultado real, quién lo determina y qué ocurre con etiquetas dudosas o pendientes. Tratar como negativo un caso cuyo resultado aún no llegó puede distorsionar la evaluación.

Examina errores por segmentos operativos que tengan sentido: origen de la incidencia, tipo de proceso o periodo, siempre con los permisos y el contexto adecuados. Informa del tamaño de cada segmento. Una tasa calculada sobre unos pocos casos necesita una interpretación prudente y más evidencia antes de convertirse en una regla.

Si aparecen duplicados o variables que revelan un resultado posterior, corrige el diseño de evaluación antes de comparar algoritmos. Una mejora aparente puede proceder de información que nunca estará disponible en el momento de predecir.

Preparar la decisión de uso

El expediente de evaluación debería permitir reconstruir la población, el periodo, las etiquetas, las particiones, el umbral y la matriz final. Añade el volumen de revisión previsto y el procedimiento para los casos que el modelo deja fuera. Después, define cómo se observarán cambios en la proporción de positivos y en los errores cuando lleguen nuevas etiquetas.

El ejemplo muestra por qué una exactitud menor puede acompañar una detección más útil; no demuestra que cualquier aumento de recall justifique sus falsas alarmas. La decisión requiere ambas dimensiones y el contexto del proceso.

Si estás valorando un sistema de inteligencia artificial y machine learning, podemos revisar su protocolo de evaluación a partir de una matriz anonimizada y la acción asociada a cada predicción. Así la conversación comienza por una decisión comprobable, antes de elegir un algoritmo.