Modelado predictivo · IA aplicada
Lead scoring y asistente RAG
Trabajo de fin de máster para la Universidad Pontificia Comillas. Un modelo que ordena los contactos de admisiones por probabilidad de entregar la documentación de matrícula y los devuelve como A, B o C, más un asistente que responde las dudas repetidas. Evaluado sobre el histórico del CRM: los dos módulos todavía no se comunican entre sí ni están en producción.
El problema
El problema no era tener pocos leads. Era el orden.
Un equipo de admisiones recibe más contactos de los que puede llamar en el plazo en que un contacto sigue caliente. Sin un criterio, se llama por orden de llegada, que es tanto como llamar al azar. La pregunta del trabajo no fue «cuántos vendrán», sino «a quién llamo primero», que es la que se puede responder por la mañana y ejecutar por la tarde.
El punto de partida fueron 30.593 registros del CRM de admisiones con 44 variables. Tras depurar duplicados, registros incompletos y contactos fuera del proceso, quedaron 24.365 leads utilizables.
El objetivo a predecir es haber entregado la documentación de matrícula: el paso que separa a quien se está informando de quien va en serio. Es una clase minoritaria, así que el problema está muy desbalanceado y eso condiciona todo lo que viene después.
Diagrama de embudo: 30.593 registros de partida, 44 variables, y 24.365 leads utilizables tras la depuración.
El proceso real
Un lead no llega: recorre un embudo.
Antes de modelar nada hay que saber por dónde pasa un candidato. Entra por un canal, queda registrado en el CRM, sube a zona MQL, se cualifica en zona SQL y termina —o no— presentando la solicitud en el Portal de Admisiones. El modelo no es una pieza aparte: vive dentro de la zona MQL, que es exactamente donde el equipo decide a quién llama primero.
La variable objetivo es la entrega de documentación, no la matrícula. Las notas son confidenciales y la matrícula depende de cosas que el candidato no controla; la documentación depende solo de él, y el CRM la registra sin ambigüedad. Predecir lo que no se puede observar limpiamente es la forma más rápida de construir un modelo que no sirve.
El Portal de Admisiones queda fuera del dataset a propósito: quien llega ahí convierte casi siempre, así que incluirlo distorsionaría la comparación. Es la última etapa del recorrido y la primera que hay que excluir del modelado.
Cadena de cinco etapas encadenadas de arriba abajo. Primera, Canales: web, eventos, publicidad y tradicional. Segunda, CRM Dynamics, que registra el lead. Tercera, zona MQL: alta, nurturing y scoring en categorías A, B o C, que es donde actúa el modelo. Cuarta, zona SQL: cualificación y evaluación. Y quinta, Portal de Admisiones: solicitud de admisión, que es la conversión.
Cómo se hizo
Seis fases, y cada una condiciona la siguiente.
El trabajo no se hizo de una vez: se hizo en seis fases, y el orden importa porque cada decisión cierra puertas a la de después. Elegir la variable objetivo antes de mirar los modelos, y fijar los cortes de categoría sobre entrenamiento y no sobre test, son las dos que más sostienen todo lo demás.
Las tres primeras fases son de modelado y responden a «¿funciona?». Las tres últimas responden a «¿sirve?»: una probabilidad convertida en categorías que un equipo puede usar, una comprobación de que el modelo aguanta el curso siguiente, y un segundo módulo que descarga al equipo de las dudas repetidas.
La validación temporal está al final por un motivo: es la única fase que puede invalidar a las anteriores. Un modelo que gana en test y se cae al curso siguiente no es un modelo, es una foto.
Recorrido vertical con las seis fases del trabajo, en orden: el dataset, con 24.365 leads y 44 variables; el entrenamiento, con 3 modelos y validación 5-fold; los resultados en test, con Random Forest y un PR-AUC de 0,691; las categorías A, B y C, con A más B capturando el 95,82% de las entregas; la validación temporal, con una caída de 0,0105 sin reentrenar; y el asistente con RAG sobre Copilot Studio, con protocolo de derivación a una persona.
El modelo
Un Random Forest, y la métrica correcta.
Con una clase positiva minoritaria, la exactitud es una trampa: un modelo que dijera «no» a todo acertaría casi siempre y no serviría para nada. La métrica que manda aquí es el PR-AUC, que solo mira la clase que interesa. En test el modelo llega a 0,691 de PR-AUC y 0,947 de ROC-AUC.
Se probaron varias familias antes de quedarse con Random Forest. Ganó por dos razones prácticas: aguanta bien el desbalanceo con pesos por clase y no se descompone cuando una variable tiene huecos, que en un CRM real es la norma y no la excepción.
El modelo no se entrega como una caja negra. Con SHAP se ve qué empuja cada predicción, y lo que más pesa son tres familias de variables: la actividad del contacto —eventos a los que asiste, peticiones que hace, visitas que registra—, el canal por el que entró y su zona de residencia.
Matriz de tres modelos por tres métricas. Regresión logística: PR-AUC 0,577 en validación cruzada, 0,564 en test, caída de 0,013. Random Forest, el elegido: 0,698, 0,691 y caída de 0,007. Gradient Boosting: 0,695, 0,685 y caída de 0,010. En las dos primeras columnas gana el valor más alto; en la caída, el más bajo.
La salida
Un comercial no llama a una probabilidad.
El modelo devuelve una probabilidad, pero nadie organiza una mañana de llamadas con cuatro decimales. La salida que usa el equipo son tres categorías por percentiles: A, B y C. Y ahí está el resultado que justifica todo lo demás: trabajando el 30,35% de los contactos —las categorías A y B— se captura el 95,82% de las entregas de documentación.
La categoría A es el 8,06% del volumen y convierte 6,8 veces por encima de la media. Es la lista de la primera hora de la mañana.
La C no se tira: se le manda información y se la deja madurar. Lo que cambia no es a quién se atiende, sino en qué orden y con cuánto esfuerzo, que es la única variable que un equipo pequeño controla de verdad.
Dos barras comparadas: las categorías A y B son el 30,35% del volumen de contactos y capturan el 95,82% de las entregas de documentación.
Validación temporal
La prueba que separa un modelo de clase de uno de producción.
Partir los datos al azar y medir ahí es cómodo, pero no dice nada sobre si el modelo seguirá sirviendo el curso que viene. Así que se probó contra la campaña siguiente, sin reentrenar y sin verla durante el entrenamiento. El PR-AUC baja 0,0105.
Poco más de una centésima es una caída pequeña, pero conviene decir exactamente de qué: es una métrica global, y lo que enseña es que el orden general aguanta de una campaña a la siguiente. No demuestra que la lista concreta de una mañana salga igual; eso sería otra medición, y no está hecha.
Para el mantenimiento sirve como cota, no como permiso: un curso sin reentrenar no deja el modelo inservible. Lo prudente sigue siendo reentrenar cada campaña, porque la prueba cubre un salto, no varios.
Dos medidores casi idénticos: PR-AUC de 0,6911 en el conjunto de test y de 0,6806 sobre la campaña siguiente sin reentrenar, una caída de 0,0105.
Segundo módulo
Y un asistente para las preguntas de siempre.
Priorizar la lista no sirve de nada si el equipo se pasa la mañana contestando las mismas cuatro dudas. El segundo módulo es un asistente con arquitectura RAG montado en Copilot Studio sobre la documentación oficial de admisión a grado.
RAG y no un modelo entrenado a medida por una razón concreta: las respuestas se fundamentan en el documento oficial vigente en vez de en lo que un modelo recuerde. Cuando cambia la normativa se cambia el documento y el asistente cambia con él. Fundamentar reduce las respuestas inventadas, no las elimina: la propia plataforma lo advierte.
Cubre cuatro categorías temáticas y tiene un protocolo de fallback explícito: si la pregunta se sale de lo que puede responder con la documentación, deriva a una persona en vez de improvisar. Un asistente de admisiones que se inventa un plazo hace más daño que uno que no contesta. Está validado en el panel de Copilot Studio, no con candidatos reales: las tasas de resolución y de derivación quedan definidas y pendientes de medir.
Esquema radial del asistente con RAG en el centro y cuatro piezas alrededor: arriba la base de conocimiento, a la izquierda la pregunta, a la derecha la respuesta y, por debajo y con línea de puntos, una persona del equipo, a la que se deriva cuando la documentación no da para responder.
Lo que no está aquí
La memoria no circula, y es parte del trabajo.
Este proyecto se hizo con datos reales del CRM de admisiones de una universidad. En esta página están las métricas del modelo, el reparto por categorías y la validación temporal, que son resultados del modelo y no dicen nada de nadie.
Lo que no está, y no va a estar: la tasa de conversión de la universidad, qué canales de captación le funcionan mejor, los umbrales concretos que separan A de B, y por supuesto ningún registro. Eso es información de negocio de Comillas y no es mía para publicarla.
La presentación de la defensa sí está, pero en una versión pública: he retirado el embudo de captación, el análisis por canal y por colegio de procedencia, la tasa de conversión de la universidad y los percentiles que fijan los cortes de A y B. Lo que queda son resultados del modelo, que no dicen nada de nadie.
La memoria completa la enseño en persona. Si estás valorando el trabajo y necesitas ver el detalle, escríbeme y lo vemos.
