Quando un LLM riutilizza i propri stati nascosti come memoria di runtime, ogni passaggio nel ciclo produce una previsione e alimenta quella successiva. È un’architettura elegante, ma pone una domanda scomoda: la funzione di perdita che calcoliamo a ogni iterazione controlla davvero tutte le variabili in gioco? Una ricerca recente mostra che la risposta è negativa: la cross-entropy densa agisce solo sulle variabili che il readout espone, lasciando scoperta un’ampia zona d’ombra nella dinamica ricorrente.

La scala nascosta che sfugge alla loss

Il meccanismo è semplice quanto insidioso. In molti LLM ricorrenti il readout è invariante di scala, grazie a normalizzazioni come RMSNorm o LayerNorm che rimuovono la grandezza radiale del vettore prima di proiettarlo sul vocabolario. Così la loss immediata non ‘vede’ la norma euclidea dello stato nascosto. Nel frattempo, la ricorrenza con residuo pre-norm continua ad accumulare e propagare proprio quella scala, senza alcun freno diretto.

Il risultato, documentato su transformer ciclici da 44 e 129 milioni di parametri, è impressionante: senza interventi architetturali, le norme degli stati finali schizzano a valori di migliaia o decine di migliaia. Una perdita di controllo che non dipende dalla quantità di supervisione – ogni passo ha la sua cross-entropy – ma da un difetto di visibilità strutturale.

Due soluzioni per una regola generale

Gli autori indicano due strade complementari, che convergono in una regola di design nitida. La prima è rendere la scala visibile alla loss, per esempio adottando readout che conservano l’informazione radiale o aggiungendo penalità esplicite sulla norma. La seconda è rimuovere completamente la scala dal loop, con una ricorrenza progettata per non trasportare informazioni di ampiezza. Entrambe riportano le norme a valori contenuti (nell’ordine delle decine) e, coerentemente con la regola, le varianti che controllano la scala ottengono perplessità più basse a parità di profondità di inference nei benchmark a profondità variabile.

Il principio che emerge è tanto semplice quanto operativo: la supervisione densa allena le uscite intermedie, ma il controllo della scala ricorrente richiede un intervento architetturale esplicito. Non c’è scorciatoia di sola loss.

Cosa significa per chi addestra modelli on-premise

Per i team che portano avanti training o fine-tuning di LLM su infrastruttura locale, questa dinamica ha un peso concreto. L’addestramento di modelli ricorrenti senza i giusti accorgimenti può nascondere derive di scala che degradano le prestazioni e allungano i cicli di debugging. Il costo computazionale perso in esperimenti non produttivi si traduce direttamente in TCO più alto per GPU e sistemi di storage.

La regola emersa – visibilità o rimozione della scala – diventa un criterio di validazione architetturale quasi a costo zero in fase di design. Chi lavora su stack self-hosted e vuole mantenere la sovranità sui dati può integrare questi controlli già nella pipeline di sperimentazione, senza attendere benchmark esterni. Lo sforzo è minimo: basta sostituire il readout invariante di scala o inserire un termine di regolarizzazione, decisioni che si possono valutare sui propri carichi di lavoro e sui dataset proprietari.

Un promemoria per l’architettura ricorrente

La scoperta aggiorna un aspetto spesso trascurato: non tutto ciò che è tecnicamente ‘addestrabile’ è automaticamente sotto controllo. I meccanismi di normalizzazione che semplificano la convergenza nei transformer statici possono creare ostacoli nuovi quando la rete si ripiega su se stessa in un loop. È un classico trade-off: l’ingrediente che stabilizza il forward pass può destabilizzare la ricorrenza, se non lo si guarda dalla prospettiva giusta.

Il messaggio per la comunità è chiaro: quando si progettano architetture cicliche, serve una verifica incrociata tra la funzione di costo e le variabili effettivamente sorvegliate. Un readout troppo ‘cieco’ non è un problema di ottimizzazione, ma di definizione del modello. E risolverlo non costa complessità, ma coerenza.