Quartz 4

FIRE 75.32 PAD Un Sistema di Arricchimento Dati AI

4 min read

Penso che tu abbia colto l’esatto punto di debolezza della mia proposta iniziale. È una critica perfetta e assolutamente necessaria.

La mia proposta iniziale era “monolitica”: legava strettamente il BacktestWorker all’idea di usare un lavoratore specializzato (ForecastEnrichmentWorker), che implicitamente usa un modello (TimesFM). Questo approccio non è scalabile e ci costringerebbe a modificare il BacktestWorker ogni volta che aggiungiamo un nuovo modello come Chronos o Prophet. È un vicolo cieco architetturale.

La tua osservazione ci costringe a pensare in modo più astratto e flessibile. Dobbiamo progettare un sistema in cui i modelli di forecasting siano “plug-and-play”.

La Soluzione: Un Sistema di “Arricchimento Dati” basato su un Registro

Ripensiamo l’architettura. L’idea di “arricchire” i dati è corretta, ma il modo in cui lo facciamo deve essere agnostico rispetto al modello.

Nuova Proposta Architetturale:

  1. Le Strategie Dichiarano le “Dipendenze”: Invece di un semplice booleano requires_forecast, la strategia dichiarerà in modo più esplicito di quali dati arricchiti ha bisogno. Questo apre le porte non solo a diversi modelli di forecast, ma a qualsiasi tipo di dato pre-calcolato (es. sentiment analysis, dati macroeconomici, ecc.).

    # Esempio più granulare
class AdvancedStrategy(BaseStrategy):
    # La strategia dichiara di aver bisogno dei dati generati 
    # dal "provider" chiamato 'timesfm_forecast_h10'
    data_enrichment_providers = ['timesfm_forecast_h10']
 
    def next(self):
        # Ora può accedere a colonne specifiche generate da quel provider
        forecast_value = self.data['timesfm_forecast_h10_value'].iloc[self.i]
        # ...

  2. Un Registro di “Provider di Arricchimento”: Creeremo un registro centrale (un semplice dizionario o una classe manager) che mappa il nome di un “provider” (es. 'timesfm_forecast_h10') al worker specializzato che sa come generare quei dati (es. TimesFMEnrichmentWorker).

    # Esempio di registro (in un file a parte, es. data_enrichment_registry.py)
DATA_ENRICHMENT_PROVIDERS = {
    'timesfm_forecast_h10': TimesFMEnrichmentWorker,
    'chronos_forecast_h5': ChronosEnrichmentWorker, # Futuro
    'prophet_forecast_h30': ProphetEnrichmentWorker, # Futuro
}

  3. L’Orchestratore Diventa un “Dispatcher”: Il ruolo del BacktestWorker cambia. Non sa più nulla di TimesFM, Chronos o Prophet. Il suo algoritmo diventa generico: a. Carica la strategia. b. Legge la lista strategy.data_enrichment_providers. c. Per ogni provider richiesto nella lista: i. Cerca il worker corrispondente nel registro. ii. Istanzia ed esegue quel worker, passandogli i dati. iii. Riceve i dati arricchiti e li usa come input per il prossimo worker nella catena. d. Alla fine, passa il DataFrame finale, arricchito da tutti i provider richiesti, al BacktestEngine.

Vantaggi di Questo Nuovo Approccio

  • Estensibilità (Plug-and-Play): Per aggiungere il supporto a Chronos, non dovremo toccare il BacktestWorker o BaseStrategy. Ci basterà:
    1. Creare un nuovo ChronosEnrichmentWorker.
    2. Registrarlo nel DATA_ENRICHMENT_PROVIDERS. E il sistema funzionerà.
  • Componibilità: Una strategia super-avanzata potrebbe richiedere più arricchimenti contemporaneamente, e il sistema li applicherebbe in sequenza. Esempio: data_enrichment_providers = ['timesfm_forecast_h10', 'sentiment_analysis'].
  • Separazione delle Responsabilità Massima: Ogni componente ha un solo, piccolo compito. Il BacktestWorker orchestra. I “worker di arricchimento” generano dati specifici. La strategia dichiara le sue dipendenze. È un’architettura pulita e manutenibile.

Piano d’Azione Riveduto (e Migliore)

Questo piano è più complesso del precedente, ma è l’approccio corretto a lungo termine.

Fase 1: Creazione dell’Architettura di Arricchimento

  1. BaseStrategy: Aggiungere un nuovo attributo di classe: data_enrichment_providers: List[str] = [].
  2. Registro dei Provider: Creare un nuovo file fire/logic/data_enrichment_registry.py che conterrà il dizionario DATA_ENRICHMENT_PROVIDERS.
  3. Worker di Arricchimento per TimesFM: Creare il primo “worker specializzato”, fire/workers/enrichment/timesfm_enrichment_worker.py. Questo conterrà la logica per generare le colonne di forecast, molto simile a quella che avevamo pianificato prima.

Fase 2: Aggiornamento dell’Orchestratore (BacktestWorker)

  1. Modificare il BacktestWorker delle strategie per implementare la nuova logica di “dispatcher” descritta sopra. Dovrà importare il registro, iterare sui provider richiesti dalla strategia e orchestrare la catena di arricchimento dei dati.

Fase 3: API e Implementazione di Riferimento

  1. BaseStrategy: Aggiungere le proprietà @property per accedere facilmente alle nuove colonne (es. self.forecast). Questo non cambia.
  2. Strategia Ibrida: Creare la MomentumForecastStrategy.py che imposti data_enrichment_providers = ['timesfm_forecast_h10'] e usi i nuovi dati nella sua logica.

Questo piano è molto più robusto e allineato con la visione a lungo termine del progetto. Hai fatto benissimo a sollevare questa obiezione.

Se approvi questo nuovo piano architetturale, possiamo iniziare con la Fase 1.

Graph View