Instruction fragility under hidden operational requirements

Sintesi Tecnica: Fragilità delle Istruzioni sotto Requisiti Operativi Nascosti

Definizione del Problema
Il documento affronta il problema della fragilità delle istruzioni derivante da requisiti operativi nascosti. Nelle interazioni in linguaggio naturale con i Large Language Models (LLM), gli utenti spesso omettono vincoli che sono noti a loro o ai valutatori ma assenti dal prompt (ad esempio, formati di output specifici, limiti di parole, etichette di rischio o limitazioni delle fonti). Gli autori formalizzano questo fenomeno non come un singolo esito intenzionale, ma come una semantica a valori di insieme: un'istruzione denota un insieme di esecuzioni ammissibili. La sicurezza sotto tale sottospecificazione richiede che ogni esecuzione ammissibile all'interno di tale insieme rientri nell'insieme accettabile dell'utente. Se l'istruzione consente anche una sola esecuzione inaccettabile (ad esempio, un metodo fraudolento per "rendermi ricco"), l'istruzione non è robusta. Il problema centrale è che le istruzioni finite non possono identificare univocamente una singola esecuzione intenzionale senza trasmettere tutti i vincoli latenti.

Metodologia
Lo studio combina un quadro teorico formale con un benchmark empirico controllato.

1. Quadro Formale:

   • Gli autori definiscono un'istruzione $s$ come avente una denotazione $J_sK_B \subseteq H$ (un insieme di storie ammissibili) sotto una teoria di base $B$.
   • La sicurezza è definita dal criterio di sicurezza avversaria: $J_sK_B \subseteq A_{\tau, \eta}$, dove $A_{\tau, \eta}$ è l'insieme delle storie accettabili (che soddisfano le soglie di utilità e i budget di effetti collaterali).
   • Le analisi teoriche derivano limiti inferiori informativi (richiedono $\Omega(\log N)$ simboli per distinguere $N$ intenzioni), vincoli di cardinalità (le istruzioni finite non possono denotare sottoinsiemi arbitrari di spazi di esecuzione infiniti) e complessità computazionale (la sintesi sicura mappa sul problema Set Cover, che è NP-completo).

2. Costruzione del Benchmark:

   • È stato creato un benchmark di 100 task, che copre 20 domini tematici (ad esempio, memo politici, risposta agli incidenti, note finanziarie).
   • Ogni task consiste in un prompt visibile dell'utente e un set di requisiti nascosti (da 2 a 5 per task) noti al valutatore ma omessi dal prompt.
   • I requisiti sono categorizzati in tre tipi:
     • Impliciti convenzionali: Assunzioni, incertezza, trade-off, livelli di rischio.
     • Operativi: Limiti di parole, limiti di fonti.
     • Formattazione privata: JSON valido, conteggio esatto dei punti elenco.
   • Un "passaggio rigoroso" è definito come il soddisfacimento di ogni requisito nascosto in un task.

3. Protocolli Sperimentali:
   Lo studio ha valutato tre modelli (GPT-5.4, Claude Opus 4.7, Gemini 3.1 Pro) attraverso nove condizioni:

   • Bassa Informazione: Prompt one-shot, template generici e chiarificazione di controllo negativo (domande forzate con risposte "nessun vincolo nascosto").
   • Elicitazione: Chiarificazione forzata (risposte veritiere a domande basate su menu) e verifica (checklist visibili o interne).
   • Condizioni Oracle: Oracle con budget (rivelazione di fino a 4 requisiti nascosti) e Full Oracle (rivelazione di tutti i requisiti nascosti).

Risultati Chiave
I risultati empirici, basati su 2.700 osservazioni task–modello–condizione, rivelano un netto contrasto tra l'interazione generica e la rivelazione dei veri vincoli:

• Fallimento dell'Interazione Generica: Il prompting one-shot ha ottenuto un tasso di passaggio rigoroso di solo il 2,7% (8/300 prove). I template generici (7,3%) e la chiarificazione di controllo negativo (1,7%) hanno offerto miglioramenti trascurabili. Ciò indica che l'interazione senza informazioni rilevanti per il task non recupera i vincoli omessi.
• Valore della Corretta Elicitazione: La rivelazione dei corretti requisiti nascosti ha prodotto un salto qualitativo nelle prestazioni. La condizione Full Oracle ha raggiunto un tasso di passaggio rigoroso del 64,7%. La condizione Budgeted Oracle (rivelazione parziale) ha raggiunto il 54,0%.
• Fallimento dell'Elicitazione: Anche quando i modelli erano costretti a porre domande (Forced Clarify), hanno ottenuto solo un tasso di passaggio dell'8,0%. Il divario tra Forced Clarify e Budgeted Oracle (46,0 punti percentuali) dimostra che i modelli falliscono frequentemente nell'identificare quali vincoli latenti siano rilevanti, ponendo le domande sbagliate o omettendo quelle critiche (ad esempio, i limiti delle fonti sono stati richiamati solo l'1,0% delle volte).
• Fallimento dell'Esecuzione: Anche in condizioni di Full Oracle, dove tutti i requisiti erano noti, il tasso di passaggio non ha raggiunto il 100% (64,7%). Ciò indica un secondo modo di fallimento: la conformità ai vincoli noti, dove i modelli non riescono a eseguire l'intera specifica anche quando viene fornita esplicitamente.
• Fallimento Composto: I tassi di passaggio rigoroso sono crollati in modo moltiplicativo all'aumentare del numero di requisiti nascosti. Per i protocolli a bassa informazione, i tassi di passaggio sono scesi quasi a zero per i task con 3–5 requisiti.
• Specificità dei Requisiti: I requisiti di formattazione privata (JSON, conteggio dei punti elenco) erano quasi impossibili da recuperare senza divulgazione (0% in one-shot), mentre i requisiti convenzionali (incertezza, evitare assoluti) erano parzialmente inferiti ma comunque inaffidabili.

Significato e Rivendicazioni
Il documento sostiene di aver identificato un modo di fallimento controllato per la conformità operativa rigorosa nei sistemi di IA. I suoi principali contributi sono:

1. Formalizzazione della Fragilità delle Istruzioni: Fornisce un quadro denotazionale a valori di insieme che mostra come la robustezza richieda l'esclusione di tutte le esecuzioni inaccettabili, non solo l'inclusione di una buona esecuzione.
2. Diagnosi del Fallimento della Comunicazione: I risultati dimostrano che il collo di bottiglia nell'esecuzione delle istruzioni non è semplicemente la mancanza di turni di dialogo, ma la qualità dell'informazione elicitata. La chiarificazione generica è insufficiente; è necessaria un'elicitazione mirata dei requisiti.
3. Riformulazione di Template e Verifica: Lo studio suggerisce che i template di prompt e le checklist di verifica generiche forniscono solo guadagni marginali. Non possono sostituire la comunicazione esplicita dei vincoli privati specifici del task.
4. Implicazioni per la Sicurezza: Le scoperte supportano il principio di progettazione secondo cui gli assistenti IA robusti richiedono l'elicitazione esplicita dello stato dei requisiti, l'integrazione fedele di tali vincoli e la verifica rispetto a tale stato, piuttosto che affidarsi a prompt più lunghi o interazioni generiche.

Gli autori mantengono un ambito modesto, notando che il benchmark è sintetico e puramente testuale, focalizzato su vincoli verificabili superficialmente. Non pretendono di misurare il comportamento di un agente a lungo raggio o la qualità soggettiva, ma piuttosto di isolare il modo di fallimento specifico dei requisiti operativi omessi. I risultati suggeriscono che gli attuali modelli all'avanguardia, pur essendo capaci, non sono chiaroveggenti e non possono recuperare in modo affidabile i vincoli omessi senza una comunicazione esplicita.