Piano d’Azione Definitivo: Integrazione di Chronos come Piattaforma di Forecasting Avanzata
Obiettivo Strategico: Trasformare il “Forecast Lab” di FIRE in una dashboard di confronto multi-modello, implementando un’architettura che sfrutti appieno l’accelerazione GPU per offrire analisi “ensemble” e benchmark in tempo reale.
Fase 1: POC Esteso - Benchmark Rigoroso su Hardware High-End (Durata: 1 settimana)
L’obiettivo è creare una base di dati oggettiva per tutte le decisioni future. Il POC non servirà più solo a validare, ma a profilare e confrontare.
-
Obiettivo: Estendere poc_chronos_forecast.py in una Benchmark Suite (poc/poc_forecasting_benchmark.py).
-
Azioni:
-
Setup Ottimizzato per GPU:
-
Lo script forzerà l’uso di CUDA (device_map=“cuda”).
-
Utilizzerà il torch_dtype=torch.float16 per sfruttare i Tensor Core della nostra RTX 4080.
-
Abiliterà le ottimizzazioni cudnn.benchmark e matmul.allow_tf32.
-
-
Modelli Sotto Test:
-
TimesFM (la nostra baseline).
-
chronos-t5-small
-
chronos-t5-base (il nostro nuovo candidato principale).
-
-
Metriche da Tracciare (per ogni modello):
-
Performance: Tempo di inferenza, VRAM di picco (in MB), utilizzo % della GPU.
-
Accuracy: Calcolo di MAE (Mean Absolute Error) e MAPE (Mean Absolute Percentage Error) rispetto a un set di dati di hold-out.
-
-
Dataset Diversificati: Il benchmark verrà eseguito su almeno due tipi di serie temporali (es. una azionaria volatile e un ETF più stabile) per valutare il comportamento in diversi regimi di mercato.
-
-
Deliverable: Uno script di benchmark eseguibile e un report in formato Markdown (poc_benchmark_results.md) generato dallo script, che tabula chiaramente i risultati di performance e accuracy per ogni modello.
Fase 2: Architettura Multi-Modello (Backend)
Svilupperemo un ModelManager che astrae la complessità del caricamento e dell’esecuzione dei modelli, progettato fin da subito per la gestione simultanea.
-
Creare il ModelManager:
-
Una nuova classe in fire/logic/model_manager.py.
-
Responsabilità:
-
Lazy Loading su GPU: Caricherà i modelli in VRAM solo alla prima richiesta, tenendoli pronti per esecuzioni successive.
-
Gestione Centralizzata: Manterrà un registro dei modelli caricati (timesfm, chronos-base, ecc.).
-
Monitoraggio Risorse: Includerà metodi per riportare l’utilizzo attuale di VRAM e RAM.
-
-
-
Worker di Forecasting Generico:
-
Creare fire/workers/forecasting/generic_forecast_worker.py.
-
Questo worker non conterrà la logica di un modello specifico. Riceverà invece il nome del modello da eseguire (es. “chronos-base”), i dati, e i parametri. Chiamerà il ModelManager per ottenere il modello corretto ed eseguire l’inferenza. Questo design ci permetterà di aggiungere nuovi modelli in futuro senza dover creare un nuovo worker ogni volta.
-
-
Aggiornare l’InitializationWorker:
- Aggiungere il download dei modelli chronos-t5-small e chronos-t5-base al primo avvio, con feedback chiaro sulla splash screen.
Fase 3: UI/UX “Premium” - Dashboard Multi-Modello
Trasformeremo l’interfaccia del Forecast Lab per riflettere le nostre nuove capacità avanzate.
-
Pannello di Gestione Modelli:
-
All’interno delle Impostazioni di FIRE, creeremo una nuova sezione “Gestione Modelli di Forecasting”.
-
Questa UI permetterà all’utente di vedere quali modelli sono installati, la loro dimensione su disco, la VRAM richiesta, e di scaricare/rimuovere modelli opzionali (come chronos-t5-large in futuro).
-
-
Nuovo ForecastLabWidget:
-
La UI permetterà all’utente di selezionare uno o più modelli da eseguire simultaneamente tramite checkbox (☑ Chronos T5-Base, ☑ TimesFM, ecc.).
-
Quando viene lanciata la previsione, verranno avviati worker multipli in parallelo.
-
-
Visualizzazione Comparativa:
-
Il grafico dei risultati mostrerà le previsioni di tutti i modelli selezionati sovrapposte, ognuna con un colore distinto.
-
Una tabella riassuntiva confronterà le metriche chiave (tempo di inferenza, VRAM, etc.) per ogni modello, come nel mockup proposto.
-
Priorità e Primo Passo:
Concordo pienamente con la raccomandazione di iniziare con la Fase 1: POC Esteso. È il passo più critico perché fornirà i dati oggettivi su cui basare tutte le successive decisioni di implementazione e UX.
Se approvi questo piano d’azione definitivo, il mio prossimo compito sarà quello di riscrivere il POC per trasformarlo nella Benchmark Suite descritta sopra.
Sei d’accordo a procedere?