Riflessioni su ChatGPT e sui sistemi di memoria di Claude: Cosa serve per abilitare il recupero conversazionale on-demand

Nei sistemi di agenti di intelligenza artificiale di alta qualità, la progettazione della memoria è molto più complessa di quanto sembri a prima vista. In sostanza, deve rispondere a tre domande fondamentali: Come deve essere memorizzata la cronologia delle conversazioni? Quando deve essere recuperato il contesto passato? E che cosa, esattamente, deve essere recuperato?

Queste scelte determinano direttamente la latenza di risposta di un agente, l'utilizzo delle risorse e, in ultima analisi, il suo limite di capacità.

Modelli come ChatGPT e Claude si sentono sempre più "consapevoli della memoria" quanto più li usiamo. Ricordano le preferenze, si adattano agli obiettivi a lungo termine e mantengono la continuità tra le sessioni. In questo senso, funzionano già come mini-agenti di intelligenza artificiale. Tuttavia, sotto la superficie, i loro sistemi di memoria si basano su presupposti architettonici molto diversi.

Recenti analisi di reverse-engineering dei meccanismi di memoria di ChatGPTe Claude rivelano un chiaro contrasto. ChatGPT si basa sull'iniezione di contesto precalcolato e sulla cache a strati per offrire una continuità leggera e prevedibile. Claude, invece, adotta il recupero on-demand in stile RAG con aggiornamenti dinamici della memoria per bilanciare la profondità della memoria e l'efficienza.

Questi due approcci non sono solo preferenze progettuali, ma anche capacità infrastrutturali. Milvus 2.6 introduce la combinazione di recupero ibrido denso-sparso, filtraggio scalare efficiente e archiviazione a livelli che la memoria conversazionale on-demand richiede, rendendo il recupero selettivo abbastanza veloce ed economico da essere implementato nei sistemi del mondo reale.

In questo post spiegheremo come funzionano i sistemi di memoria di ChatGPT e di Claude, perché si sono discostati dal punto di vista architetturale e come i recenti progressi di sistemi come Milvus rendono il recupero conversazionale on-demand pratico su scala.

Il sistema di memoria di ChatGPT

Invece di interrogare un database vettoriale o di recuperare dinamicamente le conversazioni passate al momento dell'inferenza, ChatGPT costruisce la sua "memoria" assemblando un insieme fisso di componenti del contesto e iniettandoli direttamente in ogni messaggio. Ogni componente è preparato in anticipo e occupa una posizione nota nel messaggio.

Questo design mantiene intatte la personalizzazione e la continuità della conversazione, rendendo al contempo più prevedibili la latenza, l'uso dei token e il comportamento del sistema. In altre parole, la memoria non è qualcosa che il modello cerca al volo, ma è qualcosa che il sistema confeziona e consegna al modello ogni volta che genera una risposta.

Ad alto livello, un prompt ChatGPT completo è costituito dai seguenti livelli, ordinati dal più globale al più immediato:

[0] Istruzioni del sistema

[1] Istruzioni per lo sviluppatore

[2] Metadati della sessione (effimeri)

[3] Memoria dell'utente (fatti a lungo termine)

[4] Riepilogo delle conversazioni recenti (chat passate, titoli + frammenti)

[5] Messaggi della sessione corrente (questa chat)

[6] Il vostro ultimo messaggio

Tra questi, i componenti da [2] a [5] formano la memoria effettiva del sistema, ciascuno con un ruolo distinto.

Metadati di sessione

I metadati di sessione rappresentano informazioni di breve durata, non persistenti, che vengono iniettate una volta all'inizio di una conversazione e scartate al termine della sessione. Il suo ruolo è quello di aiutare il modello ad adattarsi al contesto d'uso corrente, piuttosto che personalizzare il comportamento a lungo termine.

Questo livello acquisisce segnali sull'ambiente immediato dell'utente e sui modelli di utilizzo recenti. I segnali tipici includono:

• Informazioni sul dispositivo, ad esempio se l'utente si trova su un cellulare o su un desktop.

• Attributi dell'account, come il livello di abbonamento (ad esempio, ChatGPT Go), l'età dell'account e la frequenza di utilizzo complessiva.

• Metriche comportamentali, tra cui i giorni di attività negli ultimi 1, 7 e 30 giorni, la lunghezza media delle conversazioni e la distribuzione dell'utilizzo del modello (ad esempio, il 49% delle richieste gestite da GPT-5).

Memoria utente

La memoria utente è il livello di memoria persistente e modificabile che consente la personalizzazione delle conversazioni. Memorizza informazioni relativamente stabili, come il nome dell'utente, il ruolo o gli obiettivi di carriera, i progetti in corso, i risultati ottenuti in passato e le preferenze di apprendimento, e viene iniettata in ogni nuova conversazione per mantenere la continuità nel tempo.

Questa memoria può essere aggiornata in due modi:

• Gli aggiornamenti espliciti avvengono quando gli utenti gestiscono direttamente la memoria con istruzioni come "ricorda questo" o "rimuovi questo dalla memoria".

• Gli aggiornamenti impliciti avvengono quando il sistema identifica le informazioni che soddisfano i criteri di memorizzazione di OpenAI, come un nome confermato o un titolo di lavoro, e le salva automaticamente, in base al consenso e alle impostazioni di memoria predefinite dell'utente.

Riepilogo delle conversazioni recenti

Il riepilogo delle conversazioni recenti è un livello di contesto leggero e trasversale alle sessioni che preserva la continuità senza riprodurre o recuperare le cronologie complete delle chat. Invece di affidarsi al recupero dinamico, come negli approcci tradizionali basati su RAG, questo riepilogo viene precalcolato e iniettato direttamente in ogni nuova conversazione.

Questo livello riassume solo i messaggi degli utenti, escludendo le risposte degli assistenti. Le sue dimensioni sono intenzionalmente limitate (tipicamente circa 15 voci) e conserva solo segnali di alto livello sugli interessi recenti, piuttosto che contenuti dettagliati. Poiché non si basa su embeddings o sulla ricerca di similarità, mantiene bassi sia la latenza che il consumo di token.

Messaggi della sessione corrente

I messaggi della sessione corrente contengono l'intera cronologia dei messaggi della conversazione in corso e forniscono il contesto a breve termine necessario per ottenere risposte coerenti, svolta per svolta. Questo livello include sia gli input dell'utente che le risposte dell'assistente, ma solo finché la sessione rimane attiva.

Poiché il modello opera entro un limite fisso di token, questa cronologia non può crescere all'infinito. Quando il limite viene raggiunto, il sistema elimina i messaggi più vecchi per fare spazio a quelli più recenti. Questo troncamento riguarda solo la sessione corrente: la memoria a lungo termine dell'utente e il riepilogo delle conversazioni recenti rimangono intatti.

Il sistema di memoria di Claude

Claude adotta un approccio diverso alla gestione della memoria. Piuttosto che iniettare un grande pacchetto fisso di componenti di memoria in ogni prompt, come fa ChatGPT, Claude combina la memoria persistente dell'utente con strumenti su richiesta e un recupero selettivo. Il contesto storico viene recuperato solo quando il modello lo giudica rilevante, consentendo al sistema di bilanciare la profondità del contesto con il costo computazionale.

Il contesto del prompt di Claude è strutturato come segue:

[0] prompt del sistema (istruzioni statiche)

[1] Memorie dell'utente

[2] Storia della conversazione

[3] Messaggio corrente

Le differenze principali tra Claude e ChatGPT risiedono nel modo in cui viene recuperata la cronologia delle conversazioni e nel modo in cui la memoria utente viene aggiornata e mantenuta.

Memorie dell'utente

In Claude, le memorie dell'utente costituiscono un livello di contesto a lungo termine simile alla memoria dell'utente di ChatGPT, ma con una maggiore enfasi sugli aggiornamenti automatici, guidati dal background. Queste memorie sono memorizzate in un formato strutturato (avvolto in tag di tipo XML) e sono progettate per evolvere gradualmente nel tempo con un intervento minimo da parte dell'utente.

Claude supporta due percorsi di aggiornamento:

• Aggiornamenti impliciti - Il sistema analizza periodicamente il contenuto delle conversazioni e aggiorna la memoria in background. Questi aggiornamenti non vengono applicati in tempo reale e le memorie associate alle conversazioni cancellate vengono gradualmente eliminate come parte dell'ottimizzazione in corso.

• Aggiornamenti espliciti - Gli utenti possono gestire direttamente la memoria attraverso comandi quali "ricorda questo" o "cancella questo", che vengono eseguiti tramite uno strumento dedicato memory_user_edits.

Rispetto a ChatGPT, Claude attribuisce al sistema stesso una maggiore responsabilità nel perfezionare, aggiornare e sfoltire la memoria a lungo termine. Questo riduce la necessità per gli utenti di curare attivamente ciò che viene memorizzato.

Cronologia delle conversazioni

Per la cronologia delle conversazioni, Claude non si affida a un riassunto fisso che viene inserito in ogni messaggio. Al contrario, recupera il contesto passato solo quando il modello lo ritiene necessario, utilizzando tre meccanismi distinti. In questo modo si evita di portare avanti una cronologia irrilevante e si tiene sotto controllo l'uso dei token.

Componente	Scopo	Come viene utilizzato
Finestra mobile (conversazione corrente)	Memorizza la cronologia completa dei messaggi della conversazione corrente (non un riassunto), simile al contesto di sessione di ChatGPT.	Iniettato automaticamente. Il limite dei token è di ~190K; i messaggi più vecchi vengono eliminati una volta raggiunto il limite.
conversation_search strumento	Cerca le conversazioni passate per argomento o parola chiave, restituendo link alle conversazioni, titoli ed estratti di messaggi dell'utente/assistente.	Viene attivato quando il modello determina che sono necessari dettagli storici. I parametri includono query (termini di ricerca) e max_results (1-10).
recent_chats strumento	Recupera le conversazioni recenti all'interno di un intervallo di tempo specificato (per esempio, "ultimi 3 giorni"), con risultati formattati come conversation_search	Viene attivato quando il contesto recente, in ordine temporale, è rilevante. I parametri includono n (numero di risultati), sort_order e l'intervallo di tempo.

Tra questi componenti, conversation_search è particolarmente degno di nota. Riesce a far emergere risultati rilevanti anche per query non formulate o multilingue, indicando che opera a livello semantico piuttosto che basarsi sulla semplice corrispondenza delle parole chiave. Probabilmente si tratta di un recupero basato sull'embedding o di un approccio ibrido che prima traduce o normalizza la query in una forma canonica e poi applica un recupero per parole chiave o ibrido.

Nel complesso, l'approccio di Claude al recupero su richiesta ha diversi punti di forza degni di nota:

• Ilrecupero non è automatico: Le chiamate allo strumento sono attivate dal giudizio del modello stesso. Ad esempio, quando un utente fa riferimento a "il progetto di cui abbiamo discusso l'ultima volta", Claude può decidere di invocare conversation_search per recuperare il contesto pertinente.

• Contesto più ricco quando necessario: I risultati recuperati possono includere estratti delle risposte dell'assistente, mentre i riassunti di ChatGPT catturano solo i messaggi dell'utente. Questo rende Claude più adatto ai casi d'uso che richiedono un contesto di conversazione più profondo o più preciso.

• Migliore efficienza per impostazione predefinita: Poiché il contesto storico non viene iniettato se non necessario, il sistema evita di trasportare grandi quantità di storia irrilevante, riducendo il consumo di token non necessari.

I compromessi sono altrettanto chiari. L'introduzione del recupero on-demand aumenta la complessità del sistema: gli indici devono essere costruiti e mantenuti, le query eseguite, i risultati classificati e talvolta ri-classificati. Anche la latenza end-to-end diventa meno prevedibile rispetto a un contesto precalcolato e sempre iniettato. Inoltre, il modello deve imparare a decidere quando è necessario il recupero. Se questo giudizio fallisce, il contesto rilevante potrebbe non essere mai recuperato.

I vincoli del recupero su richiesta in stile Claude

L'adozione di un modello di recupero su richiesta rende il database vettoriale una parte critica dell'architettura. Il recupero delle conversazioni pone requisiti insolitamente elevati sia per l'archiviazione che per l'esecuzione delle query, e il sistema deve soddisfare quattro vincoli allo stesso tempo.

1. Tolleranza alla bassa latenza

Nei sistemi di conversazione, la latenza di P99 deve rimanere al di sotto di ~ 20 ms. Ritardi superiori a questa soglia sono immediatamente percepiti dagli utenti. Questo lascia poco spazio all'inefficienza: la ricerca vettoriale, il filtraggio dei metadati e la classificazione dei risultati devono essere ottimizzati con cura. Un collo di bottiglia in qualsiasi punto può degradare l'intera esperienza di conversazione.

2. Requisiti per la ricerca ibrida

Le richieste degli utenti spesso si estendono su più dimensioni. Una richiesta come "discussioni su RAG dell'ultima settimana" combina la rilevanza semantica con il filtraggio basato sul tempo. Se un database supporta solo la ricerca vettoriale, potrebbe restituire 1.000 risultati simili dal punto di vista semantico, solo che il filtro del livello applicativo li ridurrebbe a una manciata, sprecando la maggior parte della computazione. Per essere pratico, il database deve supportare in modo nativo query combinate vettoriali e scalari.

3. Separazione tra archiviazione e calcolo

La cronologia delle conversazioni presenta un chiaro modello di accesso caldo-freddo. Le conversazioni recenti vengono interrogate frequentemente, mentre quelle più vecchie vengono toccate raramente. Se tutti i vettori dovessero rimanere in memoria, la memorizzazione di decine di milioni di conversazioni consumerebbe centinaia di gigabyte di RAM, un costo impraticabile su scala. Per essere redditizio, il sistema deve supportare la separazione storage-compute, mantenendo i dati caldi in memoria e quelli freddi nell'object storage, con vettori caricati su richiesta.

4. Schemi di interrogazione diversi

Il recupero delle conversazioni non segue un unico modello di accesso. Alcune query sono puramente semantiche (per esempio, "l'ottimizzazione delle prestazioni di cui abbiamo discusso"), altre sono puramente temporali ("tutte le conversazioni dell'ultima settimana") e molte combinano più vincoli ("discussioni relative a Python che menzionano FastAPI negli ultimi tre mesi"). Il pianificatore di query di database deve adattare le strategie di esecuzione ai diversi tipi di query, piuttosto che affidarsi a una ricerca bruta e uguale per tutti.

Insieme, queste quattro sfide definiscono i vincoli fondamentali del recupero conversazionale. Qualsiasi sistema che voglia implementare il reperimento on-demand in stile Claude deve affrontarle tutte in modo coordinato.

Perché Milvus 2.6 funziona bene per il recupero conversazionale

Le scelte progettuali di Milvus 2.6 si allineano strettamente ai requisiti fondamentali del recupero conversazionale on-demand. Qui di seguito sono descritte le principali funzionalità e il modo in cui si adattano alle reali esigenze di recupero conversazionale.

Recupero ibrido con vettori densi e sparsi

Milvus 2.6 supporta in modo nativo la memorizzazione di vettori densi e radi all'interno della stessa collezione e la fusione automatica dei loro risultati al momento dell'interrogazione. I vettori densi (ad esempio, gli embeddings a 768 dimensioni generati da modelli come BGE-M3) catturano la somiglianza semantica, mentre i vettori radi (tipicamente prodotti da BM25) conservano i segnali esatti delle parole chiave.

Per una query come "discussioni su RAG della scorsa settimana", Milvus esegue in parallelo il recupero semantico e il recupero delle parole chiave, quindi unisce i risultati attraverso il reranking. Rispetto all'utilizzo di uno dei due approcci da solo, questa strategia ibrida offre un richiamo significativamente più elevato in scenari di conversazione reali.

Separazione storage-computer e ottimizzazione delle query

Milvus 2.6 supporta l'archiviazione a livelli in due modi:

• Dati caldi in memoria, dati freddi nell'archiviazione a oggetti.

• Indici in memoria, dati vettoriali grezzi nell'archiviazione a oggetti.

Con questo design, è possibile memorizzare un milione di voci di conversazione con circa 2 GB di memoria e 8 GB di memoria a oggetti. Con una corretta messa a punto, la latenza di P99 può rimanere al di sotto dei 20 ms, anche con la separazione storage-compute attivata.

Triturazione JSON e filtraggio scalare veloce

Milvus 2.6 abilita il JSON Shredding per impostazione predefinita, appiattendo i campi JSON annidati in una memoria colonnare. Questo migliora le prestazioni del filtraggio scalare di 3-5× secondo i benchmark ufficiali (i guadagni effettivi variano a seconda del modello di query).

Il recupero delle conversazioni richiede spesso il filtraggio di metadati come l'ID utente, l'ID sessione o l'intervallo di tempo. Con JSON Shredding, query come "tutte le conversazioni dell'utente A nell'ultima settimana" possono essere eseguite direttamente sugli indici colonnari, senza analizzare ripetutamente interi blob JSON.

Controllo open-source e flessibilità operativa

In quanto sistema open-source, Milvus offre un livello di controllo architettonico e operativo che le soluzioni chiuse e black-box non hanno. I team possono mettere a punto i parametri degli indici, applicare strategie di tiering dei dati e personalizzare le distribuzioni distribuite in base ai carichi di lavoro.

Questa flessibilità abbassa la barriera all'ingresso: i team di piccole e medie dimensioni possono costruire sistemi di recupero conversazionale su scala milionaria o decimilionaria senza dover ricorrere a budget infrastrutturali eccessivi.

Perché ChatGPT e Claude hanno intrapreso strade diverse

Ad alto livello, la differenza tra i sistemi di memoria di ChatGPT e Claude si riduce al modo in cui ciascuno di essi gestisce l'oblio. ChatGPT privilegia l'oblio proattivo: una volta che la memoria supera limiti prestabiliti, il contesto più vecchio viene abbandonato. Questo baratta la completezza con la semplicità e la prevedibilità del comportamento del sistema. Claude favorisce l'oblio ritardato. In teoria, la cronologia delle conversazioni può crescere senza limiti, con il richiamo delegato a un sistema di recupero su richiesta.

Perché i due sistemi hanno scelto strade diverse? Con i vincoli tecnici esposti in precedenza, la risposta diventa chiara: ogni architettura è praticabile solo se l'infrastruttura sottostante è in grado di supportarla.

Se l'approccio di Claude fosse stato tentato nel 2020, sarebbe stato probabilmente impraticabile. All'epoca, i database vettoriali avevano spesso una latenza di centinaia di millisecondi, le interrogazioni ibride erano scarsamente supportate e l'utilizzo delle risorse scalava in modo proibitivo con la crescita dei dati. In queste condizioni, il recupero on-demand sarebbe stato liquidato come un'eccessiva ingegnerizzazione.

Nel 2025, il panorama è cambiato. I progressi dell'infrastruttura, guidati da sistemi come Milvus 2.6, hannoreso praticabile in produzione la separazione storage-compute, l'ottimizzazione delle query, il recupero ibrido denso-sparso e il JSON Shredding. Questi progressi riducono la latenza, controllano i costi e rendono pratico il reperimento selettivo su scala. Di conseguenza, gli strumenti on-demand e la memoria basata sul recupero sono diventati non solo fattibili, ma anche sempre più interessanti, soprattutto come base per i sistemi di tipo agent.

In definitiva, le scelte architettoniche seguono ciò che l'infrastruttura rende possibile.

Conclusione

Nei sistemi del mondo reale, la progettazione della memoria non è una scelta binaria tra contesto precalcolato e recupero su richiesta. Le architetture più efficaci sono tipicamente ibride e combinano entrambi gli approcci.

Un modello comune è quello di iniettare le conversazioni recenti attraverso una finestra di contesto scorrevole, memorizzare le preferenze stabili dell'utente come memoria fissa e recuperare la storia più vecchia su richiesta attraverso una ricerca vettoriale. Man mano che un prodotto matura, questo equilibrio può cambiare gradualmente, passando da un contesto prevalentemente precalcolato a un contesto sempre più guidato dal recupero, senza richiedere un reset architetturale dirompente.

Anche quando si inizia con un approccio precalcolato, è importante progettare tenendo conto della migrazione. La memoria deve essere archiviata con chiari identificatori, timestamp, categorie e riferimenti alla fonte. Quando il recupero diventa fattibile, gli embeddings possono essere generati per la memoria esistente e aggiunti a un database vettoriale insieme agli stessi metadati, consentendo di introdurre la logica di recupero in modo incrementale e con il minimo disturbo.

Avete domande o volete un approfondimento su una qualsiasi funzione dell'ultima versione di Milvus? Unitevi al nostro canale Discord o inviate problemi su GitHub. È anche possibile prenotare una sessione individuale di 20 minuti per ottenere approfondimenti, indicazioni e risposte alle vostre domande tramite Milvus Office Hours.