Sistema Ibrido XGBoost con Zonizzazione Spaziale e Calibrazione Dinamica Real-Time
Questo percorso documenta l'evoluzione del sistema di previsione attraverso 4 fasi chiave, dalla prima implementazione RandomForest fino al modello XGBoost finale. Ogni fase ha introdotto miglioramenti misurabili, con particolare attenzione alla scoperta e correzione del bug del tempo di servizio che ha guidato l'intera ottimizzazione.
Implementazione iniziale basata sull'algoritmo RandomForest, addestrato sul dataset Amazon Last-Mile (Merchán et al., 2024).
Il modello utilizzava 24 feature tradizionali (distanza, numero fermate, traffico, meteo, ora del giorno) senza alcuna partizione spaziale per zone.
Durante i test sul campo, emergeva un'anomalia sistematica: per rotte con molte fermate, il modello sottostimava gravemente i tempi reali.
Diagnosi: Il dataset Amazon originale conteneva tempi totali che includevano già il tempo di servizio. Il modello aveva appreso a predire il tempo totale, ma nella nostra pipeline aggiungevamo il tempo di servizio una seconda volta = doppio conteggio.
Questo errore metodologico è tipico nella ricerca sulla logistica last-mile, dove la separazione tra tempo di guida e tempo di servizio richiede attenzione particolare durante la preparazione dei dati.
La correzione ha separato esplicitamente i due componenti della previsione, seguendo le best practice di Rabbi Shawon et al. (2025):
$$ T_{totale} = T_{guida\_predetto} + T_{servizio\_calcolato} $$
$$ T_{servizio} = N_{fermate} \times 4.2 \text{ min/fermata} $$
Introdotto sistema di calibrazione dinamica per adattare le predizioni base a condizioni contestuali (traffico, meteo, ora del giorno).
Passaggio a XGBoost come algoritmo principale, coerente con i risultati di Rabbi Shawon et al. (2025) che dimostrano una superiorità del 21.6% rispetto a RandomForest per problemi simili.
Innovazioni introdotte:
Questo studio presenta un sistema di previsione dei tempi di consegna last-mile basato su XGBoost con feature engineering spaziale, sviluppato attraverso una metodologia incrementale che confronta tre iterazioni modellistiche: RandomForest baseline (v1), RandomForest con calibrazione (v2), e XGBoost con zonizzazione (v3).
Il modello finale raggiunge un MAE di 30.81 minuti e un R² di 0.6025, rappresentando una riduzione del ~10% dell'errore rispetto al baseline RandomForest (MAE 34.2 min). Questo miglioramento è coerente con i risultati di Rabbi Shawon et al. (2025), che riportano riduzioni fino al 21.6% passando da RandomForest a XGBoost.
L'innovazione principale risiede nell'integrazione di un Agentic Decision Engine basato sul framework PERCEIVE-EVALUATE-ACT (Jamithireddy, 2025), che utilizza l'API Perplexity per rilevare eventi real-time e applicare calibrazione dinamica secondo il modello di impatto a 4 tier derivato da Humphreys & Pyun (2018).
La metodologia adottata segue un approccio incrementale scientificamente validato, dove ogni iterazione del modello introduce miglioramenti specifici misurabili attraverso metriche standard.
| Modello | Algoritmo | Features | Training Data | MAE (min) | R² |
|---|---|---|---|---|---|
| Classic v1 | RandomForest | 24 | Amazon 43K | 34.2 | 0.558 |
| Hybrid v2 | RandomForest + Calibrazione | 24 | Amazon 43K | 33.1 | 0.571 |
| XGBoost v3 | XGBoost + Zone Features | 22 | Amazon 43K + Rome 2K + Session 213 = 45,979 | 30.81 | 0.6025 |
Il modello XGBoost v3 utilizza 22 feature, incluse 10 feature binarie per la zonizzazione spaziale:
Il sistema implementa una partizione spaziale a 9 zone (4 Roma + 5 Boston) basata sulla metodologia "Zone ID" introdotta da Merchán et al. (2024) per il dataset Amazon Last-Mile.
Ogni zona è codificata come feature binaria (0/1) nel vettore di input del modello.
\( \vec{z} = [z_{vat}, z_{sta}, z_{cen}, z_{eur}, z_{fen}, z_{mit}, z_{bay}, z_{fin}, z_{sea}, z_{gen}] \)
Il sistema implementa un Agentic Decision Engine basato sul framework PERCEIVE-EVALUATE-ACT per l'intelligenza artificiale agentica, come definito da Jamithireddy (2025).
Il modulo PERCEIVE utilizza l'API Perplexity con il modello sonar
per interrogare in tempo reale fonti web e rilevare eventi che impattano le consegne:
Gli eventi rilevati sono classificati in 4 tier di impatto basati sulla letteratura scientifica sul traffico urbano durante eventi:
| Tier | Moltiplicatore | Impatto | Esempi |
|---|---|---|---|
| Tier 1 Minor | 1.05x | <5% impatto citywide | Festival di quartiere, mercatino |
| Tier 2 Moderate | 1.15x | +2% citywide, +10-15% near venue | Partita Serie A, concerto, ZTL attiva |
| Tier 3 Major | 1.25x | +20-30% delay in venue zone | Derby Roma-Lazio, Champions League, graduation |
| Tier 4 Critical | 1.40x | +40% max immediate vicinity | World Series, Super Bowl, Messa Pasquale |
La previsione finale è calcolata combinando la predizione base del modello XGBoost con 4 moltiplicatori contestuali applicati in modo moltiplicativo con un cap massimo di 1.50x.
$$ T_{finale} = T_{base} \times \min\left( M_{zona} \times M_{eventi} \times M_{meteo} \times M_{ora}, 1.50 \right) $$
| Componente | Range | Fonte |
|---|---|---|
| Mzona - Zone Multiplier | 1.0x - 1.25x | zones_config.json |
| Meventi - Event Multiplier | 1.0x - 1.40x | Perplexity + Tier Classification |
| Mmeteo - Weather Multiplier | 1.0x (clear) - 1.45x (snow) | Weather API + FHWA |
| Mora - Time-of-Day | 0.85x (night) - 1.30x (evening rush) | Traffic patterns |
Il moltiplicatore combinato è limitato a 1.50x (50% di incremento massimo) basandosi sulle raccomandazioni FHWA (2024) per i buffer di consegna in giornate con eventi e sulle evidenze empiriche di Humphreys & Pyun (2018) che indicano un impatto massimo near-venue del 50%.
Il modello XGBoost v3 è stato addestrato su un dataset combinato di 45,979 samples:
| Fonte | Samples | Città | Descrizione |
|---|---|---|---|
| Amazon Last-Mile Dataset | ~43,000 | Boston | Dataset pubblico Merchán et al. (2024) |
| Rome Augmented | ~2,000 | Roma | Data augmentation con caratteristiche urbane romane |
| Session Predictions | 213 | Misto | Previsioni validate durante lo sviluppo |
| Totale | 45,979 | - | Test set: 9,196 samples (20%) |
L'analisi dell'importanza delle feature nel modello XGBoost v3 rivela le variabili più influenti per la previsione dei tempi di consegna:
| Feature | Importanza | Interpretazione |
|---|---|---|
| city_encoded | 69.30% | Differenze strutturali Roma vs Boston |
| num_stops | 23.31% | Numero fermate = tempo servizio |
| avg_stop_distance_km | 2.87% | Densità del percorso |
| traffic_level | 2.16% | Condizioni traffico |
| weather_condition | 0.80% | Impatto meteo |
| rush_hour | 0.51% | Ora di punta |
| zone_* features | <0.1% | Zone contribuiscono via calibrazione |
Il modulo Smart Departure rappresenta un'innovazione rispetto ai tradizionali moltiplicatori orari statici (es. 1.10x mattina, 1.30x sera). Invece di applicare fattori predefiniti, il sistema interroga direttamente l'API Google Routes con parametri di traffico storico per ogni scenario temporale.
| Componente | Funzione | Fonte Dati |
|---|---|---|
| SmartDeparturePlanner | Orchestrazione confronto fasce orarie | Stateless service |
| Google Routes API | Tempi percorrenza con traffico storico | traffic_model=best_guess |
| Perplexity Events | Rilevamento eventi per ora target | Real-time web search |
| Zone Calibrator | Moltiplicatori zona-specifici | zones_config.json |
| DepartureNarrator | Spiegazione AI in linguaggio naturale | GPT-4 via OpenAI |
departure_time all'ora \( h \)
A differenza del sistema di calibrazione tradizionale (Sezione 4), qui il fattore Mora è implicito nel valore \( T_{Google}(h) \), poiché Google Routes già incorpora i pattern di traffico storico per l'orario richiesto.
| Parametro | Valore | Scopo |
|---|---|---|
departure_time |
Unix timestamp | Ora di partenza target |
traffic_model |
best_guess |
Stima bilanciata basata su storico |
mode |
driving |
Traffico veicolare |
Nota: Per orari futuri oltre 1 ora, Google Routes utilizza historical traffic patterns basati su dati aggregati dello stesso giorno/ora delle settimane precedenti, fornendo stime affidabili per la pianificazione.
Il modulo DepartureNarrator (GPT-4) genera raccomandazioni in linguaggio naturale che spiegano perché un orario è preferibile, citando condizioni specifiche:
Sistema sviluppato per tesi di ricerca - Dicembre 2025
Tutti i dati e le metriche sono verificabili dal codice sorgente del repository