Dream-RSI: quando l’IA migliora… senza cambiare il modello

Negli ultimi anni, le “scoperte” prodotte da sistemi di AI in matematica e nella progettazione di algoritmi hanno mostrato un pattern ricorrente: non è (solo) il modello a fare la magia, ma la macchina di ricerca che gli costruiamo attorno.

Se lavori con agenti, tool di coding, harness di valutazione o pipeline di sperimentazione, questa distinzione è cruciale: spesso i miglioramenti più forti arrivano non dall’ennesimo prompt più furbo, ma dal modo in cui organizziamo tentativi, feedback e scelta del prossimo passo.

Uno degli sviluppi più interessanti in questa direzione è l’idea di Dream-RSI: ottimizzare la strategia di esplorazione sfruttando i log dei tentativi passati, senza toccare il modello.

Il loop “classico”: proposta → score → feedback → retry

Il workflow che domina i risultati recenti è sorprendentemente uniforme:

1. dai all’agente un problema (es. dimostrazione, algoritmo, codice)
2. definisci una funzione di scoring (accuratezza, performance, correttezza, ecc.)
3. fai girare un loop di iterazioni:
   • l’agente propone una soluzione
   • il sistema la valuta (unit test, benchmark, verificatore formale, ecc.)
   • l’agente legge il feedback
   • riprova

In pratica è una forma di search guidata, dove il modello è un generatore di candidati e la pipeline è un selettore che spinge verso il miglioramento.

Fin qui nulla di nuovo. La parte sottovalutata, però, è la seguente.

La variabile nascosta: la exploration policy

A ogni giro del loop, il sistema deve decidere cosa tentare dopo. È qui che si gioca gran parte dell’efficienza.

Esempi tipici di decisioni:

• Se un’idea sembra promettente (score in salita), continui a “sfruttarla” con micro-iterazioni o riparti da un approccio diverso?
• Se un tentativo fallisce presto (crash, timeout, test che non partono), è un segnale che:
  • l’idea è sbagliata, oppure
  • è solo un dettaglio implementativo che va sistemato?
• Quanta “diversità” mantieni nella popolazione di soluzioni candidate?

Questa strategia — la policy — nella pratica è spesso hardcoded in chi costruisce l’harness: regole, euristiche, soglie, temperature, branching, reset, beam, ecc.

Ed è proprio qui che entra il concetto di Dream-RSI.

L’intuizione: usare i log come simulatore

Se durante un run salvi tutto:

• codice generato
• score ottenuto
• errori/crash
• metadati di esecuzione
• magari anche ragionamenti e tracce di tool

…ottieni un dataset che descrive il comportamento dell’agente in quel contesto.

A quel punto puoi fare una cosa controintuitiva: testare nuove exploration policy senza rilanciare il modello.

Come?

• invece di far generare nuovo codice (costoso), dai alla nuova policy l’archivio dei tentativi passati
• chiedile: “se avessi preso decisioni diverse, quali passi avresti scelto? quanto velocemente saresti arrivata al migliore risultato già presente nel log?”

In altre parole, i run storici diventano un simulatore off-line per valutare policy alternative.

Perché è potente

Perché valutare policy su log già disponibili costa pochissimo rispetto a:

• generare nuova code
• eseguire benchmark
• consumare token/tool
• pagare compute

Se il costo marginale si avvicina allo zero, puoi provare migliaia di policy, selezionare quella che minimizza il numero di tentativi per arrivare a un buon risultato, e poi usarla nel run successivo. Quel run viene salvato, e il processo continua.

Il paper chiama questa fase di valutazione off-line “dreaming”: la policy “sogna” strategie diverse dentro un mondo simulato dai log.

Cosa cambia davvero: velocità e spreco

Un risultato tipico di questo approccio non è “trovare ciò che era impossibile”, ma trovare più rapidamente ciò che era già a portata del modello.

Pensala così:

• il modello è il motore
• la policy è il navigatore

Con lo stesso motore puoi fare una gara pessima se sbagli strada mille volte. Una policy migliore riduce:

• ripetizioni inutili
• micro-tweak infiniti sulla stessa idea
• loop di crash/timeout
• tempo sprecato a esplorare rami sterili

In un test su problemi di algoritmo e matematica, questo tipo di “dreaming” ha mostrato miglioramenti forti in numero di tentativi necessari per battere baseline statiche (in particolare su task di scrittura di solver/ottimizzatori).

È davvero “recursive self-improvement”?

Dipende da quanto sei rigoroso con le definizioni.

La tesi forte della recursive self-improvement (RSI) è: un sistema diventa capace di migliorare se stesso, e ogni miglioramento lo rende più capace di migliorarsi ancora, in un’accelerazione potenzialmente esplosiva.

Nel caso del Dream-RSI la situazione è più sobria:

• il modello non cambia (niente nuovi pesi, niente training)
• ciò che cambia è il processo di ricerca attorno al modello (policy di esplorazione)

Quindi non è “l’intelligenza” del modello a crescere iterazione dopo iterazione: è l’efficienza del sistema a migliorare grazie a una metrica e a un meccanismo di selezione.

Detto questo, vale un’osservazione scomoda: molti progressi recenti che chiamiamo “breakthrough dell’AI” sono già così — modelli relativamente statici + orchestrazione, swarm, valutazione, tool, caching. L’innovazione sta spesso nell’harness.

La domanda quindi diventa pratica, non filosofica:

Se un sistema migliora drasticamente il proprio rendimento senza retraining, quanto è diverso, operativamente, da un sistema che “impara”?

Implicazioni pratiche per chi costruisce agenti (e prodotti)

Anche se non stiamo parlando di fantascienza, il pattern è estremamente utile per l’ingegneria reale.

1) Loggare tutto non è un nice-to-have

Se vuoi usare strategie tipo “dreaming”, devi progettare i run come artefatti riusabili:

• storage strutturato dei tentativi
• tracciamento degli errori
• riproducibilità del valutatore
• versioning di prompt/toolchain

Senza osservabilità, non c’è simulazione off-line.

2) Separa chiaramente modello e policy

Architettonicamente conviene trattare:

• generatore (LLM/agent)
• valutatore (scoring)
• policy (scelta dei prossimi tentativi)

come moduli sostituibili. È la condizione necessaria per migliorare il sistema senza “toccare il cervello”.

3) Ottimizza prima ciò che costa di più

Se generare ed eseguire è costoso, ha senso spendere ingegno per ridurre:

• il numero di chiamate al modello
• il numero di esecuzioni di benchmark
• i retry inutili

Le policy off-line sono un modo elegante per spostare lavoro da compute costoso a analisi economica.

Sintesi: meno “esplosione d’intelligenza”, più ingegneria della ricerca

Dream-RSI è soprattutto una lezione di sistema: quando trasformi i tentativi passati in un simulatore, puoi migliorare la strategia di esplorazione a costo marginale bassissimo. Il modello resta lo stesso, ma il loop diventa più intelligente nel senso operativo del termine: smette di sprecare mosse.

La conseguenza pratica è chiara: i prossimi salti di qualità nei prodotti basati su agenti potrebbero arrivare meno da “modelli più grandi” e più da policy migliori, caching dei run, valutatori robusti e osservabilità. Se oggi costruisci pipeline di coding agent o sistemi di ottimizzazione iterativa, investire nel come cerchi può contare quanto investire nel cosa stai usando per cercare.