Approfondimenti tecnici
Il problema della memoria: perché i sistemi di IA dimenticano e come la memoria persistente cambia tutto
I transformer non conservano alcuno stato tra una chiamata e l’altra. Tutto ciò che viene chiamato memoria dell’IA è quindi un’impalcatura aggiunta: cache KV, finestre da un milione di token ora fatturate alle tariffe standard, recupero del

Gabriele Masetti ·
L’architettura è progettata senza memoria
Durante l’inferenza, un transformer è una funzione pura. Gli si fornisce una sequenza di token e restituisce una distribuzione di probabilità per il token successivo. Lo si richiama con lo stesso input e si ottiene lo stesso output. Nulla persiste tra una chiamata e l’altra, a meno di inserirlo nell’input. Non è un bug che verrà corretto nella prossima versione: è l’architettura che funziona come previsto.
Il transformer originale del 2017 («Attention Is All You Need», Vaswani et al.) era stato costruito per trasformare sequenze in altre sequenze mediante self-attention, non per accumulare uno stato tra invocazioni indipendenti. Tutti i grandi modelli linguistici successivi — GPT, Claude, Gemini, Llama — ereditano questa caratteristica. Se si fa una domanda a ChatGPT il lunedì e gliela si ripete il martedì, in assenza di una funzione di memoria esplicita aggiunta al modello, quest’ultimo non ha idea di cosa sia successo il lunedì.
In ambito ingegneristico, questa assenza di stato ha una conseguenza pratica: la finestra di contesto è tutto il mondo che il modello può vedere. Ciò che non si trova in quella finestra non esiste per il modello, per quanto fosse importante cinque minuti o cinque mesi prima. Tutto ciò che nel linguaggio comune viene chiamato «memoria dell’IA» — un chatbot che ricorda il nome di una persona, un agente che ricorda una decisione presa tre passaggi prima, un assistente di programmazione che segue un refactoring nel corso di una sessione — è in realtà una soluzione tecnica aggiunta a un sistema che dimentica tutto non appena termina il passaggio in avanti.
Che cosa succede davvero durante una conversazione
All’interno di una singola sessione, i modelli non ricalcolano tutto da zero a ogni token: sarebbe proibitivamente lento. La generazione autoregressiva usa una cache KV: man mano che ogni token viene elaborato, il modello conserva i vettori chiave e valore calcolati dai suoi livelli di attenzione e li riutilizza per ogni token successivo, invece di ricalcolarli. Questo trasforma la generazione da un problema con tempi quadratici in uno che, per ogni nuovo token, ha tempi più vicini a quelli lineari. È per questo che, in una risposta lunga, l’avvio della generazione di ogni parola aggiuntiva non diventa proporzionalmente più lento.
Ma la cache KV è un elemento della sessione, non una memoria durevole. Cresce a ogni token del contesto, assorbe la maggior parte della memoria GPU quando si gestiscono richieste con contesti lunghi e svanisce non appena la sessione finisce. È meglio considerarla uno spazio di lavoro volatile che rende efficiente una singola elaborazione priva di stato, non un meccanismo per conservare informazioni tra sessioni.
La distinzione conta, perché è facile confondere «il modello ha tenuto traccia di ciò che ho detto dieci minuti fa» con «il modello si ricorda di me». Nel primo caso, sono la cache KV e il prompt che si allunga a fare il loro lavoro all’interno di un contesto delimitato. Il secondo richiede un’infrastruttura del tutto diversa, che scriva le informazioni da qualche parte al di fuori del modello e le recuperi in seguito.
Finestre più grandi non risolvono il problema
La soluzione più ovvia — ingrandire la finestra di contesto — è stata perseguita con decisione e, nei suoi termini, ha funzionato. Gemini 1.5 Pro di Google, presentato nel febbraio 2024, è stato il modello che ha reso ordinaria una finestra da 1 milione di token; da allora è scomparso del tutto dalla documentazione dei modelli di Google, sostituito dalle linee Gemini 2.5 e Gemini 3. La finestra da un milione di token è sopravvissuta al modello che l’aveva annunciata.
Ora è una caratteristica predefinita, non più una notizia da titolo. La documentazione di Anthropic indica una finestra di contesto da 1M token per Claude Opus 4.6 e successivi, Claude Sonnet 4.6 e successivi, e per i suoi modelli Fable e Mythos. Afferma inoltre senza mezzi termini che non serve alcun header beta: «Per ogni modello con una finestra di contesto da 1M token, 1M è il valore predefinito».
È venuta meno anche l’obiezione sul prezzo. La pagina dei prezzi di Anthropic dice che i modelli Claude 4.6 e successivi includono l’intera finestra da 1M token alle tariffe standard: una richiesta da 900k token viene fatturata alla stessa tariffa per token di una da 9k token, e gli sconti per il prompt caching e l’elaborazione in batch si applicano all’intera finestra. L’attenzione continua a operare su ogni token inviato, quindi la latenza cresce con il prompt, ma il sovrapprezzo esplicito per i contesti lunghi non è più l’ostacolo.
Se un contesto poco costoso fosse la risposta, il problema della memoria sarebbe risolto. Non lo è, per una ragione che nessun listino prezzi può eliminare: il fatto che un token si trovi nella finestra di contesto non significa che il modello sappia usarlo bene.
Persi nel mezzo
Questo secondo problema è stato documentato con precisione in "Lost in the Middle: How Language Models Use Long Contexts" di Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni e Percy Liang (pubblicato su Transactions of the Association for Computational Linguistics nel 2024, dopo essere circolato come preprint nel 2023). Gli autori hanno sottoposto i modelli linguistici a compiti che richiedevano di trovare informazioni pertinenti tra una serie di documenti o coppie chiave-valore, variando sistematicamente la posizione dell’elemento pertinente nell’input.
Il risultato è stato una caratteristica curva delle prestazioni a U: i modelli recuperano meglio le informazioni che si trovano all’inizio o alla fine di un contesto lungo, mentre le prestazioni peggiorano sensibilmente — scendendo talvolta sotto quelle di un modello a cui non è stato fornito alcun documento pertinente — quando le informazioni necessarie si trovano nel mezzo.
Questa conclusione è stata rafforzata dalla metodologia di valutazione dell’«ago nel pagliaio», un approccio reso popolare da Greg Kamradt alla fine del 2023. Un’informazione specifica (l’«ago») viene nascosta a profondità diverse in un ampio blocco di testo riempitivo (il «pagliaio») e al modello viene chiesto di recuperarla. Rappresentando il tasso di successo in funzione sia della lunghezza del contesto sia della profondità a cui l’informazione è stata inserita, si ottiene una mappa di calore che mostra esattamente dove la capacità di recupero del modello viene meno.
Ora sono gli stessi fornitori a dirlo. La documentazione di Anthropic sulla finestra di contesto avverte che «con l’aumentare del numero di token, la precisione e la capacità di recupero peggiorano, un fenomeno noto come degrado del contesto», e conclude che selezionare ciò che entra nel contesto conta quanto lo spazio disponibile. Il fornitore che vende una finestra da un milione di token dice ai clienti di non riempirla indiscriminatamente.
La conclusione, per chiunque sviluppi sistemi basati su questi modelli, è che una finestra pubblicizzata come capace di contenere un milione di token non garantisce che il modello sappia usare altrettanto bene tutti quei token. I benchmark che misurano specificamente la capacità effettiva di recuperare informazioni da contesti lunghi, anziché la semplice capacità di accettare token, rilevano regolarmente che, nel mondo reale, il contesto utilizzabile è una frazione di quello dichiarato. Una finestra più ampia cambia ciò che un modello può tecnicamente acquisire; da sola, non cambia l’affidabilità con cui il modello ragiona su tutto ciò che contiene.
Il recupero delle informazioni come sistema di memoria esterno
Se inserire tutto nel contesto è costoso e inaffidabile, l’alternativa è non inserirvi tutto, ma recuperare su richiesta soltanto ciò che è pertinente. È l’idea alla base della generazione aumentata dal recupero delle informazioni, introdotta in "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" da Patrick Lewis e coautori di Facebook AI Research nel 2020. La RAG combina un sistema di recupero, che cerca in un corpus esterno i passaggi pertinenti a una richiesta, con un generatore che produce la risposta sulla base sia della richiesta sia dei passaggi recuperati. Anziché affidarsi a un insieme fisso di informazioni incorporate nei pesi del modello durante l’addestramento, il modello consulta un archivio di documenti al momento dell’inferenza.
Il meccanismo che rende praticabile il recupero delle informazioni su larga scala è il database vettoriale. Il testo (o le immagini, o l’audio) viene convertito in vettori densi, detti embedding, che collocano i contenuti semanticamente simili vicini tra loro in uno spazio ad alta dimensionalità. Strumenti come FAISS (una libreria per la ricerca efficiente di elementi simili) e servizi gestiti come Pinecone permettono a un sistema di prendere una richiesta, trasformarla in un embedding e recuperare gli elementi più vicini in quello spazio vettoriale: passaggi concettualmente legati alla richiesta anche se non contengono le stesse parole chiave.
Nel contesto di un agente o di un chatbot, questo archivio diventa una memoria a lungo termine: le conversazioni passate, le preferenze degli utenti o i documenti vengono trasformati in embedding e indicizzati una sola volta, e a ogni turno vengono recuperati e inseriti nel prompt soltanto i pochi elementi più pertinenti. La finestra di contesto resta piccola ed economica; la memoria effettiva può essere grande a piacere perché risiede fuori dal modello, su disco, non all’interno di una singola passata di elaborazione.
Il limite della RAG è che la sua qualità dipende interamente da quella del recupero. Se il sistema di recupero non trova il passaggio pertinente, o se la pertinenza è ambigua, il generatore non vede mai le informazioni di cui aveva bisogno: un tipo di errore diverso da quello descritto in "Lost in the Middle", ma che porta comunque il modello a comportarsi come se non sapesse qualcosa a cui tecnicamente ha accesso.
MemGPT e l’analogia con il sistema operativo
Un approccio più strutturato alla memoria degli agenti è arrivato con MemGPT (presentato nel paper del 2023 «MemGPT: Towards LLMs as Operating Systems» di Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil e Joseph E. Gonzalez), le cui idee sopravvivono oggi nel framework open source Letta. L’idea centrale di MemGPT è trattare la finestra di contesto limitata come un sistema operativo tratta la RAM fisica limitata: usa la paginazione della memoria virtuale per spostare le informazioni tra una «memoria principale» piccola e veloce (la finestra di contesto vera e propria) e uno spazio di archiviazione esterno molto più grande e lento, decidendo che cosa caricare e rimuovere tramite chiamate di funzione che il modello stesso può effettuare.
In concreto, ne risulta un’architettura di memoria a livelli: un blocco di memoria centrale che risiede direttamente nel contesto (e contiene, per esempio, un profilo e informazioni chiave sull’utente, modificabili dall’agente stesso), una memoria di richiamo che conserva l’intera cronologia delle conversazioni passate e in cui è possibile cercare, e una memoria d’archivio basata su un archivio vettoriale per le informazioni a lungo termine che non trovano posto nel contesto attivo.
L’agente decide, tramite chiamate agli strumenti, quando salvare un’informazione nella memoria a lungo termine e quando ricaricarne una perché è diventata improvvisamente rilevante. È un’impostazione sostanzialmente diversa dal semplice RAG: anziché eseguire un passaggio di recupero fisso per ogni richiesta, il modello gestisce attivamente la propria gerarchia di memoria, scegliendo che cosa tenere a portata di mano e che cosa archiviare.
Da allora Anthropic ha introdotto come funzionalità propria qualcosa di strutturalmente simile: uno strumento di memoria, disponibile in generale sulla Claude Developer Platform senza bisogno di un flag beta, che consente a Claude di scrivere informazioni in file da rileggere nelle sessioni successive. A questo si aggiunge una funzione di modifica del contesto che può eliminare i risultati degli strumenti o i blocchi di ragionamento ormai superati dal contesto di un agente attivo da tempo, quando non servono più.
Da allora è stato aggiunto, al di sotto di entrambi, un terzo livello: la compattazione, che viene eseguita sul server e riassume automaticamente la parte iniziale di una conversazione quando questa si avvicina al limite del contesto, permettendole di proseguire oltre quel limite. È in beta per Claude 4.6 e i modelli successivi, e la documentazione consiglia di abbinarla alla memoria, anziché scegliere tra le due: «la compattazione mantiene piccolo il contesto attivo senza richiedere una gestione lato client, mentre la memoria conserva le informazioni che devono sopravvivere alla sintesi». È ancora una volta l’argomento a favore dei livelli, con il passaggio di rimozione dalla memoria spostato sul server.
Anthropic ha riferito di benchmark interni in cui la combinazione delle due funzionalità ha mostrato notevoli risparmi di token e miglioramenti dell’accuratezza nei compiti agentici lunghi e articolati in più turni. OpenAI ha seguito una strada affine ma distinta sul fronte del prodotto: la memoria di ChatGPT, introdotta nel 2024 e ampliata nel corso del 2025 per fare riferimento a una cronologia delle chat più ampia, consente all’assistente di portare informazioni e preferenze da una conversazione all’altra, anche quando sono separate, senza che l’utente debba ripeterle.
Memoria a breve e a lungo termine negli agenti
Nel confronto tra questi sistemi, è utile distinguere due categorie che vengono confuse sotto l’unica parola «memoria». La memoria a breve termine, o memoria di lavoro, è tutto ciò che si trova nella finestra di contesto attiva per il compito in corso: la cache KV, la conversazione in svolgimento, i ragionamenti intermedi prodotti da un agente durante il compito. È veloce, contiene integralmente ciò che vi è stato inserito e scompare alla fine della sessione, a meno che non venga salvata esplicitamente.
La memoria a lungo termine è tutto ciò che viene conservato fuori dal modello tra una sessione e l’altra: archivi indicizzati tramite vettori, file di memoria strutturati, registrazioni delle preferenze dell’utente. È persistente, ma richiede un passaggio esplicito di scrittura (decidere che cosa valga la pena conservare) e uno di recupero (decidere che cosa sia rilevante in quel momento). Entrambi possono fallire: vengono salvate le cose sbagliate, oppure quelle giuste vengono salvate ma non ritrovate in seguito.
Per questo, nella pratica, i sistemi di memoria per agenti assomigliano sempre meno al tentativo di «dare al modello un cervello più grande» e sempre più a un problema di ingegneria dei sistemi: che cosa si scrive e dove, che cosa si ricarica e quando, che cosa si riassume e che cosa si conserva parola per parola, che cosa si elimina quando lo spazio finisce. Le architetture a livelli di MemGPT/Letta e dello strumento di memoria di Anthropic riconoscono esplicitamente che nessun livello di archiviazione — solo contesto, solo recupero o solo fine-tuning — risolve il problema da sé.
Perché cambia ciò che si può costruire
La conseguenza pratica di una soluzione al problema della memoria, anche parziale, è un cambiamento nel tipo di software di cui un LLM può realisticamente far parte. Un modello senza stato, con una finestra di contesto limitata, va bene per rispondere a domande isolate, ma è una base poco adatta per un assistente destinato a lavorare con qualcuno per settimane: o bisogna ricordargli tutto all’inizio di ogni conversazione, oppure dimentica cose che una persona troverebbe offensivo veder dimenticate.
La memoria persistente, che si basi sul recupero, sulla paginazione a livelli o su funzionalità di memoria offerte dal fornitore, permette a un agente di accumulare nel tempo informazioni su un determinato utente, progetto o codebase, anziché ripartire da zero a ogni utilizzo.
Questo cambia anche il modo di intendere la «finestra di contesto»: diventa una scelta di prodotto, non soltanto architetturale. Una finestra più ampia è una leva; un recupero migliore è un’altra; la gestione esplicita della memoria da parte del modello stesso è una terza. Nessuna sostituisce completamente le altre: il solo contesto lungo è soggetto al deterioramento dovuto alla «perdita delle informazioni al centro», per quanto poco costi; il solo recupero è limitato dalla qualità del sistema che recupera le informazioni; e la paginazione gestita dal modello dipende dalla sua capacità di giudicare che cosa conservare.
I sistemi che stanno ottenendo un’effettiva diffusione — la memoria a livelli per agenti di Letta, lo strumento di memoria di Anthropic abbinato alla modifica del contesto e alla compattazione lato server, la memoria di ChatGPT tra conversazioni diverse di OpenAI — sono quelli che combinano più di uno di questi meccanismi, anziché puntare su un’unica soluzione. Il transformer senza stato al centro non è cambiato; è cambiata la quantità di strutture che ora lo circondano per far sì che il sistema si comporti come se ricordasse.