Lunedì, il nostro agente di ricerca AI ha trovato una strategia su futures crypto con un rapporto di Sharpe pari a 4.1. Giovedì, dopo aver contato gli esperimenti e impedito all’agente di ottimizzare ancora sulla stessa finestra di validazione, il risultato era 0.8. La strategia non era cambiata. Era cambiata la nostra stima di ciò che la ricerca aveva ottenuto.
Abbiamo tenuto questo piccolo diario di ricerca perché «ottimizzate con attenzione» è un consiglio facile da dare e difficile da mettere in pratica quando un agente può scrivere codice, lanciare backtest, esaminare il punteggio e riprovare nel giro di pochi minuti. Ecco cosa si è inceppato, in ordine.
Lunedì: assegnare all’agente un quesito circoscritto
Abbiamo chiesto all’agente di testare una semplice strategia oraria basata sul trend in un mercato liquido di futures perpetual: entrare quando una media mobile breve incrocia una più lunga, dimensionare la posizione in base a un obiettivo di volatilità fisso e chiuderla al segnale opposto. Abbiamo specificato lo strumento, le date, il tariffario delle commissioni, lo storico dei funding rate, l’ipotesi di esecuzione e gli intervalli di parametri esplorabili.
Il campione storico copriva il periodo dal 2021 al 2025. Abbiamo assegnato il 2021–2023 allo sviluppo, il 2024 alla validazione e tenuto il 2025 sigillato come holdout finale. La suddivisione era definita nella configurazione del job: l’agente poteva leggere i risultati di sviluppo e i punteggi di validazione, ma non poteva recuperare i rendimenti del holdout.
Il nostro primo errore è stato consentire 300 combinazioni di parametri in un unico job, senza registrare il budget di ricerca come risultato dello studio. L’agente ha restituito la configurazione migliore: una media veloce a 9 ore, una lenta a 73 ore e un obiettivo di volatilità dello 0.8%. Lo Sharpe in validazione era 4.1. Sapevamo che l’agente aveva provato molte impostazioni. Non avevamo ancora fatto in modo che fosse impossibile dimenticarlo.
Martedì: il vincitore è cambiato al nuovo avvio
Abbiamo rilanciato lo stesso job in un ambiente pulito. La configurazione migliore era cambiata e il suo Sharpe era sceso a 2.7. Nella prima esecuzione una cache dei dati di mercato aveva fornito una serie aggiornata dei funding rate, mentre il nuovo avvio usava uno snapshot bloccato. Entrambi i job dichiaravano di usare lo stesso intervallo di date, ma solo uno aveva una versione dei dati riproducibile.
Abbiamo smesso di confrontare i punteggi e iniziato a registrare l’esperimento completo: revisione del codice, snapshot dei dati, commissioni, funding, impostazioni di esecuzione, valori dei parametri e ogni prova lanciata dall’agente. Così abbiamo capito che il 4.1 non era un misterioso vantaggio di mercato. Apparteneva a una configurazione tra 300 tentativi sulla stessa annualità di validazione.
Mercoledì: bloccare la ricerca prima di aprire il holdout
Abbiamo ripetuto l’esperimento con uno snapshot dei dati fisso e una griglia più piccola, definita in anticipo: 24 combinazioni. L’agente poteva classificarle in base al periodo di sviluppo 2021–2023. Gli abbiamo mostrato il 2024 una sola volta, per la selezione, poi abbiamo bloccato le impostazioni scelte e il codice.
La strategia selezionata ha ottenuto uno Sharpe di 0.8 in validazione. Sul holdout 2025 sigillato, ha ottenuto 0.3 al netto delle commissioni taker e del funding, applicando lo stesso ritardo di esecuzione di una barra usato in tutto lo studio. Era una risposta utile. Non dimostrava che la strategia avrebbe generato profitti su un conto reale.
Una parentesi su questa settimana: abbiamo dedicato più tempo a decidere cosa intendessimo per «una prova» che a scrivere il codice della media mobile. Abbiamo considerato una prova ogni modifica all’insieme dei parametri, e contato anche le esecuzioni che modificavano il segnale o la regola di dimensionamento della posizione. Un nuovo snapshot dei dati o una diversa ipotesi di esecuzione riceveva una registrazione separata, perché poteva cambiare la classifica altrettanto.
Giovedì: cosa salteremmo la prossima volta
Salteremmo il primo job senza limiti. Un agente di ricerca ha bisogno di un budget di ricerca e di un registro dei tentativi, soprattutto se può usare ogni risultato per decidere cosa provare dopo. Anche il holdout va protetto da consultazioni informali: se qualcuno ne legge il risultato e modifica la strategia, quel periodo diventa un altro insieme di validazione.
Per una ricerca piccola, un registro degli esperimenti pratico può essere semplice e chiaro:
| Registrazione | Perché è importante |
|---|---|
| Versioni di codice e dati | Così un nuovo avvio usa gli stessi input e la stessa logica |
| Ogni variante testata | Così si interpreta il vincitore alla luce della ricerca |
| Ruoli di sviluppo, validazione e holdout | Così il punteggio finale non viene riutilizzato di nascosto per l’ottimizzazione |
| Ipotesi su commissioni, funding ed esecuzione | Così il risultato riportato descrive una simulazione verificabile |
Dopo aver aperto il holdout, tornate allo sviluppo con una nuova domanda di ricerca e conservate il vecchio risultato come evidenza storica. Non continuate a perfezionare la stessa strategia su un periodo che ha già visto.
L’agente ha fatto il suo lavoro: ha esplorato rapidamente e trovato una configurazione da esaminare. Il nostro compito era rendere leggibile la ricerca, conservare un test intatto e trattare il punteggio come una misurazione con una storia. Il risultato interessante non era 4.1 o 0.3. Era vedere esattamente come si era ottenuto il primo numero.
← Tutti gli articoli
