La rotación de empleados no es solo un "problema de Recursos Humanos": es una fuga directa de capital. Según Gallup, reemplazar a un empleado cuesta habitualmente entre 0.5 y 2 veces su salario anual, entre reclutamiento, onboarding y pérdida de productividad.
La mayoría de los proyectos de Machine Learning en este dominio se detienen en una métrica superficial: "nuestro modelo predice quién se irá con 85% de ROC-AUC". Pero esa cifra, por sí sola, no le dice a un director financiero cuánto invertir para evitarlo, ni a quién priorizar cuando el presupuesto es limitado.
Este artículo documenta el diseño, evaluación y entrega de un Sistema de Soporte a la Decisión (DSS) que combina modelado predictivo, explicabilidad con SHAP, segmentación no supervisada y optimización financiera bajo restricción de presupuesto, junto con el proceso de control de calidad que se aplicó antes de considerarlo listo para producción.
Repositorio completo:
👉github.com/purischaky/workforce_attrition_project
Paso 1: Diseñar el problema
El primer paso no fue elegir un algoritmo. Fue definir qué pregunta de negocio se estaba respondiendo. "Predecir la rotación" no es el objetivo real; el objetivo es estimar un costo esperado y decidir dónde asignar presupuesto. Esa distinción definió toda la arquitectura:
src/features.py - un transformador custom (LaborEconomicsFeatures) que construye ratios econométricos, no solo variables crudas. Por ejemplo la presión de burnout:
Junto con la velocidad de carrera, el índice de estancamiento y el salario relativo contra la mediana correspondiente a departamento y nivel de cargo.
src/models.py - Un enfoque de modelado dual:
- una regresión logística (para interpretabilidad vía odds ratios)
- un HistGradientBoostingClassifier calibrado con CalibratedClassifierCV. Un buen AUC no es suficiente: si las probabilidades no están calibradas, cualquier cálculo de ROI que dependa de ellas pierde validez matemática.
src/explainability.py - SHAP para explicar por qué el modelo predice lo que predice, a nivel global y local.
src/segmentation.py - Análisis de Componentes Principales(PCA) + K-Means para encontrar arquetipos latentes de empleados, más allá de la etiqueta binaria "se va / se queda".
src/retention_optimizer.py - el módulo central desde una perspectiva de negocio. Dado un presupuesto fijo, resuelve un problema para determinar ¿a quién se le asigna una intervención de retención para maximizar el valor esperado neto?
Paso 2: Traducir el modelo a una decisión de asignación de presupuesto
Tras entrenar y calibrar, el modelo alcanzó un ROC-AUC ≈ 0.81 con un Brier Score de ~0.10, es decir, probabilidades bien calibradas y no solo un buen ranking. SHAP confirmó los principales drivers de rotación: satisfaction_score, burnout_pressure_ratio y promotion_wait_years.
El resultado con mayor peso de negocio fue el siguiente: con un presupuesto de $50,000 distribuido entre 20 empleados de alto riesgo (a $2,500 por intervención), el modelo proyectó $745,000+ en valor esperado salvado, un ROI neto de ~1,391%.
Esa cifra se deriva directamente de la optimización bajo restricción de presupuesto:
Donde:
- k: número de empleados seleccionados dentro del presupuesto disponible.
- P_i: probabilidad calibrada de que el empleado i renuncie.
- C_reemplazo,i: costo estimado de reemplazar al empleado i (1.5 × salario anual).
- S_i: tasa de éxito estimada de la intervención de retención.
- I_i: costo directo de implementar la intervención (ej. $2,500).
El valor de este enfoque no está en la cifra en sí, sino en que convierte una lista de probabilidades en una tabla de asignación de capital accionable: qué empleados, con qué prioridad, y con qué retorno esperado. Esa es la diferencia entre un modelo predictivo y una herramienta de decisión ejecutiva.
Paso 3: Control de calidad: auditar el código antes de entregarlo como producción
Un pipeline que produce buenas métricas no es lo mismo que un pipeline listo para producción. Antes de considerar el proyecto terminado, se ejecutó un proceso de auditoría técnica, tests y reproducibilidad, módulo por módulo, con apoyo de IA para acelerar la revisión y las correcciones.
Los hallazgos y sus correcciones:
Path roto → el pipeline apuntaba a un archivo incorrecto y caía en un fallback silencioso que auditaba datos ya procesados en vez de datos crudos. Una vez corregido, se agregó un warning explícito para que cualquier futura desviación de este tipo sea visible en consola.
Reentrenamiento → el modelo se entrenaba desde cero tres veces en una sola corrida del pipeline. Se introdujo serialización con joblib: el modelo se entrena una vez y los módulos de explicabilidad y optimización cargan el artefacto en vez de reentrenar. El pipeline pasó de 3 entrenamientos a 1 por corrida.
README vs. tests → Se sincronizó la documentación con el código real y se agregó el test que faltaba (test_models.py) en vez de solo borrar la mención.
Módulo desconectado → eda_economic.py, responsable de la validación de hipótesis econométricas, no estaba integrado en el pipeline principal. Se conectó a main.py como paso formal del proceso.
Reproducibilidad del split de datos → no existía un script que generara los conjuntos de entrenamiento y prueba desde el dato crudo. Se creó src/make_dataset.py, con train_test_split estratificado y semilla fija, para que el pipeline sea reproducible de punta a punta por cualquier persona que clone el repositorio.
Lo que este proceso demuestra, desde una perspectiva de negocio
Hoy en día, el verdadero diferencial no está en la métrica, sino en la capacidad de traducir esa predicción en una decisión de negocio con un ROI cuantificado. Para ello, se debe someter el propio trabajo a un rigor de ingeniería implacable antes de darlo por terminado: rutas de datos verificadas, persistencia de modelos, documentación sincronizada y reproducibilidad garantizada desde el dato crudo.
Ese debe ser el estándar para evaluar cualquier proyecto de Machine Learning que aspire a estar en producción. No se trata solo de que el modelo prediga bien, sino de que el sistema completo (pipeline, tests, documentación y arquitectura), resista una auditoría externa sin una sola sorpresa.
¿Quieres replicarlo o contribuir?
El proyecto usa datos sintéticos con propiedades econométricas realistas, pensado para adaptarse a datasets reales de cualquier organización interesada en cuantificar su exposición financiera a la rotación de talento.
🔗Explora el código, clona el repositorio y ejecuta el dashboard aquí:
👉 https://github.com/purischaky/workforce_attrition_project.git
¿Has abordado el problema de la rotación de personal en tu empresa? ¿Usaste algún enfoque de optimización de presupuesto? ¡Déjame tus comentarios abajo! 👇
Top comments (0)