L'AI che non ricorda
Drew Barrymore, Adam Sandler e il diario che dobbiamo tenere noi per lavorare con GenAI.
Quarto intervento su un tema che ho già toccato in “L’agente che non sa perché” (2 aprile), “Quando il computer indovina e quando calcola” (4 aprile) e “‘Per un martello, il mondo è fatto solo di chiodi’” (11 aprile). Questa volta provo a guardare la radice — l’architettura.
C’è un film del 2004 di Peter Segal, 50 First Dates, che da noi è uscito col titolo 50 volte il primo bacio. Adam Sandler si innamora di Drew Barrymore, ma lei ha un trauma cerebrale: ogni notte, mentre dorme, la memoria di tutto ciò che è successo durante il giorno si cancella. Henry — Adam Sandler — capisce che esiste un modo per costruire comunque una relazione. Le registra su VHS un diario quotidiano in cui le racconta chi è lui, come si sono conosciuti e che cosa hanno vissuto insieme. Ogni mattina Lucy lo guarda e, in qualche modo, ricostruisce la sua vita.
Da quando uso quotidianamente i Large Language Model per il mio lavoro, mi ritrovo a fare la stessa cosa. Ogni nuova sessione comincia con un’operazione di ricostruzione: un file .md con il contesto, le skill che descrivono ciò che stiamo facendo e le istruzioni globali per ricordare al modello chi sono e quali sono le mie convenzioni. È diventato un riflesso. E somiglia al diario di Henry.
Una macchina senza stato che scommette
Per andare oltre l'immagine letteraria, è necessario ricordare due questioni tecniche, senza le quali la somiglianza non illumina il problema.
La prima: i transformer (l’architettura su cui si basano tutti gli LLM moderni) sono nati nel 2017 con un mandato preciso, descritto da Vaswani e colleghi nel paper “Attention Is All You Need” [1]. Servono a tradurre, cioè a trasformare una sequenza di input in una di output. Sono una funzione senza memoria: input → output. Non c’è uno stato interno che persiste tra una chiamata e l’altra. Quella che chiamiamo “conversazione” è un’illusione, fabbricata reinviando l'intero storico a ogni nuova chiamata. Uno storico che cresce a ogni interazione, rendendo ogni chiamata sempre più complessa e costosa dal punto di vista computazionale ed economico. Atlan, in un articolo recente sul problema della memoria negli agenti AI, lo dice in modo nitido:
Statelessness is a deliberate trade-off that enables scale and reproducibility. All continuity, including session history, organisational knowledge, and user preferences, must be built externally and injected at runtime [2].
L'assenza di memoria è costitutiva, intrinseca e non certo un bug da correggere in una versione futura.
La seconda: il modello non risponde, scommette. Matt Calkins, CEO di Appian, lo ha riassunto sul Wall Street Journal con una formula che vale la pena ricordare:
AI is probabilistic technology, which means it’s slightly unpredictable. Underneath the surface, it is constantly guessing. This is an immutable characteristic of large language models [3].
Anche qui: caratteristica immutabile, non un difetto in attesa di una patch.
Mettiamo insieme le due cose. L’LLM è una macchina senza stato che scommette. Tutto l’apparato che gli costruiamo intorno (RAG, agenti con memoria esterna, context engineering, skill, file di configurazione, Model Context Protocol) esiste per reificare proprietà che il modello, nella sua architettura nuda, non possiede.
Il martello e i chiodi, di nuovo
Qui torno su un tema che ho già trattato in “Per un martello, il mondo è fatto solo di chiodi”. La legge dello strumento ci spinge a considerare l’AI generativa come la risposta a ogni domanda. Quando il problema è integrare l’AI in un processo operativo aziendale — un workflow di approvazione, un sistema transazionale, una procedura amministrativa — la tentazione è di prendere il martello e cercare chiodi ovunque.
Ma i processi operativi che hanno sostenuto l’IT degli ultimi quarant’anni poggiano su tre assunzioni implicite:
Lo stato persiste.
Il comportamento è deterministico.
Il sistema è riproducibile e auditabile.
Tre proprietà che consentono di certificare, controllare, eseguire test di regressione e ricostruire chi ha deciso cosa e perché. Gli LLM violano tutte e tre per design. L’immaturità del prodotto non c’entra: conta la natura dell’architettura.
Pretendere di usare un LLM come componente di un workflow di questo tipo è la versione 2026 della legge dello strumento. Si ha in mano un martello potente, capace di fare cose che nessun altro strumento aveva mai saputo fare, e si cominciano a vedere chiodi ovunque, anche dove non ce ne sono. Il transformer è nato per trasformare il testo in testo. Trattarlo come componente di un sistema transazionale significa fargli fare qualcosa per cui non è stato progettato.
E nemmeno la corsa allo scaling cambierà queste caratteristiche. I miglioramenti pratici ci sono, perché le innovazioni e le estensioni introdotte aumentano la potenza e la capacità di risolvere i problemi. Ma questo aumento di prestazioni si paga, e si paga molto: un modello di frontiera costa decine di volte più di uno più piccolo. Lo scaling sposta la soglia, ma non la cancella, perché non è in grado di cambiare ciò che il transformer è: resta senza memoria e probabilistico per sua natura. Lo scaling rende il martello più grande. Non lo trasforma in un cacciavite.
Quando il diario costa più del processo
Si può sempre rispondere che basta ricostruire lo stato esternamente, nel file system o tramite strumenti esterni. È vero. È quello che stiamo facendo tutti: io con il mio diario in file .md, le aziende con i loro context layer, gli architetti con sistemi ibridi in cui la parte deterministica e quella probabilistica si parlano.
In linea di principio funziona. Il problema si vede quando si prova a farlo davvero, non a parlarne o a fare esperimenti di laboratorio. Lo stato esterno non è passivo. Va costruito, mantenuto, validato. E deve essere gestito tramite una macchina probabilistica. La stessa che, ogni volta che legge e scrive in quello stato, può scegliere percorsi diversi a partire dallo stesso input.
L’intersezione tra questi due fattori — stato esterno persistente ed elaborazione probabilistica — fa esplodere la complessità in modi che chi non ci ha lavorato fatica a immaginare. Salgono i costi di costruzione, di manutenzione e di test. E con la riproducibilità è anche peggio: lo stesso flusso, eseguito due volte, può produrre due risultati diversi, e ricostruire il senso di quanto fatto diventa un esercizio non banale.
In molti casi, quando si tirano le somme, l'investimento non si ripaga. L'AI funziona, ma farla funzionare seriamente all'interno di un processo operativo costa più di quanto si potesse ipotizzare.
Henry continua a registrare su VHS perché ama Lucy: per lui il diario non costa più della relazione che vuole tenere viva. Per chi prova a integrare l’AI in un processo operativo serio, il calcolo risulta meno scontato. A volte il diario è più costoso e meno affidabile del processo.
Il gioco vale la candela?
Questo post è stato scritto con l'assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.
Ashish Vaswani et al., “Attention Is All You Need”, NeurIPS 2017, arXiv:1706.03762. ↩
Atlan, “Why AI Agents Forget: The Stateless LLM Problem”, 2 aprile 2026, https://atlan.com/know/why-ai-agents-forget/. ↩
Matt Calkins, “The Software Industry Will Survive AI”, Wall Street Journal, 26 febbraio 2026. ↩
© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it
Sempre lucido ed esemplificativo. In modo non continuativo ma dopo essermi arrabbiato più volte in chat anche io mi faccio fare dei doc dopo una sessione importante. Il problema è che ho una tonnellata di file e non ho il tempo di rileggerli.
Bellissimo articolo e metafora azzeccata. Dal punto di vista della natura degli LLM hai perfettamente ragione: la statelessness è una caratteristica strutturale della matematica dei Transformer. I pesi non cambiano durante l'uso.
La cosa interessante però è come la ricerca e l'industria abbiano affrontato questo limite negli ultimi due anni. Visto che non possiamo cambiare i pesi del modello in tempo reale (e anche ammesso si potesse fare, comunque non avrebbe senso per questioni di costi e scalabilità), si è passati dal concetto di "modello isolato" a quello di "sistema agentico".
In pratica, quel file .md che apri ogni mattina, le architetture attuali iniziano a gestirlo in background in modo automatico e trasparente per l'utente. Framework di memoria a lungo termine (un'ottima rassegna recente è il paper di Tang et al., 2026, "LLM Agent Memory: A Survey from a Unified Representation–Management Perspective", qui: https://www.preprints.org/manuscript/202603.0359 o i lavori sui Knowledge Graphs applicati ai memory database) estraggono i fatti salienti dalle chat passate (tue, o in certi ambiti e con certe logiche anche dei colleghi per non riscoprire l'acqua calda ogni volta) e li "iniettano" nel contesto in modo dinamico.
Anche lato infrastrutturale (penso a strumenti enterprise come vLLM), il problema di non dover ricalcolare quel "diario" ogni volta è stato ottimizzato con tecniche come l'Automatic Prefix Caching, che "congela" la memoria dei prompt ricorrenti (la KV Cache) sulla GPU per abbattere tempi e costi. O il semantic routing, che ti permette di indirizzare parte della query al modello più conveniente: ad esempio quello generico in cloud per "sgrossare" il problema, e successivamente quello piccolo, ma alimentato da conoscenza di dominio privata, all'interno del datacenter aziendale o addirittura edge. Non è per far pubblicità alle soluzioni dell'azienda per cui lavoro, quanto per sottolineare che sia un tema caldissimo su cui l'industria sta spingendo forte proprio per mitigare quei costi architetturali che giustamente evidenzi nel post.
Insomma, l'AI continua a non avere memoria nel senso biologico, ma i sistemi che le costruiamo attorno stanno automatizzando quel diario quotidiano, rendendo l'illusione della memoria incredibilmente stabile, concreta e utile per i flussi di lavoro complessi.