Sintesi Tecnica: IH-BENCHMARK

Definizione del Problema

Man mano che i Large Language Models (LLM) evolvono in agenti capaci di orchestrare strumenti e gestire conversazioni multi-turno, l'affidabilità della robustezza della gerarchia delle istruzioni è diventata centrale sia per la sicurezza che per l'utilità. Il problema fondamentale affrontato è la capacità del modello di dare la corretta priorità alle istruzioni in base alla loro origine: i messaggi di sistema dovrebbero avere la precedenza sugli input dell'utente, che a loro volta dovrebbero avere la precedenza sulla cronologia della chat e sugli output degli strumenti.

Quando i modelli non rispettano questo ordine, input utente avversari possono sovrascrivere i vincoli di sistema, e output malevoli degli strumenti possono dirottare il comportamento del modello nel mezzo di un compito. Sebbene lavori precedenti abbiano formalizzato questa gerarchia, le valutazioni esistenti soffrono di due limitazioni primarie:

1. Focus su un singolo arco: Molti benchmark si concentrano solo sui conflitti sistema-utente ($S \succ U$), trascurando i conflitti derivanti dagli output degli strumenti.
2. Dataset adattati: Altri adattano dataset pubblici invece di costruire scenari di conflitto gerarchico appositamente progettati, risultando in una copertura limitata per gli ambienti agentici e per vincoli specifici come liste di ammissione/esclusione di strumenti o restrizioni dei parametri.

Di conseguenza, vi è una mancanza di benchmark che testino congiuntamente i conflitti attraverso i livelli della gerarchia in un contesto agentico.

Metodologia: IH-BENCHMARK

Gli autori introducono IH-BENCHMARK (IH-B), un benchmark creato ad hoc progettato per valutare la robustezza della gerarchia delle istruzioni attraverso due percorsi distinti:

1. Sistema $\succ$ Utente ($S \succ U$): Valuta se un modello preserva un vincolo di sistema a priorità superiore quando un utente emette una richiesta conflittuale.
2. Utente $\succ$ Strumento ($U \succ T$): Valuta se un modello preserva il compito dell'utente quando un'istruzione conflittuale appare in un output di uno strumento a priorità inferiore.

Costruzione e Ambito

• Famiglie di Vincoli: Il benchmark è costruito da una tassonomia autoriale di 44 famiglie di vincoli suddivise in cinque domini: generico, salute, finanza, vendita al dettaglio e programmazione.
  • Percorso $S \succ U$: 19 famiglie che coprono vincoli di output (lessicali, formato), vincoli di argomento (argomenti proibiti, deviazione verso competitor) e vincoli di strumenti (divieti generalizzati, restrizioni dei parametri).
  • Percorso $U \succ T$: 25 famiglie che coprono la manipolazione del formato di risposta, la manipolazione del contenuto (alterazione fattuale), la manipolazione degli strumenti (blocco/reindirizzamento delle chiamate) e azioni agentiche ad alta gravità (esecuzione di comandi, esfiltrazione di dati, acquisti non autorizzati).
• Generazione di Scenari: IH-B genera proceduralmente 2.336 scenari eseguibili (734 in $S \succ U$, 1.602 in $U \succ T$). Gli scenari sono generati legando i parametri dei vincoli e variando:
  • Rigidezza del Vincolo ($L$): Da semplici dichiarazioni ($L_1$) a clausole rafforzate e direttive di rifiuto ($L_3$).
  • Formulazione del Prompt ($P$): Richieste utente esplicite ($P_1$) vs implicite ($P_2$).
  • Variante di Consegna ($D$): Per $U \succ T$, variando il modo in cui le istruzioni conflittuali sono incorporate negli output degli strumenti (plain, breakout, acknowledge, switch).
• Simulatori di Agenti: Per gli scenari agentici $U \succ T$, il benchmark impiega tre simulatori basati su Python e dotati di stato (coding, retail, supporto sanitario) per modellare effetti collaterali persistenti e interazioni multi-step con gli strumenti.
• Protocollo di Valutazione: Viene utilizzato un protocollo uniforme di passaggio/fallimento binario.
  • DSL del Predicato: Un linguaggio specifico del dominio leggero valuta il matching delle stringhe, i controlli strutturali e l'ispezione delle chiamate agli strumenti.
  • LLM-as-a-Judge: Utilizzato selettivamente per le categorie in cui la verifica meccanica è difficile (ad esempio, disparaging di marca, impegno su un argomento), utilizzando una rubrica a 4 livelli mappata su decisioni binarie.
  • Scenari di Non-Conflitto: Inclusi per misurare il rifiuto eccessivo (over-refusal) e garantire che i modelli non falliscano richieste ordinarie a causa della sensibilità ai vincoli.

Contributi Chiave

1. Benchmark Procedurale: La proposta di IH-B, che copre sia i percorsi $S \succ U$ che $U \succ T$ con 2.336 scenari derivati da 44 famiglie di vincoli.
2. Framework di Valutazione Unificato: Un sistema che combina scenari controllati a livello di prompt con simulatori di agenti dotati di stato, consentendo la valutazione in contesti statici, mediati da strumenti e agentici.
3. Analisi Empirica Completa: Valutazione di 37 varianti di modelli (22 closed-source, 15 open-weight) che rivela come la robustezza della gerarchia delle istruzioni non sia una singola capacità, ma un insieme di comportamenti che variano tra superfici di conflitto e tipi di vincolo.

Risultati

La valutazione di 37 modelli rivela una variazione significativa nelle prestazioni, con tassi di conformità complessivi che vanno dal 98,2% al 20,5%.

• Dissociazione dei Percorsi: Un'elevata prestazione sul percorso $S \succ U$ non è un proxy affidabile per la robustezza $U \succ T$. Ad esempio, Grok 4.20 (R) ha ottenuto una conformità del 96,9% su $S \succ U$ ma solo del 65,6% su $U \succ T$. Ciò suggerisce che resistere ai superamenti diretti dell'utente non garantisce la resistenza all'iniezione di output degli strumenti.
• Disparità tra Modelli: I modelli closed-source hanno generalmente superato i modelli open-weight. La conformità media per i modelli closed-source è stata dell'88,6% ($S \succ U$) e del 75,1% ($U \succ T$), rispetto all'80,5% e 59,1% per i modelli open-weight.
• Effetti della Rigidezza del Vincolo:
  • In $S \succ U$, vincoli più rigidi ($L_2, L_3$) hanno costantemente migliorato la conformità, in particolare per i modelli più deboli (ad esempio, Qwen 3 235B-A22B è passato dal 23,5% all'88,2% in contesti specifici del dominio).
  • In $U \succ T$, l'effetto dell'indurimento è stato meno uniforme. Mentre alcuni modelli (ad esempio, Grok 4.20 (R)) hanno mostrato guadagni massicci (dal 18,8% all'89,6%), altri (ad esempio, Qwen 3 235B-A22B) sono rimasti vicini al 10% attraverso tutti i livelli di rigidezza, indicando un'incapacità fondamentale di mantenere i confini piuttosto che una semplice sensibilità alle istruzioni.
• Analisi delle Famiglie di Vincoli:
  • $S \succ U$: La famiglia più difficile è stata forbid-tools-all (52,4%), dove i modelli faticano a rifiutare tutte le chiamate agli strumenti nonostante le richieste dell'utente. I vincoli di argomento sono stati i più facili (ad esempio, forbid-disparagement al 98,6%).
  • $U \succ T$: Le famiglie più difficili hanno riguardato azioni a basso rischio e non sospette come content-lie (50,1%) e format-disclaimer (50,4%). Al contrario, le azioni ad alta gravità come acquisti non autorizzati o chiusure di massa di biglietti sono state resistere più affidabilmente (ad esempio, purchase all'88,1%), probabilmente a causa dell'esistente addestramento all'allineamento della sicurezza.
• Sottigliezza dei Fallimenti: I fallimenti più rivelatori sono stati spesso sottili (ad esempio, disclaimer iniettati, piccole distorsioni fattuali) piuttosto che azioni apertamente pericolose. I modelli sono stati più affidabili nel resistere ad azioni di massa non autorizzate che nel rilevare sottili derive fattuali.

Significato e Limitazioni

L'articolo sostiene che la robustezza della gerarchia delle istruzioni non è una singola capacità uniforme, ma una collezione di comportamenti che devono essere valutati attraverso molteplici superfici di conflitto, tipi di vincolo e presentazioni di attacco. Il rilascio di IH-B, inclusi il corpus, i simulatori e l'armatura di valutazione, mira a supportare la valutazione e la distribuzione responsabile aiutando gli sviluppatori a identificare debolezze specifiche del modello o dello scenario prima del deployment.

Limitazioni:

• Il benchmark si concentra su scenari a compito singolo limitati e non copre impostazioni multi-turno più lunghe dove il contesto si accumula nel tempo.
• La copertura del dominio è selezionata e asimmetrica in base a dove ogni dominio si inserisce naturalmente nel percorso (ad esempio, la finanza è solo in $S \succ U$, la programmazione solo in $U \succ T$).
• Sebbene 35 delle 44 famiglie di vincoli siano state scritte manualmente, le restanti sono state suggerite da un LLM e revisionate manualmente, il che significa che la copertura è ampia ma non esaustiva.

Gli autori riconoscono che rivelare le debolezze specifiche dei modelli comporta dei rischi di agevolare gli avversari, ma sostengono che il beneficio di una valutazione della sicurezza sistematica e riproducibile superi tali rischi.