Approfondimenti tecnici

Il problema della memoria: perché i sistemi di IA dimenticano e come la memoria persistente cambia tutto

I transformer non conservano uno stato tra una chiamata e l’altra. Perciò tutto ciò che viene chiamato memoria dell’IA è un’impalcatura aggiunta: cache KV, finestre da un milione di token ormai per lo più fatturate a tariffe standard, recup

AI.info Team · 2026-09-03

L’architettura è progettata per non avere memoria

Durante l’inferenza, un transformer è una funzione pura. Gli si fornisce una sequenza di token e restituisce una distribuzione di probabilità sul token successivo. Se lo si chiama di nuovo con lo stesso input, si ottiene lo stesso output. Nulla persiste tra una chiamata e l’altra, a meno di inserirlo nell’input. Non è un difetto 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.) fu costruito per trasformare sequenze in sequenze usando la self-attention, non per accumulare uno stato tra invocazioni indipendenti. Ogni modello linguistico di grandi dimensioni basato su transformer da allora — GPT, Claude, Gemini, Llama — eredita questa caratteristica. Se si pone una domanda a ChatGPT lunedì e la si ripete martedì, in assenza di una funzione di memoria esplicita aggiunta al modello, questo non ha idea che lunedì sia mai esistito.

In ambito ingegneristico, questa assenza di stato ha una conseguenza pratica: la finestra di contesto è l’intero mondo che il modello può vedere. Ciò che non è 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 tuo nome, un agente che ricorda una decisione presa tre passaggi prima, un assistente alla programmazione che segue un refactoring nel corso di una sessione — è in realtà una soluzione ingegneristica aggiunta a un sistema che dimentica tutto non appena termina il passaggio in avanti.

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 decodifica autoregressiva usa una cache KV: man mano che ogni token viene elaborato, il modello conserva i vettori di chiave e valore calcolati dai suoi livelli di attenzione e li riutilizza per ogni token successivo, anziché ricalcolarli. Questo trasforma la generazione da un problema a tempo quadratico in qualcosa di più vicino a un tempo lineare per ogni nuovo token. È 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 persistente in alcun senso. Cresce con ogni token nel contesto, domina l’uso della memoria della GPU quando si gestiscono richieste con contesti lunghi e può essere eliminata al termine della sessione, anche se la cache dei prompt può conservarla per riutilizzarla tra richieste diverse. È più corretto considerarla uno spazio di lavoro volatile che rende efficiente un singolo calcolo privo di stato, non un meccanismo per conservare informazioni tra sessioni.

La distinzione è importante 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, la cache KV e il prompt che si allunga stanno svolgendo il loro compito all’interno di un unico contesto delimitato. Il secondo richiede un’infrastruttura completamente diversa, che scriva le informazioni da qualche parte fuori dal 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 stessi termini, ha funzionato. Gemini 1.5 Pro di Google, presentato nel febbraio 2024, è stato il modello che ha reso comune una finestra da 1 milione di token. Da allora è scomparso del tutto dalla documentazione sui modelli di Google, soppiantato dalle linee Gemini 2.5 e Gemini 3. La finestra da un milione di token è sopravvissuta al modello che l’aveva annunciata.

Oggi è un’impostazione predefinita, non più un titolo di richiamo. 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, e afferma esplicitamente 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 afferma che i modelli Claude 4.6 e successivi, a eccezione di Claude Haiku 5.5, includono l’intera finestra da 1M token alla tariffa standard: una richiesta da 900k token viene fatturata alla stessa tariffa per token di una da 9k token. Gli sconti per la cache dei prompt e per l’elaborazione batch si applicano all’intera finestra. L’attenzione continua a operare su ogni token inviato, quindi la latenza aumenta con la lunghezza del prompt, ma il sovrapprezzo esplicito per i contesti lunghi non è più l’ostacolo.

Se bastasse un contesto economico, il problema della memoria sarebbe risolto. Non lo è, per una ragione che nessun listino può eliminare: la presenza di un token 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 messo alla prova i modelli linguistici con compiti che richiedevano di trovare informazioni pertinenti tra una serie di documenti o coppie chiave-valore, variando sistematicamente la posizione dell’elemento rilevante nell’input.

Il risultato è stato una caratteristica curva di rendimento a U: i modelli recuperano meglio le informazioni che si trovano proprio all’inizio o alla fine di un contesto lungo, mentre il rendimento peggiora sensibilmente quando l’informazione necessaria si trova nel mezzo, scendendo talvolta sotto quello di un modello a cui non è stato fornito alcun documento pertinente.

Questa conclusione è stata rafforzata dalla metodologia di valutazione dell’«ago nel pagliaio», un approccio reso popolare da Greg Kamradt alla fine del 2023: un fatto specifico (l’«ago») viene nascosto a profondità diverse in un grande blocco di testo riempitivo (il «pagliaio») e al modello viene chiesto di recuperarlo. Riportando il tasso di successo in funzione sia della lunghezza del contesto sia della profondità a cui è inserito il fatto, si ottiene una mappa di calore che mostra esattamente dove la capacità del modello di richiamare informazioni 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 richiamare informazioni 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 sta dicendo ai clienti di non riempirla indiscriminatamente.

Per chiunque sviluppi sistemi basati su questi modelli, la conseguenza è questa: il fatto che un modello pubblicizzi una finestra da un milione di token non garantisce che usi tutti quei token con la stessa efficacia. I benchmark che misurano specificamente la capacità effettiva di richiamare informazioni da contesti lunghi, anziché la semplice accettazione di token, riscontrano regolarmente che il contesto utilizzabile nella pratica è una frazione di quello pubblicizzato. Una finestra più ampia cambia ciò che un modello può tecnicamente ricevere in input; da sola, non cambia l’affidabilità con cui ragiona su tutto ciò che contiene.

Il recupero come sistema di memoria esterna

Se inserire tutto nel contesto è costoso e inaffidabile, l’alternativa è non inserirvi tutto, ma recuperare su richiesta soltanto ciò che serve. È l’idea alla base della generazione aumentata dal recupero, introdotta in «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» da Patrick Lewis e coautori di Facebook AI Research nel 2020. La RAG abbina un sistema di recupero, che cerca in un corpus esterno i passaggi pertinenti a una query, a un generatore che produce il proprio output sulla base sia della query sia dei passaggi recuperati. Invece di affidarsi a un insieme fisso di fatti incorporati nei pesi del modello durante l’addestramento, il modello consulta un archivio di documenti al momento dell’inferenza.

Uno dei meccanismi che rendono praticabile il recupero su larga scala è il database vettoriale. Il testo (o le immagini, o l’audio) viene convertito in vettori di embedding densi, 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 consentono a un sistema di prendere una query, convertirla in un embedding e recuperare i vicini più prossimi in quello spazio vettoriale: passaggi concettualmente legati alla query anche se non contengono esattamente le stesse parole chiave.

Nel contesto di un agente o di un chatbot, questo diventa un archivio di memoria a lungo termine: conversazioni passate, preferenze degli utenti o documenti vengono convertiti in embedding e indicizzati una sola volta, e per ogni turno vengono recuperati e inseriti nel prompt soltanto i pochi elementi più pertinenti. La finestra di contesto rimane piccola e poco costosa; la memoria effettiva può essere arbitrariamente grande perché risiede fuori dal modello, su disco, e non all’interno di un singolo passaggio di propagazione in avanti.

Il compromesso della RAG è che la sua efficacia dipende interamente dalla qualità del recupero. Se il sistema di recupero non trova il passaggio pertinente, o se la pertinenza è ambigua, il generatore non vede mai l’informazione di cui aveva bisogno: un tipo di errore distinto dall’essere «persi nel mezzo», 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 nell’articolo del 2023 «MemGPT: Towards LLMs as Operating Systems» di Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica e Joseph E. Gonzalez), le cui idee proseguono 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 un archivio esterno molto più grande e lento, decidendo cosa caricare e cosa rimuovere attraverso chiamate a funzioni che il modello stesso può effettuare.

In concreto, ne risulta un’architettura di memoria a livelli: un blocco di memoria centrale che si trova direttamente nel contesto (e contiene, per esempio, il profilo dell’agente (la sua «persona») e informazioni fondamentali 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 affatto posto nel contesto attivo.

L’agente decide, attraverso chiamate agli strumenti, quando scrivere un’informazione nell’archivio a lungo termine e quando recuperare qualcosa perché è diventato improvvisamente pertinente. È un’impostazione sostanzialmente diversa dal semplice RAG: anziché avere una fase di recupero fissa associata a ogni richiesta, il modello gestisce attivamente la propria gerarchia di memoria, scegliendo cosa tenere a portata di mano e cosa archiviare.

Da allora Anthropic ha reso disponibile una funzione proprietaria dalla struttura simile: uno strumento di memoria, disponibile in generale sulla Claude Developer Platform senza bisogno di attivare un’opzione beta, che consente a Claude di scrivere informazioni in file che potrà rileggere nelle sessioni successive. A questo si aggiunge una funzione di modifica del contesto, capace di eliminare dal contesto di un agente attivo da tempo i risultati degli strumenti o i blocchi di ragionamento ormai superati.

Da allora è stato aggiunto un terzo livello, sottostante a entrambi: la compattazione, che viene eseguita sul server e riassume automaticamente la parte precedente di una conversazione quando questa si avvicina al limite del contesto, consentendole di proseguire oltre. È in beta per Claude 4.6 e i modelli successivi, e la documentazione consiglia di abbinarla alla memoria invece di scegliere tra le due: «la compattazione mantiene ridotto il contesto attivo senza richiedere la gestione del contesto lato client, e la memoria conserva le informazioni che devono sopravvivere alla sintesi». È ancora una volta la logica dei livelli, con il passaggio di rimozione dal contesto spostato sul server.

Anthropic ha comunicato i risultati di benchmark interni che mostrano miglioramenti delle prestazioni combinando memoria e modifica del contesto, oltre a un notevole risparmio di token grazie alla modifica del contesto. OpenAI ha sviluppato una funzione 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, permettendo all’assistente di conservare informazioni e preferenze tra conversazioni altrimenti separate, senza che l’utente debba ripeterle.

Memoria a breve e a lungo termine negli agenti

Per esaminare questi sistemi è utile distinguere due categorie che vengono confuse sotto un’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 corrente: la cache KV, la conversazione in corso, i ragionamenti intermedi che un agente produce durante il compito. È veloce, contiene per intero ciò che vi è memorizzato e scompare alla fine della sessione, a meno che non venga salvata esplicitamente.

La memoria a lungo termine comprende 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 cosa valga la pena conservare) e uno di recupero (decidere cosa sia pertinente in quel momento). Entrambi sono potenziali punti di errore: si salvano le cose sbagliate, oppure si salvano quelle giuste ma poi non le si ritrova.

Per questo i sistemi pratici di memoria degli agenti somigliano sempre meno al tentativo di «dare al modello un cervello più grande» e sempre più a un problema di ingegneria dei sistemi: cosa viene scritto e dove, cosa viene recuperato e quando, cosa viene riassunto e cosa conservato parola per parola, cosa viene eliminato quando lo spazio finisce. Le architetture a livelli di MemGPT/Letta e dello strumento di memoria di Anthropic riconoscono esplicitamente che nessun singolo livello di archiviazione — solo contesto, solo recupero, solo fine-tuning — risolve il problema da sé.

Perché questo cambia ciò che si può costruire

La conseguenza pratica di risolvere il problema della memoria, anche solo in parte, è un cambiamento nel tipo di software di cui un LLM può realisticamente fare parte. Un modello senza stato, con una finestra di contesto limitata, va bene per rispondere a domande isolate, ma è una base poco adatta a un assistente destinato a lavorare con una persona per settimane: o bisogna ricordargli tutto all’inizio di ogni conversazione, oppure dimentica cose la cui dimenticanza una persona troverebbe offensiva.

La memoria persistente, che si basi sul recupero, sulla paginazione a livelli o su funzioni di memoria offerte dal fornitore, è ciò che permette a un agente di accumulare nel tempo informazioni su un determinato utente, progetto o codebase, anziché ripartire da zero a ogni utilizzo.

Cambia anche il modo di intendere la «finestra di contesto»: non più una questione puramente architetturale, ma una scelta di prodotto. 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 contesto lungo, da solo, va incontro al degrado noto come «lost in the middle», per quanto basso sia il suo costo; il solo recupero è limitato dalla qualità del sistema di recupero; e la paginazione gestita dal modello stesso dipende dalla sua capacità di giudicare bene cosa conservare.

I sistemi che stanno ottenendo un’adozione concreta — la memoria a livelli degli agenti di Letta, lo strumento di memoria di Anthropic abbinato alla modifica del contesto e alla compattazione sul server, la memoria di ChatGPT di OpenAI che opera tra conversazioni diverse — sono quelli che combinano più di uno di questi meccanismi, anziché puntare su un’unica soluzione. Il transformer senza stato al centro non è cambiato; a cambiare è la quantità di infrastruttura che ora lo circonda per far sì che il sistema si comporti come se ricordasse.