La memoria degli agenti AI sopravvive al cambio di modello?
Cambiare il modello di un agente può degradarne la memoria senza produrre errori visibili. Uno studio confronta cronologia completa, RAG, note compresse e knowledge graph.
Aggiornare il modello alla base di un agente AI sembra un'operazione semplice: si cambia endpoint e si continua a utilizzare la stessa memoria. In realtà, il sistema può restare operativo e allo stesso tempo iniziare a dimenticare. Il nuovo modello può interpretare diversamente le note prodotte dal precedente, la ricerca può recuperare le informazioni sbagliate e una migrazione parziale degli embedding può degradare i risultati senza generare errori tecnici.
Il preprint Does Your Agent's Memory Survive a Model Upgrade? analizza il problema con un esperimento controllato su 48 cronologie sintetiche e due modelli open weight con meno di 10 miliardi di parametri. Lo studio separa il modello che scrive la memoria da quello che la legge, così da misurare cosa accade quando un nuovo modello eredita uno store già esistente.
Quattro modi di costruire la memoria
Cronologia completa, LC-RAW: Conserva l'intera conversazione. Mantiene più informazioni, ma richiede più contesto, tempo e costo a ogni lettura.
RAG: Divide la cronologia in segmenti e recupera quelli considerati pertinenti. Riduce il contesto inviato al modello, ma dipende dalla qualità di chunking, embedding e ricerca.
Note compresse, NOTES: Un modello sintetizza la cronologia in linguaggio naturale. Sono compatte e leggibili, ma il modello che le scrive decide cosa conservare e cosa scartare.
Knowledge graph a schema fisso, KG-fixed: Salva i fatti in relazioni strutturate e condivise. Offre meno libertà espressiva, ma rende il formato più stabile tra modelli diversi.
Lo schema fisso è il formato più portabile nel test
Il knowledge graph a schema fisso mantiene prestazioni quasi identiche dopo il cambio del modello che scrive la memoria: la variazione media è appena +0,0004, con un intervallo di confidenza di ±0,0020. La struttura condivisa stabilisce chiavi, relazioni e campi sorgente; il modello deve riempire i valori senza reinventare il formato.
Le note in linguaggio naturale mostrano invece un forte accoppiamento con il modello che le ha create. In una direzione di migrazione l'accuratezza migliora di 9,91 punti percentuali, mentre nella direzione opposta peggiora di 13,28 punti. La media tra le due direzioni è vicina allo zero e nasconde due effetti molto grandi. Per questo non basta testare genericamente la compatibilità: ogni passaggio da modello A a modello B va misurato nella direzione reale della migrazione.
Con il RAG, il problema può nascere prima della lettura
Nel sistema RAG sperimentale, la cronologia completa raggiunge un'accuratezza compresa tra 0,712 e 0,911, mentre il RAG si ferma tra 0,535 e 0,565. Il recupero porta al lettore l'evidenza necessaria soltanto nel 60% circa dei casi. L'81% del deficit del RAG viene attribuito proprio alla fase di retrieval.
Questo dato non rappresenta un limite universale del RAG: il test utilizza un singolo retriever denso, segmenti basati sugli eventi, top-k pari a 8 e nessun reranker o ricerca lessicale. Mostra però un principio generale: anche il modello migliore non può usare un'informazione che il sistema non gli consegna.
Mescolare embedding vecchi e nuovi crea errori silenziosi
Lo studio confronta un indice costruito con una vecchia versione dell'embedder, uno completamente rigenerato, un indice misto al 50% e un sistema ideale capace di instradare ogni query verso l'indice corretto. La reindicizzazione completa migliora l'accuratezza di 11,90 punti, mentre l'indice misto ne recupera soltanto 4,96. Quasi il 60% del beneficio potenziale viene perso.
Le due versioni dell'embedder producono vettori della stessa dimensione, quindi il database non segnala incompatibilità. Il sistema continua a rispondere, ma vecchi documenti e nuove query occupano spazi vettoriali differenti. La migrazione sicura richiede un nuovo indice separato, ricostruito integralmente e verificato prima del passaggio. Se la transizione deve essere graduale, gli spazi vettoriali vanno isolati e interrogati con un routing consapevole della versione.
La cronologia originale rende possibile il recupero
Quando una nota compressa ha eliminato un fatto, riscrivere soltanto quella nota non può ricrearlo. Nei 48 casi analizzati, la riparazione basata unicamente sullo store non raggiunge mai il 90% delle prestazioni di riferimento. Conservare la cronologia originale consente invece il recupero in 34 casi su 48 in una delle direzioni testate, anche se nell'altra il modello non riesce a completare il lavoro entro i limiti di output.
Mantenere la fonte originale offre quindi una seconda possibilità, ma introduce obblighi di sicurezza, privacy e cancellazione. Dove le policy lo consentono, serve una copia cifrata, con accessi limitati e tempi di conservazione definiti.
Una checklist per aggiornare un agente
Testare il nuovo modello sul vecchio store: Misurare la configurazione che verrà davvero messa in produzione.
Registrare la provenienza della memoria: Modello, prompt, schema, sistema di chunking ed embedder devono essere versionati.
Ricostruire interamente gli indici vettoriali: Non mescolare vettori prodotti da embedding diversi nello stesso spazio.
Separare scrittura, recupero e lettura: Prima di accusare il nuovo modello, verificare dove è stata persa l'informazione.
Conservare una fonte recuperabile: Quando è compatibile con privacy e sicurezza, mantenere la cronologia necessaria a ricostruire lo store.
Prevedere test dopo ogni transizione: Una batteria breve può segnalare regressioni immediate; la validazione finale deve coprire casi e formati realistici.
I limiti da ricordare
I risultati derivano da cronologie sintetiche, due modelli di dimensioni simili e configurazioni specifiche di retrieval. Lo schema del knowledge graph è adatto al compito studiato e non dimostra che ogni grafo superi sempre le note. Anche la possibilità di riparazione dipende dal modello, dai limiti di contesto e dalle risorse assegnate.
La conclusione pratica è netta: la memoria deve essere progettata come un componente durevole e versionato. Un cambio di modello non è soltanto un aggiornamento dell'intelligenza dell'agente; è una migrazione di dati e comportamento che richiede test, rollback e un percorso di ricostruzione.
Fonte originale: Ankit Goyal e Jaideep Ray, Does Your Agent's Memory Survive a Model Upgrade? A Controlled Study of Memory Portability, arXiv:2609.05339v1, 4 settembre 2026.
