Guida avanzata al trading con IA: Il riferimento completo di librerie, modelli e framework di ML per quant

Gli alberi decisionali con gradient boosting (GBDT), non le reti profonde, sono la famiglia di modelli predefinita per ogni compito tabulare di classificazione/regressione di questa pipeline: meta-etichettatura, caratteristiche di regime, scoring dei fattori. Un confronto del 2024 ampiamente citato, su oltre 100-300 benchmark tabulari, ha rilevato che i GBDT eguagliano o superano il deep learning sui dati tabulari con molta meno messa a punto (arXiv:2402.03970). I dati finanziari tabulari sono esattamente il regime in cui questo vale con più forza: basso rapporto segnale-rumore, caratteristiche miste continue/categoriali/sparse, forte non stazionarietà e piccole dimensioni effettive del campione, condizioni in cui la flessibilità delle reti profonde compra soprattutto varianza, non segnale.

Perché i GBDT dominano sui dati finanziari tabulari

• Compromesso bias-varianza. Con poche migliaia di righe effettive (ponderate per unicità) e un segnale debole e rumoroso, il basso bias di una rete ad alta capacità ha un costo in varianza che non puoi permetterti. Alberi poco profondi con forte regolarizzazione (numero di foglie, min-data-in-leaf, bagging) si collocano in un punto molto migliore di quel compromesso.
• Caratteristiche miste e sparse in modo nativo. Gli alberi dividono sui valori grezzi delle caratteristiche: nessuna scalatura, nessuna strategia di imputazione, nessuna tabella di embedding per categoriali raramente popolate (settore, borsa, indicatore di prossimità alla scadenza). Lo sforzo di ingegneria delle caratteristiche va nel segnale, non nell'idraulica di preprocessing.
• I vincoli monotoni codificano direttamente priori finanziari. LightGBM/XGBoost/CatBoost supportano tutti monotone_constraints: ad es. forzare P(vincita) a essere non decrescente nella forza del trend e non crescente nella volatilità realizzata. Questo regolarizza verso modelli sensati per il dominio ed è indisponibile, o molto più macchinoso, in un MLP standard.
• Valori mancanti e non stazionarietà. Gli alberi instradano i valori mancanti in modo nativo (nessuna imputazione soggetta a fughe adattata sull'intero dataset), e alberi poco profondi e frequentemente riaddestrati si adattano più rapidamente ai cambi di regime rispetto a una grande rete che ha bisogno di molte epoche per disimparare schemi obsoleti.

*I conteggi di stelle sono indicativi, verificati a metà 2026: trattali come "ordine di grandezza", non come cifre esatte.

import lightgbm as lgb
from sklearn.model_selection import train_test_split

# X: one row per primary-strategy signal date. Columns e.g.
#   log_ret_5d, log_ret_20d, realized_vol_20d, atr_14, frac_diff_price,
#   ema_slope, rsi_14, bb_pctb, obv_z, dist_200ma
# y: triple-barrier label from mlfinpy -> 1 = profit barrier hit first, 0 = stop/time first
# w: sample weight from mlfinpy uniqueness/time-decay (NEVER plain 1s -- labels overlap)
X, y, w = features_df[feature_cols], labels_df["tb_label"], labels_df["sample_weight"]

X_train, X_val, y_train, y_val, w_train, w_val = train_test_split(
    X, y, w, test_size=0.2, shuffle=False              # never shuffle time series
)

params = {
    "objective": "binary", "metric": "auc",
    "num_leaves": 31, "learning_rate": 0.03,
    "feature_fraction": 0.7, "bagging_fraction": 0.7, "bagging_freq": 5,
    "min_data_in_leaf": 50,
    # financial priors: e.g. [trend, vol, ...] -> win-prob non-decreasing in trend,
    # non-increasing in realized vol, unconstrained (0) elsewhere
    "monotone_constraints": [1, 0, -1, 0, 0, 1, 0, 0, 0, -1],
    "verbosity": -1,
}
train_set = lgb.Dataset(X_train, label=y_train, weight=w_train)
val_set   = lgb.Dataset(X_val, label=y_val, weight=w_val, reference=train_set)

model = lgb.train(params, train_set, num_boost_round=2000,
                   valid_sets=[val_set], callbacks=[lgb.early_stopping(100)])

meta_label_proba = model.predict(X_new)  # P(this signal hits the profit barrier first)

pip install xgboost
# minimal use: xgboost.XGBClassifier(n_estimators=800, max_depth=4, learning_rate=0.03,
#   subsample=0.7, colsample_bytree=0.7, monotone_constraints="(1,0,-1,0,0,1,0,0,0,-1)")

pip install catboost
# CatBoostClassifier(cat_features=["sector","exchange"], iterations=1500,
#   depth=6, learning_rate=0.03, monotone_constraints="1:1,2:-1")

Queste sono le architetture neurali da addestrare da zero tu stesso (tipicamente tramite neuralforecast, Apache-2.0, che le implementa tutte), in contrapposizione ai modelli di fondazione preaddestrati del §3. Ognuna di esse è stata portata all'esistenza a suon di benchmark su M4/M3/electricity/traffic/ETT: nessuna è stata progettata contro serie di rendimenti finanziari, e il verdetto onesto per architettura lo riflette.

I previsori di serie temporali preaddestrati e zero-shot sono reali e utili, per la volatilità, non per la direzione del prezzo. Uno studio del giugno 2026 costruito appositamente per testare questo, "Pretrained Time-Series Foundation Models for Financial Return Forecasting" (Noguer i Alonso e Pereira Franklin, AI Finance Institute), ha messo a benchmark TimeGPT, TimesFM-2.5, Moirai-2.0, Chronos e Chronos-2 contro NBEATS/NHITS/PatchTST/iTransformer/KAN addestrati da zero su cinque azioni statunitensi liquide (AAPL, AMZN, GOOG, JPM, META) con un protocollo a origine mobile rispetto a un benchmark di random walk. Il risultato: su dieci combinazioni asset/compito, solo due hanno mostrato una sovraperformance statisticamente significativa rispetto al random walk: Chronos su AMZN e Moirai-2.0 su GOOG, e gli autori affermano senza mezzi termini che "i guadagni sul benchmark di random walk sono piccoli e sparsi", concludendo che i TSFM sono "priori pratici utili che riducono i costi di sviluppo dei modelli", ma esplicitamente "non motori universali per una generazione di alpha statisticamente affidabile". Tratta ogni modello sotto di conseguenza: motori eccellenti, eseguibili su CPU, per input di volatilità/previsione di vol verso uno strato di dimensionamento; deboli o pari al random walk per la direzione del prezzo.

pip install chronos-forecasting torch

import torch
from chronos import BaseChronosPipeline

pipeline = BaseChronosPipeline.from_pretrained(
    "amazon/chronos-bolt-base",     # T5-style encoder-decoder, 205M params, Apache-2.0
    device_map="cpu",               # CPU is fine for daily-bar, small-batch inference
    torch_dtype=torch.bfloat16,
)

# Feed REALIZED VOLATILITY, not raw price -- this is a vol forecaster, not an oracle
context = torch.tensor(realized_vol_20d.values[-512:])

quantiles, mean = pipeline.predict_quantiles(
    context=context,
    prediction_length=10,                   # 10-day-ahead vol forecast
    quantile_levels=[0.1, 0.5, 0.9],
)
vol_forecast_median = quantiles[0, :, 1]    # feed straight into GARCH/vol-target sizing (see §10)

pip install timesfm
# tfm = timesfm.TimesFm(context_len=512, horizon_len=10, backend="cpu")
# tfm.load_from_checkpoint(huggingface_repo_id="google/timesfm-2.0-500m-pytorch")
# point_fc, quantile_fc = tfm.forecast([realized_vol_20d.values], freq=[0])

Il sentiment/NLP finanziario appartiene allo strato di rischio (una caratteristica di veto/regime) e non allo strato di alpha: secondo la ricerca fonte del §0, il vantaggio del sentiment delle notizie da solo è in gran parte un artefatto di anticipazione che muore fuori campione. Ecco i tre modelli che vale davvero la pena conoscere.

pip install transformers torch

from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch

tok = AutoTokenizer.from_pretrained("ProsusAI/finbert")
model = AutoModelForSequenceClassification.from_pretrained("ProsusAI/finbert")
model.eval()

headlines = ["Company X beats earnings estimates, raises guidance",
             "Regulators open investigation into Company X"]

with torch.no_grad():
    inputs = tok(headlines, return_tensors="pt", padding=True, truncation=True)
    probs = torch.softmax(model(**inputs).logits, dim=-1)

# label order per config.id2label: 0=positive, 1=negative, 2=neutral
labels = ["positive", "negative", "neutral"]
scores = [dict(zip(labels, p.tolist())) for p in probs]
# aggregate to a daily sentiment score; use ONLY as a veto/regime feature, not alpha

Il RL è l'elemento più sopravvalutato e meno affidabile di tutta questa pagina per un motore di trading centrale. La strumentazione è genuinamente buona; il verdetto onesto, supportato dallo stesso concorso di benchmark della comunità RL, è confinarlo a sotto-problemi ristretti e rigorosamente validati (ad es. il timing di esecuzione) anziché a un motore principale o a livello di portafoglio.

Le quattro famiglie di algoritmi (una riga ciascuna)

• PPO (Proximal Policy Optimization): on-policy, azioni discrete o continue; limita il passo di aggiornamento della policy per restare vicino alla policy precedente, scambiando un po' di efficienza campionaria con stabilità di addestramento. La prima scelta predefinita nella maggior parte degli esempi FinRL.
• SAC (Soft Actor-Critic): off-policy, solo azioni continue; obiettivo a massima entropia (premia esplicitamente l'esplorazione) con un replay buffer, generalmente più efficiente in campioni di PPO ma più sensibile agli iperparametri.
• DQN (Deep Q-Network): off-policy, solo azioni discrete; apprende una funzione valore-azione tramite un replay buffer e una rete target. Necessita di uno spazio d'azione discretizzato (ad es. compra/mantieni/vendi), che mal si adatta al dimensionamento continuo della posizione.
• A2C (Advantage Actor-Critic): on-policy, discreto o continuo; un cugino più semplice e sincrono di A3C, generalmente il più debole dei quattro sui compiti finanziari nei benchmark di FinRL stesso.

Ambito pratico, se usi il RL comunque: un sotto-problema ristretto con una ricompensa naturalmente in forma di MDP (ad es. il timing di esecuzione degli ordini all'interno di un ordine padre fisso, il tracking VWAP), valutato con la stessa disciplina PBO/DSR di tutto il resto nel §14, mai come motore principale di ingresso/uscita/dimensionamento.

Qlib è la cosa più vicina a una piattaforma di ricerca IA-quant chiavi in mano nell'open source: uno strato dati, un DSL di ingegneria delle caratteristiche, uno zoo di modelli e un'infrastruttura di backtest walk-forward/analisi di portafoglio, collegati tra loro tramite configurazioni di workflow YAML. Con licenza MIT (microsoft/qlib), decine di migliaia di stelle su GitHub, MIT dalla sua apertura del settembre 2020, attivamente rilasciato (v0.9.7, agosto 2025) e ora abbinato all'RD-Agent di Microsoft per una sperimentazione automatizzata a ciclo di ricerca.

Alpha158 vs. Alpha360: i due set di caratteristiche integrati

Sistema di workflow/configurazione e zoo di modelli integrato

Gli esperimenti Qlib sono tipicamente guidati da un singolo file YAML consumato dalla CLI qrun, che dichiara il gestore dei dati (Alpha158/360 o personalizzato), il modello, la suddivisione del dataset, la strategia di portafoglio e i parametri di backtest: questo rende il passaggio da LightGBM a un GRU o a un wrapper TFT un cambio di configurazione di una riga, non una riscrittura. Lo zoo di modelli integrato spazia tra approcci classici e profondi: LGBModel (LightGBM), XGBModel, CatBoostModel, MLP, GRU/LSTM/ALSTM (ricorrenti), Transformer, wrapper TFT, TabNet, HIST, IGMTF e diversi modelli di ricerca a grafi/attenzione (GATs, KRNN, Localformer), tutti addestrati e valutati attraverso la stessa infrastruttura di workflow con un report condiviso di backtest walk-forward/analisi dell'IC.

qlib_init:
  provider_uri: "~/.qlib/qlib_data/custom_nse"   # see note below on pointing Qlib at NSE data
  region: in                                       # generic region tag; India isn't a stock Qlib region out of the box

market: &market custom_nse_500
benchmark: &benchmark NIFTY500

data_handler_config: &data_handler_config
  start_time: 2010-01-01
  end_time: 2025-12-31
  fit_start_time: 2010-01-01
  fit_end_time: 2019-12-31
  instruments: *market

task:
  model:
    class: LGBModel
    module_path: qlib.contrib.model.gbdt
    kwargs:
      loss: binary
      num_leaves: 31
      learning_rate: 0.03
      monotone_constraints: [1, 0, -1, 0]
  dataset:
    class: DatasetH
    module_path: qlib.data.dataset
    kwargs:
      handler:
        class: Alpha158
        module_path: qlib.contrib.data.handler
        kwargs: *data_handler_config
      segments:
        train: [2010-01-01, 2019-12-31]
        valid: [2020-01-01, 2021-12-31]
        test:  [2022-01-01, 2025-12-31]

# run with:  qrun this_config.yaml

Il toolkit di Advances in Financial Machine Learning di López de Prado significava un tempo una licenza a pagamento mlfinlab: non è più così. Due pacchetti gratuiti e con licenza permissiva coprono ora l'etichettatura a tripla barriera, la meta-etichettatura, la differenziazione frazionaria, la ponderazione di unicità del campione, la CPCV e la HRP.

pip install mlfinpy

from mlfinpy.labeling import get_events, add_vertical_barrier, get_bins
from mlfinpy.util import get_daily_vol

# causal, EWMA-based daily volatility -- uses data strictly up to t, no leakage
daily_vol = get_daily_vol(close=prices, lookback=50)

vertical_barriers = add_vertical_barrier(
    t_events=signal_dates, close=prices, num_days=10       # time-limit barrier
)

triple_barrier_events = get_events(
    close=prices,
    t_events=signal_dates,             # your primary (Pine) strategy's signal dates
    pt_sl=[2.0, 1.5],                  # profit-take / stop-loss as multiples of daily_vol
    target=daily_vol,
    min_ret=0.0005,
    num_threads=4,
    vertical_barrier_times=vertical_barriers,
)

labels = get_bins(triple_barrier_events, prices)
# labels['bin']    -> 1 = profit barrier hit first, 0 = stop/time barrier hit first
# labels['ret']    -> realized return at the barrier that was hit
# labels['t1']     -> the barrier-touch timestamp (needed for purging downstream)

pip install skfolio

from skfolio.model_selection import CombinatorialPurgedCV, cross_val_predict
from sklearn.pipeline import Pipeline
import lightgbm as lgb

meta_label_pipeline = Pipeline([
    ("model", lgb.LGBMClassifier(num_leaves=31, learning_rate=0.03,
                                  min_child_samples=50)),
])

# n_folds=10, n_test_folds=2  ->  C(10,2) = 45 combinatorial train/test paths
# purged_size / embargo_size sized to the max holding horizon (t1 - t0), NOT a flat 1%
cv = CombinatorialPurgedCV(n_folds=10, n_test_folds=2,
                            purged_size=10, embargo_size=10)

# returns an empirical DISTRIBUTION of out-of-sample paths, not one score --
# use it to compute PBO and the Deflated Sharpe Ratio, not a single train/test split
oos_paths = cross_val_predict(estimator=meta_label_pipeline, X=X, y=y,
                               cv=cv, sample_weight=w)

Cosa ti dà ciascuna tecnica

• Differenziazione frazionaria (mlfinpy.features.frac_diff / variante FFD a larghezza fissa): trova l'ordine minimo di differenziazione d (spesso 0,2-0,5) che supera un test di stazionarietà ADF pur mantenendo una correlazione >0,9 con la serie dei livelli, dando un input stazionario che conserva memoria: strettamente migliore per modelli ad alberi/lineari rispetto ai rendimenti grezzi (memoria nulla) o al prezzo grezzo (non stazionario).
• Ponderazione di unicità del campione: le etichette a tripla barriera si sovrappongono nel tempo (un periodo di mantenimento di 10 giorni significa che segnali adiacenti condividono finestre di etichetta), violando l'assunzione IID su cui si basa gran parte della teoria del ML. Pondera ogni campione per la sua unicità media (inverso del conteggio di etichette concorrenti) più un decadimento temporale, altrimenti la tua dimensione effettiva del campione è una frazione del tuo conteggio di righe e ogni test di significatività a valle è sovrastimato.
• Validazione incrociata depurata combinatoria (CPCV): genera molte combinazioni di percorsi train/test (non un singolo percorso walk-forward), depura le righe di addestramento la cui finestra di etichetta si sovrappone al fold di test e applica un embargo cuscinetto dopo ogni fold di test. Produce una distribuzione completa di indici di Sharpe fuori campione (che alimenta PBO e DSR) anziché una stima puntuale: ecco perché è strutturalmente più affidabile del walk-forward semplice.
• HRP (Hierarchical Risk Parity) (skfolio.optimization.HierarchicalRiskParity): alloca tramite clustering gerarchico della matrice di correlazione anziché invertire una matrice di covarianza rumorosa (cosa che fa l'ottimizzazione media-varianza), rendendola molto più robusta all'errore di stima su un paniere di azioni correlate.

Questa è la sezione dove vive il bug di fuga silenziosa più comune nel gating di regime al dettaglio, e dove mostrare lo schema sbagliato accanto a quello giusto è più utile che descriverlo a parole.

from hmmlearn.hmm import GaussianHMM

model = GaussianHMM(n_components=2, covariance_type="diag", n_iter=1000)
model.fit(X_full)                    # fit on the ENTIRE history -- future leaks into the fit
regimes = model.predict(X_full)      # Viterbi = globally-smoothed decode over the whole path
# regimes[t] used information from t+1 ... T. This is look-ahead bias.
# Any backtest of a regime gate built this way is invalid and will not reproduce live.

from hmmlearn.hmm import GaussianHMM
import numpy as np

regime_at_t = np.full(len(X), np.nan)
model, refit_every, min_train = None, 63, 500     # e.g. refit quarterly

for t in range(min_train, len(X)):
    if model is None or t % refit_every == 0:
        model = GaussianHMM(n_components=2, covariance_type="diag", n_iter=200)
        model.fit(X[:t])                          # ONLY data strictly before t

    # forward-algorithm FILTERED posterior using data up to and including t --
    # no smoothing, no future information, no re-fit on data that includes t's label use
    posteriors = model.predict_proba(X[:t + 1])
    regime_at_t[t] = posteriors[-1].argmax()       # today's regime, knowable today

# regime_at_t is safe to merge into the feature frame for both backtest and live use.
# Expect a MUCH smaller, laggier drawdown benefit than the full-sample-smoothed version --
# that gap IS the size of the leakage bug you just closed.

ruptures è lo strumento complementare quando vuoi punti di cambiamento anziché uno stato di regime persistente, ad es. segnalare una rottura di regime di volatilità in una serie EWMA per innescare un riadattamento dell'HMM, o come rilevatore alternativo di confini di regime per verificare le transizioni dell'HMM. Pelt (ricerca esatta a costo lineare, numero sconosciuto di punti di rottura, richiede un parametro di penalità) è quello predefinito; Binseg scambia l'esattezza con la velocità su serie più lunghe; i metodi basati su finestra sono i più economici ma i meno precisi sulle rotture sottili. Come l'HMM, eseguilo in una finestra espansiva/mobile per l'uso in reale: anche l'API standard di ruptures è un metodo offline sull'intera serie per impostazione predefinita.

Nessun singolo motore è adatto a ogni fase. Usa un motore vettorizzato per selezionare migliaia di combinazioni di parametri, poi rivalida ogni sopravvissuto su un motore basato su eventi con esecuzioni realistiche prima di rischiare capitale: confondere le due fasi (fidarsi di un backtest di motore vettorizzato come risposta finale) è un errore comune e costoso.

Perché l'architettura di NautilusTrader conta davvero

La maggior parte dei fallimenti "ottimo backtest, reale deludente" non sono fallimenti del modello: sono bug di scostamento ricerca/produzione: il tuo motore di backtest e il tuo codice di esecuzione in reale sono due basi di codice separate che silenziosamente divergono l'una dall'altra (un'assunzione di prezzo di esecuzione qui, un bug di timing di barra spostato di uno là), e nulla le costringe a rimanere coerenti. Il design basato su eventi con nucleo in Rust di NautilusTrader esegue lo stesso codice di strategia (le stesse classi, gli stessi gestori di eventi) in modalità backtest, paper e reale; cambiano solo gli adattatori di dati/esecuzione. Quella scelta architetturale elimina un'intera classe di bug per costruzione anziché per disciplina, motivo per cui è lo strumento giusto per il ruolo di "rivalidazione finale con esecuzioni realistiche e ponte verso la produzione" anziché un semplice di più.

È qui che il "controllo del drawdown" viene effettivamente implementato: come matematica deterministica che consuma previsioni di volatilità e confidenza della meta-etichetta, non come un altro compito di predizione.

pip install arch

from arch import arch_model
import numpy as np

returns_pct = 100 * log_returns.dropna()      # arch expects % returns for numerical stability
# GJR-GARCH(1,1,1) with Student-t errors -- captures the leverage effect (vol reacts more to
# negative returns than positive ones), which plain GARCH(1,1) misses
am = arch_model(returns_pct, vol="GARCH", p=1, o=1, q=1, dist="t")
res = am.fit(disp="off", last_obs=train_end_date)   # fit only on data up to the current date

fcast = res.forecast(horizon=10, reindex=False)
vol_forecast_daily = np.sqrt(fcast.variance.values[-1]) / 100   # back to decimal daily vol

target_vol_daily = 0.10 / (252 ** 0.5)        # ~10% annualized portfolio vol target
position_scale = target_vol_daily / vol_forecast_daily[0]
position_size = base_size * min(position_scale, max_leverage_cap)   # always cap leverage

from pypfopt import HRPOpt
hrp = HRPOpt(returns=daily_returns_df)   # NOT prices -- pass returns
weights = hrp.optimize()                 # hierarchical-clustering-based, no covariance inversion

import riskfolio as rp
port = rp.Portfolio(returns=daily_returns_df)
port.assets_stats(method_mu="hist", method_cov="hist")
weights = port.optimization(model="Classic", rm="CVaR", obj="MinRisk", rf=0, l=0)

Prima di fidarti di qualsiasi risultato di GBDT o di un modello di fondazione, mettilo a benchmark rispetto alla noiosa linea di base. Queste due librerie coprono l'estrazione automatizzata delle caratteristiche e le linee di base di previsione classiche che non dovresti mai saltare.

pip install tsfresh
from tsfresh import extract_relevant_features

# long-format df: columns [id, time, value]; y indexed by id (e.g. triple-barrier label)
features = extract_relevant_features(
    long_format_df, y=labels_by_id, column_id="id", column_sort="time",
    fdr_level=0.01,           # false-discovery-rate control -- do NOT skip this on financial data
)
# re-run the relevance filter INSIDE each CV fold in production, never on the full dataset

pip install statsforecast
from statsforecast import StatsForecast
from statsforecast.models import AutoARIMA, AutoETS

sf = StatsForecast(models=[AutoARIMA(), AutoETS()], freq="D", n_jobs=-1)
sf.fit(train_df)
baseline_forecast = sf.predict(h=10)
# your GBDT / foundation-model forecast must beat THIS, net of cost, or there is no edge

La strumentazione MLOps qui non riguarda la scala, riguarda l'onestà. La funzione MLOps più determinante di tutto questo stack è la disciplina del conteggio delle prove per il Deflated Sharpe Ratio: ogni configurazione di backtest che hai mai provato, tracciata, per sempre, così che la correzione per test multipli sia calcolata rispetto al tuo conteggio di prove reale, non al sottoinsieme lusinghiero che ricordi.

pip install mlflow
import mlflow

with mlflow.start_run(run_name="lgbm_meta_label_v37"):
    mlflow.log_params(params)                                   # every hyperparameter tried
    mlflow.log_param("cv_scheme", "CombinatorialPurgedCV(10,2)")
    mlflow.log_param("feature_set_hash", feature_set_hash)       # so re-used feature sets don't double count
    mlflow.log_metric("oos_sharpe_median", oos_sharpe_median)    # across the CPCV path distribution
    mlflow.log_metric("pbo", pbo_value)
    mlflow.log_metric("trial_number_in_family", trial_counter)   # THIS feeds the Deflated Sharpe N
    mlflow.lightgbm.log_model(model, "model")

# Query the full run history to compute N for the Deflated Sharpe Ratio -- include prior
# Pine-Script optimization trials too (see §14), not just the ML runs.

Oltre agli hub di modelli, il Datasets Hub di Hugging Face ospita un insieme crescente di dataset rilevanti per la finanza che vale la pena conoscere per la prototipazione e il lavoro sul sentiment: trattali tutti come fonti di prototipazione/di riserva, non come dati di produzione privi di survivorship bias (vedi la disciplina del Piano Dati nel report di ricerca fonte).

Numerai: un gioco diverso, non una fonte di dati per il tuo sistema

Numerai si capisce meglio come un mercato di abilità di modellazione, non come un dataset da collegare alla tua pipeline. Il torneo principale fornisce gratuitamente caratteristiche pre-ingegnerizzate e offuscate: passate in PCA, z-scored e suddivise nel tempo, così puoi modellare dati finanziari di livello mondiale senza mai sapere quali azioni o quali date stai guardando (ogni "era" settimanale ha ID che non si corrispondono tra le ere, per progetto). Numerai Signals è il prodotto complementare: invii previsioni sul tuo proprio universo/caratteristiche, puntando a segnali ortogonali a ciò che lo stack di modelli esistente di Numerai già cattura. Tutti i modelli inviati alimentano un meta-modello ponderato per lo stake che a sua volta guida l'hedge fund di Numerai stesso. Inquadralo come opzionalità per monetizzare l'abilità di modellazione (valutata su performance pluriennale e inclusiva del drawdown, non come una via rapida verso un reddito) e come un ecosistema adiacente interessante anziché un componente della pipeline del §14.

Come un utente avanzato collega ogni libreria sopra in un'unica pipeline, dall'inizio alla fine. Ingestione dei dati → caratteristiche Qlib/tsfresh → differenziazione frazionaria (mlfinpy) → modello di meta-etichetta LightGBM validato con validazione incrociata depurata combinatoria annidata (skfolio) → gate di regime causale hmmlearn → dimensionamento con targeting di vol basato su GARCH (arch) → backtest NautilusTrader → logging MLflow → webhook PickMyTrade per l'esecuzione.

"""
Reference pipeline skeleton: data ingestion -> PickMyTrade execution.
Every preprocessing step is fit INSIDE the CPCV training fold only -- never on
the full dataset. Illustrative structure; wire in your own data store / config.
"""
import numpy as np
import pandas as pd
import lightgbm as lgb
import mlflow
import requests
from hmmlearn.hmm import GaussianHMM
from arch import arch_model
from mlfinpy.labeling import get_events, add_vertical_barrier, get_bins
from mlfinpy.util import get_daily_vol
from mlfinpy.features import frac_diff_ffd
from skfolio.model_selection import CombinatorialPurgedCV, cross_val_predict
from sklearn.pipeline import Pipeline
from qlib.contrib.data.handler import Alpha158
from tsfresh import extract_relevant_features
from nautilus_trader.backtest.engine import BacktestEngine
from nautilus_trader.trading.strategy import Strategy


# 1. DATA INGESTION -- point-in-time, survivorship-bias-free universe only
def load_point_in_time_universe(as_of_date, min_adv_usd=2_500_000):
    """Never filter by TODAY's liquidity -- that imports survivorship bias."""
    raw = data_store.query_asof(as_of_date=as_of_date)          # Parquet/DuckDB store
    return raw[raw["adv_20d_asof"] > min_adv_usd]


# 2. FEATURES -- Qlib Alpha158 for technicals, tsfresh + mlfinpy for the rest
def build_features(prices: pd.DataFrame) -> pd.DataFrame:
    alpha158 = Alpha158(instruments=prices["symbol"].unique().tolist(),
                         start_time=prices.index.min(), end_time=prices.index.max())
    tech_features = alpha158.fetch()

    tsfresh_features = extract_relevant_features(
        prices.reset_index(), y=None, column_id="symbol", column_sort="date", fdr_level=0.01,
    )

    d = find_min_ffd_order(prices["close"], adf_pvalue=0.05, min_corr=0.9)   # search d in [0.1, 1.0]
    frac_diff_price = frac_diff_ffd(prices["close"], d=d, threshold=1e-4)    # stationary, RETAINS memory

    return tech_features.join(tsfresh_features, how="inner").assign(frac_diff_price=frac_diff_price)


# 3. LABELS -- causal EWMA vol -> ATR-scaled triple barrier (mlfinpy)
def label_events(prices: pd.Series, signal_dates: pd.DatetimeIndex) -> pd.DataFrame:
    daily_vol = get_daily_vol(close=prices, lookback=50)
    vertical_barriers = add_vertical_barrier(t_events=signal_dates, close=prices, num_days=10)
    events = get_events(close=prices, t_events=signal_dates, pt_sl=[2.0, 1.5], target=daily_vol,
                         min_ret=0.0005, num_threads=4, vertical_barrier_times=vertical_barriers)
    return get_bins(events, prices)          # -> bin (0/1), ret, t1 (needed for purging)


# 4. META-LABEL MODEL -- LightGBM inside nested Combinatorial Purged CV
def train_meta_label_model(X: pd.DataFrame, y: pd.Series, w: pd.Series, trial_counter: int):
    pipeline = Pipeline([("model", lgb.LGBMClassifier(
        num_leaves=31, learning_rate=0.03, min_child_samples=50,
        monotone_constraints=MONO_CONSTRAINTS))])

    cv = CombinatorialPurgedCV(n_folds=10, n_test_folds=2, purged_size=10, embargo_size=10)
    oos_paths = cross_val_predict(estimator=pipeline, X=X, y=y, cv=cv, sample_weight=w)

    pbo = compute_pbo(oos_paths)
    dsr = compute_deflated_sharpe(oos_paths, n_trials=get_trial_count_from_mlflow() + trial_counter)
    if pbo > 0.50 or dsr.p_value > 0.05:
        raise ValueError(f"Model rejected: PBO={pbo:.2f}, DSR p={dsr.p_value:.3f}")

    final_model = pipeline.fit(X, y, model__sample_weight=w)
    return final_model, pbo, dsr


# 5. REGIME GATE -- causal, walk-forward, FILTERED (never smoothed) HMM posterior
def causal_regime_state(vol_return_features: np.ndarray, t: int, model_cache: dict,
                         refit_every: int = 63, min_train: int = 500) -> int:
    if t < min_train:
        return 1  # default "calm" until enough history exists
    if t % refit_every == 0 or "model" not in model_cache:
        hmm = GaussianHMM(n_components=2, covariance_type="diag", n_iter=200)
        hmm.fit(vol_return_features[:t])                       # only data strictly before t
        model_cache["model"] = hmm
    posteriors = model_cache["model"].predict_proba(vol_return_features[: t + 1])
    return int(posteriors[-1].argmax())                        # filtered state at t, no look-ahead


# 6. VOL-TARGETED SIZING -- GJR-GARCH forecast -> fractional-Kelly-scaled size
def size_position(returns_pct: pd.Series, meta_label_confidence: float, regime_state: int,
                   target_vol_annual: float = 0.10, kelly_fraction: float = 0.5,
                   max_leverage: float = 1.5) -> float:
    if regime_state == 0:                                       # 0 = "stormy" -- stand aside
        return 0.0
    res = arch_model(returns_pct, vol="GARCH", p=1, o=1, q=1, dist="t").fit(disp="off")
    vol_fc = np.sqrt(res.forecast(horizon=1, reindex=False).variance.values[-1, 0]) / 100
    vol_scale = (target_vol_annual / (252 ** 0.5)) / vol_fc
    kelly_scale = kelly_fraction * max(2 * meta_label_confidence - 1, 0)   # confidence -> edge proxy
    return float(np.clip(vol_scale * kelly_scale, 0, max_leverage))


# 7. BACKTEST -- NautilusTrader (same strategy class runs backtest AND live)
class MetaLabelStrategy(Strategy):
    def __init__(self, model, hmm_cache, config):
        super().__init__(config)
        self.model, self.hmm_cache = model, hmm_cache

    def on_bar(self, bar):
        feats = self.build_live_features(bar)                   # same code path as build_features()
        confidence = self.model.predict_proba(feats)[:, 1][0]
        regime = causal_regime_state(self.vol_history, self.clock.timestamp_ns, self.hmm_cache)
        size = size_position(self.returns_pct_history, confidence, regime)
        if confidence > 0.55 and size > 0:
            self.submit_bracket_order(side="BUY", size=size, sl_atr_mult=1.5, tp_atr_mult=2.0)


def run_backtest(historical_bars, final_model, strat_config):
    engine = BacktestEngine()
    engine.add_data(historical_bars)
    engine.add_strategy(MetaLabelStrategy(model=final_model, hmm_cache={}, config=strat_config))
    return engine.run()      # the SAME strategy object later promotes to paper/live -- adapters swap only


# 8. MLFLOW LOGGING -- every trial, forever (feeds the Deflated Sharpe trial count)
def log_run(params, pbo, dsr, backtest_results, final_model, trial_counter):
    with mlflow.start_run(run_name=f"pipeline_v{trial_counter}"):
        mlflow.log_params(params)
        mlflow.log_metric("pbo", pbo)
        mlflow.log_metric("dsr_p_value", dsr.p_value)
        mlflow.log_metric("backtest_sharpe", backtest_results.sharpe_ratio)
        mlflow.log_metric("backtest_max_dd", backtest_results.max_drawdown)
        mlflow.log_metric("trial_number_in_family", trial_counter)
        mlflow.lightgbm.log_model(final_model, "meta_label_model")


# 9. EXECUTION -- PickMyTrade webhook JSON (paper first, then tiny live)
def send_to_pickmytrade(symbol, side, qty, sl_price, tp_price, webhook_url, secret):
    payload = {
        "secret": secret, "symbol": symbol, "action": side,     # "buy" / "sell"
        "quantity": qty, "stopLoss": sl_price, "takeProfit": tp_price, "orderType": "market",
    }
    resp = requests.post(webhook_url, json=payload, timeout=5)
    resp.raise_for_status()
    return resp.json()

Claude Fable è il modello di punta di Anthropic (id modello claude-fable-5), disponibile tramite l'app Claude e Claude Code. Su uno stack così profondo, il suo valore non è "scrivimi un bot di trading": è la parte intermedia ingrata e soggetta a errori: azzeccare l'aritmetica dei fold di CPCV, scrivere un ciclo di decodifica HMM causale (non con fughe) al primo colpo, cablare un gestore di dati Qlib per un mercato che non arriva di serie, e leggere una pipeline multi-fase dall'inizio alla fine per trovare l'unica fuga che altrimenti emergerebbe solo come uno scarto reale/backtest mesi dopo.

Dove si guadagna la pagnotta sullo stack specifico di questa pagina:

• Logica dei fold di CPCV: derivare le dimensioni di depurazione/embargo dall'orizzonte della tua etichetta e dal lookback di caratteristica più lento (§7), anziché indovinarle e scoprirlo da uno Sharpe di backtest gonfiato.
• Inferenza di regime causale: scrivere il ciclo walk-forward a posteriore filtrata anziché la chiamata con fughe a decode()/Viterbi sull'intero campione mostrata come esempio "sbagliato" nel §8.
• Configurazione Qlib: generare e adattare lo YAML di workflow Alpha158/Alpha360 a un gestore di dati personalizzato per una regione che Qlib non fornisce, come l'esempio NSE nel §6.
• Revisione delle fughe sull'intera pipeline: leggere lo scheletro del §14 fase per fase in cerca di un bug di adattamento fuori dal fold prima che tocchi capitale.
• Conversione Pine Script → Python: portare la logica di ingresso di una strategia TradingView nella funzione di segnale primario che alimenta il modello di meta-etichettatura.
• Collante di esecuzione: redigere il codice del payload del webhook / della chiave di idempotenza trattato nel §14.6, e il logging MLflow che mantiene onesto il tuo conteggio delle prove del Deflated Sharpe (§12).

Prompt pronti da adattare per ciascuno di quei casi, specifici per lo stack di questa pagina, non richieste generiche di "costruiscimi un bot":

Review this skfolio CombinatorialPurgedCV setup [paste code]: 10 folds, 2 test folds, on triple-barrier-labeled
signals where barriers can resolve up to 10 trading days after the signal (get_events num_days=10). Check whether
purged_size and embargo_size are large enough to cover that full label-resolution window plus my slowest feature's
lookback. Flag any fold where a training sample's resolution window overlaps a test sample's, explain the leak, and
give me corrected purge/embargo values with the reasoning shown.

Here is my hmmlearn regime-detection code [paste code]. Confirm it only calls predict_proba on data up to and
including index t when producing the label used AT time t, and that it never calls hmm.decode() or reads a Viterbi
path computed over the full series. If it's using the full-sample smoothed posterior, rewrite it as a walk-forward
loop that refits every N bars on strictly past data and returns the filtered (not smoothed) posterior at each step,
matching the causal pattern, not the leaky one.

I want Microsoft Qlib's Alpha158 handler running on NSE (India) equities, not one of Qlib's built-in regions.
Here's my current workflow YAML [paste config]. Write a custom data handler/provider that points Alpha158's feature
computation at my own point-in-time OHLCV store instead of Qlib's default region data, keeping the Alpha158 feature
set intact. Explain specifically what breaks -- calendar, instrument universe, trading-day alignment -- if I just
change the region tag without supplying compatible replacements.

Here is my end-to-end pipeline: data ingestion, feature engineering, triple-barrier labeling, LightGBM meta-label
training inside CombinatorialPurgedCV, HMM regime gate, GARCH-based sizing, and NautilusTrader backtest [paste code].
Walk it stage by stage and flag every point where a transform -- scaler, feature selector, frac-diff order search, HMM
fit -- is fit on data outside the current CV training fold, or a feature could see information unavailable at signal
time. Rank findings by how much each would inflate the backtest Sharpe if left uncorrected.

Here is my TradingView Pine Script strategy [paste script]. Convert its entry logic into a Python function that
takes a pandas DataFrame of OHLCV bars and returns a boolean signal series, matching the Pine version bar-for-bar on
identical historical data. This becomes the primary-model signal feeding my meta-labeling filter, so flag anything --
security() calls with lookahead, use of the current bar's close before it closes -- that would make the two versions
diverge.

Write a Python function that takes a meta-label confidence score, ATR-based stop/target multiples, and a
position size from my vol-targeted sizing calc, and builds the JSON payload for a PickMyTrade webhook POST -- symbol,
side, quantity, stopLoss, takeProfit. Add a deterministic idempotency key (hash of symbol + signal timestamp + bar
index) as a payload field, and wrap the POST in retry-with-backoff logic that treats a timeout as "unknown, reconcile
before retrying" rather than blindly resubmitting.

La stessa decisione costruire vs. acquistare che prende qualsiasi team di sistemi, applicata all'ultimo salto della pipeline del §14: le tue scarse ore di ingegneria vanno nell'idraulica di instradamento degli ordini, o negli strati di modello che sono davvero tuoi? Questa sezione sostiene di trattare l'esecuzione in reale come una dipendenza acquistata a interfaccia ristretta, e mostra come appare l'interfaccia dal lato della pipeline.

Dove si colloca questo nella pipeline del §14

La pipeline di riferimento termina a "logging MLflow → webhook PickMyTrade per l'esecuzione" perché quello è il confine di fiducia naturale. Il tuo modello emette un segnale → scatta un alert TradingView, oppure (dato che una configurazione avanzata può saltare del tutto TradingView) il tuo servizio Python costruisce e fa il POST del JSON direttamente all'endpoint webhook di PickMyTrade → PickMyTrade si occupa del piazzamento dei bracket OCO, della traduzione degli ordini specifica del broker, del fan-out multi-conto e del ciclo di riconnessione/retry verso la piazza a cui instradi. Quella divisione del lavoro significa che il tuo servizio deve essere affidabile solo fino a "inviare un singolo POST HTTP idempotente": non deve mai mantenere una connessione con stato, di più settimane, all'API di sessione di un broker, aggiornare i token di autenticazione secondo una pianificazione, né riconciliare lo stato degli ordini dopo una partizione di rete. L'intera categoria di problema esce dal tuo piatto.

{
  "idempotencyKey": "SIG-MES-2026-07-03T14:32:00Z-000481",
  "symbol": "MES",
  "side": "buy",
  "quantity": 2,
  "orderType": "market",
  "stopLoss": 5320.25,
  "takeProfit": 5364.75,
  "meta": {
    "metaLabelConfidence": 0.62,
    "atr14": 14.8,
    "slAtrMult": 1.5,
    "tpAtrMult": 2.0,
    "regimeState": 1
  }
}

Deliberatamente generico — non è uno schema PickMyTrade verificato (vedi la chiamata funzionante send_to_pickmytrade() nel §14 per i nomi dei campi già usati nella pipeline di riferimento di questa pagina). quantity deriva direttamente dal calcolo di sizing con target di volatilità dei §11/§14; stopLoss/takeProfit sono l'ingresso ± ATR × i multipli di barriera già validati nel labeling a tripla barriera (§7); idempotencyKey — assente dall'esempio minimo del §14 — è ciò che trasforma una consegna di webhook «almeno una volta» in un ordine «di fatto una sola volta».

Un'unica tabella di consultazione per «ho bisogno di… → usa questo → perché…».

Ogni strumento e modello trattato in questa pagina, con la sua licenza e un indicatore chiaro. Sicuro = permissivo, senza restrizioni significative per l'uso commerciale o di trading dal vivo. Cautela = utilizzabile, ma leggi i termini (obblighi di copyleft, clausole di codice disponibile ma ristretto, oppure una preoccupazione legata allo stato di manutenzione più che alla licenza). Ristretto = un vero ostacolo per un sistema commerciale o dal vivo senza restrizioni in assenza di un accordo separato.

↑ Torna su