Flight Price Intelligence

Por qué este proyecto

Las herramientas existentes de precios de vuelos muestran gráficos históricos pero no dan una recomendación. Este proyecto cierra esa brecha: el modelo emite una señal directa COMPRA / ESPERA — no solo un gráfico.

Selección del modelo

Modelo	MAE (INR)	R²
Linear Regression	9,842	0.71
KNN (k=10)	4,201	0.88
XGBoost	2,088	0.97

XGBoost fue seleccionado porque el precio de los vuelos es intrínsecamente no-lineal: la misma ruta cuesta 3× más dependiendo de la aerolínea, la clase y la anticipación de compra. Los árboles en ensemble capturan estas interacciones sin cruces manuales de features.

Decisiones técnicas clave

Endpoint /price_curve server-side — en lugar de que Streamlit llame 10 veces a /predict para construir el gráfico de ventana de compra, un único GET genera todas las predicciones del lado de la API. Un round-trip en vez de diez.

days_until_flight como proxy de anticipación — el dataset no tiene fecha de compra, solo fecha de vuelo y fecha de scraping. La diferencia se usó como proxy para la anticipación de compra. Limitación documentada honestamente en el Model Card.

Banda de tolerancia del 5% en BUY/WAIT — precios dentro del ±5% de la predicción son BUY. La confianza escala con la distancia al precio predicho: min(|diff| / 30, 1.0).

Lo que aprendí

• MLflow rinde desde el primer experimento. Comparar 3 runs en paralelo — mismas features, mismo split — elimina toda subjetividad en la selección del modelo.
• El cold start en free tier es un problema de UX. Render Free se duerme por inactividad. Un timeout de 15s muestra un error; 45s con mensaje claro lo convierte en una demora conocida.
• La normalización de SerpAPI es inevitable. Google Flights devuelve ‘IndiGo’, el modelo fue entrenado con ‘Indigo’. Un mapa de normalización entre ambos mundos es obligatorio en el boundary de la API.

Why This Project

Existing flight price tools show historical charts but give no recommendation. This project closes that gap: the model outputs a direct BUY / WAIT signal — not just a chart.

Model Selection

| Model | MAE (INR) | R² | |---|---:|---:| | Linear Regression | 9,842 | 0.71 | | KNN (k=10) | 4,201 | 0.88 | | XGBoost | 2,088 | 0.97 |

XGBoost was selected because flight pricing is inherently non-linear: the same route costs 3× more depending on airline, class, and booking window. Tree ensembles capture these interactions without manual feature crosses.

Key Engineering Decisions

/price_curve server-side endpoint — instead of Streamlit calling /predict 10 times to build the booking-window chart, a single GET request generates all predictions on the API side. One round-trip instead of ten.

days_until_flight as booking proxy — the dataset has no purchase date, only flight date and scrape date. The difference was used as a proxy for booking anticipation. Honest limitation documented in the Model Card.

5% tolerance band on BUY/WAIT — prices within ±5% of prediction are BUY. Confidence scales with distance from the predicted price: min(|diff| / 30, 1.0).

What I Learned

• MLflow pays off immediately. Being able to compare 3 runs side-by-side — same features, same train/test split — removed all subjectivity from model selection.
• Free tier cold starts are a UX problem. Render Free sleeps after inactivity. A 15s timeout shows an error; 45s with a clear message turns it into a known delay.
• SerpAPI normalization is unavoidable. Google Flights returns 'IndiGo', the model was trained on 'Indigo'. A normalization map between both worlds is required at the API boundary.