Auditing Forgetting in Limited Memory Language Models

Sintesi Tecnica: Audit dell'Oblio nei Modelli di Linguaggio a Memoria Limitata

Enunciato del Problema
I Modelli di Linguaggio a Memoria Limitata (LMLM) rappresentano un'architettura ibrida che separa la competenza linguistica (codificata nei parametri del modello) dalla conoscenza fattuale (memorizzata in un database esterno). Questo design mira a consentire l' "unlearning basato sulla cancellazione", in cui la rimozione dei fatti dal database elimina l'accesso ad essi senza dover riaddestrare il modello. Tuttavia, i metodi di valutazione esistenti per l'oblio sono insufficienti. Essi misurano tipicamente l'accuratezza aggregata prima e dopo la cancellazione, ma non riescono a distinguere il meccanismo della correttezza post-cancellazione. Un modello potrebbe ancora rispondere correttamente a causa di:

1. Memoria parametrica residua: Il fatto rimane codificato nei pesi del modello.
2. Percorsi di recupero alternativi: Il fatto viene recuperato tramite alias, parafrasi o voci semanticamente correlate non esplicitamente eliminate.
3. Artefatti di recupero: Il modello genera la risposta corretta basandosi su candidati vicini (near-neighbor) che non sono equivalenti al fatto originale (gold-equivalent) eliminato.

Le metriche attuali non possono determinare se la conoscenza sia stata con successo esternalizzata o se persista internamente nei parametri del modello.

Metodologia: Framework di Audit Causale
Gli autori propongono un framework di audit causale che mantiene fisso il modello variando lo stato del database al momento dell'inferenza. Il framework valuta 12.228 chiusure di alias (alias-closure deletions) su tredici database (incluso il database LMLM rilasciato e dodici varianti personalizzate) utilizzando sei diverse formulazioni di prompt.

Il framework impiega tre stati di intervento controllati:

1. FULL: Il database è intatto e il recupero è abilitato. Questo stabilisce l'accuratezza di base (baseline).
2. DEL-ON: Il fatto target (e i suoi equivalenti alias) è eliminato dal database, ma il recupero rimane abilitato. Questo testa il recupero tramite percorsi alternativi o artefatti.
3. DEL-OFF: Il fatto target è eliminato e il recupero è disabilitato. Questo isola il richiamo parametrico (parametric recall), costringendo il modello a rispondere senza evidenze esterne.

Metriche Chiave e Decomposizione
Il framework decompone il comportamento post-cancellazione in tre componenti distinte:

• Leakage Parametrico ($L(f)$): Si verifica quando il modello risponde correttamente nello stato DEL-OFF. Ciò indica che il fatto eliminato persiste nei parametri del modello.
• Correttezza Mediata dal Recupero ($R(f)$): Si verifica quando il modello è corretto in DEL-ON ma errato in DEL-OFF. Ciò indica che la risposta è stata recuperata tramite il grafo di recupero.
• Tasso di Artefatti di Recupero ($A(f)$): Si verifica quando il modello produce la risposta corretta in DEL-ON nonostante non sia presente alcun candidato equivalente al gold nel tracciato di recupero. Ciò indica che la risposta è stata ricostruita da candidati vicini (es. esche parafrastiche).

Gli autori costruiscono varianti personalizzate del database per testare specifici modi di fallimento:

• Base: Solo triplette canoniche (baseline pulita).
• Alias: Fatti memorizzati solo sotto forme alias (testa la completezza della chiusura degli alias).
• Noise (Rumore): Triplette esca con soggetti parafrastici che puntano allo stesso oggetto (testa la ricostruzione dei vicini prossimi).
• Collision: Triplette "quasi-corrette" che condividono un soggetto ma indirizzano a un oggetto diverso (testa la deriva dai vicini confondibili).

Risultati Chiave
L'audit produce diverse scoperte critiche su 3 6684 completamenti del modello:

1. Leakage Parametrico Quasi Nullo: In tutte le varianti di database e stili di prompt, il leakage parametrico ($\hat{L}$) è effettivamente nullo (0,11% in media). Il modello raramente restituisce una risposta eliminata in assenza di recupero. Ciò suggerisce che per questa classe di LMLM, l'operazione di "unlearning" all'interno dei parametri del modello è pulita; il modello si comporta come se non avesse mai visto il fatto una volta disabilitato il recupero.
2. I Residui Vivono nel Grafo di Recupero: La correttezza sopravvissuta dopo la cancellazione è quasi interamente attribuibile al grafo di recupero, non al modello. Il tasso di correttezza mediata dal recupero ($R(f)$) corrisponde al tasso di artefatti di recupero ($A(f)$ entro l'errore di arrotondamento) in tutte le varianti. Ciò conferma che la correttezza post-cancellazione è prevalentemente ricostituita dai vicini prossimi (near-neighbor) piuttosto che ricordata.
3. La Topologia del Database Controlla i Residui: L'entità del residuo (la percentuale di fatti eliminati che sopravvivono) è determinata dalla topologia del database, non dall'architettura del modello o dallo stile del prompt.
   • Base: ~3,7% di residuo.
   • Alias: ~6,2% di residuo.
   • Collision: ~7,2% di residuo.
   • Noise: ~13,6% di residuo (il caso peggiore, dove le esche parafrastiche permettono al recupero di ricostruire la risposta).
   • Database LMLM Rilasciato: ~0,7% di residuo.
4. Impatto della Formulazione del Prompt: Sebbene lo stile del prompt influenzi significativamente l'accuratezza di base (FULL) (variando tra ~17% e ~57% F1), ha un controllo indipendente minimo sul residuo post-cancellazione. Una volta rimosse le prove di supporto, il tasso di sopravvivenza di un fatto è dettato dalla struttura del grafo di recupero, non dalla forma superficiale della domanda.

Significato e Rivendicazioni
Il documento sostiene che il contributo primario sia una decomposizione del comportamento di oblio piuttosto che una singola metrica aggregata. Isolando il richiamo parametrico dalla correttezza lato recupero, l'audit rivela che:

• Il "confine dell'unlearning" in questa classe di LMLM è tracciato principalmente dall'amministratore del database, non dal modello.
• Le procedure di cancellazione standard che rimuovono solo le triplette canoniche e i loro equivalenti alias sono insufficienti se il grafo di recupero contiene esche parafrastiche (come visto nella variante "Noise").
• La correttezza residua osservata in studi precedenti (es. l'articolo originale su LMLM) è probabilmente una proprietà del grafo di recupero specifico utilizzato (che era benigno) piuttosto che un fallimento del modello nel dimenticare.

Gli autori concludono che per un efficace unlearning negli LMLM, la governance deve estendersi oltre gli alias delle entità per includere la topologia del grafo di recupero, garantendo che anche le rotte parafrastiche verso informazioni sensibili siano chiuse al momento della cancellazione. Il documento non afferma che gli LMLM siano universalmente perfetti nell'unlearning, ma che i loro modi di fallimento sono strutturali al design del database piuttosto che inerenti alla memoria parametrica del modello.