Hotel Booking Cancellation Prediction

Proyecto del Máster en Data Science & IA de Evolve Academy. La clasificación binaria estima el riesgo de cancelación: is_canceled = 1 significa cancelada y 0, no cancelada. El objetivo es aproximar una predicción en el momento de reservar, pendiente de validar la disponibilidad temporal real de las variables.

Una cancelación no detectada puede dejar una habitación vacía; una falsa alarma puede generar contactos innecesarios. La selección equilibra discriminación, Precision, Recall, F1 y volumen de reservas señaladas, no solo una métrica.

El desbalanceo es moderado. Accuracy no se utiliza como métrica principal. Se conserva un ADR extremo de 5.400 €, 715 reservas sin noches y 180 sin huéspedes registrados al no poder confirmar que sean errores; un ADR negativo pasa a nulo.

La fuga de información aparece cuando se usan datos que no estarían disponibles al predecir. Se excluyen el estado final, su fecha y variables potencialmente posteriores a la reserva.

Se conservan lead_time, fechas previstas, hotel, país, canal, segmento, agencia, empresa, cliente, comidas, habitación reservada e historial anterior. ADR, parking y peticiones especiales se mantienen como aproximaciones, no como disponibilidad temporal demostrada.

El código calcula el EDA con las 97.192 reservas anteriores al 1 de mayo de 2017: desarrollo completo, incluyendo la futura validación, pero excluyendo TEST. Los gráficos originales lo rotulan TRAIN; no debe confundirse con las 77.698 reservas de ajuste.

City Hotel presenta un 41,5 % de cancelaciones frente al 26,0 % de Resort Hotel. El segmento Groups alcanza el 60,2 %; el canal TA/TO, 40,3 %, frente al 16,8 % del canal Direct. Son asociaciones descriptivas, no efectos causales.

Solo se ocultan en los gráficos categorías con menos de 100 reservas; sus registros siguen en el dataset.

Una mayor antelación se asocia con más cancelaciones en estos datos. El ADR medio es 92,64 € en no canceladas y 96,08 € en canceladas: esta diferencia tampoco demuestra causalidad.

TRAIN ajusta modelos. La búsqueda de hiperparámetros utiliza tres ventanas temporales dentro de TRAIN/FIT, manteniendo juntas las reservas del mismo día. VALIDATION compara configuraciones y selecciona modelo y umbral. TEST se consulta después de fijar la decisión en esta ejecución.

Finalmente se reentrena el pipeline elegido con las 97.192 reservas de desarrollo. El corte es por llegada, no por creación: no reproduce exactamente qué información se conocía al reservar. TEST ya fue evaluado en versiones anteriores, por lo que hace falta otro periodo para una comprobación externa sin exposición previa.

Las variables numéricas se imputan con mediana y se estandarizan. Las categóricas reciben una categoría desconocida y OneHotEncoder, con handle_unknown=infrequent_if_exist, min_frequency=30 y max_categories=20.

Pipeline encapsula preparación y modelo. Durante la comparación, medianas, escalas y categorías se aprenden solo con el entrenamiento de cada ajuste; en el reentrenamiento final se usa desarrollo completo, nunca TEST.

Logistic Regression es el baseline interpretable; su versión balanced aumenta el peso de la clase cancelada. Random Forest y HistGradientBoosting son los finalistas.

RandomizedSearchCV prueba 12 combinaciones de Random Forest: árboles, profundidad, mínimo de división, mínimo por hoja, variables por división y peso de clases. GridSearchCV prueba cuatro combinaciones de HGB: hojas (15/31) y regularización L2 (0,1/5,0). En HGB se mantienen learning_rate=0,08 y max_iter=150; no se optimiza la tasa de aprendizaje.

Ambas búsquedas optimizan ROC-AUC medio en tres ventanas temporales de TRAIN/FIT. En VALIDATION el AUC de RF pasa de 0,8950 a 0,8933 y el de HGB de 0,9018 a 0,8998. Se comparan las versiones antes de decidir, sin dar por ganadora la etiqueta optimized.

HGB inicial ofrece mejor AUC, Precision y F1 que RF optimizado con menos intervenciones, a costa de 2,5 puntos de Recall. La versión optimizada de HGB no aporta una mejora operativa suficiente.

Configuración final: max_iter=150, learning_rate=0,08, max_leaf_nodes=15, l2_regularization=1,0 y early_stopping=False. Se selecciona modelo más umbral antes de consultar TEST en esta ejecución.

Se estudian nueve umbrales entre 0,20 y 0,60 en VALIDATION. El umbral convierte una probabilidad en una decisión: con 0,30, una probabilidad de cancelación de 0,72 activa una alerta. Reducirlo suele aumentar Recall y volumen de intervención, pero reducir Precision.

HGB a 0,25: Precision 72,5 %, Recall 80,0 %, F1 76,1 % y 40,5 % señaladas. A 0,30: Precision 76,2 %, Recall 75,3 %, F1 75,7 % y 36,2 % señaladas. Se prioriza reducir falsas alarmas y carga con una pérdida pequeña de F1. Sin costes reales de FP/FN no se demuestra un óptimo económico.

8.014 verdaderos positivos, 987 falsos negativos, 3.731 falsos positivos y 9.466 verdaderos negativos. No se mantiene la referencia provisional del 70 % de Precision. Estos resultados no acreditan un ahorro económico ni un despliegue en producción.

TEST pertenece a un periodo posterior y el modelo final se reentrena con desarrollo completo. El cambio es compatible con diferencias de distribución, pero no demuestra por sí solo su causa. No se reajusta el umbral tras observar TEST: hacerlo contaminaría la evaluación.

SHAP explica cómo cada variable aumenta o reduce la puntuación del modelo, no una relación causal. Se utiliza TreeExplainer sobre el HGB final y una muestra aleatoria de 250 reservas de TEST, sin elegirlas por su etiqueta.

Ranking agrupado por variable original: country, agent, required_car_parking_spaces, total_of_special_requests, lead_time, customer_type, market_segment y arrival_date_year. El gráfico muestra columnas individuales, incluidas las categorías One-Hot.

Los aportes se expresan en log-odds, no en puntos porcentuales. Se comprueba que valor base más contribuciones, convertido a probabilidad, reproduce predict_proba.

En el caso de mayor riesgo estimado, country=PRT, market_segment=Groups y lead_time=323 días aumentan la puntuación. El waterfall suma aportes positivos y negativos al valor base. Es un caso extremo seleccionado por la predicción, no una reserva representativa ni una regla causal.

Solicitar parking aparece asociado con menor riesgo estimado; no significa que el parking evite cancelaciones. En el ejemplo de menor riesgo su aporte es negativo. Antes de producción se necesita verificar la solicitud inicial, comparar estabilidad entre periodos y evaluar modelos con y sin parking.

La propuesta es un piloto supervisado, no una política automatizada ya validada. Los niveles siguientes son conceptuales: no se han validado umbrales adicionales para tres bandas de riesgo.

Un falso negativo puede perder la oportunidad de revender una habitación; un falso positivo añade una intervención innecesaria. Estimar ambos costes permitiría elegir un umbral según coste esperado y capacidad real del equipo, en datos de validación nuevos.