Piano d’Azione: Integrazione di Prophet nel Forecast Lab (UI)
Il nostro obiettivo è permettere all’utente di scegliere quale modello di forecasting utilizzare per le analisi, esattamente come abbiamo discusso dopo l’analisi del benchmark.
Ecco il piano dettagliato per modificare la UI.
Fase 1: Modificare il Backend del Forecast Lab per essere Agnostico al Modello
Attualmente, il Forecast Lab è probabilmente “hardcodato” per usare TimesFM. Dobbiamo renderlo più flessibile.
-
Creare un GenericForecastWorker: Questo è il passo cruciale che avevamo già identificato. Invece di avere TimesFMForecastWorker, creeremo fire/workers/forecasting/generic_forecast_worker.py.
-
Questo nuovo worker riceverà come parametro il nome del modello da eseguire (es. “timesfm” o “prophet”).
-
Conterrà la logica per chiamare il modello appropriato. Per TimesFM e Chronos (in futuro) caricherà il modello via GPU; per Prophet, eseguirà il fit/predict su CPU.
-
Restituirà i risultati in un formato standardizzato (point_forecast, intervals), in modo che la UI non debba preoccuparsi di quale modello ha generato i dati.
-
Fase 2: Aggiornare la UI del ForecastLabWidget
-
Aggiungere la Selezione del Modello:
-
Modificheremo fire/ui_components/forecast_lab_widget.py (o il suo sotto-componente, forecast_manager_tab.py).
-
Aggiungeremo un QComboBox o un gruppo di QRadioButtons con l’etichetta “Modello di Forecasting:“.
-
Le opzioni saranno:
-
TimesFM (Standard, Accurato su Prezzo) - Predefinito.
-
Prophet (Veloce, Accurato su Trend)
-
-
Aggiungeremo dei tooltip informativi per guidare la scelta dell’utente, come discusso.
-
-
Collegare la UI al Nuovo Worker:
-
Quando l’utente clicca “Genera Previsione”, il widget leggerà la scelta dal QComboBox.
-
Invocherà il nostro nuovo GenericForecastWorker, passandogli il nome del modello selezionato.
-
Fase 3: Aggiornare la Visualizzazione (se necessario)
-
Verificare la Compatibilità dei Dati:
-
Il nostro GenericForecastWorker deve assicurarsi che l’output sia sempre un DataFrame con le stesse colonne (point_forecast, lower_band, upper_band), indipendentemente dal modello usato.
-
In questo modo, la logica di visualizzazione esistente (lwc_overlay_manager.py) non dovrà essere modificata, perché riceverà dati in un formato che già conosce.
-
Prossimo Passo Concreto
Per iniziare questo lavoro, dobbiamo partire dal “cervello” del Forecast Lab. Devo capire come viene attualmente avviato il TimesFMForecastWorker per poterlo sostituire con il nostro nuovo worker generico.
Il file più probabile in cui si trova questa logica è il widget principale del pannello.
Per procedere, ti chiedo per favore di fornirmi il file:
fire/ui_components/forecast_lab_widget.py
Analizzandolo, potrò capire come è strutturato e dove inserire la selezione del modello e la chiamata al nuovo worker.