Informe de Resultados y Discusión

1. Resumen del Proyecto

El objetivo de este proyecto fue desarrollar un modelo de Machine Learning capaz de clasificar automáticamente la prioridad (Alta, Media, Baja) de los tickets de una mesa de ayuda. Se siguió un flujo de trabajo completo, desde la recolección y análisis de datos hasta el entrenamiento, evaluación y despliegue de un modelo funcional en una interfaz de usuario interactiva utilizando Streamlit.

El proyecto culminó con éxito, obteniendo un modelo de Regresión Logística que fue seleccionado por su rendimiento superior y desplegado en dos aplicaciones web funcionales.

2. Análisis Exploratorio de Datos (EDA) - Hallazgos Clave

El análisis inicial se realizó sobre un dataset consolidado de 1109 registros. Los hallazgos más importantes que guiaron el preprocesamiento y modelado fueron:

• Desbalanceo de Clases: La variable objetivo, Prioridad, mostró un claro desbalanceo. Aproximadamente el 47% de los tickets eran de prioridad 'Baja', mientras que 'Media' (27%) y 'Alta' (26%) tenían una representación menor. Este hallazgo fue crucial para elegir f1-score (macro avg) como la métrica principal de evaluación, ya que pondera equitativamente el rendimiento en todas las clases.
• Distribuciones Categóricas: El análisis de variables como Area_Solicitante y Grupo_Asignado reveló las áreas y grupos que generan mayor volumen de tickets, proporcionando un contexto operativo valioso.
• Tiempo de Resolución: La variable Tiempo_Resolucion_Horas presentó un fuerte sesgo a la derecha, indicando que la mayoría de los tickets se resuelven rápidamente, pero existe una larga cola de tickets que tardan mucho más tiempo en cerrarse (valores atípicos).

Visualizaciones Generadas

A continuación, se muestran los gráficos generados por el script 00_EDA.py:

3. Modelamiento y Evaluación

Comparación de Modelos

Se entrenaron y evaluaron tres modelos de clasificación distintos utilizando las características categóricas (Area_Solicitante, Grupo_Asignado, Categoria). A continuación se presenta la tabla comparativa de sus métricas de rendimiento en el conjunto de prueba:

Modelo	Accuracy	F1-score (Macro Avg)	Precisión (Clase 'Alta')	Recall (Clase 'Alta')
Regresión Logística	0.8159	0.7690	0.6207	0.7500
Random Forest	0.7545	0.6909	0.5222	0.6528
Gradient Boosting	0.7545	0.6909	0.5222	0.6528

4. Resultados del Despliegue

El modelo seleccionado fue desplegado en dos aplicaciones web interactivas construidas con Streamlit.

Aplicación 1: Predictor de Tickets Individuales

Esta herramienta permite a un usuario ingresar las características de un nuevo ticket (Categoría, Grupo Asignado, Área Solicitante) y recibir una predicción de prioridad en tiempo real, junto con las probabilidades asociadas a cada clase.

Aplicación 2: Dashboard de Tickets por Grupo y Área

Esta aplicación ofrece una vista agregada, procesando todos los tickets del dataset para mostrar un resumen de las prioridades predichas por cada combinación de `Grupo_Asignado` y `Area_Solicitante`. La celda con la mayor cantidad de tickets por fila se resalta en verde para una fácil identificación de patrones.

5. Discusión, Limitaciones y Futuras Mejoras

Discusión

El proyecto demuestra de manera exitosa la viabilidad de utilizar un modelo de Machine Learning para automatizar la priorización de tickets. El modelo de Regresión Logística, aunque simple, provee una base sólida y resultados interpretables que pueden ayudar a optimizar la asignación de recursos en una mesa de ayuda. Las aplicaciones de Streamlit validan que el modelo puede ser integrado en herramientas prácticas para usuarios finales.

Limitaciones del Modelo Actual

• Tamaño del Dataset: El modelo fue entrenado con solo 1109 registros. Un dataset más grande y variado aumentaría la confianza en su capacidad para generalizar a tickets futuros.
• Ingeniería de Características Limitada: El modelo final se basa únicamente en tres variables categóricas. Se está desaprovechando información potencialmente valiosa, como el texto del Asunto o la fecha/hora de creación.
• Validación Simple: Se utilizó una única división de datos para entrenamiento y prueba. Una técnica más robusta como la validación cruzada (k-fold) proporcionaría una estimación más fiable del rendimiento del modelo.
• Sin Optimización de Hiperparámetros: Los modelos se entrenaron con sus hiperparámetros por defecto. Un proceso de ajuste fino podría mejorar aún más el rendimiento.

Posibles Mejoras Futuras

• Incorporar Procesamiento de Lenguaje Natural (NLP): Integrar el análisis del campo Asunto utilizando técnicas como TF-IDF (como se exploró en el script 05_ENTRENA_REPARA_DATOS.py) para capturar el contexto del ticket, lo cual probablemente mejoraría significativamente la precisión.
• Implementar Validación Cruzada y Ajuste de Hiperparámetros: Utilizar herramientas como GridSearchCV para encontrar la mejor combinación de parámetros y validar los resultados de forma más rigurosa.
• Expandir la Ingeniería de Características: Extraer nuevas características de las columnas de fecha, como el día de la semana, la hora del día o si fue creado fuera del horario laboral.
• Recopilar Más Datos: Implementar un ciclo de retroalimentación donde el modelo se re-entrene periódicamente con nuevos tickets para que aprenda de nuevos patrones y no se vuelva obsoleto.