LLM e memoria persistente: come Google e OpenAI stanno risolvendo il problema del contesto

Google presenta Context Engineering e l'architettura Titans per la memoria a lungo termine, mentre OpenAI implementa la funzione Memory in ChatGPT. Le sfide te…

Contenuto

LLM e memoria persistente: come Google e OpenAI stanno risolvendo il problema del contesto

Scopri anche

LLM e memoria persistente: come Google e OpenAI stanno risolvendo il problema del contesto

LLM e memoria persistente: come Google e OpenAI stanno risolvendo il problema del contesto

In questo articolo:

I modelli di linguaggio di grandi dimensionzioni (LLM) presentano una limitazione strutturale: ogni richiesta viene elaborata in isolamento, senza memoria delle interazioni precedenti. Google definisce questo il "goldfish problem", riferendosi all'incapacità dei modelli di mantenere il contesto tra una conversazione e l'altra. Due approcci stanno emergendo per risolvere questa carenza: da un lato, Google ha pubblicato un whitepaper di 70 pagine su Context Engineering insieme all'architettura Titans; dall'altro, OpenAI ha implementato la funzione Memory in ChatGPT (esclusa temporaneamente da Europa e Regno Unito).

Il problema del contesto isolato

⬆ Torna su

Senza un meccanismo di contesto appropriato, ogni richiesta a un LLM viene processata indipendentemente. Questo significa che preferenze, progetti in corso, dettagli personali devono essere ripetuti a ogni nuova interazione. La documentazione di Google indica che un contesto ben ingegnerizzato riduce le allucinazioni, migliora l'accuratezza fattuale e consente risposte personalizzate. La sfida consiste nel far rientrare tutte le informazioni rilevanti entro i limiti di token mantenendo la coerenza.

Il Context Engineering risolve questo problema assemblando dinamicamente le informazioni necessarie al momento della richiesta. Le fonti di contesto includono istruzioni, cronologia conversazionale, memoria e RAG (Retrieval-Augmented Generation). L'assemblaggio del contesto avviene prima che l'LLM generi la risposta, e la risposta stessa può aggiornare la cronologia e la memoria.

Sessioni: il contenitore della conversazione

⬆ Torna su

Una sessione rappresenta il contenitore per una singola conversazione tra utente e agente. La documentazione di Google specifica che le sessioni sono limitate a un singolo utente e un singolo thread conversazionale. Quando l'utente inizia una nuova conversazione, inizia una nuova sessione. Le sessioni sono tipicamente volatili: esistono solo per la durata dell'interazione.

All'interno di una sessione, gli eventi costituiscono le unità atomiche della cronologia conversazionale. Ogni evento cattura il messaggio dell'utente, la risposta dell'agente, le chiamate agli strumenti e i risultati. Gli eventi sono di sola append: una volta registrati, formano un log immutabile del flusso conversazionale. Questo log diventa il componente "cronologia conversazionale" della finestra di contesto.

Lo stato (state) fornisce un archivio key-value per la memoria di lavoro all'interno di una sessione. A differenza degli eventi, lo stato è mutabile: i valori possono essere aggiornati man mano che la conversazione progredisce. Lo stato è accessibile agli strumenti, consentendo loro di leggere il contesto e scrivere risultati che persistono tra un turno e l'altro.

Memoria: persistenza cross-conversazione

⬆ Torna su

Se le sessioni gestiscono il contesto all'interno della conversazione, la memoria gestisce la persistenza tra conversazioni diverse. La memoria risponde alla domanda: "Cosa dovrebbe ricordare l'agente di questo utente dopo che la conversazione è terminata?"

Google distingue tra memoria dichiarativa e procedurale. La memoria dichiarativa memorizza ciò che l'agente sa (fatti, preferenze, informazioni sull'utente). La memoria procedurale memorizza come l'agente dovrebbe comportarsi (pattern di risposta, stili comunicativi). Entrambe vengono estratte dalla cronologia conversazionale e raffinate nel tempo.

La generazione della memoria segue un pattern ETL: Extract (estrazione di fatti dalle sessioni), Transform (consolidamento tramite unione e deduplicazione), Load (caricamento in storage per il recupero). L'LLM identifica le informazioni degne di essere ricordate durante le sessioni, estraendo segnali piuttosto che tutto il contenuto.

L'architettura Titans di Google

⬆ Torna su

L'architettura Titans, sviluppata dai ricercatori di Google, affronta il problema della memoria a lungo termine nei Transformer tradizionali. L'architettura classica usa il meccanismo di self-attention per calcolare le relazioni tra tutte le coppie di token. Sebbene preciso, i costi computazionali e di memoria aumentano quadraticamente con la lunghezza della sequenza di input.

Titans introduce un modulo di "memoria neurale a lungo termine" che complementa i layer di attention. Il componente chiave è una memoria che impara una funzione per memorizzare nuovi fatti durante l'inferenza. Questo meccanismo può adattarsi dinamicamente man mano che i dati incontrati cambiano, consentendo la generalizzazione a diversi pattern di dati.

Il modello Titans ha tre componenti principali: il modulo "core", che funge da memoria a breve termine e usa il meccanismo di attention classico per processare il segmento corrente di token; il modulo "memoria a lungo termine", che usa l'architettura di memoria neurale per memorizzare informazioni oltre il contesto corrente; e il modulo "memoria persistente", i parametri apprendibili che rimangono fissi dopo il training e memorizzano conoscenza indipendente dal tempo.

Il meccanismo della "sorpresa"

⬆ Torna su

Il modulo di memoria neurale usa un concetto di "sorpresa" per decidere quali informazioni memorizzare. Confronta i nuovi token con i dati precedentemente visti e memorizza i dati molto diversi (cioè sorprendenti) rispetto alla conoscenza esistente. Questo consente al modulo di usare la memoria in modo efficiente, immagazzinando dati che aggiungono informazioni utili a ciò che il modello già sa.

Per gestire sequenze di dati molto lunghe, il modulo ha un meccanismo di forgetting adattivo che rimuove le informazioni non più necessarie, aiutando a gestire la capacità limitata della memoria. Gli esperimenti su modelli da 170 milioni a 760 milioni di parametri mostrano che Titans supera i Transformer classici, Mamba e modelli ibridi come Samba.

La differenza di prestazioni è particolarmente pronunciata in task su sequenze lunghe, come i test "needle in a haystack" e BABILong, dove il modello deve ragionare su fatti distribuiti in documenti molto lunghi. Titans ha superato modelli con ordini di grandezza più parametri, inclusi GPT-4 e GPT-4o-mini, e un modello Llama-3 migliorato con RAG. L'architettura è scalabile fino a 2 milioni di token mantenendo i costi di memoria a un livello contenuto.

ChatGPT Memory: l'implementazione di OpenAI

⬆ Torna su

OpenAI ha attivato la funzione Memory in ChatGPT (esclusa Europa, Regno Unito e alcuni altri paesi). A differenza della cronologia delle chat, che mantiene conversazioni separate, Memory crea un modello persistente per l'utente attraverso tutte le interazioni. Il sistema non memorizza letteralmente ogni parola scambiata, ma crea sintesi e riassunti delle informazioni più rilevanti, costruendo gradualmente una comprensione dell'utente.

La funzione è opzionale e può essere disattivata, consentendo agli utenti di controllare quali informazioni l'IA dovrebbe ricordare o dimenticare. Tuttavia, con migliaia di conversazioni accumulate, diventa difficile sapere quali mantenere e quali eliminare. La documentazione osserva che la memoria artificiale non funzionerà come la memoria umana: crea riassunti e sintesi basati su pattern ricorrenti secondo criteri noti solo agli algoritmi di OpenAI.

Il pattern Memory-as-a-Tool

⬆ Torna su

Invece di iniettare automaticamente le memorie nel contesto, il pattern Memory-as-a-Tool dà all'agente un controllo esplicito. L'agente decide quando ricordare e quando recuperare informazioni. Google fornisce strumenti come LoadMemoryTool e SaveMemoryTool che permettono all'agente di recuperare preferenze utente e interazioni passate, o di memorizzare informazioni importanti per uso futuro.

I vantaggi di questo pattern includono autonomia dell'agente, auditability (tracciabilità di ciò che viene ricordato), efficienza (nessuna iniezione automatica di memorie irrilevanti) e controllo utente. Il compromesso è una complessità aumentata: l'agente deve imparare quando usare gli strumenti di memoria, richiedendo un buon prompting o fine-tuning.

Gestione conflitti e affidabilità

⬆ Torna su

Non tutte le memorie hanno la stessa affidabilità. Google introduce il tracciamento della provenienza: registrare da dove proviene ogni memoria e quanto dovremmo fidarci. Quando le memorie sono in conflitto, le fonti con maggiore affidabilità sovrastanno quelle con minore affidabilità. Se un utente dichiara esplicitamente un cambiamento ("ora mangio carne"), questo sovrascrive i pattern precedenti osservati.

I punteggi di confidence quantificano l'affidabilità. Una memoria con confidence 0.9 potrebbe essere inclusa nel contesto, mentre memorie con confidence 0.3 potrebbero essere trattenute a meno che non siano specificamente rilevanti. La provenienza traccia l'origine delle informazioni: dichiarazione esplicita dell'utente (massima attendibilità), inferenza da comportamento (media), inferenza da singolo evento (bassa).

Compattazione della cronologia

⬆ Torna su

Man mano che le conversazioni crescono, il log degli eventi può superare i limiti della finestra di contesto. La compattazione riduce la dimensione della cronologia preservando le informazioni essenziali. Google identifica tre strategie principali: troncamento (rimuove gli eventi più vecchi, alta perdita di informazioni, basso costo e latenza), keep-last-N (mantiene gli N eventi più recenti, perdita media), e summarization ricorsiva (l'LLM genera un riassunto preservando i fatti chiave, bassa perdita ma alto costo computazionale).

Il whitepaper raccomanda approcci ibridi: usare il troncamento per la riduzione iniziale, poi la summarization per preservare il contenuto semantico degli eventi scartati. La scelta dipende dal caso d'uso: query semplici possono tollerare il troncamento, mentre sessioni lunghe beneficiano della summarization.

RAG e Memoria: approcci complementari

⬆ Torna su

Una domanda comune è se usare RAG o Memoria per la personalizzazione. La risposta: entrambi, per scopi diversi. RAG fornisce competenza di dominio da documenti esterni e knowledge base. Risponde a domande come "Qual è la politica di reso?" Memoria fornisce competenza sull'utente dalla cronologia delle interazioni. Risponde a domande come "Questo utente preferisce email o chat?"

La documentazione di Google specifica che un agente di supporto usa RAG per trovare la politica di reso, poi usa la Memoria per sapere che l'utente preferisce punti elenco concisi piuttosto che paragrafi. I due sistemi lavorano insieme: RAG risponde alle domande di dominio, la Memoria personalizza le risposte.

Applicazioni settoriali

⬆ Torna su

Nel customer support, i chatbot AI possono memorizzare e recuperare dettagli specifici dell'utente come cronologia degli acquisti o reclami precedenti, eliminando la necessità per i clienti di ripetere informazioni. In sanità, i sistemi AI con memoria possono conservare record dettagliati dei pazienti, incluse sintomi, piani di trattamento e risultati dei test, garantendo continuità delle cure.

Nell'educazione, i sistemi di tutoring AI possono mantenere la cronologia di apprendimento dello studente, includendo progressi, punti di forza e debolezze. Usando questi dati, il sistema può adattare le strategie didattiche, offrendo lezioni personalizzate allineate ai bisogni specifici dello studente.

Sfide tecniche e considerazioni

⬆ Torna su

L'implementazione della memoria persistente negli LLM comporta sfide significative. La scalabilità richiede che i sistemi AI gestiscano vaste quantità di dati per milioni di utenti senza compromettere velocità o prestazioni. Se un assistente AI impiega troppo tempo per recuperare informazioni immagazzinate, rischia di frustrare gli utenti invece di assisterli.

Il bias nei sistemi AI aggiunge un ulteriore livello di complessità. Se i dati memorizzati non sono monitorati e diversificati, la memoria persistente potrebbe amplificare involontariamente i bias esistenti. Le fonti sottolineano che audit regolari, dataset diversificati e misure proattive sono necessari per garantire equità e inclusività.

La privacy dei dati rappresenta una preoccupazione crescente. Quando si condividono informazioni sensibili con ChatGPT, specialmente quelle che riguardano altre persone, la gestione dei dati diventa un problema sempre più rilevante. Le fonti notano che OpenAI ha questi dati sui suoi server, ma non sono mai stati usati per fare inferenze sulle caratteristiche di chi li usa. Tuttavia, nel "blob fangoso" della memoria sarà difficile etichettarli correttamente.

Isolamento dei dati utente

⬆ Torna su

La documentazione di Google enfatizza che i dati utente devono essere completamente isolati. Le memorie di un utente non possono trapelare nel contesto di un altro utente. Questo è un requisito fondamentale per qualsiasi sistema di memoria persistente. Ogni memoria deve essere associata a uno specifico user_id e l'accesso deve essere rigorosamente controllato.

Il potenziale per l'AGI

⬆ Torna su

Guardando oltre, la memoria persistente potrebbe giocare un ruolo nello sviluppo dell'Artificial General Intelligence (AGI). L'AGI richiede la capacità di conservare e applicare conoscenza nel tempo per evolvere e adattarsi efficacemente. La memoria persistente fornisce la fondazione strutturale necessaria per questo livello di intelligenza, consentendo ai sistemi di apprendere dall'esperienza accumulata.

Framework disponibili

⬆ Torna su

Sia l'ADK (Agent Development Kit) di Google che LangGraph forniscono astrazioni per sessioni e memoria, ma con filosofie diverse. L'ADK è consigliato per chi costruisce su Google Cloud con integrazione Vertex AI, o quando l'interoperabilità A2A (Agent-to-Agent) è rilevante. LangGraph è consigliato per workflow flessibili basati su grafi, integrazione stretta con l'ecosistema LangChain, o preferenza per la gestione dello stato nativa in Python. Nuovi framework come MemGPT e Letta stanno guadagnando attenzione, consentendo agli sviluppatori di integrare memoria persistente nelle applicazioni AI con gestione migliorata del contesto.

Questo articolo è una sintesi basata esclusivamente sulle fonti elencate.

Implicazioni e scenari

⬆ Torna su

La corsa alla memoria persistente ridefinisce il rapporto tra utenti e assistenti conversazionali. Se Titans dimostra di scalare efficacemente, l'architettura a tre moduli potrebbe diventare un nuovo paradigma per i transformer di prossima generazione.

  • Scenario 1: L'approccio Memory-as-a-Tool si afferma come standard per sistemi agentic, dove l'agente decide autonomamente cosa ricordare e recuperare.
  • Scenario 2: La funzione Memory diventa un fattore di lock-in: utenti con cronologie ricche potrebbero esitare a migrare verso piattaforme alternative.
  • Scenario 3: La gestione dei conflitti tra memorie richiede framework di provenienza che potrebbero influenzare anche la regolamentazione sulla trasparenza algoritmica.

Cosa monitorare

⬆ Torna su
  • Tempi di arrivo di Memory in Europa e Regno Unito, attualmente esclusi.
  • Integrazione di Titans in prodotti Google già disponibili.
  • Reazione di competitor alle soluzioni di memoria persistente.

Nota editoriale: questa sezione propone una lettura analitica dei temi trattati, senza introdurre dati fattuali non presenti nelle fonti.

Fonti

⬆ Torna su

In breve

  • llm
  • chatgpt
  • transformer
  • agentic

Link utili

Apri l'articolo su DeafNews