What Benchmarks Don't Measure: The Case for Evaluating Abstention Competence in Autonomous Agents

Sintesi Tecnica: Ciò che i Benchmark non Misurano: Il Caso dell'Valutazione della Competenza di Astensione negli Agenti Autonomi

Problematica
I paradigmi di valutazione attuali sono sistematicamente ciechi di fronte a una modalità di fallimento critica: procedere quando un agente dovrebbe invece fermarsi. I benchmark dominanti misurano il successo del compito (tassi di completamento, conteggio dei passi, accuratezza delle risposte), ma mancano di scenari in cui il comportamento corretto rispetto alla verità di base (ground-truth) sia l'astensione. Di conseguenza, gli agenti addestrati sotto obiettivi di feedback umano sviluppano un "bias di conformità" strutturale: una tendenza a procedere anche quando mancano gli input, le prove o l'autorizzazione necessari. Questo bias è radicato perché i regimi di punteggio dei benchmark trattano il procedere come l'azione corretta predefinita, spesso penalizzando gli agenti per essersi fermati (ad esempio, tramite budget di passi fissi) o non distinguendo una pausa principesca da un fallimento silenzioso. Il documento sostiene che questo vuoto di valutazione impedisce lo sviluppo di agenti capaci di un' "astensione informata", portando a cambiamenti di stato irreversibili e pericolosi in ambienti aziendali.

Metodologia
Gli autori propongono un framework per valutare e imporre l' "astensione informata", definita come una pausa strutturata innescata da specifiche condizioni non soddisfatte piuttosto che da una generica fiducia astratta.

1. Tassonomia degli Scenari che Motivano l'Astensione: Il documento introduce una tassonomia a tre lacune per categorizzare quando un agente dovrebbe fermarsi:

   • Lacuna di Specificazione (Specification Gap): Le informazioni richieste sono assenti (definite dallo schema dello strumento, non dalla fiducia del modello). La risposta appropriata è la chiarificazione mirata.
   • Lacuna di Verifica (Verification Gap): L'agente non può confermare uno stato del mondo necessario prima di agire. La risposta appropriata è un passo di verifica limitato.
   • Lacuna di Autorità (Authority Gap): L'azione richiede un'autorizzazione esplicita per un impegno vincolante o un cambiamento ad alto impatto. La risposta appropriata è una pausa di impegno per richiedere l'approvazione.

2. Protocolli di Valutazione: Per misurare la competenza di astensione, gli autori propongono tre metriche composte:

   • Tasso di Sicurezza (Safety Rate - SR): La frazione di scenari pericolosi in cui l'agente produce una risposta di blocco.
   • Tasso di Usabilità (Usability Rate - UR): La frazione di scenari sicuri in cui l'agente completa il compito senza attriti superflui.
   • Tasso di Rifiuto Informato (Informed Refusal Rate - IRR): La frazione di risposte di blocco che nomina esplicitamente la precondizione non soddisfatta, distinguendo una sicurezza calibrata da un rifiuto vago ed eccessivo.

3. Configurazione Sperimentale:

   • Dataset: 144 scenari per agenti aziendali derivati da 24 semi scritti da umani, aumentati per includere 120 scenari pericolosi (categorizzati per le tre lacune) e 24 controlli sicuri corrispondenti.
   • Modelli: Sette famiglie di modelli (GPT-4o, GPT-5.4-mini, Llama 3.1 8B, Claude Sonnet 4.6, Claude Opus 4.6, Gemini 2.5 Pro, Gemini 2.5 Flash) utilizzando un'architettura ReAct.
   • Condizioni: Sono state testate tre condizioni di valutazione:
     • Baseline: Nessuna politica di astensione.
     • Solo Prompt (Prompt-Only): Istruzioni di sicurezza tramite system prompt.
     • Checkpoint: Enforcement a runtime tramite un hook di pre-esecuzione (InformedAbstentionToolWrapper) che esegue controlli dello schema, polling dello stato e verifica dell'autorizzazione utilizzando un modello di guardia separato.

Risultati Chiave
I risultati preliminari attraverso 144 scenari e cinque famiglie di modelli rivelano scoperte significative riguardo al compromesso tra sicurezza e usabilità:

• Universal Compliance Bias: Tutti i modelli hanno mostrato un bias di conformità alla baseline, ma le modalità di fallimento variavano. Alcuni modelli (es. Llama 3.1 8B) tendevano di default a "procedere" (alta Usabilità, bassa Sicurezza), mentre altri (es. Claude Opus 4.6) tendevano di default a "rifiutare" (alta Sicurezza, usabilità quasi nulla).
• Il "Cliff" del Solo Prompt (The Prompt-Only Cliff): Fare affidamento esclusivamente sui system prompt per imporre la sicurezza si è rivelato inaffidabile. Per i modelli fortemente allineati alla sicurezza come Claude Opus 4.6, le politiche basate solo sul prompt hanno causato un "cliff di usabilità", facendo scendere il Tasso di Usabilità vicino allo 0% poiché i modelli interpretavano le istruzioni di sicurezza come override assoluti dell'intento dell'utente. Al contrario, alcuni modelli hanno mostrato un miglioramento della usabilità con i prompt, evidenziando che l'effetto dipende dal modello ed è imprevedibile.
• Efficacia dell'Enforcement a Runtime: La condizione Checkpoint (enforcement a runtime) ha ottenuto le prestazioni più elevate in tutti i modelli.
  • Sicurezza: Tutti i modelli sono confluiti in un Tasso di Sicurezza compreso tra l'88% e il 91%, suggerendo un limite strutturale in cui gli agenti rifiutano nativamente senza invocare strumenti.
  • Usabilità: L'enforcement a runtime ha recuperato drasticamente la usabilità per i modelli che precedentemente rifiutavano eccessivamente (es. +87,5 punti percentuali per GPT-4o e +70,9 per Claude Opus 4.6 rispetto alla condizione solo prompt).
  • Rifiuto Informato: L'architettura Checkpoint ha garantito il 100% di IRR per design, poiché il wrapper emetteva sempre una spiegazione strutturata per i blocchi, mentre i modelli baseline e solo prompt dipendevano da giudici LLM stimati e mostravano un IRR inferiore.
• Difficoltà della Lacuna di Verifica: La Lacuna di Verifica si è rivelata la tipologia di scenario più difficile per tutti i modelli alla baseline, con i maggiori guadagni osservati sotto la condizione Checkpoint, a supporto dell'ipotesi che l'autoconsapevolezza degradi sotto il cambiamento di distribuzione (distribution shift).

Significatività e Rivendicazioni
Il documento posiziona questi risultati come un lavoro preliminare inteso a stimolare ulteriore conversazione all'interno della comunità dei benchmark. I suoi contributi primari sono:

1. Contesto Teorico: Identificare che l'incapacità di misurare la competenza di astensione è un risultato diretto del reward hacking nelle pipeline di feedback umano e del design degli attuali benchmark.
2. Tassonomia e Metriche: Fornire un vocabolario principato (la tassonomia delle tre lacune) e un set di metriche composte (SR, UR, IRR) per rendere l'astensione visibile e valutabile.
3. Dimostrazione di Fattibilità: Dimostrare che il compromesso tra sicurezza e usabilità non è intrinseco ma regolabile, e che l'enforcement a runtime può risolvere simultaneamente le modalità di fallimento di "rifiuto eccessivo" e "rifiuto insufficiente".

Gli autori concludono che i benchmark devono evolversi per includere scenari in cui la pausa è la corretta verità di base. Senza tali cambiamenti, gli incentivi di addestramento continueranno a rafforzare il bias di conformità, impedendo lo sviluppo di agenti capaci di fermarsi in modo affidabile quando necessario. Gli strumenti proposti sono offerti come punto di partenza per testare la resistenza contro architetture di agenti e domini di implementazione più ampi.