Cuando entrenamos un modelo de Machine Learning para tareas de clasificación, muchas veces nos tenemos que enfrentar a un problema que es sumamente común en la Ciencia de Datos: la presencia de datos desbalanceados.
Básicamente, un set de datos desbalanceado es aquel donde tenemos muchos más datos correspondientes a unas categorías y muy pocos datos correspondientes a otras.
Esta situación se puede convertir en un problema crítico no solo al momento de entrenar el modelo, sino también al momento de evaluar de forma objetiva su desempeño.
Así que en este artículo veremos en detalle qué son los datos desbalanceados, por qué se originan, qué efecto tienen al momento de construir un clasificador de Machine Learning y, lo más importante, las diferentes estrategias que podemos implementar para manejar y mitigar este problema.
¿Qué son los datos desbalanceados?
En esencia, vamos a tener un set de datos desbalanceado siempre que tengamos una cantidad significativamente mayor de datos de una categoría (o de varias) en comparación con otra.
Para ilustrar este concepto, veamos tres ejemplos clásicos:
- Detección de fraudes bancarios: si analizamos un histórico de transacciones bancarias, lo que estadísticamente esperaríamos es que la gran mayoría de las veces las transacciones sean normales y solo en unas contadas ocasiones aparezcan transacciones fraudulentas. Esta desproporción es un ejemplo perfecto de un set de datos desbalanceado.
- Control de calidad en manufactura: si una empresa que fabrica vehículos saca sus productos al mercado, la expectativa es que la inmensa mayoría de ellos funcionen correctamente y que solo unos cuantos presenten problemas en el sistema de frenos. Esa minoría de autos defectuosos frente a la gran mayoría de carros en buen estado conforma un dataset desbalanceado.
- Diagnóstico médico: si hablamos de un sistema basado en IA para detectar enfermedades cardíacas en pacientes, lo que podemos esperar es que la gran mayoría de las personas que se sometan a la prueba sean personas sanas o normales y que sólo unas cuantas tengas efectivamente la patología cardíaca. Así que en este caso también nos enfrentamos a un escenario de desbalance en los datos.
¿Por qué se originan los datos desbalanceados?
Esencialmente existen dos razones principales que explican la presencia de datos desbalanceados en nuestros proyectos de Machine Learning:
1. La naturaleza intrínseca de los datos
En la mayoría de los casos, los datos simplemente «son así». Si volvemos a los ejemplos de detección de fraudes, fallas de frenos o diagnósticos médicos, en todos estos escenarios los eventos de interés representan anomalías. Es decir, son sucesos que ocurren solo ocasionalmente de forma natural. Lo estadísticamente normal es que las transacciones sean legítimas, los vehículos no fallen o los pacientes estén sanos; por lo tanto, los datos anómalos siempre constituirán una minoría matemática.
2. Errores o sesgos en la recolección de los datos
La segunda razón ocurre cuando no recolectamos los datos de manera estadísticamente adecuada.
Supongamos que trabajamos en una empresa de telecomunicaciones que busca medir la percepción de calidad del servicio por parte de los clientes. Naturalmente, algunos clientes evaluarán el servicio como bueno y otros como deficiente.
Sin embargo, al momento de acceder a la base de datos para construir nuestro set de entrenamiento, ignoramos la necesidad de aplicar un muestreo aleatorio y, en su lugar, introducimos un sesgo al extraer únicamente (o en su gran mayoría) los registros asociados a las quejas o percepciones negativas. Al inducir este sesgo, estamos generando artificialmente un set de datos desbalanceado.
Implicaciones de entrenar modelos con datos desbalanceados
Ignorar el balanceo de clases puede tener consecuencias graves en los resultados de nuestro proyecto. Las principales implicaciones son:
1. Generación de sesgos en el modelo
La primera implicación directa es que el modelo resultante presentará un sesgo severo hacia la clase mayoritaria.
Por ejemplo, supongamos que construimos un clasificador para detectar fraudes financieros con un dataset donde el 98% de las transacciones son normales y solo el 2% son fraudulentas:
Lo que ocurrirá en este caso es que, tras el entrenamiento, el modelo aprenderá a identificar con altísima precisión los patrones de la clase mayoritaria (las transacciones normales). Sin embargo, al contar con tan pocas muestras del comportamiento fraudulento, el modelo no tendrá la información suficiente para capturar los patrones detras de esas anomalías.
En la práctica, el sistema tenderá a clasificar casi todo como normal, generando excelentes predicciones para la clase mayoritaria pero fallando estrepitosamente en su tarea principal: detectar el fraude.
2. Desempeño irreal y engañoso al momento de la evaluación
La segunda implicación, y quizás la más peligrosa, es que podemos obtener métricas de desempeño irreales que no reflejan el comportamiento del modelo en el mundo real.
Supongamos que queremos crear un modelo médico que clasifique a los pacientes en dos categorías: personas sanas y personas con alguna enfermedad. Y supongamos además que tenemos un dataset altamente desbalanceado de 10.000 personas sanas y únicamente 50 personas con la enfermedad:
Supongamos que tras entrenar el modelo obtenemos los siguientes resultados en la clasificación:
- De las 10.000 personas sanas, 9.800 son clasificadas correctamente.
- De las 50 personas enfermas, solo 3 son clasificadas correctamente.
Si cuantificamos el desempeño usando la métrica de Exactitud (Accuracy), la fórmula tomaría todos los aciertos sobre el total de datos. En el denominador tendríamos 10.050 (10.000 sanos + 50 enfermos), mientras que en el numerador tendríamos los aciertos: 9.800 + 3 = 9.803. Al dividir 9.803 entre 10.050 obtenemos una exactitud del 97.5%:
Si nos quedamos solo con esta métrica, tenderíamos a pensar que es un modelo excelente que acierta el 97.5% de las veces. Sin embargo, al observar la clase minoritaria (que es nuestro verdadero objetivo), vemos que de 50 personas enfermas solo se identificaron 3, logrando una tasa de acierto de tan solo el 6%. Es por esto que la exactitud enmascara el verdadero desempeño y es una pésima opción en situaciones donde hay un alto desbalance en las categorías de los datos.
Estrategias para manejar los datos desbalanceados
Para tratar de minimizar los inconvenientes explicados anteriormente podemos usar diversas técnicas que se agrupan en tres grandes familias: estrategias a nivel de los datos, a nivel de modelo/algoritmos y a nivel de las métricas de evaluación.
Veamos en detalle cada una de estas estrategias
1. Estrategias a nivel de los datos
Estas técnicas buscan modificar de forma directa la distribución del set de datos para entregarle al modelo un conjunto lo más balanceado posible.
La primera técnica es el sobremuestreo aleatorio, que consiste en balancear las clases generando réplicas de datos de la clase minoritaria:
En la figura anterior, los datos de color amarillo pertenecen a las categorías mayoritarias y los datos de color azul a las categorías minoritarias. Esta técnica se enfoca en los puntos de color azul, seleccionando aleatoriamente algunos de estos registros originales y, simplemente, duplicándolos (generando réplicas exactas).
La desventaja de este método es que al estar presentando copias idénticas repetidamente, el modelo corre un alto riesgo de sufrir de sobreajuste u overfitting con la clase minoritaria, memorizando esos puntos en lugar de generalizar patrones.
La segunda alternativa es el uso de la técnica SMOTE (Synthetic Minority Over-sampling Technique). Esta es una alternativa mucho más robusta que el sobremuestreo tradicional que acabamos de analizar.
Lo que hace SMOTE es crear nuevos datos para la clase minoritaria pero de forma sintética (artificial) mediante técnicas de interpolación:
En el dataset de la figura anterior, SMOTE analiza la manera como están distribuidos los datos minoritarios, busca patrones en esos datos y genera a través de técnicas de interpolación puntos intermedios.
Estos nuevos valores sintéticos (los puntos de color azul oscuro en la figura anterior) tienen características similares a los originales pero no son réplicas exactas, lo que permite introducir variabilidad al momento de entrenar el modelo reduciendo así la probabilidad de sobre-ajuste.
La desventaja de SMOTE es que no siempre los datos creados sintéticamente tendrán una distribución similar a la de los datos originales, lo que podría dificultar el entrenamiento del modelo pues no le permitiría detectar patrones adecuados en los datos minoritarios.
Y la última técnica de esta familia es el submuestreo. A la inversa del sobremuestreo, si tenemos nuestros puntos amarillos (mayoría) y azules (minoría), el submuestreo toma la categoría mayoritaria y, de forma aleatoria, elige puntos amarillos para eliminarlos definitivamente del set de datos hasta equilibrar estos con los datos de la clase minoritaria:
La desventaja de este método es que, si contamos con pocos datos en total, eliminar una porción grande de la categoría mayoritaria podría dejarnos con un dataset muy pequeño para el entrenamiento, limitando el aprendizaje profundo de los patrones.
2. Estrategias a nivel de algoritmos o modelos
El segundo conjunto de estrategias no altera los datos de origen, sino la forma en la que los algoritmos procesan dicha información al momento de entrenar los modelos.
La primera estrategia en esta familia es la ponderación de clases (class weighting). Con esta técnica lo que hacemos es asignar distintos pesos matemáticos a los datos, para darle más importancia a la categoría minoritaria y menos a la mayoritaria durante el entrenamiento.
Por ejemplo, en la figura de abajo la Categoría A (mayoritaria) está representada por círculos de color amarillo totalizando 90 datos y la Categoría B (minoritaria) está representada por puntos de color azul con tan solo 10 datos. Es decir que tenemos una relación de 9 a 1: por cada dato minoritario tendremos 9 datos mayoritarios:
Así, si programamos el algoritmo de entrenamiento usando esta ponderación, lo que hacemos es asignar a cada categoría una importancia (peso) que es inversamente proporcional al número de datos que posee.
Por ejemplo, en la figura anterior asignamos un peso de 1 a la categoría A (la mayoritaria) mientras que el peso para la categoría B (minoritaria) es igual a 9. Esto quiere decir que, al momento del entrenamiento, cada dato minoritario tiene un peso 9 veces más grande que uno mayoritario. Así, al presentarle los datos al modelo durante el entrenamiento, se fuerza un equilibrio matemático de importancia sin cambiar la cantidad total de datos.
Una segunda estrategia dentro de esta familia es el uso de algoritmos de detección de anomalías (u «outliers»).
Y es que usualmente pensamos que para clasificar datos entre normales y anómalos (fraudes, por ejemplo) debemos usar siempre modelos de Machine o Deep Learning (como Árboles de Decisión, Bosques Aleatorios, XGBoost o incluso Redes Neuronales). Sin embargo, dichos modelos tienden a ser muy sensibles al desbalance.
Así que una alternativa es no pensar la solución como una tarea de clasificación desde el Machine Learning convencional y, en su lugar, abordar el problema como un problema de desarrollo de un algoritmo de detección de valores extremos.
Por ejemplo, en el caso de detección de fraudes, las transacciones sospechosas generalmente tienen montos y características muy distantes (aisladas) del valor normal, así que en este tipo de situaciones podríamos implementar un algoritmo basado en lógica matemática (sin necesidad de entrenar modelo alguno) que permita identificar de manera eficaz estos «outliers».
Y una tercera estrategia dentro de esta familia es simplemente la selección adecuada de la arquitectura del modelo.
Por ejemplo, los modelos basados en particiones del espacio de características (como los árboles de decisión y los bosques aleatorios) sufren enormemente cuando hay pocos datos en un nodo en particular (es decir, sufren cuando hay un alto desbalance entre los datos).
Si en lugar de ello usamos alternativas más robustas al desbalance, como por ejemplo los modelos clásicos de Näive Bayes o incluso arquitecturas de aprendizaje profundo como los autoencoders, podríamos obtener mejores resultados al momento de la clasificación.
Por ejemplo, en el caso de los autoencoders lo que hacemos es entrenar este tipo de red neuronal únicamente con los datos normales para que aprenda a reconstruirlos perfectamente. Al finalizar, si se le presenta un dato anómalo (como un fraude), el autoencoder no podrá generar una buena reconstrucción de la entrada, disparando el error de reconstrucción y permitiéndonos detectar fácilmente la anomalía sin necesidad de haber tenido ejemplos fraudulentos balanceados.
Si quieres ver en detalle cómo funciona esta estrategia te invito a darle una mirada al tutorial de detección de anomalías con autoencoders, donde vemos todos los detalles de esta estrategia y su implementación en Python.
3. Estrategias a nivel de las métricas de desempeño
Si los datos están desbalanceados y no logramos los resultados esperados con las estrategias anteriores, podemos usar estrategias enfocadas en las métricas de desempeño del modelo.
Como vimos anteriormente, la exactitud no resulta adecuada en estos escenarios. Así que podríamos usar métricas derivadas de la matriz de confusión, como el precision y el recall.
Así que volvamos a nuestro ejemplo médico (10.000 sanos, 50 enfermos; donde clasificamos bien a 9.800 sanos y a 3 enfermos) y definamos cuatro parámetros fundamentales para calcular el precision y el recall:
- Verdaderos Positivos (TP): las personas enfermas que fueron clasificadas correctamente como enfermas (3 personas).
- Verdaderos Negativos (TN): las personas sanas clasificadas correctamente como sanas (9,800 personas).
- Falsos Positivos (FP): personas sanas que incorrectamente fueron clasificadas por el modelo como enfermas. Si había 10.000 sanos y 9.800 se clasificaron bien, los 200 restantes son los Falsos Positivos.
- Falsos Negativos (FN): personas enfermas que fueron erróneamente clasificadas como sanas. Si había 50 enfermos en total y acertamos 3, quedan 47 personas clasificadas incorrectamente como sanas; estos son los falsos negativos.
Con estos conteos ya podemos entonces calcular las métricas de desempeño del modelo:
Precision (Precisión)
Evalúa qué porcentaje de las predicciones positivas fueron realmente correctas y es simplemente la proporción entre el número de Verdaderos Positivos sobre la suma de Verdaderos Positivos y Falsos Positivos:
$$Precision = \frac{3}{3+200} = 0.015$$
Es decir que este modelo tendría una precisión del 1.5%. Esto quiere decir que del total de 203 personas a las que el modelo les dijo «estás enfermo», únicamente 3 lo estaban en la vida real. Es decir, el modelo tiene una precisión bajísima del 1.5% (cuando idealmente, esto debería acercarse al 100%).
Recall (Exhaustividad / Sensibilidad)
Esta métrica evalúa qué porcentaje del total de la clase minoritaria logramos encontrar. Es la proporción entre los Verdaderos Positivos sobre la suma de Verdaderos Positivos y Falsos Negativos:
$$Recall = \frac{3}{3+47} = 0.06$$
Es decir que el recall de este modelo es del 6%, lo cual quiere decir que del total de 50 pacientes enfermos (el denominador), el modelo solo logró identificar y clasificar correctamente a 3 de ellos (el 6%).
Al igual que con el precision, en este caso también vemos que el recall es muy pero muy bajo (pues su valor ideal debería ser el 100%). Y esto nos permite ver el verdadero desempeño del modelo cuando es entrenado con los datos desbalanceados, desmintiendo las falsas expectativas que nos generaba la exactitud (que tenía un valor altísimo del 97.5%).
Así que para este ejemplo, estos valores de precision y recall (1.5% y 6% respectivamente) nos muestran la cruda realidad del modelo: su desempeño con la clase de interés (la clase minoritaria, personas enfermas) es sumamente bajo.
Conclusión
El primer paso fundamental en todo proyecto de Ciencia de Datos debe ser realizar un análisis exploratorio riguroso de nuestro set de datos para entender a fondo el comportamiento de nuestros datos y para detectar si nos enfrentamos a clases balanceadas o desbalanceadas.
Y si efectivamente, tras esta exploración, nos damos cuenta de que tenemos clases desbalanceadas debemos decidir si realizaremos el manejo de estos datos desbalanceados usando alguna de las técnicas mencionadas anteriormente (sobre-muestreo de la clase minoritaria, sub-muestreo de la clase mayoritaria o SMOTE) o si haremos ajustes internos a los algoritmos de entrenamiento (usando por ejemplo ponderación de clases) o si elegiremos por ejemplo un modelo adecuado para este tipo de problemas (como los autoencoders).
Y desde luego, también es importante usar la métrica adecuada para evaluar el desempeño de nuestro modelo teniendo en cuenta este desbalance de los datos (usando por ejemplo el precision, el recall o el f1-score).
De hecho, en el curso de Regresión Logística, disponible en la Academia Online, vemos en detalle cómo evaluar un modelo de Regresión Logística y allí muestro de forma práctica cómo implementar en Python un clasificador usando ponderación de clases y cómo evaluarlo usando métricas como el precision, el recall y el f1-score.