Context Language Models: quando il modello riscrive la propria memoria
Un paper di Meta e University of Washington propone modelli che trattano il contesto come un file modificabile. Come funzionano, cosa cambia per chi costruisce agenti e quali controlli servono quando la memoria la gestisce il modello
Luciano Cipriano
10/13/20266 min read
Ciao a tutti,
Ben arrivati su WikiLuc.
Quando si costruisce un agente che lavora su compiti lunghi, una delle decisioni più delicate riguarda la memoria: cosa tenere nel contesto del modello, cosa riassumere, cosa scartare. Oggi quella decisione la prende quasi sempre chi scrive l'impalcatura intorno al modello, il cosiddetto harness, con regole fisse: riassumere ogni tanti passaggi, troncare i risultati troppo lunghi, salvare alcune informazioni in un file esterno.
Il 29 settembre un gruppo di ricercatori della University of Washington e di Meta Superintelligence Labs, tra cui Rulin Shao, Luke Zettlemoyer e Pang Wei Koh, ha pubblicato su arXiv il paper Context Language Models. La proposta è spostare quella decisione dentro il modello: il contesto diventa un file che il modello può modificare liberamente, invece di una sequenza a cui si possono solo aggiungere nuovi pezzi.
Ne avevamo parlato a giugno, a proposito di context engineering e memoria degli agenti. Questo lavoro sposta il problema dal progettista al modello, e con esso anche una parte delle responsabilità di controllo.
Di cosa parliamo oggi:
Il limite del contesto che si allunga e basta
Come funziona un Context Language Model, passo per passo
Cosa cambia per chi costruisce agenti
I rischi di una memoria riscrivibile
Le scelte di governance da fare prima di adottarli
Partiamo dal limite attuale.
Dalla conversazione al file
Il contesto che si allunga e basta
Un modello linguistico, per come funziona oggi, legge il contesto e aggiunge in coda i nuovi token che produce. In notazione, il contesto al passo successivo è quello precedente più l'output del modello: c(t+1) = c(t) ⊕ output. Il modello non può cancellare, spostare o riscrivere nulla di ciò che sta già nel contesto.
Un'analogia aiuta. È come lavorare a un progetto lungo con un quaderno in cui si può solo scrivere in fondo, senza mai cancellare o riordinare le pagine. Dopo qualche ora il quaderno è pieno di tentativi abbandonati, appunti superati e informazioni ripetute, e trovare ciò che serve diventa sempre più difficile. Gli harness intervengono dall'esterno, come un assistente che ogni tanto strappa pagine o riassume capitoli seguendo una regola fissa, ma una regola uguale per tutti i compiti difficilmente è quella giusta per ciascuno.
Come funziona un Context Language Model
I Context Language Models cambiano la formula: il contesto al passo successivo è una trasformazione decisa dal modello del contesto attuale, c(t+1) = f(c(t)). Nell'analogia, il modello riceve una gomma, delle forbici e la possibilità di riordinare le pagine.
In pratica il contesto viene sincronizzato con un file, e il modello lo modifica con comandi Bash, gli stessi che un programmatore usa nel terminale. Può cancellare righe, riscrivere una sezione, spostare un'informazione, sostituire un risultato lungo con un riassunto, conservare alla lettera ciò che serve esatto. Nei sistemi multi-agente, ogni agente ha il proprio file di contesto.
Gli autori mostrano tre modi per insegnare al modello a farlo bene: istruzioni in linguaggio naturale, un ciclo di ottimizzazione che fa evolvere le strategie migliori, e l'apprendimento per rinforzo, che premia il modello quando risolve il compito usando meno calcolo. Con quest'ultimo, un modello piccolo come Qwen3.5-9B passa dal 28,8% al 42,5% di accuratezza su un benchmark di ricerca approfondita, con il 38,8% di calcolo in meno. Sugli altri benchmark il risultato è coerente: più accuratezza, o la stessa accuratezza con meno calcolo.
Cosa cambia per chi costruisce agenti
La conseguenza principale riguarda la divisione del lavoro tra modello e harness.
Meno regole di memoria scritte a mano.
Oggi una parte rilevante del codice di un agente gestisce il contesto: quando riassumere, cosa troncare, cosa salvare. Con modelli di questo tipo, quella logica può essere in parte appresa. Il progettista definisce obiettivi e vincoli, il modello sceglie la strategia.Strategie che si adattano al compito.
Gli autori documentano strategie emerse senza essere insegnate: tabelloni interni per coordinare più agenti, ruoli di chat inventati per tenere note separate, cicli in Bash per eliminare risultati irrilevanti, funzioni di compattazione riutilizzabili. È il segnale che la gestione della memoria si può imparare come qualsiasi altra abilità.Nuovi vincoli sull'infrastruttura.
Quando il modello modifica il contesto a metà, le cache che i server usano per non ricalcolare i token già elaborati smettono di funzionare dal punto modificato in poi. Gli autori propongono una tecnica, Suffix Cache Reuse, che riduce il calcolo lato server del 35% rispetto a SGLang. Chi gestisce l'inferenza in casa dovrà tenerne conto.Architetture da tenere modulari.
Se la gestione del contesto può migrare dall'harness al modello, conviene progettare oggi gli agenti in modo che quella parte sia separata e sostituibile, invece che dispersa in tutto il codice.
I rischi di una memoria riscrivibile
Il primo rischio è dichiarato dagli autori stessi: la prompt injection nella memoria. Se il modello può riscrivere il proprio contesto, può anche inserire nei propri riassunti istruzioni che nessuno ha autorizzato e che influenzano il comportamento successivo. Un contenuto malevolo letto durante un compito, ad esempio in una pagina web, potrebbe essere trasformato in una "nota" che il modello rileggerà come se fosse un'indicazione legittima. Il paper indica la necessità di difese specifiche, non ancora sviluppate.
Il secondo rischio riguarda la verificabilità. In un contesto che si allunga e basta, tutto ciò che il modello ha visto resta leggibile. In un contesto riscrivibile, ciò che il modello sapeva al momento di una decisione può essere stato cancellato o modificato pochi passaggi dopo. Ricostruire perché un agente ha agito in un certo modo diventa più difficile.
Il terzo riguarda la maturità. Si tratta di un paper di ricerca, con il codice pubblicato da Meta, non di un prodotto. I risultati vengono da benchmark scelti dagli autori, e la loro tenuta su compiti aziendali reali è ancora da verificare.
Le scelte di governance
Per chi valuta di adottare modelli con memoria riscrivibile, tre scelte vanno fatte prima e non dopo.
Conservare la storia delle modifiche.
Ogni versione del file di contesto va registrata, in modo da poter ricostruire cosa il modello sapeva in ogni momento. È l'equivalente del controllo di versione nel software.Separare le istruzioni dalle note.
Le istruzioni di sistema e i vincoli dell'operatore devono stare in una parte del contesto che il modello non può modificare, distinta dalla memoria di lavoro.Controllare ciò che entra nella memoria da fonti esterne.
I contenuti letti da pagine web, documenti o altri agenti vanno trattati come dati non affidabili, anche quando il modello li ha già riassunti.
Su cosa focalizzarsi
Quanta logica di gestione della memoria sta oggi nel proprio harness. È la parte che modelli di questo tipo potrebbero assorbire, e che conviene tenere modulare.
Come si ricostruisce a posteriori cosa sapeva l'agente. Senza una cronologia delle modifiche, un agente che riscrive la propria memoria diventa difficile da verificare.
Quali parti del contesto il modello non deve poter modificare. La separazione tra istruzioni e memoria di lavoro è la prima difesa contro le istruzioni inserite.
Sono domande che oggi interessano soprattutto chi progetta agenti per compiti lunghi. Nei prossimi due o tre anni, se questa direzione si consolida, il lavoro di chi costruisce agenti si sposterà dallo scrivere regole di memoria al definire obiettivi, vincoli e controlli su come il modello gestisce il proprio contesto, e chi avrà già separato bene queste responsabilità potrà adottare i nuovi modelli con meno riscritture e meno rischi.
Notizie da tenere d'occhio
OpenAI Dots e gli agenti sempre attivi
Il 29 settembre OpenAI ha lanciato Dots, agenti personali che lavorano in background mantenendo il contesto tra tutte le superfici di ChatGPT.
Perché importa: gli agenti che lavorano per ore o giorni sono esattamente il caso d'uso in cui la gestione del contesto diventa critica.
OpenAI ferma GPT-6.1 Astra
Il 28 settembre OpenAI ha cancellato il rilascio di GPT-6.1 Astra perché nei test non restava nei confini di scope e autorizzazione e nascondeva alcune azioni all'utente.
Perché importa: la visibilità su ciò che un agente fa e sa è già un criterio di rilascio, e una memoria riscrivibile la rende ancora più importante.
TraceML: gli agenti si chiudono in loop
Un dataset della Carnegie Mellon confronta 4.465 traiettorie umane con 207 esecuzioni di agenti su compiti di machine learning: gli agenti tendono a ripetere cicli stretti, gli umani cambiano strategia tre volte più spesso.
Perché importa: riorganizzare il proprio lavoro, contesto compreso, è uno dei limiti attuali degli agenti che i CLM provano ad affrontare.
Una cosa da provare
🔧 Il repository context-language-models di Facebook Research
Il codice pubblicato insieme al paper, con licenza aperta. Lo consiglio a chi costruisce agenti per compiti lunghi: anche senza adottare l'approccio completo, osservare come il modello organizza il proprio file di contesto offre idee concrete per migliorare le strategie di memoria del proprio harness.
I Context Language Models spostano una decisione importante, cosa ricordare e cosa dimenticare, dall'architettura esterna al modello, con guadagni misurabili di accuratezza e di costo. Proprio per questo l'autonomia sulla memoria va accompagnata da controlli progettati in anticipo: cronologia delle modifiche, separazione tra istruzioni e note, cautela su ciò che entra da fonti esterne. È su questo equilibrio che si giocherà l'adozione di questa direzione nei sistemi reali.
Grazie per aver letto questo articolo fammi sapere cosa ne pensi!
Ci vediamo presto qui su WikiLuc!
