Sintesi Tecnica: Memorizzazione al Momento del Deployment in Agenti basati su Modelli di Fondazione

Definizione del Problema

Gli agenti basati su modelli di fondazione si stanno evolvendo da assistenti stateless in sistemi persistenti che mantengono una memoria utente duratura attraverso le interazioni. Sebbene questa capacità migliori la personalizzazione, altera fondamentalmente il panorama della privacy. A differenza della tradizionale memorizzazione parametrica (dove i dati sono codificati nei pesi del modello ed esposti tramite attacchi di estrazione), gli agenti persistenti memorizzano i fatti dell'utente in pipeline di memoria esterne. Queste pipeline scrivono, riassumono, recuperano e condizionano le risposte sui dati dell'utente, creando una nuova superficie di attacco.

La ricerca esistente si è concentrata ampiamente sull'audit di configurazioni di memoria fisse o sullo studio della memorizzazione parametrica. Tuttavia, manca una caratterizzazione su come le scelte di progettazione della memoria influenzino congiuntamente il compromesso tra:

1. Utilità di Personalizzazione: La capacità dell'agente di ricordare le preferenze dell'utente.
2. Rischio di Estrazione: La probabilità che un avversario recuperi informazioni private.
3. Fedeltà della Cancellazione: La capacità del sistema di cancellare realmente le informazioni, inclusi gli artefatti derivati (es. riassunti, embedding) quando un utente richiede la cancellazione.

Questo articolo identifica e studia questa superficie mancante, definita memorizzazione al momento del deployment (deployment-time memorization).

Metodologia

1. Modello di Sistema

Gli autori modellano la memoria dell'agente come una pipeline di scrittura–recupero–risposta:

• Scrittura (Write): I dati della sessione utente vengono memorizzati nella memoria a lungo termine.
• Recupero (Retrieve): I chunk di memoria vengono recuperati tramite similarità del coseno e pre-concatenati al contesto dell'agente.
• Risposta (Respond): Il modello di fondazione genera risposte condizionate dal contesto recuperato.

2. Design Sperimentale (Le "Manopole")

Lo studio analizza tre parametri specifici di progettazione della memoria:

• Aggressività della Riassunzione ($S$): Controlla ciò che viene memorizzato.
  • $S=0$: Turni utente grezzi (raw).
  • $S=1$: Fatti personali chiave estratti dai turni.
  • $S=2$: Riassunti della sessione di una sola frase.
• Ampiezza del Recupero ($k$): Il numero di chunk di memoria iniettati nel contesto ($k \in \{1, 3, 6, 10, 25\}$).
• Modalità di Cancellazione: Una scala a cinque livelli che disciplina il modo in cui il sistema gestisce le richieste di "dimentica":
  1. No-op: Controllo (nessuna modifica).
  2. Solo Raw: Testo grezzo rimosso; embedding/riassunti intatti.
  3. Raw + Riassunto: Raw rimosso e ri-embedded; le sessioni interessate vengono riassunte partendo dall'input pulito.
  4. Purga Totale (Full Purge): Tutti i livelli rimossi/ri-embedded; i chunk vuoti vengono scartati.
  5. Tombstone: Il canary viene sostituito con [REDACTED] in ogni livello e ri-embedded.

3. Metriche

• Richiamo di Personalizzazione (PR): Misura se l'agente risponde correttamente a query che richiedono il contesto utente (basandosi su similarità del coseno > 0.50 o copertura delle parole del contenuto verbatim).
• Tasso di Estrazione Avversaria (AER): La frazione di token "canary" ad alta entropia (iniettati nelle sessioni precedenti) recuperati verbatim sotto tre tipi di probe:
  • Diretto: Chiedere esplicitamente il segreto.
  • Indiretto: Chiedere cosa ricorda l'agente dell'utente.
  • Jailbreak: Istruzioni di modalità developer o dump di debug.
• AUC Privacy–Utilità (PUA): L'area sotto l'inviluppo empirico del richiamo ottenibile, che riassume la frontiera dove si ottiene un maggiore richiamo a un minore rischio di estrazione.
• Punteggio di Residuo di Oblio (FRS): Misura la perdita post-cancellazione attraverso i livelli di memoria (raw vs. summary). Un FRS non nullo indica che il segreto rimane recuperabile nonostante la cancellazione.

4. Setup

Gli esperimenti sono stati condotti sul benchmark LongMemEval (split oracle) utilizzando:

• Modelli: Gemma 3 12B (locale, open-weight) e GPT-4o-mini (closed-weight).
• Dati: 50 istanze con canary sintetici ad alta entropia iniettati in turni utente non-evidence per isolare la memorizzazione al deployment dalla esposizione dell'addestramento.

Risultati Chiave

1. La Frontiera Privacy–Utilità

• Memoria Raw ($S=0$): Non offre un punto operativo pulito. Aumentare l'ampiezza del recupero ($k$) migliora l'utilità (PR) ma aumenta linearmente la perdita (AER). Per Gemma 3 12B, la PR sale da 0.42 a 0.66 all'aumentare di $k$, mentre l'AER sale da 0.70 a 0.86.
• Riassunto ($S=1$): Agisce come un meccanismo di "lavaggio" (laundering).
  • Riduzione della Perdita: La riassunzione dei fatti chiave riduce l'AER del 76% su Gemma 3 12B e del 64% su GPT-4o-mini rispetto alla memoria raw.
  • Preservazione dell'Utilità: Questa riduzione avviene con un costo minimo per la PR (circa il 5% su Gemma, 2% su GPT).
  • Neutralità del Recupero: Una volta compresso il contenuto (riassunto), aumentare $k$ non ripristina la perdita. L'AER rimane piatto per tutti i valori di $k$, indicando che se il segreto è assente dal riassunto, recuperare più chunk non può ripristinare la sua presenza.
• Comportamento dei Probe: Con la memoria raw, i probe diretti e indiretti producono tassi di estrazione differenti. Sotto la riassunzione, questi tassi collassano allo stesso livello basso, suggerendo che la riassunzione controlla la recuperabilità dei fatti a livello di pipeline, indipendentemente dalla resistenza al jailbreak del modello sottostante.

2. Fedeltà della Cancellazione e Residuo

• Il Fallimento della Cancellazione Solo-Raw: Cancellare solo il record raw ($S=1$, modalità "raw only") lascia copie derivate del riassunto recuperabili in circa il 20% dei casi. Il FRS per il livello di riassunto rimane statisticamente indistinguibile dal controllo "no-op".
• Mitigazione Parziale: "Raw + riassunto" riduce il residuo (es. a ~11% su Gemma) ma non lo elimina, poiché gli artefatti del riassunto preesistenti non vengono completamente purgati prima della rigenerazione.
• Oblio Vero: Solo la Purga Totale e la redazione Tombstone portano il residuo del livello peggiore (FRS) a zero in tutte le impostazioni. Ciò conferma che in pipeline a più livelli, cancellare la sorgente è insufficiente; gli artefatti derivati devono essere esplicitamente rimossi o oscurati.

Contributi

1. Formalizzazione della Memorizzazione al Momento del Deployment: Il paper definisce la memoria persistente dell'agente come una funzione di sistema misurabile, introducendo una frontiera privacy-utilità basata su PR, AER e PUA.
2. Analisi Controllata delle Scelte di Progettazione: Dimostra che la riassunzione riduce significativamente il rischio di estrazione con un costo di personalizzazione trascurabile, mentre l'ampiezza del recupero da sola non può raggiungere un compromesso favorevole.
3. Benchmark della Fedeltà dell'Oblio: Introducendo il Forgetting Residue Score (FRS), il lavoro rivela che la cancellazione standard "solo-raw" è insufficiente per sistemi di memoria a più livelli, stabilendo che è necessaria la purga completa della pipeline o l'uso di tombstone per un vero oblio.

Significato

Il paper stabilisce che la memoria persistente degli agenti deve essere valutata come un meccanismo di memorizzazione di prima classe. Sostiene che i rischi di privacy degli agenti non sono solo un sottoprodotto dei pesi del modello, ma sono attivamente modellati dalle scelte di ingegneria al momento del deployment.

I risultati suggeriscono una ricetta pratica per il deployment sicuro degli agenti:

• Utilizzare la riassunzione dei fatti chiave ($S=1$) per "lavare" i segreti dai contesti di recupero.
• Mantenere un'ampiezza di recupero moderata ($k$), poiché non ripristina la perdita una volta applicata la compressione.
• Implementare la cancellazione consapevole dei livelli (purga totale o tombstoning) per garantire che le copie derivate (riassunti, embedding) non vengano lasciate indietro.

In definitiva, l'opera pone la memorizzazione al momento del deployment come una frontiera utilità-perdita controllabile, piuttosto che come una conseguenza inevitabile dell'uso di modelli di fondazione.