ContextLeak: Auditing Leakage in Private In-Context Learning Methods

1. Il Problema

L'Apprendimento in Contesto (In-Context Learning - ICL) è diventato una tecnica standard per adattare i Large Language Models (LLM) a compiti specifici fornendo esempi (esemplari) direttamente nel prompt, senza necessità di un fine-tuning completo. Tuttavia, quando questi prompt contengono informazioni sensibili (es. dati medici, finanziari o personali), esiste il rischio che il modello le "leaki" (le divulghi) nelle risposte, anche se sono presenti istruzioni di sicurezza.

Sebbene esistano metodi per proteggere la privacy durante l'ICL, come:

• Difese euristiche: Istruzioni nel sistema prompt che chiedono al modello di non rivelare dati.
• Metodi Differenzialmente Privati (DP): Algoritmi che offrono garanzie matematiche formali (tramite il budget $\epsilon$) limitando l'impatto di un singolo record sui dati.

Esiste un vuoto critico: mancano strumenti affidabili per auditare (verificare) l'efficacia reale di queste difese. Le garanzie teoriche del DP sono spesso troppo pessimistiche (bordi lassi) e le difese euristiche possono dare un falso senso di sicurezza. Non esiste un metodo sistematico per misurare empiricamente la perdita di privacy nel caso peggiore (worst-case) durante l'inferenza.

2. Metodologia: ContextLeak

Gli autori introducono ContextLeak, il primo framework per misurare empiricamente la perdita di informazione nel caso peggiore per l'ICL privato. Il framework si basa su un attacco di Inferenza di Membria (Membership Inference Attack - MIA) adattato al contesto dell'ICL.

Il processo si articola in cinque fasi principali (illustrate nella Figura 2 del paper):

1. Creazione del "Canary" (Faro):
   Vengono inseriti nel dataset sensibile dei token univocamente identificabili, chiamati "canary", con una probabilità del 50% per ogni esecuzione. I tipi di canary proposti sono:

   • Hex: Stringhe esadecimali casuali.
   • Unigram: Token rari e poco frequenti nel dataset.
   • False Facts: Affermazioni semanticamente contraddittorie rispetto alla conoscenza generale del modello (es. "Il sole sorge a ovest").

2. Progettazione della Query Utente Adversariale:
   Vengono creati prompt specifici per indurre il modello a rivelare la presenza del canary. Le strategie includono:

   • Input-Output: Chiedere al modello di completare l'etichetta associata all'input del canary.
   • If-Then (Esplicito): "Se la stringa X è presente nel prompt, output Y, altrimenti Z".
   • If-Then (Non Esplicito): Chiedere di rilevare stringhe "incoerenti" senza nominarle esplicitamente.
   • Ottimizzazione: Le query vengono ulteriormente ottimizzate utilizzando un framework di ottimizzazione dei prompt (GEPA) per massimizzare l'accuratezza dell'attacco.

3. Esecuzione dell'Attacco:
   Il sistema privato ICL (con o senza difese) riceve il prompt contenente il dataset (con o senza il canary) e la query avversariale. Il modello genera un output privatizzato.

4. Rilevamento del Canary:
   Un "auditor" analizza l'output del modello per determinare se il canary era presente o meno nel contesto.

   • Per compiti di classificazione, si analizza la distribuzione delle frequenze delle classi (o l'output diretto).
   • Per la generazione di testo, si utilizzano embedding vettoriali per distinguere le uscite con e senza canary.

5. Misurazione della Perdita:
   L'accuratezza dell'auditor (o il TPR/FPR) viene utilizzata per calcolare un limite inferiore empirico del budget di privacy $\epsilon$.
   $$\epsilon_{emp} \approx \max \left\{ \log \frac{TPR}{FPR}, \log \frac{1-FPR}{1-TPR} \right\}$$
   Un'accuratezza di rilevamento del 50% indica nessuna perdita di privacy, mentre un'accuratezza del 100% indica una perdita totale.

3. Contributi Chiave

1. Primo Framework di Audit Empirico per ICL: ContextLeak è il primo metodo sistematico per stimare la perdita di privacy nel caso peggiore e calcolare un limite inferiore empirico per $\epsilon$ specificamente per l'ICL.
2. Strategie di Attacco Ottimizzate: Propone nuove strategie di canary (hex, unigram, false facts) e query avversariali, dimostrando che l'ottimizzazione dei prompt (tramite GEPA) può migliorare ulteriormente l'efficacia dell'attacco.
3. Valutazione Unificata: Permette di confrontare direttamente difese euristiche (basate su prompt) e difese formali (DP) sullo stesso piano empirico.
4. Scoperta di Trade-off Inefficienti: Dimostra che le attuali difese offrono compromessi privacy-utilità subottimali: o perdono completamente le informazioni sensibili o degradano drasticamente le prestazioni del modello.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su diversi modelli (Llama 3.3, Qwen 2.5, GPT-4.1) e dataset (SubJ, Sarcasm, SAMSum, DocVQA).

• Efficacia dell'Attacco: ContextLeak rileva con successo la perdita di privacy attraverso tutte le difese testate. Le difese basate su prompt (euristiche) e quelle basate su LLM (es. L3) vengono aggirate efficacemente, mentre gli attacchi tradizionali di "prompt injection" falliscono contro le difese più forti.
• Correlazione con $\epsilon$ Teorico: L'accuratezza dell'audit aumenta monotonicamente all'aumentare del budget di privacy teorico $\epsilon$. Questo conferma che ContextLeak fornisce un segnale pratico affidabile del rischio di privacy.
• Difese DP (RNM e ESA):
  • Report-Noisy-Max (RNM): Mostra una perdita non banale che aumenta con $\epsilon$.
  • Embedding-Space Aggregation (ESA): Anche nello spazio continuo degli embedding, si osserva una perdita significativa.
  • Gap Teorico-Empirico: Esiste un divario sostanziale tra il $\epsilon$ teorico e quello empirico. Anche quando $\epsilon \to \infty$ (dove ci si aspetterebbe un comportamento non privato), l'aggregazione tramite ensemble introduce un "artefatto" che mantiene una certa privacy, suggerendo che le analisi teoriche attuali sono troppo lasse.
• Trade-off Privacy-Utilità:
  • Le difese DP recuperano la maggior parte dell'utilità a budget di privacy bassi, ma mostrano rendimenti decrescenti.
  • Esiste un gap persistente di utilità rispetto all'ICL non privato, anche con budget elevati, dovuto all'overhead dell'aggregazione e alla perdita di informazioni durante la privatizzazione.
  • Le difese euristiche mantengono un'alta utilità ma falliscono completamente nel proteggere i dati sensibili nel caso peggiore.

5. Significato e Implicazioni

Il lavoro di ContextLeak è fondamentale per la sicurezza dei LLM per diversi motivi:

• Spostamento del Paradigma: Sposta la valutazione della privacy da analisi basate su garanzie teoriche o casi medi a un approccio guidato dagli attacchi (attack-driven) che misura il caso peggiore reale.
• Strumento Pratico: Fornisce un banco di prova per sviluppatori e organizzazioni che intendono utilizzare ICL in settori ad alto rischio (sanità, finanza), permettendo loro di scegliere le difese in base a dati empirici reali piuttosto che a stime teoriche.
• Avvertenza sulle Difese Attuali: Evidenzia che le attuali implementazioni di privacy per l'ICL sono strutturalmente inefficienti: o non proteggono affatto (euristiche) o costano troppo in termini di qualità del servizio (DP).
• Futuro della Ricerca: Incoraggia lo sviluppo di meccanismi di privacy più robusti e di audit più stretti che tengano conto delle dinamiche specifiche dell'inferenza in tempo reale, andando oltre le garanzie formali statiche.

In sintesi, ContextLeak dimostra che senza un audit avversariale rigoroso, le garanzie di privacy nell'ICL sono inaffidabili, e che le attuali soluzioni non riescono a bilanciare efficacemente la protezione dei dati con l'utilità del modello.