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.
Certo, ma sono tutte toppe su una struttura stateless. E più crescono lo stato e l'insieme di informazioni da memorizzare, maggiore è il costo. Il punto è che questo è strutturale perché stiamo forzando un comportamento che non è nativo o intrinseco.
È un'obiezione legittima, ma dipende da come guardiamo l'architettura dei sistemi. Da sviluppatore, mi viene spontaneo un parallelismo con uno strumento diverso: anche un compilatore per sua natura è assolutamente stateless.
Il comportamento del compilatore non dipende dal software compilato in precedenza.
Lo stato del software che sto sviluppando risiede in un sistema di version control esterno (Git/SVN/...), non dentro i binari del compilatore.
Per ovvie questioni di prestazioni ed economia computazionale, non ricompiliamo tutto da zero a ogni singola modifica ma salviamo dei file oggetto semilavorati (.o) e nelle iterazioni successive procediamo a compilazioni incrementali o differenziali delle sole parti "nuove". Ma questi semilavorati intermedi restano fuori, non finiscono dentro il compilatore, che continua a rimanere felicemente stateless.
Nel mondo dell'AI oggi, con tecniche come la KV Cache e l'Automatic Prefix Caching ed altre che oggettivamente neppure penso di conoscere, l'ingegneria delle soluzioni AI sta facendo esattamente la stessa cosa: si "congelano" all'esterno del modello i semilavorati intermedi ricorrenti (i token già elaborati del diario) per:
1. Non dover ricominciare ogni volta da capo e non pagare il "biglietto pieno" della GPU.
2. Eseguire "fuori" (in cloud) ciò che è meno critico e meno sensibile, per poi terminare in casa l'elaborazione con modelli successivi più piccoli e specializzati, salvaguardando la privacy dei dati sensibili.
Dal mio punto di vista, questo non è un "forzare un comportamento con delle toppe", ma è una classica sana questione ingegneristica applicata a un nuovo paradigma.
Abbiamo sempre costruito sistemi complessi e deterministici orchestrando componenti atomici e privi di stato. La sfida strutturale c'è ed è enorme (e per certi versi per fortuna, dato che ci lavoro), ma l'approccio architetturale per risolverla è lo stesso che usiamo con successo da decine d'anni.
Ma su questo mi trovi d'accordo al 100%! Il paragone con la blockchain è azzeccatissimo: per anni abbiamo visto usare un database distribuito, costoso e lento per fare cose che un banalissimo database relazionale centralizzato faceva meglio, in un millesimo di secondo e a costo zero. Chi propone l'AI per sostituire un workflow transazionale deterministico (tipo un sistema di fatturazione o un gestionale per il magazzino) sta prendendo esattamente lo stesso abbaglio.
Il punto che volevo sottolineare con il parallelismo del compilatore (che a differenza degli LLM sì, è sostanzialmente deterministico) è che l'ottimizzazione infrastrutturale (vLLM, caching, routing) non nasce per l'hype di "far fare all'LLM tutto", ma per pragmatismo economico: serve a rendere sostenibili quei (pochi ???) casi d'uso dove l'apporto probabilistico/semantico dell'LLM serve davvero ed ha un forte valore aggiunto, ma dove prima i costi di contesto erano proibitivi.
La vera maturità ingegneristica secondo me sta proprio nel capire il confine: usare l'AI come "motore di trasformazione testo/semantica" (pur accettando che non sia deterministico, ma neppure il linguaggio umano lo è) dove serve flessibilità, e lasciar gestire lo stato, il determinismo e il workflow ai sistemi tradizionali che costano un milionesimo e non sbagliano un colpo. Se un'architettura enterprise non parte da questo bilancio economico, ha già fallito in partenza.
“L'assenza di memoria è costitutiva, intrinseca e non certo un bug da correggere in una versione futura.” credo invece che stiano lavorando per superare questo limite.
Però la scommessa sui prossimi modelli (penso ai sistemi ad agenti o alle architetture ibride che integrano memoria a lungo termine vettoriale o logica simbolica) punta proprio a superare questo limite strutturale del Transformer puro. Se l'obiettivo industriale è l'affidabilità, la direzione sembra obbligata: passare dalla pura statistica alla gestione strutturata della conoscenza persistente. Altrimenti l'AI rimarrà un eterno, formidabile generatore di risposte al presente.
La domanda finale (ne vale la pena?) ha una risposta sempre più incerta. Il costo dei token sta aumentando, non diminuendo come proiettato, tanti strumenti con licenza a "seat" ora stanno passando a "consumo". GitHub Copilot dal 1 Giugno implementa questo switch e la stima iniziale per un team come il mio é un cost increase del 100%, sento altri CTO e per i loro team rappresenta un uplift del 200-300-400% di increase. A un certo punto si arriva a livelli dove "ne vale la pena" solo se lo si fa per amore come nel caso di Henry.
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.
Certo, ma sono tutte toppe su una struttura stateless. E più crescono lo stato e l'insieme di informazioni da memorizzare, maggiore è il costo. Il punto è che questo è strutturale perché stiamo forzando un comportamento che non è nativo o intrinseco.
È un'obiezione legittima, ma dipende da come guardiamo l'architettura dei sistemi. Da sviluppatore, mi viene spontaneo un parallelismo con uno strumento diverso: anche un compilatore per sua natura è assolutamente stateless.
Il comportamento del compilatore non dipende dal software compilato in precedenza.
Lo stato del software che sto sviluppando risiede in un sistema di version control esterno (Git/SVN/...), non dentro i binari del compilatore.
Per ovvie questioni di prestazioni ed economia computazionale, non ricompiliamo tutto da zero a ogni singola modifica ma salviamo dei file oggetto semilavorati (.o) e nelle iterazioni successive procediamo a compilazioni incrementali o differenziali delle sole parti "nuove". Ma questi semilavorati intermedi restano fuori, non finiscono dentro il compilatore, che continua a rimanere felicemente stateless.
Nel mondo dell'AI oggi, con tecniche come la KV Cache e l'Automatic Prefix Caching ed altre che oggettivamente neppure penso di conoscere, l'ingegneria delle soluzioni AI sta facendo esattamente la stessa cosa: si "congelano" all'esterno del modello i semilavorati intermedi ricorrenti (i token già elaborati del diario) per:
1. Non dover ricominciare ogni volta da capo e non pagare il "biglietto pieno" della GPU.
2. Eseguire "fuori" (in cloud) ciò che è meno critico e meno sensibile, per poi terminare in casa l'elaborazione con modelli successivi più piccoli e specializzati, salvaguardando la privacy dei dati sensibili.
Dal mio punto di vista, questo non è un "forzare un comportamento con delle toppe", ma è una classica sana questione ingegneristica applicata a un nuovo paradigma.
Abbiamo sempre costruito sistemi complessi e deterministici orchestrando componenti atomici e privi di stato. La sfida strutturale c'è ed è enorme (e per certi versi per fortuna, dato che ci lavoro), ma l'approccio architetturale per risolverla è lo stesso che usiamo con successo da decine d'anni.
Tutto si può fare. A quali costi? É efficiente ed economico? É il modo migliore per farlo? In quali casi applicativi? Di tutto questo non si parla.
Se poi vuoi dire che la soluzione é un approccio ibrido tipo headless 360 sono d’accordo.
Alla blockchain si voleva far fare qualunque cosa. Alla fine c’è quasi sempre una soluzione che funziona meglio e costa meno.
Ma su questo mi trovi d'accordo al 100%! Il paragone con la blockchain è azzeccatissimo: per anni abbiamo visto usare un database distribuito, costoso e lento per fare cose che un banalissimo database relazionale centralizzato faceva meglio, in un millesimo di secondo e a costo zero. Chi propone l'AI per sostituire un workflow transazionale deterministico (tipo un sistema di fatturazione o un gestionale per il magazzino) sta prendendo esattamente lo stesso abbaglio.
Il punto che volevo sottolineare con il parallelismo del compilatore (che a differenza degli LLM sì, è sostanzialmente deterministico) è che l'ottimizzazione infrastrutturale (vLLM, caching, routing) non nasce per l'hype di "far fare all'LLM tutto", ma per pragmatismo economico: serve a rendere sostenibili quei (pochi ???) casi d'uso dove l'apporto probabilistico/semantico dell'LLM serve davvero ed ha un forte valore aggiunto, ma dove prima i costi di contesto erano proibitivi.
La vera maturità ingegneristica secondo me sta proprio nel capire il confine: usare l'AI come "motore di trasformazione testo/semantica" (pur accettando che non sia deterministico, ma neppure il linguaggio umano lo è) dove serve flessibilità, e lasciar gestire lo stato, il determinismo e il workflow ai sistemi tradizionali che costano un milionesimo e non sbagliano un colpo. Se un'architettura enterprise non parte da questo bilancio economico, ha già fallito in partenza.
“L'assenza di memoria è costitutiva, intrinseca e non certo un bug da correggere in una versione futura.” credo invece che stiano lavorando per superare questo limite.
Nel modello transformer? Che si reifichi lo stato certamente. Lo faccio anche io. Ma é un’altra cosa.
Però la scommessa sui prossimi modelli (penso ai sistemi ad agenti o alle architetture ibride che integrano memoria a lungo termine vettoriale o logica simbolica) punta proprio a superare questo limite strutturale del Transformer puro. Se l'obiettivo industriale è l'affidabilità, la direzione sembra obbligata: passare dalla pura statistica alla gestione strutturata della conoscenza persistente. Altrimenti l'AI rimarrà un eterno, formidabile generatore di risposte al presente.
Non deve convincermi. Ma io guardo la struttura dei modelli di oggi e quel che si fa facendo. Per questo (come altri) sono critico.
La domanda finale (ne vale la pena?) ha una risposta sempre più incerta. Il costo dei token sta aumentando, non diminuendo come proiettato, tanti strumenti con licenza a "seat" ora stanno passando a "consumo". GitHub Copilot dal 1 Giugno implementa questo switch e la stima iniziale per un team come il mio é un cost increase del 100%, sento altri CTO e per i loro team rappresenta un uplift del 200-300-400% di increase. A un certo punto si arriva a livelli dove "ne vale la pena" solo se lo si fa per amore come nel caso di Henry.
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.