Quartz 4

FIRE 75.0039 Sensitivity Analysis Mode

5 min read

Questa è un’ottima direzione. Stai spostando il focus dall’esecuzione di una “singola previsione” (tattica) alla validazione sistematica (strategia). È esattamente quello che farebbe un Quantitative Analyst (Quant).

Quello che descrivi è il passaggio dal Backtesting all’Optimization/Sensitivity Analysis.

Ecco il mio brainstorming strutturato su come potremmo evolvere il Forecast Lab per rispondere a queste domande.

1. La Soluzione al Tuo Problema: “Sensitivity Analysis Mode”

Attualmente il tuo test è un “punto singolo” nello spazio dei parametri. Tu vuoi tracciare una curva.

A. Horizon Sensitivity (La “Curva di Decadimento”)

  • Domanda: “Fino a quanti giorni nel futuro il mio modello è affidabile?”
  • Come realizzarlo: Invece di un singolo input Horizon, l’utente seleziona un set (es. [1, 3, 7, 14, 30] giorni).
  • Il Workflow: Il sistema lancia un batch di backtest. Per ogni horizon, calcola le metriche.
  • L’Output Visivo (Cruciale): Un grafico a linea.
    • Asse X: Giorni di orizzonte (1, 3, 7…).
    • Asse Y: Directional Accuracy (o RMSE).
    • Interpretazione: Vedrai tipicamente una curva che scende. Il punto dove l’accuratezza scende sotto il 50% (random guess) è il “Limite di Visibilità” del modello per quel ticker. Oltre quel punto, non dovresti tradare.

B. Ticker Benchmark (La “Leaderboard”)

  • Domanda: “Su quale asset questo modello funziona meglio?” (Magari TimesFM è un genio su ENEL ma un disastro su BITCOIN).
  • Come realizzarlo: Invece di un singolo ticker, selezioni un’intera Watchlist (es. FTSE MIB).
  • Il Workflow: Il BatchWorker itera su ogni ticker della lista con gli stessi parametri.
  • L’Output Visivo:
    • Tabella Ordinabile: Ticker ordinati per Directional Accuracy decrescente.
    • Heatmap: Una mappa di calore dove verde scuro = alta predicibilità, rosso = bassa.
    • Valore: Ti permette di fare “Cherry Picking”: tradi solo i 3 asset che il modello storicamente capisce meglio.

2. Metodi Standard di Analisi (Best Practices dei Quant)

Oltre a cambiare i parametri, ci sono metriche standard per valutare la qualità di un forecaster probabilistico (come TimesFM/Prophet).

C. Calibration Plot (Analisi dell’Affidabilità)

  • Il Concetto: I nostri modelli producono bande di confidenza (es. “80%”).
  • La Verifica: Se il modello dice “c’è l’80% di probabilità che il prezzo stia qui dentro”, nella realtà storica il prezzo ci è rimasto davvero l’80% delle volte?
    • Se ci è rimasto il 95% delle volte → Il modello è Sottostimato (troppo prudente).
    • Se ci è rimasto il 50% delle volte → Il modello è Overconfident (pericoloso, crede di sapere ma sbaglia).
  • Perché implementarlo: È fondamentale per il Risk Management. Se il modello è overconfident, i tuoi stop loss verranno presi troppo spesso.

D. Profitability Analysis (Simple Trading Strategy)

  • Il Concetto: MAE e RMSE sono metriche da data scientist. Al trader interessa il P&L (Profit & Loss).
  • La Simulazione: Aggiungiamo un layer semplice sopra il backtest:
    • Regola: Se Previsione(t+1) > Prezzo(t) + Threshold, COMPRA.
    • Regola: Se Previsione(t+1) < Prezzo(t) - Threshold, VENDI.
  • L’Output: Una Equity Curve.
  • Perché è critico: Un modello potrebbe avere un’ottima Directional Accuracy (55%), ma sbagliare clamorosamente i grandi movimenti (crash), facendoti perdere soldi. Vedere l’Equity Curve smaschera questi casi.

3. Proposta Concreta per FIRE: Il “Forecast Optimizer”

Potremmo creare una nuova tab (o estendere quella attuale) chiamata “Optimizer”.

Input:

  1. Universo: Ticker Singolo vs Watchlist Intera.
  2. Parametro Variabile:
    • Nessuno (Test Singolo).
    • Horizon (es. Step range: 5-30, step 5).
    • Initial Window.

Architettura Tecnica (Senza impazzire): Non serve riscrivere tutto. Possiamo usare il pattern Composite Worker.

  • Creiamo un BatchForecastWorker.
  • Questo worker non fa calcoli. Al suo interno, istanzia in sequenza N ForecastBacktestWorker (quelli che abbiamo appena fixato!).
  • Raccoglie i risultati in un pandas.DataFrame aggregato.
  • Passa il DataFrame finale alla UI per fare i grafici comparativi (con Plotly, che è perfetto per questo).

Cosa ne pensi? Quale di queste analisi (“Curva di Decadimento”, “Leaderboard Ticker”, o “Profitability”) senti che darebbe più valore immediato al tuo trading oggi?

Analisi Critica: UI e UX

La risposta è netta: Nuova Tab.

Motivazione Tecnica:

  1. Divergenza degli Input: La tab “Model Backtester” accetta scalari (un numero per Horizon, un numero per Window). L’Optimizer richiede vettori o range (Min, Max, Step). Mischiare questi controlli creerebbe una UI confusa (“Sto lanciando un test o una serie?”).
  2. Divergenza degli Output:
    • Backtester: Restituisce una time-series (Prezzo vs Previsione) e metriche puntuali.
    • Optimizer: Restituisce una curva di tendenza (Metrica vs Parametro).
    • Visualizzare una curva di decadimento (Decay Curve) nello stesso spazio dove ci si aspetta un grafico di prezzo violerebbe il principio di minima sorpresa.
  3. Flusso Operativo: L’ottimizzazione è un’attività “preparatoria”. Prima trovi i parametri migliori (Optimizer), poi esegui il backtest di verifica (Backtester), poi passi al Live. Sono fasi distinte.

Piano d’Azione: Implementazione “Decay Curve”

Chiameremo questa nuova funzionalità Forecast Optimizer.

Componenti da Sviluppare:

  1. Backend: SensitivityAnalysisWorker (Nuovo)

    • Responsabilità: Eseguire un ciclo di backtest variale.
    • Logica: Invece di riscrivere la logica di backtest, questo worker agirà da “Orchestratore Batch”.
      • Input: param_name (es. “horizon”), range (start, stop, step), base_params.
      • Loop: Per ogni valore nel range, istanzia la logica di calcolo (possiamo riutilizzare la logica core di ForecastBacktestWorker o estrarla in una funzione pura per evitare overhead di QThread multipli).
      • Output: Un Dizionario/DataFrame: { parameter_value: [MAE, RMSE, DirAccuracy] }.

  2. Frontend: ForecastOptimizerTab (Nuovo)

    • Controlli:
      • Selettore Modello (TimesFM, Prophet, ecc.).
      • Selettore Parametro da testare (iniziamo solo con Horizon).
      • Input Range: Min (es. 1), Max (es. 30), Step (es. 1).
    • Visualizzazione:
      • Un grafico QCPlotlyChartWidget configurato per linee semplici (Scatter/Line plot).
      • Asse X: Horizon (Giorni).
      • Asse Y: Metrica (es. Directional Accuracy %).

  3. Integrazione: ForecastLabWidget

    • Aggiunta della terza scheda.

Passo 1: Creazione del Worker di Sensibilità

Poiché vogliamo evitare di lanciare 30 thread pesanti in sequenza (overhead eccessivo), la strategia migliore è refactorizzare leggermente la logica di calcolo.

Tuttavia, per rispettare la regola del “POC First” (visto che stiamo introducendo un loop su calcoli pesanti che potrebbe bloccare o saturare la memoria), ti propongo di creare prima il Worker e testarlo.

Richiesta: Dammi il via libera per creare il file fire/workers/forecasting/sensitivity_worker.py. Lo strutturerò per accettare un range di horizon e restituire i dati grezzi per la curva.

Se approvi, procedo con la scrittura del codice del Worker.

Graph View