Un backtest perfettamente riproducibile può essere meno affidabile di uno che varia leggermente. La ripetibilità dimostra che puoi ottenere due volte la stessa risposta; non dice nulla sul fatto che la risposta dipenda da uno snapshot di dati arbitrario, da una particolarità di una libreria o da un valore predefinito nascosto.
Sembra un argomento contro la riproducibilità, ma non lo è. Congela l’esecuzione per poterla spiegare. Poi varia deliberatamente le ipotesi che non dovrebbero determinare il risultato. Il primo passaggio rende un risultato verificabile; il secondo ti dice se significa qualcosa.
Che cosa dimostra davvero un backtest riproducibile?
Se lo stesso codice, gli stessi dati, la stessa configurazione e lo stesso seed casuale producono le stesse operazioni e metriche, hai controllato un’importante fonte di confusione. Puoi confrontare il “miglioramento” di un agente con la sua esecuzione precedente. Puoi distinguere la correzione di un bug da una modifica al piano commissionale. Un collega può esaminare lo stesso registro e ritrovare gli stessi eseguiti.
Ma il risultato è condizionato da tutto ciò che hai congelato. Considera una strategia crypto il cui file storico contiene barre a 1 minuto. Salvi l’hash del file, blocchi il codice e ottieni uno Sharpe di 1.4 a ogni nuova esecuzione. Se in seguito il fornitore corregge diverse candele, quella riproducibilità impeccabile continua a descrivere il vecchio file. Non ti dice se il segnale resiste alla cronologia corretta, né se quelle candele fossero disponibili in quella forma all’epoca.
L’hash è utile: rende visibile la dipendenza. Non dimostra che tale dipendenza sia innocua.
Mantieni fissa l’esecuzione; metti alla prova il risultato
Preferisco distinguere due domande. Possiamo ricostruire questa esecuzione esatta? E la conclusione della ricerca resiste a cambiamenti ragionevoli? La prima richiede un registro immutabile; la seconda perturbazioni controllate, una alla volta.
| Cosa registrare | Cosa variare in seguito | Cosa può rivelare |
|---|---|---|
| Versione dei dati grezzi e checksum | Revisione del fornitore o una seconda fonte | Dipendenza da valori corretti o specifici del fornitore |
| Commit del codice e versioni dei pacchetti | Implementazione numericamente equivalente | Sensibilità all’ordine, agli arrotondamenti o alla libreria |
| Commissioni, funding e ipotesi sugli eseguiti | Un intervallo di costi difendibile | Se un margine ridotto richiede condizioni di esecuzione insolitamente favorevoli |
| Universo e composizione valida nel tempo | Regole alternative per i mercati ammessi | Dipendenza dalle decisioni di inclusione o esclusione |
Per esempio, supponiamo che una strategia sui futures mostri un rendimento in eccesso annualizzato dell’8% nella simulazione di riferimento. Eseguila di nuovo con costi taker superiori del 25%, il funding spostato al regolamento osservato successivo e i due maggiori contributori rimossi a turno. Non sono tre modi per migliorare il modello. Sono verifiche: ciascuna chiede se un dettaglio plausibile sia quello che sostiene il risultato principale.
Mantieni separate le verifiche. Se modifichi insieme i dati, il piano commissionale e la tempistica di esecuzione, un risultato peggiore ti aiuta poco a capire la causa. Se una verifica è implausibile, presentala come scenario di stress, non come esito probabile.
Non confondere l’identità byte per byte con la verità numerica
Alcuni calcoli sono sensibili all’ordine. La somma in virgola mobile non è associativa, quindi sommare molti piccoli valori di P&L in un ordine diverso può cambiare le ultime cifre. Le riduzioni parallele, l’hardware e le versioni delle librerie possono influire sull’output esatto. Di solito è innocuo; a volte una variazione numerica minima fa scattare una soglia, cambia una posizione e porta il resto della simulazione lungo un percorso diverso.
Per questo conserverei sia gli artefatti esatti sia le tolleranze per i confronti. Registra il libro delle operazioni, non soltanto lo Sharpe finale. Confronta prima le decisioni e i flussi di cassa, poi le metriche entro una tolleranza dichiarata. Se una differenza di un centesimo cambia la decisione di inviare un ordine, esamina esplicitamente quel limite.
Un registro utile dell’esecuzione include l’identità dei dati e del codice, la configurazione, il seed casuale, l’ambiente di esecuzione e abbastanza risultati intermedi da ricondurre una metrica agli eseguiti e ai flussi di cassa. Un punteggio finale, da solo, non è un artefatto di ricerca riproducibile.
Quando una variazione è rumore e quando è un risultato
Non ogni numero diverso è una crisi. Una variazione minima di una metrica dovuta a un diverso ordine di riduzione può lasciare invariate le operazioni. Un’operazione modificata vicino a una soglia può meritare un esame. Una strategia che perde gran parte del risultato quando un fornitore rivede una piccola porzione della cronologia ha rivelato qualcosa sulla propria fragilità, anche se l’esecuzione originale resta perfettamente riproducibile.
Chi critica i controlli di robustezza ha ragione su un punto: è facile continuare a cambiare le ipotesi finché una strategia preferita sembra resiliente, oppure scartare un risultato valido perché uno scenario volutamente estremo lo mette in crisi. Definisci in anticipo le variazioni plausibili, riporta l’intero insieme e distingui le alternative ordinarie dagli scenari di stress. Poi conserva la versione di riferimento, così un altro ricercatore può riprodurre esattamente ciò che hai osservato.
La riproducibilità ti offre un punto di partenza affidabile. La domanda utile viene dopo: quali parti della risposta restano stabili quando il contesto di quell’esecuzione cambia in modi ragionevolmente prevedibili?
← Tutti gli articoli
