REPORTE TRABAJO 2: APLICACIONES DE REDES NEURONALES A DATOS TABULARES

REDES NEURONALES Y ALGORITMOS BIOINSPIRADOS

Presentado por:

Leonardo Federico Corona Torres
David Escobar Ruiz
Johan Sebastian Robles Rincón
Sebastián Soto Arcila

Profesor: Juan David Ospina Arango

Monitor: Andrés Mauricio Zapata Rincón

Universidad Nacional de Colombia
Facultad de Minas
Ingeniería de Sistemas e Informática

12 de junio de 2025

Contenidos

• Introducción
• Metodología
• Definición del problema
• 1. Limpieza de datos
• 1.1 Objetivos
• 1.2 Estructura del dataset
• 1.3 Limpieza de datos inicial
• 1.4 Análisis exploratorio univariado de columnas numéricas
• 1.5 Análisis exploratorio univariado de columnas no numéricas
• 1.6 Análisis multivariado
• 1.7 Conclusiones parte 1
• 2. Ingeniería de features
• 2.1 Objetivos
• 2.2 Tratamiento de columnas numéricas
• 2.3 Tratamiento de columnas no numéricas
• 2.4 Conclusiones parte 2
• 3. Modelado
• 3.1 Objetivos
• 3.2 Train-Test split
• 3.3 Modelo 1: XGBoost
• 3.4 Modelo 2: XGBoost tras resolver problema de data leakage
• 3.5 Modelo 3: Multilayer Perceptron
• 3.6 Conclusiones parte 3
• Casos de uso alternativos
• Conclusiones finales
• Reporte de contribución individual
• Repositorio de GitHub del proyecto
• Link hacia app web del proyecto.
• Bibliografía

Introducción

Las redes neuronales son un tipo de modelo computacional inspirado en el funcionamiento del cerebro humano, compuesto por capas de unidades llamadas neuronas artificiales (Wikipedia, s.f., Artificial Neural Networks). Estas redes son capaces de aprender patrones complejos a partir de grandes volúmenes de datos mediante un proceso conocido como entrenamiento. A través de este proceso, ajustan internamente sus parámetros para minimizar el error en la tarea que se les asigna.

Se utilizan ampliamente en tareas de clasificación, regresión, detección de anomalías, procesamiento de imágenes, procesamiento de lenguaje natural, entre muchas otras aplicaciones. Su capacidad para capturar relaciones no lineales y complejas entre variables las convierte en una herramienta poderosa dentro del campo del aprendizaje automático.

Uno de los problemas clásicos en los que se aplican técnicas de aprendizaje supervisado es la clasificación de riesgo de crédito , que consiste en predecir la probabilidad de que un solicitante de crédito cumpla o no con sus obligaciones financieras (Synapse Analytics, s.f., Credit Scoring Explained - The Problem Statement). Este tipo de modelos es crucial para las instituciones financieras, ya que les permite tomar decisiones más informadas, reducir riesgos y mejorar la asignación de recursos.

En este contexto, las redes neuronales ofrecen una alternativa eficaz frente a modelos más tradicionales, ya que pueden modelar relaciones no evidentes entre los atributos financieros y demográficos de los solicitantes y su comportamiento crediticio futuro. A pesar de que requieren más datos y mayor capacidad de cómputo, su rendimiento suele ser superior cuando se dispone de información suficiente y bien estructurada.

Para facilitar el uso del modelo desarrollado, se construyó una aplicación web que permite ingresar los datos relevantes del solicitante y obtener, en tiempo real, la predicción del nivel de riesgo de crédito. Esta interfaz busca demostrar cómo una solución basada en inteligencia artificial puede integrarse fácilmente en entornos reales, brindando accesibilidad, automatización y soporte a la toma de decisiones.

Metodología

El desarrollo del proyecto se dividió en tres etapas principales: limpieza de datos y análisis exploratorio (EDA), ingeniería de features y modelado. Cada una de estas fases fue abordada de manera modular para facilitar la comprensión y el desarrollo iterativo del modelo.

Para el procesamiento y análisis, se utilizaron Jupyter Notebooks, lo cual permitió una exploración interactiva del dataset. No obstante, se reconoce que para entornos de producción y mejor escalabilidad, sería recomendable implementar estos procesos como pipelines orquestados con herramientas como Apache Airflow.

El dataset utilizado proviene de Kaggle y está disponible en su respectivo enlace (Kaggle, s.f., Credit Risk Analysis).

Durante la etapa de análisis exploratorio y visualización, se hizo uso de librerías como Seaborn y Matplotlib, mientras que para la manipulación y transformación de los datos se emplearon NumPy y Pandas. El preprocesamiento y el modelado inicial se realizaron con herramientas de Scikit-learn, y para la construcción del modelo de red neuronal se utilizó PyTorch, lo que permitió una mayor flexibilidad en la implementación del modelo de deep learning.

Definición del problema

El riesgo crediticio se puede abordar como un problema de clasificación binaria, en el que se busca predecir si un solicitante de crédito representa un riesgo alto o bajo de incumplimiento. Esta tarea es fundamental para instituciones financieras, ya que les permite tomar decisiones más seguras y eficientes al momento de otorgar préstamos.

El objetivo principal de la solución a este problema es entrenar un modelo basado en redes neuronales que sea capaz de aprender patrones a partir de los datos históricos y realizar predicciones precisas sobre el riesgo crediticio de nuevos solicitantes.

Para lograrlo, es necesario identificar y seleccionar las variables más relevantes del conjunto de datos, de manera que el modelo pueda capturar la información crítica que influye en el comportamiento financiero de los individuos.

El qué tan bueno sea el modelo estará definido por las siguientes métricas (Geeks for Geeks, 2025):

• Accuracy: Proporción de predicciones correctas sobre el total de casos.

• Precision: Casos que el modelo predijo como alto riesgo y sí lo eran realmente (verdaderos positivos).

• Recall: Tasa de verdaderos positivos, es decir, los casos que el modelo detectó correctamente de todos los casos de alto riesgo.

• F1-score: Media armónica entre precision y recall.

• AUC-ROC: Área bajo la curva ROC. Evalúa la capacidad del modelo para distinguir entre clases. Mientras más cercano a 1 esté esta métrica, más discriminativo será el modelo, lo cual es lo ideal.

Parte 1. Limpieza de Datos y Análisis Exploratorio de Datos

A continuación se presenta una síntesis de lo realizado en el proceso de limpieza de datos y análisis exploratorio de datos. Todo el código con los detalles de implementación se puede encontrar en el archivo poc_EDA.ipynb en el repositorio del proyecto.

1.1 Objetivos

Antes de comenzar a modelar, es necesario asegurarse de que los datos están lo suficientemente procesados y preparados para poder entrenar el modelo, de tal forma que este pueda alcanzar los niveles deseados en las métricas previamente definidas.

Adicionalmente, se debe entender primero el conjunto de datos junto con sus propiedades estadísticas tanto univariadas como multivariadas, con el objetivo de encontrar patrones o relaciones que den pistas de qué factores podrían estar más relacionados con la probabilidad de cumplimiento o incumplimiento del pago del préstamo.

A manera de síntesis, se tienen los siguientes objetivos para la limpieza de datos y el análisis exploratorio de datos:

• Entender la estructura general del dataset y sus columnas, recogiendo información como las dimensiones del dataset, sus tipos de datos y cómo se ven las primeras y últimas filas del dataset.

• Definir un conjunto de criterios de limpieza de datos previo al análisis exploratorio de datos que permita evitar desvíos de los patrones realmente relevantes del conjunto de datos.

• Realizar una adecuada limpieza de los datos a partir de los criterios anteriormente definidos.

• Realizar un análisis univariado y multivariado de las columnas tanto numéricas como no numéricas del dataset para poder entender de mejor manera las propiedades estadísticas del mismo.

• Derivar conclusiones relevantes a partir de cada análisis realizado.

• Contar con un dataset lo suficientemente limpio como para poder seguir con un proceso de ingeniería de features.

1.2 Estructura del dataset

Antes de comenzar con la limpieza de los datos, se debe estar familiarizado con el propio dataset. Es por esto que se parte de una visión general, revisando la estructura del dataset, para después ir a lo particular, revisando cada columna.

1.2.1 Origen del dataset

El dataset a utilizar se puede encontrar en (Kaggle, s.f., Credit Risk Analysis).

1.2.2 Dimensiones del dataset

Las dimensiones del dataset, calculadas a partir de la lectura del mismo como un DataFrame de pandas (ver código en repositorio), son las siguientes:

Columnas	74 columnas
Filas	887379 filas

Tabla 1. Dimensiones del dataset crudo.

De la Tabla 1 se puede evidenciar que se está lidiando con un dataset de tamaño relativamente grande, lo cual hay que considerar a la hora de realizar la limpieza y el modelado.

Algo bueno a resaltar es que se cuenta con una buena abundancia de datos para poder entrenar el modelo, y por lo tanto con una buena limpieza y preprocesamiento, se cree que se pueden alcanzar valores ideales para las métricas del modelo una vez entrenado.

1.2.3 Primeras y últimas 5 filas del dataset

Debido al gran tamaño del dataset, se complica la exploración del mismo por el uso de herramientas de ofimática básicas como Excel o Google Sheets. Es por esto que se optó por revisar las primeras y últimas 5 filas del dataset por medio del uso de los métodos head() y tail() de pandas.

Debido al gran tamaño del dataset no es posible adjuntar las filas y columnas en este reporte. Sin embargo, se puede revisar el archivo poc_EDA.ipynb en el repositorio del proyecto para revisarlas.

1.2.4 Información estructural general del dataset

Nombre de columna	Número de valores no nulos	Tipo de dato
id	887379	int64
member_id	887379	int64
loan_amnt	887379	float64
funded_amnt	887379	float64
funded_amnt_inv	887379	float64
term	887379	object
int_rate	887379	float64
installment	887379	float64
grade	887379	object
sub_grade	887379	object
emp_title	835917	object
emp_length	842554	object
home_ownership	887379	object
annual_inc	887375	float64
verification_status	887379	object
issue_d	887379	object
loan_status	887379	object
pymnt_plan	887379	object
url	887379	object
desc	126026	object
purpose	887379	object
title	887226	object
zip_code	887379	object
addr_state	887379	object
dti	887379	float64
delinq_2yrs	887350	float64
earliest_cr_line	887350	object
inq_last_6mths	887350	float64
mths_since_last_delinq	433067	float64
mths_since_last_record	137053	float64
open_acc	887350	float64
pub_rec	887350	float64
revol_bal	887379	float64
revol_util	886877	float64
total_acc	887350	float64
initial_list_status	887379	object
out_prncp	887379	float64
out_prncp_inv	887379	float64
total_pymnt	887379	float64
total_pymnt_inv	887379	float64
total_rec_prncp	887379	float64
total_rec_int	887379	float64
total_rec_late_fee	887379	float64
recoveries	887379	float64
collection_recovery_fee	887379	float64
last_pymnt_d	869720	object
last_pymnt_amnt	887379	float64
next_pymnt_d	634408	object
last_credit_pull_d	887326	object
collections_12_mths_ex_med	887234	float64
mths_since_last_major_derog	221703	float64
policy_code	887379	float64
application_type	887379	object
annual_inc_joint	511	float64
dti_joint	509	float64
verification_status_joint	511	object
acc_now_delinq	887350	float64
tot_coll_amt	817103	float64
tot_cur_bal	817103	float64
open_acc_6m	21372	float64
open_il_6m	21372	float64
open_il_12m	21372	float64
open_il_24m	21372	float64
mths_since_rcnt_il	20810	float64
total_bal_il	21372	float64
il_util	18617	float64
open_rv_12m	21372	float64
open_rv_24m	21372	float64
max_bal_bc	21372	float64
all_util	21372	float64
total_rev_hi_lim	817103	float64
inq_fi	21372	float64
total_cu_tl	21372	float64
inq_last_12m	21372	float64

Tabla 2. Información estructural básica del dataset crudo.

Utilizando el método info() de la libería pandas, se puede generar la información de la información estructural general del dataset que contiene información como el número de columnas y entradas, valores no nulos por cada columna y el tipo de dato de cada una.

1.2.5 Conclusiones

A partir de lo anterior, se derivaron las siguientes conclusiones:

• Se cuenta con un dataset relativamente grande, con aproximadamente 887K filas y 74 columnas. Se tendrá que hacer un análisis riguroso para poder limpiar los datos apropiadamente.

• Se cuenta con datos tanto de tipo numérico (float64 e int64) como no numérico (object). Probablemente los de tipo no numérico pertenecen a columnas de texto plano, categóricas y ordinales, que se tendrán que tratar más adelante.

• Puede que algunos valores de columnas object pertenezcan a fechas, los cuales se analizarán más adelante.

• Las columnas de identificación se podrán eliminar (id y member_id) debido a que son de identificación de cada fila y no impactarán en la probabilidad de pago.

1.3 Limpieza de datos inicial

Una vez más familiarizados con los datos, se procederá a definir ciertos criterios de limpieza generales para implementar antes del análisis exploratorio de datos.

1.3.1 Criterios de limpieza

Se definen los siguientes criterios de limpieza previo al análisis con el objetivo de mitigar la cantidad de “pistas falsas” con las que se podría estropear el entendimiento del dataset.

• Criterio 1: El porcentaje de valores nulls no debe superar el 80%:

  Columnas que tengan más del 80% de sus valores nulos serán difíciles de imputar mas adelante, y por lo tanto se optará por eliminarlas.

• Criterio 2: No se dejarán columnas de texto plano. Se aceptarán columnas categóricas y ordinales que luego se codificarán:

  Columnas que sean de texto plano y no sigan ninguna estructura definida que permitan tratarlas serán eliminadas debido a la dificultad que podrían traer al momento de codificarlos a valores numéricos.

• Criterio 3: No se dejarán columnas de identificación, ya que son para identificar filas y entidades y no están relacionados con ningún patrón relevante para el análisis:

  Columnas que correspondan a formas de identificación de filas serán eliminadas ya que no contribuirán al análisis.

• Criterio 4: Se descartarán columnas que tengan solamente un valor único:

  Se descartarán columnas que consten de solamente un valor único para evitar redundancias entre los datos.

1.3.2 Cumplimiento de criterio 1

Nombre de Columna	Número de valores nulos	Porcentaje de valores nulos
desc	761353	85.797951
mths_since_last_record	750326	84.555303
mths_since_last_major_derog	665676	75.015974
annual_inc_joint	886868	99.942415
dti_joint	886870	99.942640
verification_status_joint	886868	99.942415
open_acc_6m	866007	97.591559
open_il_6m	866007	97.591559
open_il_12m	866007	97.591559
open_il_24m	866007	97.591559
mths_since_rcnt_il	866569	97.654892
total_bal_il	866007	97.591559
il_util	868762	97.902024
open_rv_12m	866007	97.591559
open_rv_24m	866007	97.591559
max_bal_bc	866007	97.591559
all_util	866007	97.591559
inq_fi	866007	97.591559
total_cu_tl	866007	97.591559
inq_last_12m	866007	97.591559

Tabla 3. Columnas que tienen más del 80% de sus valores como nulos.

Para cumplir el criterio del porcentaje de valores nulls se identificaron las columnas que se muestran en la Tabla 3 que tienen un porcentaje de valores nulls mayor al 80%.

Se procedió a eliminarlos, pasando de tener un dataset de 74 columnas a uno de 55 columnas.

Se filtraron las columnas utilizando las herramientas y los métodos de tratamiendo de datos de pandas.

1.3.3 Cumplimiento de criterio 2

Para el cumplimiento de este criterio se tuvieron que separar las columnas numéricas de las no numéricas.

Nombre de Columna	Algunos Valores Únicos
term	[’ 36 months’ ’ 60 months’]
grade	[‘B’ ‘C’ ‘A’ ‘E’ ‘F’ ‘D’ ‘G’]
sub_grade	[‘B2’ ‘C4’ ‘C5’ ‘C1’ ‘B5’ ‘A4’ ‘E1’ ‘F2’ ‘C3’ ‘B1’ ‘D1’ ‘A1’ ‘B3’ ‘B4’ ‘C2’ ‘D2’ ‘A3’ ‘A5’ ‘D5’ ‘A2’]
emp_title	[nan ‘Ryder’ ‘AIR RESOURCES BOARD’ ‘University Medical Group’ ‘Veolia Transportaton’ ‘Southern Star Photography’ ‘MKC Accounting’ ‘Starbucks’ ‘Southwest Rural metro’ ‘UCLA’ ‘Va. Dept of Conservation/Recreation’ ‘Target’ ‘SFMTA’ ‘Internal revenue Service’ “Chin’s Restaurant” ‘Duracell’ ‘Connection Inspection’ ‘Network Interpreting Service’ ‘Archdiocese of Galveston Houston’ ‘Osram Sylvania’]
emp_length	[‘10+ years’ ‘< 1 year’ ‘1 year’ ‘3 years’ ‘8 years’ ‘9 years’ ‘4 years’ ‘5 years’ ‘6 years’ ‘2 years’ ‘7 years’ nan]
home_ownership	[‘RENT’ ‘OWN’ ‘MORTGAGE’ ‘OTHER’ ‘NONE’ ‘ANY’]
verification_status	[‘Verified’ ‘Source Verified’ ‘Not Verified’]
issue_d	[‘Dec-2011’ ‘Nov-2011’ ‘Oct-2011’ ‘Sep-2011’ ‘Aug-2011’ ‘Jul-2011’ ‘Jun-2011’ ‘May-2011’ ‘Apr-2011’ ‘Mar-2011’ ‘Feb-2011’ ‘Jan-2011’ ‘Dec-2010’ ‘Nov-2010’ ‘Oct-2010’ ‘Sep-2010’ ‘Aug-2010’ ‘Jul-2010’ ‘Jun-2010’ ‘May-2010’]
loan_status	[‘Fully Paid’ ‘Charged Off’ ‘Current’ ‘Default’ ‘Late (31-120 days)’ ‘In Grace Period’ ‘Late (16-30 days)’ ‘Does not meet the credit policy. Status:Fully Paid’ ‘Does not meet the credit policy. Status:Charged Off’ ‘Issued’]
pymnt_plan	[‘n’ ‘y’]
url	[‘https://www.lendingclub.com/browse/loanDetail.action?loan_id=1077501’ ‘https://www.lendingclub.com/browse/loanDetail.action?loan_id=1077430’ ‘https://www.lendingclub.com/browse/loanDetail.action?loan_id=1077175’ ‘https://www.lendingclub.com/browse/loanDetail.action?loan_id=1065775’ ‘https://www.lendingclub.com/browse/loanDetail.action?loan_id=1069971’ ‘https://www.lendingclub.com/browse/loanDetail.action?loan_id=1062474’ ‘https://www.lendingclub.com/browse/loanDetail.action?loan_id=1069742’]
purpose	[‘credit_card’ ‘car’ ‘small_business’ ‘other’ ‘wedding’ ‘debt_consolidation’ ‘home_improvement’ ‘major_purchase’ ‘medical’ ‘moving’ ‘vacation’ ‘house’ ‘renewable_energy’ ‘educational’]
title	[‘Computer’ ‘bike’ ‘real estate business’ ‘personel’ ‘Personal’ ‘My wedding loan I promise to pay back’ ‘Loan’ ‘Car Downpayment’ ‘Expand Business & Buy Debt Portfolio’ ‘Building my credit history.’ ‘High intrest Consolidation’ ‘Consolidation’ ‘freedom’ ‘citicard fund’ ‘Other Loan’ ‘Debt Consolidation Loan’ ‘Home’ ‘Holiday’ ‘Medical’ ‘lowerratemeanseasiertogetoutofdebt!’]
zip_code	[‘860xx’ ‘309xx’ ‘606xx’ ‘917xx’ ‘972xx’ ‘852xx’ ‘280xx’ ‘900xx’ ‘958xx’ ‘774xx’ ‘853xx’ ‘913xx’ ‘245xx’ ‘951xx’ ‘641xx’ ‘921xx’ ‘067xx’ ‘890xx’ ‘770xx’ ‘335xx’]
addr_state	[‘AZ’ ‘GA’ ‘IL’ ‘CA’ ‘OR’ ‘NC’ ‘TX’ ‘VA’ ‘MO’ ‘CT’ ‘UT’ ‘FL’ ‘NY’ ‘PA’ ‘MN’ ‘NJ’ ‘KY’ ‘OH’ ‘SC’ ‘RI’]
earliest_cr_line	[‘Jan-1985’ ‘Apr-1999’ ‘Nov-2001’ ‘Feb-1996’ ‘Jan-1996’ ‘Nov-2004’ ‘Jul-2005’ ‘Jan-2007’ ‘Apr-2004’ ‘Sep-2004’ ‘Jan-1998’ ‘Oct-1989’ ‘Jul-2003’ ‘May-1991’ ‘Sep-2007’ ‘Oct-1998’ ‘Aug-1993’ ‘Oct-2003’ ‘Jan-2001’ ‘Nov-1997’]
initial_list_status	[‘f’ ‘w’]
last_pymnt_d	[‘Jan-2015’ ‘Apr-2013’ ‘Jun-2014’ ‘Jan-2016’ ‘Apr-2012’ ‘Nov-2012’ ‘Jun-2013’ ‘Sep-2013’ ‘Jul-2012’ ‘Oct-2013’ ‘May-2013’ ‘Feb-2015’ ‘Aug-2015’ ‘Oct-2012’ ‘Sep-2012’ nan ‘Dec-2012’ ‘Dec-2014’ ‘Aug-2013’ ‘Nov-2013’]
next_pymnt_d	[nan ‘Feb-2016’ ‘Jan-2016’ ‘Sep-2013’ ‘Feb-2014’ ‘May-2014’ ‘Jun-2013’ ‘Mar-2012’ ‘Apr-2012’ ‘May-2013’ ‘Aug-2012’ ‘Aug-2013’ ‘Jun-2012’ ‘Nov-2013’ ‘Feb-2012’ ‘Oct-2011’ ‘Jan-2013’ ‘Jan-2014’ ‘Jul-2013’ ‘Jul-2015’]
last_credit_pull_d	[‘Jan-2016’ ‘Sep-2013’ ‘Jan-2015’ ‘Sep-2015’ ‘Dec-2014’ ‘Aug-2012’ ‘Mar-2013’ ‘Dec-2015’ ‘Aug-2013’ ‘Nov-2012’ ‘Mar-2014’ ‘Apr-2015’ ‘May-2014’ ‘Jul-2015’ ‘Jul-2012’ ‘Sep-2012’ ‘May-2013’ ‘Oct-2015’ ‘Jun-2012’ ‘Mar-2015’]
application_type	[‘INDIVIDUAL’ ‘JOINT’]

Tabla 4. Columnas no numéricas junto con algunos de sus valores únicos

Se revisaron las columnas de tipo object (mostradas en la Tabla 4 y se revisaron sus valores únicos para verificar cuáles eran de texto plano para poder eliminarlas.

De lo anterior, se concluyó que las columnas de texto plano eran las siguientes: emp_title, title y url. Se procedió con su eliminación, pasando de tener 55 columnas a tener 52.

1.3.4 Cumplimiento de criterio 3

Del propio nombre de las columnas id y member_id y del diccionario de datos que vino con el dataset, se concluye que estas dos columnas son de identificación y se procede a eliminarlas para cumplir el criterio 3.

Tras la eliminación, se pasa de 52 columnas a 50 columnas.

1.3.5 Cumplimiento de criterio 4

Tras examinar los valores únicos de las columnas numéricas, se identificó que la columna policy_code solamente tenía 1 solo valor para cada fila de las columnas, y por eso se procedió con su eliminación, pasando de tener 50 columnas a 49 columnas.

1.3.6 Conclusiones

A partir de lo anterior, se derivaron las siguientes conclusiones:

• Se eliminaron columnas con más del 80% de valores nulos, lo que permitió reducir significativamente la cantidad de ruido y valores faltantes difíciles de imputar.

• Se descartaron columnas de texto plano que no aportaban estructura útil para el modelado, lo que facilitó la futura codificación de variables categóricas.

• Se eliminaron columnas de identificación y aquellas con un único valor, ya que no aportaban información relevante al análisis.

• Tras aplicar todos los criterios de limpieza definidos, se pasó de un total de 74 columnas a 49, dejando un conjunto de datos más limpio, manejable y adecuado para el análisis y modelado posterior.

1.4 Análisis exploratorio univariado de columnas numéricas

Utilizando este nuevo dataset procesado, se permite proceder con el análisis exploratorio de los datos. Se comenzó por el análisis univariado de las columnas numéricas.

1.4.1 Estadísticas descriptivas

Nombre col	Media	Std	Min	25%	50%	75%	Max	Skewness	Kurtosis
loan_amnt	14755.264605	8435.455601	500.000000	8000.000000	13000.000000	20000.000000	35000.000000	0.681683	-0.256715
funded_amnt	14741.877625	8429.897657	500.000000	8000.000000	13000.000000	20000.000000	35000.000000	0.683745	-0.251638
funded_amnt_inv	14702.464383	8442.106732	0.000000	8000.000000	13000.000000	20000.000000	35000.000000	0.680983	-0.251765
int_rate	13.246740	4.381867	5.320000	9.990000	12.990000	16.200000	28.990000	0.429481	-0.155362
installment	436.717127	244.186593	15.670000	260.705000	382.550000	572.600000	1445.460000	0.936952	0.685970
annual_inc	7.502759e+04	6.469830e+04	0.000000e+00	4.500000e+04	6.500000e+04	9.000000e+04	9.500000e+06	4.447849e+01	4.808192e+03
dti	18.157039	17.190626	0.000000	11.910000	17.650000	23.950000	9999.000000	441.486775	256126.862941
delinq_2yrs	0.314442	0.862244	0.000000	0.000000	0.000000	0.000000	39.000000	5.473796	57.309081
inq_last_6mths	0.694623	0.998448	0.000000	0.000000	0.000000	1.000000	33.000000	2.108411	11.925103
mths_since_last_delinq	34.063798	21.884940	0.000000	15.000000	31.000000	50.000000	188.000000	0.455520	-0.767314
open_acc	11.548469	5.317313	0.000000	8.000000	11.000000	14.000000	90.000000	1.249380	3.103994
pub_rec	0.195307	0.582091	0.000000	0.000000	0.000000	0.000000	86.000000	13.261941	993.199008
revol_bal	1.692079e+04	2.242679e+04	0.000000	6.443000e+03	1.187500e+04	2.082900e+04	2.904836e+06	1.594930e+01	9.858908e+02
revol_util	55.067693	23.834344	0.000000	37.700000	56.000000	73.600000	892.300000	-0.123869	1.027269
total_acc	25.268026	11.840561	0.000000	17.000000	24.000000	32.000000	169.000000	0.892539	1.377589
out_prncp	8403.124852	8493.450269	0.000000	0.000000	6458.290000	13659.055000	49372.860000	0.932018	0.122621
out_prncp_inv	8399.713242	8489.997617	0.000000	0.000000	6455.810000	13654.050000	49372.860000	0.931868	0.121827
total_pymnt	7558.826684	7871.243336	0.000000	1914.590000	4894.999117	10616.814231	57777.579870	1.788894	3.620120
total_pymnt_inv	7521.160306	7846.108604	0.000000	1899.700000	4862.010000	10565.690000	57777.580000	1.793832	3.641981
total_rec_prncp	5757.706424	6625.441046	0.000000	1200.570000	3215.320000	8000.000000	35000.030000	1.935036	3.989046
total_rec_int	1754.804327	2095.356099	0.000000	441.460000	1073.280000	2238.265000	24205.620000	2.826100	11.543598
total_rec_late_fee	0.396692	4.087825	0.000000	0.000000	0.000000	0.000000	358.680000	17.404085	515.724165
recoveries	45.919243	409.693874	0.000000	0.000000	0.000000	0.000000	33520.270000	18.061839	617.211417
collection_recovery_fee	4.880757	63.125281	0.000000	0.000000	0.000000	0.000000	7002.190000	29.655693	1684.165364
last_pymnt_amnt	2164.145585	4794.783233	0.000000	280.170000	462.780000	831.245000	36475.590000	3.475852	13.355772
collections_12_mths_ex_med	0.014380	0.134191	0.000000	0.000000	0.000000	0.000000	20.000000	17.410400	1097.854795
mths_since_last_major_derog	44.104838	22.179841	0.000000	27.000000	44.000000	61.000000	188.000000	0.264932	-0.031362
acc_now_delinq	0.004991	0.077625	0.000000	0.000000	0.000000	0.000000	14.000000	24.066357	1630.866453
tot_coll_amt	2.257026e+02	1.031137e+04	0.000000	0.000000e+00	0.000000e+00	0.000000e+00	9.152545e+06	8.561805e+02	7.596112e+05
tot_cur_bal	1.394582e+05	1.537500e+05	0.000000	2.985300e+04	8.055900e+04	2.082050e+05	8.000078e+06	2.918174e+00	2.940881e+01
total_rev_hi_lim	3.206862e+04	3.749826e+04	0.000000	1.390000e+04	2.370000e+04	3.980000e+04	9.999999e+06	7.304552e+01	1.840039e+04

Tabla 5. Resumen de estadísticas descriptivas para cada columna numérica.

De esta tabla se pueden realizar las siguientes observaciones:

• annual_inc, dti, pub_rec, recoveries, collection_recovery_fee, tot_coll_amt, total_rev_hi_lim, entre otras, presentan fuerte asimetría a la derecha (valores extremos altos). Esto podría llegar a afectar el modelo de redes neuronales.

• dti, annual_inc, tot_coll_amt, pub_rec, collections_12_mths_ex_med, total_rev_hi_lim, etc., tienen colas pesadas con outliers extremos.

• delinq_2yrs, inq_last_6mths, pub_rec, collections_12_mths_ex_med, acc_now_delinq, etc., tienen mayoría de valores en 0.

• Variables financieras como loan_amnt, funded_amnt, installment, total_pymnt, etc., probablemente están altamente correlacionadas.

• Montos como total_rec_late_fee, recoveries, collection_recovery_fee tienen valores extremos que pueden distorsionar análisis

1.4.2 Valores vacíos y conteo de valores por columna

Nombre de Columna	Número de valores null	Porcentaje de valores null	Número de valores únicos en columna (Si tiene menos de 300, se muestran los primeros 20 valores)
annual_inc	4	0.000451	49385
delinq_2yrs	29	0.003268	30 [ 0. 2. 3. 1. 4. 6. 5. 8. 7. 9. 11. nan 13. 15. 10. 12. 17. 18. 29. 24.]
inq_last_6mths	29	0.003268	29 [ 1. 5. 2. 0. 3. 4. 6. 7. 8. 9. 10. 11. 12. 15. 14. 33. 17. 32. 24. 13.]
mths_since_last_delinq	454312	51.197065	156 [nan 35. 38. 61. 8. 20. 18. 68. 45. 48. 41. 40. 74. 25. 53. 39. 10. 26. 56. 77.]
open_acc	29	0.003268	78 [ 3. 2. 10. 15. 9. 7. 4. 11. 14. 12. 20. 8. 6. 17. 5. 13. 16. 30. 21. 18.]
pub_rec	29	0.003268	33 [ 0. 1. 2. 3. 4. 5. nan 6. 9. 8. 7. 11. 49. 10. 54. 12. 18. 19. 16. 15.]
revol_util	502	0.056571	1357
total_acc	29	0.003268	136
collections_12_mths_ex_med	145	0.016340	13 [ 0. nan 1. 2. 4. 3. 6. 16. 20. 5. 7. 10. 14.]
mths_since_last_major_derog	665676	75.015974	169 [nan 53. 34. 54. 69. 7. 16. 71. 33. 59. 45. 8. 56. 11. 50. 47. 64. 32. 62. 39.]
acc_now_delinq	29	0.003268	9 [ 0. 1. nan 2. 3. 5. 4. 6. 14.]
tot_coll_amt	70276	7.919502	10326
tot_cur_bal	70276	7.919502	327343
total_rev_hi_lim	70276	7.919502	21252

Tabla 6. Valores vacíos y conteo de valores únicos para cada columna numérica.

Los valores null de las columnas categóricas se resumen en la Tabla 6. A partir de esto se pudo notar lo siguiente:

• Las columnas con mayor número de nulos son mths_since_last_major_derog y mths_since_last_delinq. Se deberán imputar con precaución.

• La mayoría de valores tienen una cantidad de nulos relativamente baja, así que se podrá realizar una imputación sencilla para llenar estos valores.

• Hay varias columnas que tienen nans, así que se tendrán que imputar con precaución también.

1.4.3 Distribución e identificación de datos atípicos (outliers)

Figura 1. Violin plots y box plots de cada variable numérica en el dataset.

En la Figura 1 se muestran plots de violin y caja para poder identificar tanto la distribución de los datos como para identificar los valores anómalos por cada columna. Se puede apreciar lo siguiente:

• loan_amnt, funded_amnt, funded_amnt_inv tienen distribuciones simétricas y estables, sin valores extremos notables.

• installment presenta un leve sesgo a la derecha.

• out_prncp y out_prncp_inv están centradas en cero, indicando muchos préstamos pagados.

• total_rec_prncp se concentra cerca de cero pero con un rango amplio.

• annual_inc tiene un fuerte sesgo a la derecha, con outliers significativos.

• revol_bal, tot_cur_bal, total_rev_hi_lim, total_rec_int, total_rec_late_fee, tot_coll_amt están sesgadas a la derecha con colas largas.

• collection_recovery_fee, recoveries, last_pymnt_amnt, avg_cur_bal también muestran colas largas hacia la derecha.

• delinq_2yrs, inq_last_6mths, open_acc, pub_rec, acc_now_delinq, collections_12_mths_ex_med tienen distribuciones discretas, centradas en pocos valores.

• mths_since_last_delinq y mths_since_last_major_derog presentan huecos grandes debido a muchos valores nulos.

• collections_12_mths_ex_med, acc_now_delinq, total_rec_late_fee, recoveries, collection_recovery_fee están dominadas por ceros.

• funded_amnt, loan_amnt, funded_amnt_inv tienen patrones similares y pueden ser redundantes.

• out_prncp y out_prncp_inv también son similares entre sí.

• total_rec_prncp, total_rec_int, total_rec_late_fee, recoveries podrían agruparse como montos recuperados.

• Variables fuertemente sesgadas podrían beneficiarse de transformaciones.

• Variables con muchos ceros podrían eliminarse.

• Variables redundantes podrían eliminarse o consolidarse.

• Variables discretas con pocos valores pueden tratarse como categorías ordinales.

1.4.4. Conclusiones

A partir de lo anterior, se derivaron las siguientes conclusiones:

• Entre los datos se encuentran varias columnas que están muy o poco sesgadas, además de contar con muchos o pocos outliers. Se tendrá que tener esto en cuenta a la hora de preprocesar los datos.

• Existen varias columnas con valores nulos pero imputables, y por lo tanto se podrá realizar la debida imputación al momento de hacer el preprocesado.

1.5 Análisis exploratorio univariado de columnas no numéricas

1.5.1 Distribución de frecuencias y cardinalidad

A partir del análisis de la estructura del proyecto, se pudieron identificar las columnas no numéricas que se muestran en la Tabla 4. Se procedió a analizar la frecuencia y cardinalidad de estas columnas.

De esto, se pudo identificar lo siguiente:

• term solo tiene dos valores posibles, y por lo tanto podrá ser codificada fácilmente.

• grade y sub_grade están relacionadas, pero sub_grade tiene más granularidad, y por lo tanto se decide eliminar la columna grade.

• emp_length es ordinal, y por lo tanto deberá ser codificada según corresponde.

• home_ownership tiene algunas clases similares, como OTHER, NONE y ANY, por lo que dependiendo de su frecuencia se podrían agrupar.

• verification_status también será fácil de codificar debido a que cuenta solamente con 2 valores.

• Debido a la antiguedad de los datos, se optará luego por descartar las columnas que contengan fechas.

• loan_status será nuestro target, el cual más adelante se codificará siguiendo las recomendaciones dadas por el enunciado del problema.

• purpose es una versión más estructurada y constante de title, y por lo tanto se conservará.

• zip_code y addr_state están relacionadas, pero addr_state tiene menos cardinalidad, y por lo tanto se optará por eliminar la columna zip_code.

• initial_list_status será fácil de codificar al contar con pocos valores.

1.5.2 Conteo de valores por columna

Figura 2. Gráficos de barras para las variables categóricas.

En la Figura 2 se muestran los gráficos de barras generados para ver la frecuencia de los valores de cada variable categórica. De esta, se puede identificar lo siguiente:

• Muchas variables categóricas (como term, grade, pymnt_plan, application_type) tienen categorías dominantes, lo que sugiere un fuerte desbalance que se tendría que tratar, por ejemplo, eliminando las filas que contienen valores que no son comunes.

• Se puede ver que la mayoría de los préstamos son a 36 meses y los principales motivos de préstamo son deb_consolidation y credit_card.

• La mayoría de los datos tienen a MORTGAGE como su estado de home_ownership.

• Columnas como application_type, last_credit_pull_d, next_pymnt, last_pymnt_d, pymnt_plan y home_ownership tienen muy poca variabilidad o tienen valores que son muy raros. Para tratarlos, se optará por eliminar las filas que contengan valores extremadamente raros, y se eliminarán columnas que tengan más del 80% de los valores iguales.

1.5.3 Limpieza adicional de columnas con poca varianza

A partir de lo anteriormente mencionado, se decidió por realizar las siguientes acciones de limpieza para las columnas categóricas:

• Se eliminarán las columnas grade y zip_code debido a que ya tienen otras columnas que encapsulan sus significados.

• Por el momento, debido a que los datos van hasta el 2016, se eliminarán las siguientes columnas que representan fechas: last_pymnt_d, next_pymnt_d, issue_d, earliest_cr_line, last_credit_pull_d.

• Se eliminarán las filas que no cumplan con los siguientes criterios:

  • El valor de home_ownership deberá ser RENT, MORTGAGE o OWN.

  • El valor de pymnt_plan deberá ser “n”.

  • El valor de application_type deberá ser INDIVIDUAL.

Una vez aplicada la limpieza de acuerdo a los anteriores criterios, se pasó de tener 887379 filas a tener 886623 filas, es decir, que hubo una reducción de menos del 0.01% del dataset.

1.6 Análisis multivariado

1.6.1 Transformación de target a valores numéricos

Según el enunciado, los valores del target deberán ser codificados de la siguiente manera:

• Positive (0): Si el target es “Fully Paid” o “Does not meet the credit policy. Status:Fully Paid”.

• Negative (1): Si el target es “Charged Off”, “Late (31-120 days)”, “Default” o “Does not meet the credit policy. Status:Charged off”.

• Null (indefinido): Si el target es “Current”, “Issued”, “In Grace Period” o “Late (16-30 days)”.

La codificación se realizó utilizando la siguiente función de mapeo:

positive = {
    "Fully Paid", 
    "Does not meet the credit policy. Status:Fully Paid"
}
negative = {
    "Charged Off",
    "Late (31-120 days)",
    "Default",
    "Does not meet the credit policy. Status:Charged Off"
}
null = {
    "Current",
    "Issued",
    "In Grace Period",
    "Late (16-30 days)",
}


def custom_target_transformer(value):
    if value in positive:
        return 0
    elif value in negative:
        return 1
    else:
        return np.nan

Con el target debidamente codificado como una variable binaria, ya se podrá realizar un análisis de correlación respectivo.

1.6.2 Matriz de correlación

Figura 3. Matriz de correlación.

De esta matriz de correlación, considerando que loan_status es el target del problema de aprendizaje supervisado, se observa lo siguiente:

• Las columnas loan_amnt, funded_amnt y funded_amnt_inv están fuertemente correlacionadas, lo cual tiene sentido al tratarse de representaciones del monto del préstamo.

• La mayoría de las variables presentan correlaciones moderadas o bajas, lo cual es positivo para evitar redundancia en modelos lineales como regresión logística.

• loan_status no tiene correlaciones muy fuertes, lo que sugiere que no hay ningún predictor lineal dominante y que el modelo podría beneficiarse de enfoques no lineales o combinaciones de múltiples variables.

1.6.3 Análisis de target

Tras hacer la conversión de loan_status a valores binarios, se procedió a realizar el análisis de la frecuencia de las clases.

loan_status	Conteo	Frecuencia de valor
NaN	618330	69.7%
0	209526	23.6%
1	58767	6.6%

Tabla 7. Balance de target antes de eliminar valores NaN.

En la Tabla 7 se muestran los valores en la columna del target loan_status. Como se busca realizar el entrenamiento del modelo, aquellos valores NaN que están en la columna no nos servirán, y por lo tanto esas filas se eliminarán.

loan_status	Conteo	Frecuencia de valor
0	209526	78.1%
1	58767	21.9%

Tabla 8. Balance de target después de eliminar valores NaN.

En la Tabla 8 se muestra el nuevo balance de los valores de las clases después de eliminar las filas con NaNs en el target.

Ya se cuenta con un total de 268293 de 887379 que se tenían inicialmente, lo cual representa una disminución considerable del 70% de los datos. Sin embargo, debido a cómo se recomendó codificar el target, se considera apropiado.

1.6.4 Conclusiones

A partir de lo anterior, se derivaron las siguientes conclusiones:

• La transformación del target loan_status a una variable binaria permitió definir con claridad las clases positivas y negativas, eliminando aquellos casos con estado incierto.
• La matriz de correlación reveló que no existe una variable numérica con correlación fuerte directa con el target, lo que sugiere que se requerirán modelos no lineales o técnicas de combinación de variables para una predicción efectiva.
• La eliminación de registros con valores nulos en el target redujo el dataset en aproximadamente un 70%, lo cual representa una pérdida significativa de datos, pero es necesaria para garantizar la calidad del aprendizaje supervisado.
• Tras la depuración, se identificó un leve desbalance de clases (78.1% positivas vs 21.9% negativas), lo cual se deberá tener en cuenta en el diseño del modelo y en la selección de métricas de evaluación.

1.7 Conclusiones parte 1

• Se realizó una limpieza estructurada del dataset, eliminando columnas irrelevantes, redundantes o con valores excesivos nulos, lo que permitió reducir la dimensionalidad y facilitar futuros análisis.
• A través del análisis de variables categóricas, se identificaron patrones de frecuencia esperables en atributos como term, grade, home_ownership y purpose, lo cual aporta contexto relevante para la posterior construcción del modelo.
• El análisis de correlación evidenció que muchas variables numéricas tienen baja correlación entre sí y con el target, lo que reduce el riesgo de multicolinealidad pero también sugiere que el problema no será fácilmente resuelto por modelos lineales simples.
• La transformación del target loan_status a una variable binaria (0: positivo, 1: negativo) permitió estructurar el problema como una clasificación supervisada binaria, eliminando casos con estatus indefinido.
• La depuración del target implicó una pérdida significativa de datos (70%), pero se consideró necesaria para asegurar la coherencia y confiabilidad del modelo predictivo.
• El conjunto final presenta un leve desbalance de clases, lo que debe ser tratado adecuadamente en la etapa de modelado mediante técnicas como el uso de métricas apropiadas o balanceo de datos.

Ya con el dataset limpio, se procede a la sección dedicada a la ingeniería de features.

Parte 2. Ingeniería de Features

A continuación se presenta una síntesis de lo realizado en el proceso de ingeniería de features. Todo el código con los detalles de implementación se puede encontrar en el archivo poc_FeatureEngineering.ipynb en el repositorio del proyecto.

2.1 Objetivos

Una vez con el dataset lo suficientemente limpio, se procederá a preprocesar estos datos para poder realizar el entrenamiento de los modelos. Se tendrán los siguientes objetivos:

• Codificar las columnas no numéricas de acuerdo a su naturaleza categórica u ordinal, y de acuerdo a la cardinalidad de cada una.

• Imputar valores nulls para variables numéricas que lo permitan.

• Escalar los datos numéricos para mitigar el efecto de las anomalías en el modelo.

2.2 Tratamiento de columnas numéricas

2.2.1 Imputación de nulls

Para la imputación de nulls, se optó por utilizar un SimpleImputer de la herramienta sklearn, el cual permite realizar imputación de nulls sencilla utilizando la media, mediana o el valor más frecuente. Para este caso, se optó por imputar utilizando el valor de la media para cada columna numérica.

Esto se hizo para poder verificar cómo se comportaba el modelo con este tipo de imputación. Si se notaba que las métricas no eran las deseadas a la hora de evaluar el modelo, se volvería aquí a cambiar la técnica de imputación. Sin embargo, de los resultados del modelado se concluyó que esto era suficiente.

2.2.2 Escalado de datos

Para el escalado de datos, se optó por utilizar el escalador RobustScaler de sklearn, ya que aplica un escalado que es más robusto a los valores atípicos. Según (Interactive Chaos,s.f., Robust Scaler), realiza dos pasos principales:

1. Calcula la mediana y el rango intercuartil (IQR) de cada característica en el conjunto de datos (el IQR es la diferencia entre el percentil 75 y el percentil 25 de los datos).
2. Utiliza la mediana y el IQR de cada característica para escalar los datos.

En caso de ver que el modelo no tiene métricas favorables, se cambiaría. Sin embargo, a partir de los resultados del modelado se concluyó que esta opción era suficiente.

2.3 Tratamiento de columnas no numéricas

2.3.1 Transformación de variables ordinales

A partir de la Tabla 4, se pudieron identificar que las variables ordinales a codificar eran sub_grade y emp_length respectivamente.

Para codificar a sub_grade, dado que se trataba de una “nota” similar a una nota académica, se optó por intentar codificarla de una forma similar a como se califica del 1 al 5 en los sistemas educativos colombianos. Sin embargo, al tratarse de 7 notas mayores (A, B, C, D, E, F y G), la calificación ahora sería del 1 al 7. Por otro lado, cada valor estaba acompañado de un número del 1 al 5, por lo que se optó porque estos valores representaran cierta fracción dentro de la nota mayor.

Se codificó utilizando la siguiente función:

def sub_grade_mapper(val):
    val = str(val)
    grade_mapping = {
        "A": 7,
        "B": 6,
        "C": 5,
        "D": 4,
        "E": 3,
        "F": 2,
        "G": 1
    }
    num_mapping = {
        "1": 0.8,
        "2": 0.6,
        "3": 0.4,
        "4": 0.2,
        "5": 0.0
    }
    num_val = grade_mapping[val[0]] + num_mapping[val[1]]
    return num_val

Para la columna emp_length, se optó por utilizar la clase OrdinalEncoder y sus métodos para codificarla de acuerdo al siguiente orden:

1. “Unknown”: Estos son los valores que estaban como NaN en esta columna.
2. “< 1 year”
3. “1 year”
4. “2 years”
5. “3 years”
6. “4 years”
7. “5 years”
8. “6 years”
9. “7 years”
10. “8 years”
11. “9 years”
12. “10+ years”

Se utilizó la siguiente porción de código para hacerlo:

ordered_vals = [
    "Unknown", 
    "< 1 year", 
    "1 year", 
    "2 years", 
    "3 years", 
    "4 years", 
    "5 years", 
    "6 years", 
    "7 years", 
    "8 years", 
    "9 years", 
    "10+ years"
]
ordinal_encoder = OrdinalEncoder(categories=[ordered_vals])
df["emp_length"] = ordinal_encoder.fit_transform(df[["emp_length"]])

2.3.2 Transformación de variables categóricas con baja cardinalidad

En cuanto a las variables categóricas que contaban con baja cardinalidad, es decir, con pocos valores únicos, se optó por codificarlos utilizando la técnica One-Hot, usando las herramientas de pandas para esto.

Las columnas identificadas como aptas para la implementación de esta técnica de acuerdo a la revisión de la Tabla 4 fueron: term, home_ownership, verification_status, initial_list_status y purpose.

Se codificaron utilizando la siguiente porción de código:

categ_cols_onehot = [
    "term",
    "home_ownership",
    "verification_status",
    "initial_list_status",
    "purpose"
]

df = pd.get_dummies(df, columns=categ_cols_onehot)

2.3.3 Transformación de variables categóricas con alta cardinalidad

Para el caso de la variable addr_state, la cual se consideró que tenía una alta cardinalidad al contar con 51 valores únicos, se optó por utilizar el método de Hashing encoding, el cual es recomendado para variables con alta cardinalidad (Swayam, 2023).

Se utilizó la siguiente porción de código para esto:

hashing_encoder = HashingEncoder(cols=["addr_state"], n_components=8)
    
hashed = hashing_encoder.fit_transform(df[["addr_state"]])
    
hashed.columns = [f"addr_state_hash_{i}" for i in range(hashed.shape[1])]
    
df = df.drop(columns=["addr_state"]).join(hashed)

2.4 Conclusiones parte 2

Tras haber realizado todo el preprocesamiento adecuado de los datos y haber generado un nuevo dataset con todos estos datos tratados, se sacaron las siguientes conclusiones y aprendizajes:

• Se implementaron técnicas adecuadas de preprocesamiento para preparar los datos para el siguiente proceso de modelado, implementando técnicas de imputación, escalado y codificación de variables no numéricas.

• Una variable ordinal puede ser codificada tanto manualmente (si se ve un paralelo claro y una forma de implementación concisa) como apoyándose en herramientas especializadas en codificación, como lo son las herramientas que brinda SKlearn.

• Se logró una transformación del dataset que se considera lo suficientemente coherente, escalada y completamente numérica como para pasar a la siguiente fase de modelado.

Parte 3. Modelado

A continuación se presenta una síntesis de lo realizado en el proceso de modelado. Todo el código con los detalles de implementación se puede encontrar en el archivo poc_Modeling.ipynb en el repositorio del proyecto.

3.1 Objetivos

Ya contando con un dataset listo para el entrenamiento de modelos de deep learning y clasificación binaria, se espera cumplir con los siguientes objetivos:

• Realizar una división apropiada del dataset para entrenar y validar el modelo, concretamente un 70% para entrenamiento y un 30% para la evaluación.

• Entrenar un modelo simple de XGBoost para tenerlo como punto de comparación vs los modelos multiperceptron a definir.

• Entrenar dos modelos multiperceptron con varias variaciones de arquitectura para comparar cómo es el impacto de estos cambios en los valores objetivos para las métricas del modelado.

3.2 Train-Test split

Para hacer el split de los datos, se optó por utilizar una proporción del 70% para el entrenamiento y un 30% para el testeo, el cual es una proporción estándar en machine learning (Stojiljkovic, 2025).

Se hizo el split utilizando la siguiente porción de código:

y = df["loan_status"].astype(int)
X = df.drop(columns=["loan_status"])
X_train, X_test, y_train, y_test = train_test_split(
    X, y,
    test_size = 0.3,
    random_state = 35,
    stratify = y,
    shuffle=True
)

3.3. Modelo 1: XGBoost

XGBoost es una librería de código abierto que emplea árboles de decisiones potenciados por gradiente. (IBM, 2024). Suele ser muy veloz y eficiente con conjuntos grandes de datos. Suele ser muy utilizado en problemas de clasificación y regresión.

3.3.1 Definición del modelo

El modelo utilizado se definió de la siguiente manera:

xgb_classifier = XGBClassifier(
    objective='multi:softmax', # 
    num_class=2,       
    n_estimators=500,          
    learning_rate=0.1,         
    max_depth=3,               
    subsample=0.8,             
    colsample_bytree=0.8,      
    gamma=0,                   
    reg_lambda=1,              
    use_label_encoder=False,   
    eval_metric='mlogloss',    
    random_state=35,
    n_jobs=-1                 
)

A continuación algunas observaciones recogidas para definir el modelo:

• Se optó por utilizar un objetivo multiclase para poder ver cómo afectaba esto a la calidad del modelo, sabiendo que la tarea en cuestión es de clasificación binaria.

• Se optó por utilizar un número relativamente alto de estimadores para garantizar tener un desempeño descente del modelo, considerando que se tiene un alto número de features.

• Se optó por un valor bajo de la tasa de aprendizaje para tener un modelo más robusto.

• Se optó por una profundización de 3 para evitar sobreajuste y ayudar al modelo con la generalización.

• Se introduce una proporción de muestras aleatorias de 80% para reducir el sobreajuste.

• Se introduce una proporción de features para la construcción de los árboles de 0.8 para reducir el sobre ajuste.

• Se le pasa un gamma igual a 0 para darle algo de flexibilidad al modelo.

• Se optó por utilizar multi log loss para la función de pérdida, la cual es válida tanto para problemas multiclase como de clasificación binaria.

3.3.2 Evaluación

Los resultados obtenidos en el conjunto de entrenamiento se resumen en la siguiente tabla generada por el código encargado de realizar la evaluación:

Figura 4. Tabla de resultados de XGBoost en el conjunto de entrenamiento

De igual forma, a continuación se tiene la tabla respectiva para el conjunto de testing.

Figura 5. Tabla de resultados de XGBoost en el conjunto de testing

3.3.3. Conclusiones modelado XGBoost

De los anteriores resultados se obtuvieron las siguientes conclusiones y aprendizajes:

• Sorprendentemente, el modelo tuvo resultados excelentes en ambos conjuntos de datos. Esto es algo sospechoso, debido a que puede haber una alta probabilidad de data leakage debido a la falta de revisión en algún punto durante la limpieza de los datos.

3.4. Modelo 2: XGBoost tras resolver problema de data leakage

Debido a lo anterior, hizo falta revisar nuevamente las columnas utilizadas para verificar que no hubiera ninguna fuga de datos, es decir, que no hubiera ninguna columna que no debiera aparecer al momento de entrenar y evaluar el modelo.

Después de una revisión del diccionario de datos, se confirmó que había un problema de fuga de datos, específicamente con las siguientes columnas que se estaban utilizando:

• total_rec_prncp: Pagos principales recibidos hasta la fecha.
• total_rec_int: Intereses recibidos hasta la fecha.
• total_rec_late_fee: Intereses tardíos recibidos hasta la fecha.
• recoveries: Monto total recuperado por el acreedor después de considerar la deuda como incobrable.
• total_pymnt: Pagos recibidos hasta la fecha de la totalidad de lo prestado.
• total_pymnt_inv: Pagos recibidos hasta la fecha en proporción a lo pagado por inversores.
• collection_recovery_fee: Monto de tarifas cobradas por recuperar la deuda después de haber sido cobrada.
• last_pymnt_amnt: Monto total del último pago recibido.

3.4.2 Evaluación

Los resultados obtenidos en el conjunto de entrenamiento se resumen en la siguiente tabla generada por el código encargado de realizar la evaluación:

Figura 4. Tabla de resultados de XGBoost en el conjunto de entrenamiento corregido

De igual forma, a continuación se tiene la tabla respectiva para el conjunto de testing.

Figura 5. Tabla de resultados de XGBoost en el conjunto de testing corregido

3.4.3. Conclusiones modelado XGBoost

De los anteriores resultados se obtuvieron las siguientes conclusiones y aprendizajes:

• Ahora sí, se cuentan con valores de las métricas más razonables, y por lo tanto se puede concluir que se ha resuelto el problema del data leakage.
• Debido al desbalance de clases, se puede notar que el modelo tiene un buen rendimiento general identificando a las personas que pagan sus deudas (f1 score 0.9), pero no lo es a la hora de identificar los casos de personas que no pagan (f1 score 0.4). Esto es crítico, ya que el interés principal está en identificar a estos últimos para mitigar el riesgo de dar préstamos que no se van a pagar después.

3.5 Modelo 3: MultiLayer Perceptron

3.5.1 Definición del modelo

Para crear el modelo, se optó por utilizar la herramienta PyTorch para crear un modelo multiperceptron. El modelo como tal está definido en la siguiente clase:

class MLP(nn.Module):
    def __init__(self, input_dim, n_classes):
        super(MLP, self).__init__()
        
        self.model = nn.Sequential(
            nn.Linear(input_dim, 128),
            nn.ReLU(),
            nn.BatchNorm1d(128),
            nn.Dropout(0.3),
            nn.Linear(128, 64),
            nn.ReLU(),
            nn.BatchNorm1d(64),
            nn.Dropout(0.3),
            nn.Linear(64, n_classes)
        )
    
    def forward(self, x):
        return self.model(x)

Para el entrenamiento, se utilizó como función de pérdida la función CrossEntropyLoss, y como optimzador, se optó por usar el optimizador ADAM. Se utilizaron 10 épocas para entrenar el respectivo modelo

3.5.2 Evaluación

Los resultados obtenidos en el conjunto de entrenamiento se resumen en la siguiente tabla generada por el código encargado de realizar la evaluación:

Figura 6. Tabla de resultados de Multilayer Perceptronen el conjunto de entrenamiento corregido

De igual forma, a continuación se tiene la tabla respectiva para el conjunto de testing.

Figura 7. Tabla de resultados de Multilayer Perceptron en el conjunto de testing corregido

3.5.3 Conclusiones multilayer perceptron

• Se tiene una situación similar a con el anterior modelo, pero esta vez el modelo pudo clasificar los verdaderos positivos a la perfección.

• Sin embargo, debido al desbalance sigue estando la dificultad con la segunda categoría, lo cual sigue siendo muy crítico.

• Talvez con cambios breves en la red neuronal creada pueda mejorar un poco, pero si no se trata el desbalance se tendrá el mismo problema.

3.6 Conclusiones parte 3

• La división 70/30 de entrenamiento y prueba permitió garantizar que ambas particiones tuvieran una representación balanceada de las clases, lo cual es crucial para problemas de clasificación binaria y especialmente útil en presencia de desbalance.
• El modelo inicial de XGBoost ofreció resultados prometedores, aunque inicialmente demasiado buenos, lo cual llevó a sospechar de un posible problema de data leakage. Esto demuestra la utilidad de este modelo como un baseline fuerte para evaluar comparativamente otros enfoques más complejos como las redes neuronales.
• La detección de variables relacionadas directamente con el resultado a predecir (como pagos realizados, intereses recibidos, etc.) confirmó la existencia de una fuga de información. Su exclusión fue fundamental para obtener resultados realistas y fiables, evidenciando la importancia de una limpieza rigurosa de los datos basada en un buen entendimiento del negocio.
• A pesar de corregir el leakage, ambos modelos (XGBoost y MLP) evidenciaron dificultades para identificar correctamente a los deudores (la clase minoritaria), logrando un F1 score bajo (cercano a 0.4) en esa clase, mientras que el desempeño en la clase mayoritaria fue mucho mejor. Esto es problemático desde el punto de vista de negocio, ya que el foco está en identificar correctamente los casos de alto riesgo.
• El modelo de red neuronal mostró un rendimiento comparable al de XGBoost, con incluso mejor precisión para verdaderos positivos. Sin embargo, el problema de desbalance persistió, lo que indica que ajustes en la arquitectura por sí solos no serán suficientes.
• El modelado no solo sirve para ajustar hiperparámetros y arquitecturas, sino también para validar supuestos, detectar problemas en los datos y comprender las limitaciones de los modelos ante características del dataset como el desbalance o la calidad de las features.

Casos de uso alternativos

El análisis y la detección de personas con alto riesgo de impago crediticio no solo son fundamentales para la gestión financiera de las entidades prestamistas, sino que también pueden extrapolarse a otros dominios mediante el desarrollo de modelos predictivos similares.

Este tipo de enfoque basado en datos permite identificar patrones de comportamiento y factores de riesgo que, una vez comprendidos, pueden aplicarse a problemas como la detección temprana de fraudes financieros, la evaluación de riesgo en la suscripción de seguros o la predicción de enfermedades crónicas en el ámbito de la salud.

Conclusiones finales

A lo largo del desarrollo del proyecto, se evidenció que la calidad del preprocesamiento es determinante para el éxito del modelado, ya que las decisiones tomadas durante la ingeniería de features —como la imputación de valores faltantes, el escalado de variables numéricas y la codificación adecuada de variables categóricas— permitieron construir un conjunto de datos sólido y apto para el entrenamiento de modelos. No obstante, la experiencia con el primer modelo XGBoost también demostró que el data leakage puede invalidar completamente los resultados, resaltando la necesidad de comprender a profundidad el significado y la temporalidad de cada variable para evitar fugas de información.

Una vez corregido este problema, los modelos entrenados dejaron en evidencia otro gran desafío: el desbalance de clases. A pesar de obtener buenos resultados generales, tanto XGBoost como el modelo MultiLayer Perceptron mostraron ser ineficientes para detectar correctamente a los usuarios que no pagan sus deudas, lo cual es crítico dado el objetivo del problema.

Finalmente, se concluye que utilizar modelos más complejos no garantiza mejores resultados si no se aborda de forma adecuada la estructura del problema; por ello, el foco debe estar tanto en la calidad de los datos como en estrategias específicas que respondan a los retos particulares del dominio, como el balanceo de clases o el ajuste fino de métricas.

Reporte de contribución individual

- Leonardo Federico Corona Torres

• Definición y escritura de estructura del reporte.
• Colaboración en creación de video promocional.
• Aportes entregable escrito.

- David Escobar Ruiz

• Realización de limpieza de datos.

• Realización de EDA.

• Realización de ingeniería de features.

• Realización de proceso de modelado.

• Colaboración en creación de video promocional.

- Johan Sebastián Robles Rincón

• Desarrollo del backend de la aplicación web.

• Apoyo en despliegue de la aplicación.

• Apoyo en desarrollo frontend.

• Apoyo en conexión de API del modelo con vistas de Django.

- Sebastian Soto Arcila

• Desarrollo frontend de la aplicación web.

• Apoyo en conexión de API del modelo con vistas de Django.

• Apoyo en despliegue de la aplicación.

• Aportes entregable escrito.

Repositorio de GitHub del proyecto

https://github.com/druiz35/RNABI2025-1-Equipo3/

Link hacia app web del proyecto

http://3.101.66.127:8000/predictor/

Bibliografía

Geeks for Geeks. (2025). Evaluation Metrics in Machine Learning. Geeks for Geeks. Recuperado el 12 de junio de 2025 de https://www.geeksforgeeks.org/metrics-for-machine-learning-model/

IBM. (2024). ¿Qué es XGBoost? IBM. https://www.ibm.com/mx-es/think/topics/xgboost

Interactive Chaos. (s.f.). Robust Scaler. Interactive Chaos. Recuperado el 12 de junio de 2025 de https://interactivechaos.com/es/manual/tutorial-de-machine-learning/robustscaler

Kaggle. (s.f.). Credit Risk Analysis. Kaggle. Recuperado el 12 de junio de 2025 de https://www.kaggle.com/datasets/ranadeep/credit-risk-dataset/data

Stojiljkovic. (2025). Split Your Dataset With scikit-learn’s train_test_split(). Real Python. https://realpython.com/train-test-split-python-data

Swayam. (2023). Exploring Different Encoding Techniques for Machine Learning Models. Medium. https://medium.com/@swayampatil7918/exploring-different-encoding-techniques-for-machine-learning-models-b762e3b546db

Synapse-Analytics. (s.f.). Credit Scoring Explained - The Problem Statement. Synapse Analytics. Recuperado el 12 de junio de 2025 de https://synapse-analytics.io/blog/guide-to-credit-scoring-part-1-the-problem-statement

Wikipedia. (s.f.). Artificial Neural Networks. Wikipedia. Recuperado el 12 de junio de 2025 de https://es.wikipedia.org/wiki/Red_neuronal_artificial