Programmazione nello spazio dei pesi: la terza leva per gli LLM

La discesa del gradiente non è mai stata sacra. Era un'impalcatura: l'unico strumento generale che avevamo per modellare miliardi di numeri che nessun essere umano può leggere, quindi abbiamo costruito attorno a essa l'intera religione del deep learning. Un team del MIT CSAIL ha appena smontato l'impalcatura. Hanno dato a un modello di frontiera i pesi grezzi di reti neurali addestrate e gli hanno chiesto, in linguaggio naturale, di spiegarli, correggerli e riscriverli, senza ciclo di addestramento, senza gradienti, senza forward pass. Ha funzionato. La programmazione nello spazio dei pesi, cioè ragionare direttamente sui parametri invece di spingerli in discesa, è passata da esperimento mentale a dimostrazione, e secondo me declassa silenziosamente il fine-tuning da "il modo in cui adattiamo i modelli" a una tra tre opzioni.

Il risultato principale merita l'hype che sta ricevendo. Chiesto di migliorare Qwen3.5-0.8B in matematica senza alcun aggiornamento dei gradienti, il modello, GPT-6 Astra, ha ricondotto un ciclo patologico di ragionamento a una singola direzione scritta in due layer MLP, l'ha sottratta dallo 0,016% dei pesi e ha portato l'accuratezza su MATH-500 dal 7,9% al 48,1%. Stesse impostazioni di campionamento, stesso tutto. La correzione si è perfino trasferita al seguire istruzioni, triplicando il punteggio IFEval. Non è un ritocco di iperparametri, è chirurgia. Ma prima di seppellire la discesa del gradiente, vale la pena essere precisi su cosa sia stato dimostrato davvero, dove si generalizza e dove già fallisce.

Cos'è davvero la programmazione nello spazio dei pesi

Per anni abbiamo avuto esattamente due modi per cambiare cosa fa un modello. Il prompting cambia l'input e lascia i pesi congelati. Il fine-tuning cambia i pesi, ma alla cieca: mostri al paesaggio della loss un lotto di esempi e lasci che i gradienti spingano i parametri in qualunque direzione riduca l'errore, con scarso controllo su quale meccanismo interno venga riconnesso per strada. La programmazione nello spazio dei pesi propone una terza leva: eliminare completamente la funzione di loss e far sì che un sistema di ragionamento legga i pesi, formuli un'ipotesi su cosa calcolino e li modifichi per conformarsi a una specifica in linguaggio naturale.

La parte più inquietante sono i risultati di lettura. I ricercatori hanno addestrato quattro piccole policy con PPO a giocare versioni grid-world di Breakout, Pong, Pac-Man e Freeway: architetture identiche, stessi canali di input, stessi spazi di azione, quindi solo i pesi potevano distinguerle. Astra ha riconosciuto correttamente tutti e quattro i giochi senza che gli fosse fornita la lista dei candidati. Lo stesso ha fatto con modelli di diffusione addestrati a generare cerchi, quadrati e triangoli e, la versione difficile, ha stabilito quale di tre transformer a livello di carattere fosse stato addestrato su Python, inglese o giapponese romanizzato, avendo a disposizione solo i layer centrali, con embedding e layer di output rimossi e ogni dimensione senza etichetta. Lungo il percorso ha individuato ogni induction head, i circuiti di copia che permettono a un modello di ripetere testo precedente, moltiplicando tra loro le matrici dei pesi. È una tecnica nota della letteratura sull'interpretabilità di cui nessuno gli aveva parlato. Se hai seguito il lento lavoro di interpretabilità meccanicistica, vedere un modello general-purpose farlo in modo nativo provoca un certo capogiro.

Poi ha scritto dei pesi. Dato un controller PPO per un'auto bloccato in un minimo locale, con la policy che sbatteva dritta contro una rampa invece di fare retromarcia per prendere velocità, Astra ha diagnosticato il guasto dai pesi più un singolo episodio registrato, e la sua modifica ha fatto riuscire l'auto in tutti i 1.024 episodi di valutazione dopo aver cambiato il 3,5% dei parametri. Chiesto di scrivere da zero reti per giocare, senza alcun feedback dall'ambiente, ha prodotto policy che battevano reti addestrate con PPO per 100 milioni di passi. Rileggi pure: nessuna interazione, nessun segnale di reward, solo una descrizione in linguaggio naturale di un gioco, compilata in pesi funzionanti dal ragionamento di un modello linguistico.

Come funzionano le modifiche dirette ai pesi su modelli reali

La correzione su Qwen è il risultato che conta per chi lavora sul campo, perché 0,8 miliardi di parametri sono un modello reale, del tipo che i team fanno davvero fine-tuning e rilasciano. Il guasto era ben documentato: i piccoli modelli di ragionamento cadono in loop, ripetendo lo stesso testo fino a raggiungere il limite di token senza mai produrre una risposta. La model card di Qwen stessa lo segnala e, nelle prove dei ricercatori, 85 delle prime 96 risposte hanno consumato l'intero contesto di 32.768 token in quel modo. La diagnosi di Astra: gli MLP nei layer 15 e 19 scrivevano nel residual stream una direzione che riportava continuamente il modello nella stessa traiettoria generativa. La correzione è stata sottrarre quella direzione da 64 colonne di output in ciascuno dei due MLP: 131.072 pesi in totale, lo 0,016% del modello.

L'aritmetica è quasi offensivamente semplice, ed è proprio questo il punto. Una volta che sai quale direzione nello spazio delle attivazioni corrisponde a "loopa all'infinito", rimuoverla è una proiezione: per ogni vettore di pesi interessato, sottrai la componente lungo la direzione sbagliata. Chiunque può scriverla in una decina di righe.

import numpy as np
def subtract_direction(W, v, columns):
"""Remove the component of each chosen column that lies along v."""
v = v / np.linalg.norm(v)
W[:, columns] -= np.outer(v, v @ W[:, columns])
return W
# The Qwen repair, schematically: for the MLP output projections of
# layers 15 and 19, subtract the "loop" direction from 64 columns each.
# 2 layers x 64 columns x 1024 rows = 131,072 edited weights.
W_down[15] = subtract_direction(W_down[15], loop_dir[15], cols[15])
W_down[19] = subtract_direction(W_down[19], loop_dir[19], cols[19])

La parte difficile non è mai stata la sottrazione, ma sapere quale direzione, in quale layer, dentro un residual stream largo migliaia di dimensioni. È la parte per cui prima ci servivano i gradienti, perché sono una procedura di ricerca nello spazio dei pesi che non richiede alcuna comprensione. Astra ha sostituito la ricerca con la diagnosi. È la differenza tra un elettricista che riconnette i circuiti per tentativi finché il guasto sparisce e uno che legge lo schema e taglia il filo giusto. Stessa logica per cui il modello ha trovato le induction head componendo matrici di pesi: stava applicando un metodo di interpretabilità pubblicato che non gli era mai stato mostrato, il che suggerisce un vero trasferimento di ragionamento e non ricette memorizzate.

Quando la modifica diretta dei pesi batte il fine-tuning

Ecco la mia posizione, e la difendo: per i guasti stretti e localizzabili in modelli di dimensione piccola-media, la modifica diretta dei pesi è già lo strumento migliore, e non è nemmeno una gara. Pensa all'alternativa del fine-tuning per il bug del loop. Dovresti assemblare un dataset di tracce di ragionamento senza loop, lanciare SFT o RL e sperare che la pressione della loss elimini il comportamento senza degradare tutto il resto di ciò che il modello sa. Bruceresti ore di GPU a risalire la collina verso un proxy, più dati di matematica, invece che verso l'intento reale, cioè "smetti di ripeterti". La programmazione nello spazio dei pesi ti permette di esprimere l'intento. La modifica ha toccato lo 0,01% del modello; un fine-tuning tocca tutto, e i danni collaterali emergono dopo come strane regressioni che nessuno ricollega al run di addestramento.

Il fine-tuning risale la collina verso un proxy del tuo intento. La programmazione nello spazio dei pesi ti permette di esprimere l'intento stesso.

Il secondo caso è uscire da minimi locali che i metodi basati su gradiente non possono strutturalmente abbandonare. PPO ha incastrato l'auto contro la rampa perché il reinforcement learning esplora perturbando la policy corrente, e nessuna piccola perturbazione di "guida dritto" scopre "prima fai retromarcia per due secondi". Il ragionamento non perturba: può saltare a una soluzione qualitativamente diversa perché opera su un modello del problema e non su una variazione della risposta attuale. Un miliardo di passi PPO non avrebbe trovato ciò che ha trovato un singolo passaggio di ragionamento: non è un divario di efficienza, è una differenza di categoria.

Terzo, il ciclo di iterazione collassa. Il fine-tuning ha una coda logistica (curation dei dati, run di addestramento, sessioni di valutazione, controlli di regressione) che trasforma un "piccolo cambio di comportamento" in un progetto di più giorni. Chiunque abbia fatto girare un modello grande sul proprio hardware sa quanta fatica sia plumbing più che modellazione. Una modifica ai pesi somiglia piuttosto a un hotfix nel codice: diagnosi, patch, valutazioni, rollback se sbagli. Quando la diagnosi è giusta, salti l'intera pipeline di addestramento. Le vittorie nette si concentrano in quattro situazioni:

• Il guasto è diagnosticato ma non hai dati di addestramento che esprimano la correzione
• Ti serve un ambito chirurgico: cambiare un comportamento senza far derivare il resto
• Il modello è bloccato in un minimo locale da cui l'esplorazione casuale non esce
• Non puoi permetterti una pipeline di addestramento, né in GPU né in tempo di calendario

Perché la programmazione nello spazio dei pesi è fragile

Ora la doccia fredda, perché ce n'è parecchia. Il dato più utile che ho visto non viene dall'articolo: viene da un professionista che ha provato lo stesso trucco su un piccolo modello da linguaggio naturale a bash e non ha ottenuto nulla di netto. Modificare 1.920 pesi ha sistemato alcuni errori di grep e ne ha rotti altri comandi. È l'esito atteso, ed è il problema profondo: i comportamenti nelle reti addestrate sono intrecciati. La correzione su Qwen ha funzionato perché il comportamento del loop viveva per caso in una direzione compatta e rimovibile. Molti comportamenti no. Sono spalmati nella superposizione, con le stesse colonne che portano più feature non correlate, quindi sottrarre una "direzione" è come cercare di togliere una nota da un accordo: finirai per tagliarne altre. Nessuno ha una teoria per prevedere in anticipo quali guasti siano geometricamente compatti e quali spalmati. Finché non ce l'avremo, ogni modifica ai pesi è una scommessa.

Anche le dimostrazioni di lettura vanno ridimensionate. Il ragionamento di Astra sulle reti dei giochi si è appoggiato a statistiche superficiali (dove si concentrano i pesi del primo layer, quali logit di output si separano), e il riconoscimento della lingua è stato di fatto una scelta multipla a tre opzioni, in cui una, il giapponese romanizzato, ha una distribuzione di lettere vistosamente insolita (niente q, l, v o x). Pattern matching impressionante? Assolutamente. Prova di una comprensione profonda e nativa dello spazio dei pesi? Meno chiaro. Il risultato sulla diffusione va in entrambe le direzioni: Astra ha disegnato ogni forma come contorno, mentre i modelli generano forme piene. Un errore che dimostra che leggeva la geometria invece di simulare la rete, ma che mostra anche come la sua "comprensione" possa essere strutturalmente sbagliata e comunque superare il test.

Poi ci sono scala e provenienza. Ogni risultato pulito sta tra 17.000 e 7 milioni di pesi, con gli 0,8 miliardi di Qwen come eccezione, e persino l'esperimento di lettura dei layer centrali ha richiesto fino a cento run di analisi in Python per arrivarci. Nessuno ha mostrato che funzioni su un modello da 70B, figuriamoci su uno di frontiera, e l'approccio ingenuo, incollare i pesi in una finestra di contesto, muore molto prima. C'è anche una domanda scomoda sull'intero lavoro: da dove viene questa capacità? Gli LLM sospettosamente bravi a scacchi di solito hanno ingerito moltissima notazione scacchistica durante l'addestramento. Se Astra è stato addestrato deliberatamente su dati di pesi, questi risultati dicono meno della comprensione emergente e più di un curriculum molto ben costruito. Non lo sappiamo davvero.

Infine, il salto su MATH-500 richiede un asterisco. Quel benchmark è saturato dai dati di addestramento da anni, e un modello base che ottiene il 7,9% sta quasi certamente fallendo su loop e formattazione più che sulla matematica, il che significa che la modifica ha sbloccato una capacità latente invece di creare una competenza. È comunque prezioso: sbloccare è una vera vittoria. Ma è un'affermazione diversa da "la modifica ha reso il modello più bravo in matematica", e rientra in uno schema noto in cui i benchmark non colgono gran parte di ciò che è il lavoro reale.

Modifiche ai pesi in produzione: trattale come hotfix

Se vuoi provarci, e sui modelli piccoli dovresti, tratta le modifiche ai pesi con la disciplina che useresti per una patch a caldo su un database in esercizio. Fai il diff di tutto: registra esattamente quali tensori sono cambiati e di quanto, perché lo 0,016% è abbastanza piccolo da nascondere per sempre un bug silenzioso nello script di modifica. Valuta in modo ampio, non solo sul comportamento bersaglio: la correzione su Qwen ha casualmente migliorato il seguire istruzioni, ma il segno di quell'effetto collaterale è stato fortuna, e la prossima volta potrebbe andare al contrario. Conserva il checkpoint base come una cosa sacra e versiona ogni modifica come patch reversibile. E dimensiona le ambizioni: la zona dolce dimostrata è fatta di guasti piccoli e ben compresi, in modelli che puoi valutare per intero. Se il tuo istinto è sistemare un vago problema di "sensazione" in un modello da 70B "rimuovendo la direzione sbagliata", stai per imparare a tue spese cos'è la superposizione.

• Fissa il checkpoint base; salva le modifiche come diff, senza mai sovrascrivere in place
• Esegui valutazioni ampie prima e dopo, non solo il benchmark bersaglio
• Preferisci guasti con una firma netta e riproducibile piuttosto che sensazioni vaghe
• Prevedi i rollback: assumi che una frazione delle modifiche rompa qualcosa

La mia posizione onesta: oggi questo è uno strumento di interpretabilità e un bisturi di debugging, non una pipeline di deployment. I team che ne estrarranno valore per primi non saranno quelli che spediscono modifiche ai pesi in produzione. Saranno quelli che usano un modello di frontiera per spiegare cosa hanno imparato i loro modelli piccoli, leggendo i checkpoint come già leggiamo le tracce di ragionamento, e poi agendo su quella conoscenza con strumenti ordinari, noiosi e affidabili.

I gradienti non sono morti: sono stati retrocessi

Qui la mia affermazione iniziale si rompe, e voglio essere onesto a riguardo. La discesa del gradiente fa una cosa che la programmazione nello spazio dei pesi non può fare: impara dai dati su larga scala. Ogni capacità che Astra ha usato per fare queste modifiche è stata a sua volta installata dai gradienti su un corpus di addestramento enorme. Il ragionamento può operare chirurgia su ciò che una rete sa, ma non può insegnare a una rete l'insieme del testo umano. Il futuro realistico non è la sostituzione dei gradienti, ma una divisione del lavoro: i gradienti gettano il calcestruzzo, la programmazione nello spazio dei pesi fa la rifinitura. Per quarant'anni abbiamo trattato i pesi addestrati come un artefatto opaco, una scatola nera che si poteva guidare solo dall'esterno. L'idea davvero nuova è che la scatola stia diventando leggibile, e che a leggerla non siamo noi. Che questo sia rassicurante o allarmante dipende probabilmente da quanto ti fidavi dei gradienti.