Quartz 4

Forecast Lab - Validazione dei Modelli

4 min read

FIRE DD-FORECAST-LAB.md

Versione: 2.0
Data: 2025-10-29
Scopo: Descrivere l’architettura, il flusso di dati e i componenti della sinapsi “Forecast Lab”, con un focus specifico sulla funzionalità “Model Backtester”.
Documento Principale: FIRE 25.07 - ARCHITECTURE-OVERVIEW

1. Filosofia: Quantificare la “Bontà” di un Modello

Prima di integrare modelli di forecasting come TimesFM nelle strategie di trading, è imperativo rispondere a una domanda fondamentale: “Quanto è accurato questo modello a prevedere il futuro?“. Rispondere a questa domanda in modo soggettivo è inaffidabile e pericoloso.

Il Forecast Lab esiste per fornire una risposta quantitativa e oggettiva. È una “sinapsi” dedicata all’interno di FIRE il cui scopo è la validazione rigorosa dei modelli di forecasting. Il suo obiettivo non è misurare la performance finanziaria di una strategia, ma l’accuratezza predittiva del modello stesso, isolandolo da ogni altra variabile.

Questo permette agli utenti di:

  • Comprendere i punti di forza e di debolezza di un modello.

  • Confrontare diversi modelli in futuro.

  • Scegliere l’orizzonte di previsione ottimale.

  • Costruire fiducia nei modelli prima di utilizzarli in strategie reali.

2. Architettura e Flusso di Dati del “Model Backtester”

La funzionalità di backtesting dei modelli è orchestrata da quattro componenti principali che comunicano in modo asincrono attraverso il sistema di segnali di Qt, garantendo una UI sempre reattiva.

codeMermaid

graph TD
    subgraph "UI Thread"
        A[<b>1. ForecastBacktestWidget</b><br>(Configurazione UI)<br>L'utente imposta i parametri e clicca "Run".] -->|backtest_requested(params)| B
        B[<b>Orchestrator</b><br>(es. MainWindow)<br>Cattura il segnale, recupera i dati e avvia il Worker.]
        D[<b>4. ForecastResultsWidget</b><br>(Dashboard Risultati)<br>Riceve i risultati e visualizza i grafici.]
    end
    
    subgraph "Worker Thread"
        C[<b>3. ForecastBacktestWorker</b><br>(Logica di Calcolo)<br>Esegue il backtest rolling-origin.]
    end

    B -->|Crea e avvia| C
    C -->|progress/log_message| A
    C -->|finished(results)| D

3. Analisi dei Componenti Chiave

3.1. ForecastLabWidget (La Sinapsi)

  • Responsabilità: Contenitore principale a schede (QTabWidget) che ospita i vari strumenti del laboratorio.

  • Componenti: Attualmente contiene “Live Forecast” e “Model Backtester”, garantendo la separazione logica e la scalabilità futura.

3.2. ForecastBacktestWidget (Il Pannello di Controllo)

  • Responsabilità: Fornire l’interfaccia utente per configurare e avviare un backtest.

  • Logica:

    1. Permette all’utente di configurare parametri specifici del backtest (es. initial_window, metric).

    2. Legge il contesto globale (ticker, start_date, end_date) da AppState al momento della richiesta.

    3. Emette un segnale backtest_requested con un dizionario di parametri, disaccoppiando la richiesta dall’esecuzione.

    4. Ascolta i segnali di progresso dal worker per aggiornare una QProgressBar e un log in tempo reale.

3.3. ForecastBacktestWorker (Il Motore)

  • Responsabilità: Eseguire il calcolo intensivo del backtest in un thread separato.

  • Algoritmo: Implementa un backtest rolling-origin (o expanding window), il gold standard per la validazione di serie temporali.

    1. Inizializza il modello (TimesFM).

    2. Itera sui dati: ad ogni step, espande la finestra di training, genera una previsione e calcola l’errore rispetto ai dati reali.

    3. Comunica costantemente con la UI tramite segnali non bloccanti (progress, log_message).

    4. Al termine, emette un singolo dizionario results contenente tutti i dati processati.

3.4. ForecastResultsWidget (La Dashboard)

  • Responsabilità: Visualizzare i risultati del backtest in una dashboard interattiva.

  • Logica:

    1. Riceve il dizionario results dal worker.

    2. Utilizza plotly per costruire due grafici chiave: “Forecast vs. Actuals” e “Error Over Time”.

    3. Converte le figure Plotly in JSON e le passa a widget QCPlotlyChartWidget per il rendering.

    4. Fornisce una potente funzione di esportazione in un report HTML autonomo, che include entrambi i grafici interattivi.

4. Il Contratto Dati: La Struttura results

La comunicazione tra il ForecastBacktestWorker e il ForecastResultsWidget si basa su un “contratto dati” ben definito: il dizionario results. La sua struttura è la seguente:

ChiaveTipoDescrizione
full_seriespd.SeriesL’intera serie storica dei prezzi di chiusura utilizzata nel backtest.
all_forecastsList[pd.DataFrame]Una lista di DataFrame, dove ogni DataFrame contiene un segmento di previsione.
error_historyList[Dict]Una lista di dizionari ({‘date’: …, ‘error’: …}) che traccia l’errore a ogni step.
metric_namestrIl nome della metrica utilizzata (es. “MAE”), per la coerenza dei titoli.

5. Metriche di Valutazione Implementate

  • MAE (Mean Absolute Error): Misura l’errore medio assoluto. È intuitivo e rappresenta la deviazione media, in dollari, della previsione rispetto al valore reale.

  • RMSE (Root Mean Square Error): Simile al MAE, ma penalizza maggiormente gli errori più grandi elevandoli al quadrato prima di farne la media. È utile per capire la presenza di outlier significativi.

Graph View