XGBoost para churn: por qué gana y cuándo no usarlo

La tabla que lo dice todo

Empecemos por el final, con los números. En un estudio comparativo sobre un dataset de churn de ecommerce, cinco modelos compitieron sobre exactamente los mismos datos. La regresión logística, el modelo clásico e interpretable, alcanzó un recall de apenas 0,471: dejó escapar a más de la mitad de los clientes que realmente abandonaron. XGBoost, en el otro extremo, alcanzó 0,952. Traducido a negocio, la elección del mejor modelo era capaz de mantener a casi todos los los clientes en riesgo o lo que es lo mismo, clientes con CPA nuevo nulo.

Fíjate en la fila de la regresión logística: un accuracy de 0,883 que parece respetable junto a un recall de 0,471 que es un desastre. Es exactamente la trampa que describimos en el artículo anterior, hecha tabla. Si Ficticia Commerce hubiera elegido su modelo por accuracy, habría descartado opciones mucho mejores y se habría quedado con una que ignora a la mitad de sus desertores. Conviene también mirar a CatBoost, que tiene el mejor F1 de la tabla pese a un recall inferior al de XGBoost: un recordatorio de que no existe un único número que decida por ti, sino que la elección depende de qué error te cuesta más caro.

Qué hace distinto a XGBoost

La diferencia de fondo entre XGBoost y Random Forest está en cómo combinan los árboles que los componen. Random Forest usa bagging: entrena muchos árboles en paralelo, cada uno sobre una muestra distinta de los datos, y promedia sus opiniones. Es un consenso democrático donde todos votan a la vez y de forma independiente, sin saber qué opinan los demás. XGBoost usa boosting: entrena los árboles en secuencia, y cada nuevo árbol se especializa en corregir los errores que cometieron los anteriores. No es un consenso simultáneo, es un aprendizaje acumulativo donde cada paso se construye sobre las equivocaciones del paso previo.

Esos árboles encadenados son, igual que en Random Forest, árboles de decisión en su base. La diferencia no está en la pieza, sino en cómo se ensamblan: el boosting concentra la capacidad del modelo justo donde están los casos que más cuestan, que en churn son precisamente los desertores difíciles de detectar, los que un modelo perezoso clasificaría como clientes estables sin pensárselo dos veces.

Las tres ventajas que importan en churn

Más allá del boosting, XGBoost trae tres características que encajan especialmente bien con los datos de clientes. La primera es la regularización: incorpora penalizaciones que castigan la complejidad excesiva del modelo, desincentivando que se ajuste a ruido en lugar de a señal. En datasets de churn, que suelen ser modestos en tamaño y ricos en peculiaridades irrelevantes, esto es decisivo para que el modelo generalice a clientes nuevos en lugar de memorizar los que ya ha visto. Random Forest también controla el sobreajuste, pero lo hace por promediado; XGBoost lo hace además de forma explícita en su función objetivo, lo que le da un control más fino.

La segunda es el manejo nativo de valores ausentes. Los datos de clientes están llenos de huecos: campos sin rellenar, métricas que no aplican a todos los perfiles, integraciones imperfectas entre sistemas. XGBoost aprende automáticamente, en cada división del árbol, hacia qué rama enviar un dato faltante, sin que tengas que imputar los huecos a mano con medias o medianas que introducen sesgos. La tercera es el control fino sobre el umbral de decisión, que es la palanca que conecta directamente con el recall y que merece su propia sección por lo determinante que resulta en retención.

Implementación y los hiperparámetros que importan

El código para entrenar XGBoost sobre el dataset de Ficticia Commerce reutiliza el mismo X_train e y_train del pipeline anterior. La novedad está en el final: en lugar de pedirle al modelo una predicción binaria directa, le pedimos la probabilidad de churn de cada cliente y decidimos nosotros dónde poner el corte. Ese umbral es lo que nos permite priorizar el recall de forma explícita y consciente.

import xgboost as xgb
from sklearn.metrics import recall_score, precision_score, f1_score

# Reutilizamos X_train, y_train del pipeline del artículo anterior
modelo_xgb = xgb.XGBClassifier(
    n_estimators=400,       # nº de árboles encadenados
    max_depth=5,            # profundidad de cada árbol; controla complejidad
    learning_rate=0.05,    # cuánto corrige cada árbol; bajo = más estable
    scale_pos_weight=9,      # compensa un desbalance de ~10:1
    eval_metric="logloss",
    random_state=42
)
modelo_xgb.fit(X_train, y_train)

# Pedimos probabilidades, no clases: así controlamos el umbral
proba = modelo_xgb.predict_proba(X_test)[:, 1]

# Bajar el umbral aumenta el recall a costa de algo de precisión
for umbral in [0.5, 0.35, 0.25]:
    pred = (proba >= umbral).astype(int)
    print(
        f"Umbral {umbral} -> "
        f"Recall {recall_score(y_test, pred):.3f} | "
        f"Precision {precision_score(y_test, pred):.3f} | "
        f"F1 {f1_score(y_test, pred):.3f}"
    )

Vale la pena detenerse en los hiperparámetros, porque son la diferencia entre un XGBoost que rinde y uno que decepciona. El n_estimators fija cuántos árboles se encadenan; max_depth limita cuánto puede crecer cada uno, y mantenerlo moderado es una de las defensas principales contra el sobreajuste. El learning_rate regula cuánto corrige cada árbol al anterior: valores bajos producen modelos más estables a cambio de necesitar más árboles. Y scale_pos_weight es el equivalente al class_weight del Random Forest: le indica cuánto más debe pesar la clase minoritaria, con un valor de 9 que refleja una proporción aproximada de un desertor por cada nueve clientes que se quedan.

El bucle final es la parte reveladora. Al bajar el umbral de 0,5 a 0,25, el modelo marca como en riesgo a más clientes, sube el recall y baja algo la precisión. Esa decisión —cuánto recall comprar a cambio de cuánta precisión— no es técnica, es de negocio, y depende directamente del coste relativo de cada tipo de error que veíamos en la matriz de confusión del artículo anterior.

Qué significan estos números en clientes reales

Las cifras de recall son abstractas hasta que las traduces a personas. Supongamos que Ficticia Commerce tiene 5.000 clientes y que, en el periodo analizado, 1.000 van a abandonar. Con el recall de 0,471 de la regresión logística, el sistema detectaría a 471 de esos mil desertores y dejaría escapar a 529 sin verlos siquiera. Con el recall de 0,952 de XGBoost, detectaría a 952 y solo se le escaparían 48.

La diferencia entre ambos modelos no es un 0,48 en una métrica: son 481 clientes que un modelo te da la oportunidad de retener y el otro deja marchar en silencio. Si recuperas la economía del cliente medio que vimos en la parte de negocio, cada uno de esos clientes tiene un valor concreto, y multiplicar 481 por ese valor convierte una mejora estadística en una cifra que cualquier comité de dirección entiende. Ahí está el argumento real para invertir en el mejor modelo posible: no en el lenguaje del recall, sino en el del margen recuperado.

Cuándo Random Forest sigue siendo mejor

XGBoost gana en los benchmarks, pero «gana en los benchmarks» no es lo mismo que «es siempre la elección correcta». Hay situaciones donde Random Forest, o incluso un modelo más simple, es la opción sensata. Con datasets muy pequeños, la ventaja de XGBoost se diluye y su mayor número de hiperparámetros se vuelve una carga: hay más que ajustar y menos datos con los que hacerlo bien, lo que aumenta el riesgo de un modelo mal calibrado que rinde peor que el baseline que pretendía superar.

También pesa la cuestión operativa, que en una scale-up sin equipo de datos dedicado no es menor. Si tu equipo no tiene experiencia ajustando modelos de boosting, un Random Forest mantenible y bien entendido en producción vale más que un XGBoost teóricamente superior que nadie sabe tocar cuando deja de funcionar. La mejor herramienta no es la que gana en un paper, sino la que tu organización puede operar de forma fiable durante meses. Empezar por Random Forest y migrar a XGBoost cuando los números lo justifiquen sigue siendo, en la mayoría de casos, la secuencia correcta.

XGBoost le da a Ficticia Commerce un modelo que detecta a casi todos sus clientes en riesgo, con el umbral ajustado a su economía concreta y un puñado de hiperparámetros bajo control. Pero un modelo preciso plantea un problema nuevo en cuanto sale de la pantalla del analista y llega a un comité de dirección. Cuando el director de operaciones pregunte por qué el modelo cree que un cliente concreto se va a ir, «lo predice el algoritmo» no será una respuesta aceptable. ¿Cómo se abre la caja negra para explicar, cliente a cliente, qué está mirando el modelo?