Desbalanceo de Clases en Credit Scoring: Por Qué Usamos Ponderación en lugar de Undersampling

En credit scoring el desbalanceo de clases es la norma, no la excepción. En una cartera de crédito al consumo típica la tasa de default oscila entre el 2% y el 15%. Eso significa que por cada cliente que impaga hay entre 6 y 50 que pagan correctamente. El dataset de entrenamiento refleja esa realidad y esa asimetría plantea un problema técnico concreto al ajustar el modelo.

Un algoritmo de clasificación entrenado sobre un dataset muy desbalanceado tiende a ignorar la clase minoritaria. Si el 95% de los clientes no impagan, el modelo puede alcanzar una precisión del 95% simplemente prediciendo que nadie impaga, sin aprender absolutamente nada útil. El Gini de ese modelo sería 0.

Para corregir este problema existen tres enfoques principales: undersampling (reducir la clase mayoritaria), oversampling (amplificar la clase minoritaria, por ejemplo con SMOTE) y ponderación de clases (ajustar la función de pérdida para que el modelo preste más atención a los errores en la clase minoritaria).

El constructor de scorecards del laboratorio de Analytics Lane y ScoreFlow usan ponderación de clases. Esta entrada explica por qué descartamos el undersampling, cuándo el oversampling tiene sentido y cuáles son las implicaciones prácticas de la decisión que tomamos.

El problema del desbalanceo en credit scoring

Antes de entrar en las soluciones, vale la pena entender exactamente cuál es el problema técnico.

La regresión logística, el algoritmo base para la construcción de los scorecard, minimiza la log-loss, que es la suma de las pérdidas individuales de cada observación: \mathcal{L} = -\frac{1}{n} \sum_{i=1}^{n} \left[ y_i \log(\hat{p}_i) + (1 - y_i) \log(1 - \hat{p}_i) \right]

Con un dataset donde el 95% de las observaciones son no eventos (y = 0), el 95% de los términos de esta suma corresponden a buenos pagadores. El algoritmo dedica el 95% de su “atención” a clasificar correctamente a los buenos pagadores y solo el 5% a los malos.

El resultado es un modelo que predice probabilidades de default sistemáticamente bajas, empujadas hacia cero por la masa de no eventos, y que tiene dificultades para discriminar en el rango de probabilidades altas donde viven los malos pagadores.

Curiosamente, el WOE compensa parcialmente este problema porque normaliza las distribuciones antes de que entren en la regresión. Pero con tasas de default muy bajas (< 2%) o incluso muy altas (> 15%) el desbalanceo sigue siendo relevante incluso con WOE.

Las tres soluciones y sus tradeoffs

Opción 1: Undersampling

Se eliminan observaciones de la clase mayoritaria hasta alcanzar un ratio más equilibrado, por ejemplo 50/50 o 70/30.

Cómo funciona: si tienes 50.000 buenos pagadores y 2.500 malos, mantienes los 2.500 malos y muestreas aleatoriamente 2.500 (o 5.000 o 7.500) buenos pagadores, descartando el resto.

Ventajas:

• Simple de implementar
• Reduce el tiempo de entrenamiento al trabajar con menos datos
• El modelo ve un dataset más equilibrado

Desventajas críticas en credit scoring:

• Pierde información real: Descartas el 90% de tus buenos pagadores, observaciones reales con información válida sobre el comportamiento crediticio. En un dataset de 50.000 observaciones puedes quedarte con solo 5.000-7.500 efectivas. Esa pérdida de información reduce la calidad del modelo, especialmente en los segmentos de la distribución donde los buenos pagadores son el grupo dominante.
• Distorsiona la distribución del WOE: El WOE se calcula sobre las proporciones de eventos y no eventos en cada bin. Si aplicas undersampling antes de calcular el WOE, estás calculando proporciones sobre una muestra artificial que no refleja la distribución real de la población. Los WOE resultantes están sesgados, y por tanto los coeficientes de la regresión también.
• Las probabilidades predichas son incorrectas: Un modelo entrenado con undersampling aprende a predecir probabilidades en el contexto del dataset rebalanceado (50/50 o 70/30), no en el contexto real de la población (95/5). Las probabilidades que predice en producción necesitan recalibrarse, lo que añade un paso adicional y una fuente de error.
• El scorecard es menos estable: Con menos datos de entrenamiento los coeficientes tienen mayor varianza, son más sensibles a qué observaciones específicas se incluyeron en la muestra. El modelo es más inestable.

Opción 2: Oversampling (SMOTE y variantes)

Se generan observaciones sintéticas de la clase minoritaria, malos pagadores artificiales, hasta equilibrar el dataset.

SMOTE (Synthetic Minority Oversampling Technique) genera nuevos malos pagadores interpolando entre malos pagadores existentes en el espacio de las variables originales.

Ventajas:

• No pierde información de la clase mayoritaria
• Puede mejorar la discriminación en la clase minoritaria

Desventajas en credit scoring:

• Las observaciones sintéticas no son clientes reales: En credit scoring los datos son observaciones de comportamiento real, un cliente pagó o no pagó. Generar malos pagadores artificiales introduce ruido: las interpolaciones pueden crear perfiles de clientes que no existen en la realidad y que el modelo aprenderá a clasificar incorrectamente.
• El WOE sobre datos sintéticos es cuestionable: El mismo problema que con el undersampling: el WOE calculado sobre un dataset que incluye observaciones sintéticas no refleja la distribución real. La relación entre el WOE y la tasa de default real en producción se distorsiona.
• La calibración se complica: Las probabilidades predichas por un modelo entrenado con SMOTE también necesitan recalibración para reflejar las tasas reales de la población.
• Cuestionable ante el regulador: En un contexto regulado, donde el modelo debe ser explicable y auditable, introducir datos sintéticos en el entrenamiento añade una capa de complejidad difícil de justificar. La pregunta “¿de dónde vienen estos datos?” tiene una respuesta incómoda cuando parte del entrenamiento son clientes artificiales.

Opción 3: Ponderación de clases

Se modifica la función de pérdida para que los errores en la clase minoritaria tengan más peso que los errores en la clase mayoritaria. En lugar de tratar cada observación igual, el algoritmo penaliza más los fallos en malos pagadores.

La log-loss ponderada es: \mathcal{L}_w = -\frac{1}{n} \sum_{i=1}^{n} w_i \left[ y_i \log(\hat{p}_i) + (1 - y_i) \log(1 - \hat{p}_i) \right] donde w_i es el peso de cada observación:

• w_i = \frac{n}{2 \times n_0} para los no eventos (buenos pagadores)
• w_i = \frac{n}{2 \times n_1} para los eventos (malos pagadores)

Con una tasa de default del 5%, los malos pagadores reciben un peso aproximadamente 19 veces mayor que los buenos pagadores. El modelo dedica una atención proporcional a ambas clases a pesar del desbalanceo.

Ventajas:

• Usa todos los datos reales: No se descarta ninguna observación ni se generan datos sintéticos. El modelo aprende sobre la distribución real de la población.
• El WOE se calcula correctamente: El WOE y el IV se calculan sobre las proporciones reales de eventos y no eventos, no sobre una muestra artificial. Las relaciones que aprende el modelo reflejan la realidad del portfolio.
• Las probabilidades predichas son correctas: A diferencia del undersampling y el oversampling, la ponderación de clases no distorsiona la escala de las probabilidades predichas. El modelo aprende a predecir probabilidades en el contexto de la distribución real, lo que es esencial para la calibración del scorecard y para la estimación de pérdidas esperadas.
• Transparente y auditable: La ponderación de clases es una decisión de la función de pérdida, matemáticamente limpia, fácil de documentar y de explicar ante el regulador.

Desventajas:

• Puede aumentar la varianza del modelo: Al multiplicar el peso de los malos pagadores, el modelo es más sensible a observaciones individuales de la clase minoritaria. Un mal pagador atípico tiene más influencia sobre los coeficientes que con un dataset equilibrado.
• No resuelve el problema si la clase minoritaria es extremadamente pequeña: Con tasas de default inferiores al 1% y datasets pequeños (< 5.000 observaciones), la ponderación puede no ser suficiente porque hay demasiado pocos eventos para que el modelo aprenda patrones robustos. En ese caso puede ser necesario combinar ponderación con alguna forma de aumento de datos, aunque no en el sentido del SMOTE estándar.

Por qué elegimos ponderación de clases en el constructor

La decisión de usar ponderación de clases en lugar de undersampling o oversampling se basa en tres razones que son específicas del contexto del credit scoring:

1. El WOE debe calcularse sobre la distribución real: El WOE es la piedra angular del scorecard. Si lo calculas sobre un dataset artificialmente rebalanceado, los valores de WOE no reflejan la realidad del portfolio y el scorecard que construyes no es válido para la población real. La ponderación de clases es la única técnica que no toca los datos de entrada, solo la función de pérdida durante el entrenamiento de la regresión logística.
2. La calibración es crítica: Como explicamos en el artículo Calibración vs Discriminación, las probabilidades predichas por el scorecard deben ser correctas, especialmente cuando el modelo se usa para estimar pérdidas esperadas o para pricing ajustado por riesgo. El undersampling y el oversampling producen probabilidades sistemáticamente incorrectas que requieren recalibración. La ponderación de clases produce probabilidades directamente calibradas con la distribución real.
3. La trazabilidad regulatoria: El constructor incluye un log de decisiones que documenta todo el proceso de construcción del modelo. En ese log, “se aplicó ponderación de clases con peso inversamente proporcional a la frecuencia de clase” es una entrada clara y justificable. “Se eliminó el 90% de los buenos pagadores aleatoriamente” o “se generaron malos pagadores sintéticos mediante SMOTE” son entradas más difíciles de defender ante un comité de validación.

Cómo funciona en el constructor

El constructor aplica automáticamente la ponderación de clases en el paso 5 (Modelo) cuando detecta que la tasa de eventos es inferior al 20% o superior al 80%. Los pesos se calculan como: w_{no\ evento} = \frac{n}{2 \times n_0} \quad w_{evento} = \frac{n}{2 \times n_1}

donde n es el total de observaciones, n_0 el número de no eventos y n_1 el número de eventos.

El constructor muestra los pesos aplicados en el panel de resultados del paso 5 para que queden documentados en el log de decisiones. Si la tasa de eventos está entre el 20% y el 80%, la ponderación no se aplica, el desbalanceo no es suficientemente severo para justificarla.

El analista puede desactivar la ponderación automática si lo considera oportuno, por ejemplo si la tasa de eventos del 5% corresponde a un portfolio con suficiente volumen de malos pagadores (más de 500 eventos) donde el modelo puede aprender sin ayuda. En ese caso la justificación queda registrada en el log.

Cuándo el undersampling podría tener sentido

Aunque no es el enfoque del constructor, hay situaciones donde el undersampling puede estar justificado:

• Datasets muy grandes con restricciones computacionales: Con 10 millones de observaciones y el 2% de tasa de default, el dataset tiene 200.000 malos pagadores, suficientes para entrenar un modelo robusto. Si las restricciones computacionales impiden trabajar con los 10 millones, muestrar 1 millón de buenos pagadores junto a los 200.000 malos puede ser una solución práctica. Pero el WOE debe calcularse sobre el dataset completo antes del muestreo.
• Exploración rápida y prototipado: Para verificar rápidamente si un conjunto de variables tiene poder predictivo antes de invertir tiempo en un modelo completo, trabajar con un dataset rebalanceado puede acelerar el proceso. Pero el modelo final debe entrenarse con los datos reales y ponderación de clases.
• Cuando el oversampling no es viable: Si los malos pagadores son tan pocos que el oversampling generaría una proporción muy alta de datos sintéticos (por ejemplo, el 80% de la clase minoritaria sería artificial), el undersampling puede ser más honesto, aunque sigue teniendo los problemas descritos.

Conclusiones

El desbalanceo de clases en credit scoring no es un problema que se resuelva manipulando los datos, se resuelve ajustando cómo el algoritmo aprende de ellos. La ponderación de clases mantiene la integridad del dataset, preserva la correcta calibración de las probabilidades y produce un modelo directamente auditable.

El undersampling y el oversampling son herramientas válidas en otros contextos: detección de fraude con millones de transacciones, visión por computador con clases muy poco frecuentes, problemas donde la calibración no es crítica. Pero en credit scoring, donde el WOE debe reflejar la distribución real del portfolio y donde las probabilidades predichas se usan directamente para estimar pérdidas y tomar decisiones reguladas, la ponderación de clases es la opción técnicamente más sólida.

El constructor de scorecards del laboratorio y ScoreFlow la aplican automáticamente y la documenta en el log de decisiones, para que la elección sea transparente, reproducible y justificable en cualquier proceso de validación.

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