Prediciendo Brechas de SLA en Soporte Técnico

Caso de estudio: Predicción de brechas de SLA
Proyecto: NovaTech AI Support (escenario hipotético, datos sintéticos)
Repo: GitHub-novatech-ai-bottleneck

Resumen ejecutivo

En los equipos de soporte técnico, no todos los tickets representan el mismo nivel de riesgo operacional. Algunos se resuelven en minutos; otros consumen horas de trabajo especializado y terminan incumpliendo el Service Level Agreement (SLA).

Este caso de estudio explora cómo construir un sistema de Machine Learning (ML) capaz de identificar, desde el momento en que se crea un ticket, cuáles tienen mayor probabilidad de incumplir su SLA.

El proyecto se desarrolló como un escenario hipotético para NovaTech AI Support, usando datos sintéticos para replicar un problema real de soporte TI. El objetivo no fue únicamente maximizar el desempeño predictivo, sino diseñar un flujo de ML realista, explicable, reproducible y desplegable.

El resultado más importante del proyecto no fue alcanzar una métrica determinada. Fue descubrir que el primer modelo estaba utilizando información del futuro, y rediseñar el problema alrededor de una pregunta más rigurosa:

¿Qué podemos saber sobre el riesgo de un ticket en el momento exacto en que entra al sistema?

El problema de negocio

Imaginemos una empresa tecnológica que recibe cientos de tickets de soporte cada día. Cada ticket puede representar desde una pregunta simple sobre el producto hasta un problema de integración que requiere investigación especializada.

Para los responsables de soporte, el reto no es solo resolver tickets. Es decidir:

• cuáles necesitan atención inmediata,
• dónde asignar recursos especializados,
• qué tickets tienen mayor riesgo de incumplir el SLA,
• cómo pasar de una operación reactiva a una preventiva.

Hipótesis de negocio: si se identifican anticipadamente los tickets de mayor riesgo, los equipos de soporte pueden priorizar recursos antes de que el problema se convierta en un incumplimiento — mejorando la asignación de recursos, la priorización y la experiencia del cliente.

Criterios de éxito

Una métrica alta de ML no bastaba. El sistema debía cumplir cuatro condiciones:

1. Rendimiento predictivo: identificar correctamente los tickets con riesgo de breach.
2. Validez temporal: usar únicamente información disponible en el momento de la predicción.
3. Explicabilidad Operativa: permitir entender por qué un ticket fue clasificado como riesgoso.
4. Preparación de ingenieria: separar datos, entrenamiento, predicción y documentación de forma reproducible.

La señal de alarma: 100% de precisión

El primer resultado fue exactamente el tipo de resultado que genera una falsa sensación de éxito: el modelo alcanzó ~100% en sus métricas de clasificación.

En un problema operacional real, una predicción perfecta debería generar más preguntas que celebración.

La auditoría de variables reveló el problema: temporal data leakage. El modelo usaba información que solo estaría disponible después de que el ticket hubiera sido resuelto — en particular, el tiempo real de resolución.

Eso crea una relación casi directa con el target: si ya sabemos cuánto tardó en resolverse un ticket, es trivial saber si incumplió su SLA. Pero esa información no existe cuando el ticket acaba de entrar al sistema.

El modelo no estaba prediciendo el futuro. Estaba usando información del futuro para reconstruir el pasado.

Corrección metodológica: restricción estricta a T=0

La solución no fue eliminar una columna. Fue redefinir el problema alrededor del momento en que el modelo realmente se usaría.

Definí T=0 como el momento de creación del ticket (intake). A partir de ahí, una variable solo podía usarse si ya estaba disponible en ese instante.

Features disponibles en T=0 (se mantuvieron):

• Ticket category
• Priority
• Channel
• Target SLA time

Se eliminaron (solo existen después del intake):

• Actual resolution time
• Accumulated waiting time

Esta decisión tuvo una consecuencia inmediata: el ROC-AUC cayó de 1.0000 → 0.9606. A primera vista parece un empeoramiento, pero un modelo ligeramente menos preciso pero válido en produccion es mucho más valioso que un modelo perfecto que no puede utilizarse.

Benchmarking de arquitecturas: más complejidad no significa mejor

Con el problema redefinido, se compararon dos enfoques bajo el mismo feature set T=0. El sistema resuelve una tarea dual: clasificación (¿va a incumplir el SLA?) y regresión (estimación del riesgo/tiempo asociado), de ahí que se reporten tanto métricas de clasificación (ROC-AUC, F1) como de regresión (R²).

Model	Scenario	ROC-AUC	F1-Score	R² (Reg)	¿Listo para producción?
Random Forest	Intake (T=0)	0.9606	0.9095	0.6416	✅ Sí (Recomendado)
PyTorch Multitask	Intake (T=0)	0.9617	0.9047	0.5232	️ Opcional
Random Forest	Omniscient (Leaky)	1.0000	1.0000	N/A	❌ No (Post-mortem only)

Random Forest fue el candidato elegido para producción. Ambos modelos T=0 quedan prácticamente empatados en clasificación (RF gana en F1; la red neuronal gana por un margen mínimo en ROC-AUC - 0.0011), pero RF tiene un desempeño de regresión claramente mejor (R² 0.64 vs 0.52), además de integración nativa con TreeSHAP y menor costo computacional. La complejidad adicional del deep learning no se justifica para una ganancia marginal en clasificación que además se paga con peor R² y menos interpretabilidad directa.

La decisión se basó en el equilibrio entre desempeño, velocidad, interpretabilidad, complejidad y recursos necesarios, no solo en la métrica más alta.

Explicabilidad operativa con SHAP: de caja negra a herramienta de soporte

Una predicción por sí sola no es suficiente para una operación de soporte. Si el sistema marca un ticket como "high risk", el equipo necesita saber por qué. Para responder esa pregunta se incorporó SHAP (SHapley Additive exPlanations) en dos niveles.

Explicación global

probabilidad de breach. Valores SHAP positivos empujan la predicción hacia "alto riesgo".

El análisis SHAP identificó los principales factores de riesgo:

• Integration/API es la categoría más consistente que incrementa el riesgo.
• Un SLA objetivo corto (8h) incrementa significativamente el riesgo frente a uno más amplio (72h).
• Technical Issue es la feature de mayor magnitud, pero es bidireccional: puede aumentar o disminuir el riesgo según el contexto.
• El canal de entrada (email, chat o teléfono) tiene un impacto mínimo.

Esto transforma el modelo de una herramienta puramente predictiva en una fuente de información operacional.

Explicación local

Para un ticket con una probabilidad final de incumplimiento de 99.1%, el análisis descompone la predicción así:

ticket con 99.1% de probabilidad de breach.

La pregunta deja de ser "¿el modelo dice que este ticket es riesgoso?" y pasa a ser "¿qué factores están haciendo que este ticket sea riesgoso?", una diferencia fundamental cuando las predicciones deben convertirse en decisiones humanas.

Implementación en producción y robustez de software

Otro problema común en proyectos de ML es confundir un modelo entrenado en un notebook con un sistema utilizable. Para evitarlo, el proyecto separa explícitamente entrenamiento y predicción.

train.py - carga los datos, ejecuta el pipeline, entrena el modelo y lo guarda para uso posterior. Reproducible mediante un solo comando, sin depender de ejecutar un notebook manualmente.

predict.py - recibe nuevos tickets, ejecuta el flujo de transformación, genera predicciones y guarda los resultados junto con sus probabilidades.

Esto crea una frontera clara: Training → Model Artifact → Prediction, dejando el sistema listo para una futura integración con otros sistemas.

Resultados

• Primer modelo con leakage: ROC-AUC 1.0000 / F1 1.0000 (no válido, usa información futura).
• Modelo corregido con features T=0 (Random Forest): ROC-AUC 0.9606 · F1 0.9095 · R² 0.6416.
• Red neuronal multitarea (PyTorch) T=0: ROC-AUC 0.9617 · F1 0.9047 · R² 0.5232.
• Random Forest seleccionado como candidato de producción por su equilibrio entre desempeño, simplicidad e interpretabilidad.
• SHAP permitió explicar tanto patrones globales como predicciones individuales.

Lecciones clave

• Una métrica perfecta puede ser señal de alarma, no de éxito.
• Definir el momento de la predicción antes de elegir features. La pregunta no es "¿esta variable es predictiva?", sino "¿esta variable existiría en el momento en que necesito predecir?"
• La complejidad debe ganarse su lugar, deep learning no se usa solo porque sea más avanzado.
• La explicabilidad vale cuando responde preguntas operativas concretas, no cuando se incluye como una visualización adicional.
• Un notebook no es un sistema de producción: hace falta data pipeline + validation + model + prediction workflow + logging + documentation + reproducibility.

Conclusión

NovaTech AI comenzó como un problema de predicción de SLA y terminó convirtiéndose en un ejercicio de Machine Learning Engineering.

El resultado más valioso no fue pasar de un ROC-AUC a otro ligeramente mejor. Fue identificar que el primer resultado perfecto era engañoso, redefinir el problema alrededor de T=0, comparar modelos considerando complejidad y valor operacional, incorporar explicabilidad y construir una estructura que pudiera evolucionar de un experimento a un sistema.

Si tienes feedback sobre el enfoque de T=0, la elección de Random Forest sobre deep learning, o ideas para llevar esto más lejos (monitoreo de drift, calibración, API de inferencia), lo leo con gusto en los comentarios. El código completo está en el repo enlazado arriba.