Riepilogo Tecnico: AESOP: Selezione del Percorso di Esecuzione Adversarial per Sovraccaricare le Pipeline di Deep Learning

1. Enunciato del Problema

Le implementazioni moderne di machine learning si basano sempre più su pipeline di inferenza multi-modello piuttosto che su modelli monolitici. In questi sistemi, modelli specializzati sono collegati tramite flussi di dati produttore-consumatore, dove i componenti a monte generano previsioni intermedie che determinano il carico di lavoro e l'instradamento dei componenti a valle.

La vulnerabilità centrale identificata è che il costo computazionale dell'elaborazione di un input in tali pipeline non è determinato esclusivamente dal costo per inferenza dei singoli modelli, ma da due fattori accoppiati:

1. Il costo per inferenza di ciascun componente invocato.
2. Il volume del carico di lavoro (cardinalità dell'output) passato ai componenti a valle.

Poiché queste pipeline operano spesso sotto vincoli di tempo reale rigidi, l'efficienza è un fattore determinante per la disponibilità del sistema. Gli attacchi avversariali esistenti prendono di mira singoli modelli (ad esempio, gonfiando i sopravvissuti alla soppressione Non-Massima o ritardando i token di fine sequenza) ma non tengono conto del percorso di esecuzione attivato da un input. Un avversario che può indirizzare gli input verso il percorso computazionalmente più intensivo può indurre costi nel caso peggiore che gli attacchi a singolo modello non possono raggiungere. Il documento formalizza questo come il problema della selezione del percorso avversariale: scegliere quale percorso di esecuzione attaccare è una leva distinta e dominante per il degrado dell'efficienza, separata dalla forza della perturbazione stessa.

2. Metodologia: Framework AESOP

Gli autori propongono AESOP (Selezione del Percorso di Esecuzione Adversarial per Sovraccaricare le Pipeline di Deep Learning), un framework che scompone l'attacco in due fasi coordinate:

Fase 1: Classificazione dei Percorsi Guidata dalla Vulnerabilità

Questa fase affronta la "massimizzazione esterna" del problema dell'attacco: identificare quale percorso di esecuzione $\pi^*$ produce la massima amplificazione del costo.

• Profilatura: Il sistema analizza tre comportamenti dipendenti dall'input per ciascun componente $v$: costo per inferenza ($c_v$), cardinalità dell'output ($o_v$) e comportamento di gating ($g_v$).
• Punteggio di Vulnerabilità del Componente: Viene calcolato un punteggio che rappresenta l'amplificazione moltiplicativa del costo sotto input avversariale rispetto all'input pulito: $Vul\text{-}Score(v) = \frac{C_{adv}(v)}{C(v)} - 1$.
• Aggregazione della Vulnerabilità del Percorso: I punteggi dei componenti lungo un percorso sono sommati (anziché massimizzati) perché i costi della pipeline si propagano; un output gonfiato in una fase propaga il carico di lavoro a tutte le fasi a valle.
• Selezione: Il percorso con il punteggio di vulnerabilità aggregato più alto viene selezionato come target $\pi^*$. Questo passaggio si basa sui dati di profilatura ed è applicabile sia in contesti white-box che gray-box (utilizzando specifiche pubbliche del modello).

Fase 2: Ponderazione Adattiva della Loss

Questa fase affronta la "massimizzazione interna": generare una perturbazione $\delta$ per massimizzare il costo del percorso selezionato $\pi^*$.

• Obiettivo Ponderato per Vulnerabilità: Invece di trattare tutti i componenti in modo uguale, la funzione di perdita è una somma ponderata delle perdite dei componenti. I pesi sono determinati dal contributo relativo di ciascun componente al punteggio di vulnerabilità totale del percorso.
• Backend Disaccoppiato: AESOP agisce come un orchestratore a livello di sistema. Non prescrive un meccanismo di perturbazione specifico, ma fornisce un'interfaccia per qualsiasi attacco esistente all'efficienza a singolo modello (ad esempio, inflazione dell'output, ritardo EOS) da utilizzare come backend. Il framework adatta la ponderazione della loss alla topologia specifica e alla struttura dei costi della pipeline target.

3. Contributi Chiave

• Formalizzazione della Selezione del Percorso Adversariale: Il documento identifica l'attivazione del percorso di esecuzione come la leva dominante per attaccare l'efficienza della pipeline, distinta dalla forza della perturbazione.
• Il Framework AESOP: Il primo framework di attacco all'efficienza che risolve il problema della selezione del percorso combinando la classificazione dei percorsi guidata dalla vulnerabilità con la ponderazione adattiva della loss. È separabile dal backend di perturbazione, permettendogli di sfruttare qualsiasi tecnica di attacco a singolo modello.
• Valutazione a Livello di Sistema: Valutazione su cinque pipeline diverse (monitoraggio del traffico, conservazione della fauna selvatica, allerta per la casa intelligente, sorveglianza autostradale e generazione di allerte Amber) e una variante realistica di produzione con batching e buffering limitato.

4. Risultati Sperimentali

Efficacia White-Box

• Amplificazione: AESOP raggiunge fino a 2.407× di inflazione FLOPs e 419× di inflazione della latenza in ambienti white-box.
• Confronto: Su input e budget identici, il baseline a singolo modello più forte (ad esempio, Overload, Phantom Sponges, SlowTrack) raggiunge un massimo di 117× FLOPs. AESOP supera questi baseline di un fattore compreso tra 3,2× e 117×, a seconda dell'asimmetria dei percorsi della pipeline.
• Meccanismo: Il divario è attribuito interamente alla selezione del percorso. Ad esempio, nella pipeline di Conservazione della Fauna Selvatica, prendere di mira il percorso "Elefante" (che esce dal gate e attiva un classificatore pesante) produce un'amplificazione massiccia, mentre gli attacchi ciechi al percorso che prendono di mira classi comuni non riescono a raggiungere il ramo costoso.

Trasferibilità Gray-Box

• Sopravvivenza: Il meccanismo di selezione del percorso sopravvive senza accesso ai gradienti del target. La classificazione della Fase 1 è riproducibile dalle specifiche pubbliche del modello (conteggi FLOPs).
• Prestazioni: Utilizzando modelli surrogati (YOLOv5m) per attaccare target (YOLOv5l, YOLOv8n), AESOP raggiunge un'amplificazione FLOPs di 3,6× fino a 58,3×.
• Insight: Un rilevatore più veloce ed economico non è necessariamente più robusto; spesso ha un costo di base inferiore, lasciando più "margine" per un attaccante da gonfiare.

Contributo per Componente (Ablazione)

• Selezione del Percorso vs. Perturbazione: Il contributo della Fase 1 (selezione del percorso) varia in base all'allineamento tra il bias naturale delle classi del rilevatore e la classe vulnerabile al percorso.
  • Nella Conservazione della Fauna Selvatica, dove il rilevatore favorisce naturalmente la classe costosa "Elefante", rimuovere la selezione del percorso riduce l'amplificazione solo del 6% (la Fase 2 da sola recupera il 94%).
  • Nel Monitoraggio del Traffico, dove il rilevatore favorisce la classe economica "Persona" ma il percorso costoso "Auto" è il target, rimuovere la selezione del percorso riduce l'amplificazione del 58%.
• Conclusione: La selezione del percorso è il primitivo algoritmico critico che manca strutturalmente agli attacchi a singolo modello.

Distribuzione Realistica di Produzione e Difese

Gli autori hanno valutato AESOP contro una pipeline di traffico realistica di produzione caratterizzata da buffering limitato, inferenza in batch e soglie di confidenza.

• Collasso del Throughput: Senza difese, attacchi sostenuti riducono il throughput da 0,578 input/s a 0,006 input/s (una riduzione di 96×).
• Fallimento delle Difese:
  • Soglia di Confidenza e Batching: Forniscono un recupero trascurabile. Il batching ammortizza l'overhead per chiamata ma non riduce il calcolo totale; le soglie di confidenza falliscono perché AESOP genera rilevamenti ad alta confidenza per progettazione.
  • Buffering Limitato: Ripristina il throughput (a ~0,3–0,4 input/s) ma solo drogando silenziosamente il 96,7% dei rilevamenti. L'attacco non è neutralizzato ma reindirizzato dall'esaurimento delle risorse computazionali alla perdita di dati.
  • Preprocessing dell'Input (Rumore/Lisciatura): Riduce il guadagno ma non elimina il meccanismo; il carico di lavoro LPR rimane 4–6× sopra la baseline.
  • Filtraggio Basato su ML (SVM): Fallisce in modo bimodale a bassi rapporti di attacco e degrada alle prestazioni senza difesa ad alti rapporti.

5. Significato e Affermazioni

Il documento afferma che la vulnerabilità è strutturale e risiede nel livello di instradamento tra i moduli, un livello dove le attuali difese a livello di modello non hanno visibilità.

• Punto Cieco Strutturale: Le difese esistenti operano su preprocessing a livello di immagine o schedulazione a livello di sistema, ma falliscono nell'osservare o vincolare come il carico di lavoro viene instradato tra i moduli.
• Impatto Operativo: L'attacco forza un compromesso: i sistemi devono scegliere tra il collasso del throughput o il mantenimento del throughput sacrificando la copertura di rilevamento (perdita silenziosa di dati).
• Direzione Futura: Una mitigazione efficace richiede meccanismi consapevoli dell'instradamento (ad esempio, budget di carico di lavoro per percorso, rilevamento di anomalie sulle distribuzioni di utilizzo del percorso o instradamento vincolato dalla fiducia) che attualmente non sono esposti dai framework standard delle pipeline. Gli autori sottolineano che trattare il carico di lavoro per percorso come una quantità operativa di prima classe è necessario per la difesa.

Il documento conclude che, sebbene l'attacco sia potente, il suo contributo principale è esporre una vulnerabilità sistemica nell'architettura delle moderne pipeline di ML che è stata trascurata dalla ricerca sulla sicurezza a singolo modello.