💻 computer science

ContractBench: Can LLM Agents Preserve Observation Contracts?

Questo articolo introduce ContractBench, un benchmark deterministico che rivela come gli attuali agenti LLM all'avanguardia falliscano frequentemente nel preservare la validità temporale e l'integrità a livello di byte dei contratti di osservazione (come i token di sessione e gli URL), una capacità che non scala in modo monotono con la dimensione del modello e richiede un addestramento specifico consapevole degli errori per essere migliorata.

Autori originali: Jicheng Wang, Yifeng He, Zili Wang, Hanwen Xing, Arkaprava De, Hao Chen

Pubblicato 2026-05-19

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jicheng Wang, Yifeng He, Zili Wang, Hanwen Xing, Arkaprava De, Hao Chen

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

L'Idea Principale: Il Problema del "Passaggio Digitale"

Immagina di assumere un assistente robot molto intelligente, ma leggermente goffo, per eseguire delle commissioni per te. Gli dici: "Vai in banca, prendi una chiave temporanea e usa quella chiave per aprire la cassaforte."

Nel mondo reale, se il robot lascia cadere la chiave, ne cambia la forma o tenta di usarla dopo che è scaduta, la cassaforte non si aprirà. Il robot ha fallito, non perché non sapesse cosa fare, ma perché non è riuscito a gestire i dettagli specifici del passaggio.

Questo documento definisce questi dettagli "Contratti di Osservazione".

Il Contratto: Quando uno strumento (come un'API bancaria) fornisce al robot un pezzo di dati (come una password temporanea o un link firmato), quei dati arrivano con due regole invisibili:
1. La Data di Scadenza: Devi usarlo ora, altrimenti diventa inutile.
2. La Regola "Non Toccare": Devi copiarlo esattamente, lettera per lettera. Se cambi anche una virgola o uno spazio, si rompe.

Gli autori hanno scoperto che anche gli agenti AI più intelligenti di oggi sono terribili nel seguire queste regole. Spesso lasciano cadere la chiave, la fondono o tentano di usarla il giorno dopo.

Il Nuovo Test: CONTRACTBENCH

Per dimostrarlo, i ricercatori hanno costruito un nuovo test chiamato CONTRACTBENCH. Pensalo come una "prova di guida" per agenti AI, ma invece di guidare un'auto, devono navigare un percorso a ostacoli digitale dove ogni passo richiede di passare un pacchetto fragile e sensibile al tempo alla persona successiva.

Il Percorso: Comprende 33 scenari diversi (come scaricare un file con un link che muore in 10 secondi, o accedere con un codice che deve essere digitato perfettamente).
Le Regole: Il test è eseguito da un programma informatico rigoroso (nessun giudice umano). Utilizza un "orologio virtuale" per vedere se l'agente è troppo lento e un "scanner digitale delle impronte" per vedere se l'agente ha cambiato una singola lettera nel codice.
Il Punteggio: Se l'agente supera il limite di tempo o sbaglia l'ortografia del codice, fallisce.

Cosa Hanno Scoperto (I Risultati)

I ricercatori hanno testato 38 diversi modelli AI (inclusi i più nuovi e famosi di OpenAI, Anthropic, Google e team open-source). Ecco cosa hanno scoperto, tradotto in termini quotidiani:

1. Anche i Robot "Più Intelligenti" Falliscono

Il Risultato: Nessun modello ha superato l'80% del test. Il migliore (Claude Opus 4.6) ha ottenuto circa il 78%.
L'Analogia: Immagina lo studente più intelligente del mondo che sostiene un test di matematica. Può risolvere problemi di calcolo complesso, ma se gli chiedi di copiare un numero di 10 cifre perfettamente senza fare errori di battitura, sbaglia comunque il 22% delle volte. Essere "intelligenti" non significa essere "attenti".

2. La "Soglia Magica" (Qwen 3.5)

Il Risultato: In una specifica famiglia di modelli (Qwen 3.5), c'è stato un salto improvviso di capacità. Il modello piccolo da 4 miliardi di parametri ha ottenuto 0% di correttezza. Il modello leggermente più grande da 9 miliardi è saltato al 56%.
L'Analogia: È come un personaggio di un videogioco che è inutile finché non raggiunge il Livello 9. Al Livello 8, non riesce nemmeno a tenere la chiave. Al Livello 9, improvvisamente impara a tenerla delicatamente. Non è stato un miglioramento lento; è stato un improvviso "risveglio" di una competenza specifica chiamata autocontrollo (sapere non modificare i dati).

3. Più Grande Non è Sempre Meglio (L'Altalena di GPT-5)

Il Risultato: Mentre la famiglia di modelli GPT-5 evolveva, le loro prestazioni sono salite, poi crollate, poi risalite.
L'Analogia: Immagina uno chef che riceve un nuovo libro di ricette.

Chef A (GPT-5): Prepara una torta perfetta.
Chef B (GPT-5.1): Ottiene una versione "più intelligente" del libro ma inizia ad aggiungere troppo zucchero e rovina la ricetta (in particolare, hanno iniziato a modificare gli ingredienti invece di copiarli).
Chef C (GPT-5.2): Ripara la ricetta e torna a preparare torte perfette.
Il documento suggerisce che rendere un AI "più intelligente" o "più conversazionale" può talvolta renderlo peggiore nel seguire regole rigide e noiose.

4. I Modelli "Base" Non Riescono a Farlo

Il Risultato: I modelli che non sono stati "addestrati" a chattare o seguire istruzioni (modelli Base) hanno ottenuto lo 0% nel test. Solo i modelli che erano stati insegnati a seguire le istruzioni (modelli Instruct) potevano superare il test.
L'Analogia: Un blocco grezzo di argilla (modello Base) non può mantenere una forma. Devi scolpirla (Post-training) per farla reggere una tazza d'acqua. La capacità di seguire questi contratti non è naturale; deve essere insegnata.

5. L'"Indizio" Funziona

Il Risultato: Quando i ricercatori hanno detto all'AI esattamente cosa aveva sbagliato (ad esempio: "Hai cambiato una lettera nel codice"), l'AI ha potuto correggere il suo errore e superare il test.
L'Analogia: Se dici a un bambino: "Hai lasciato cadere la palla", potrebbe riprovare e afferrarla. Ma se dici solo: "Riprova", potrebbe lasciarla cadere di nuovo. Il feedback specifico è stata la chiave per correggere l'errore.

Perché Questo È Importante (Secondo il Documento)

Il documento sostiene che abbiamo continuato a testare l'AI su se riesce a "risolvere un enigma" o "scrivere una storia". Ma nel mondo reale, gli agenti AI sono spesso usati per svolgere lavori in cui la precisione è tutto.

Se un agente AI sta gestendo il tuo conto bancario, non può permettersi di cambiare una singola cifra in un codice di transazione. Se sta gestendo un server, non può permettersi di usare una password scaduta.

La Conclusione: Gli attuali agenti AI sono come stagisti brillanti ma goffi. Capiscono il quadro generale, ma continuano a lasciar cadere gli strumenti fragili che vengono loro affidati. Per renderli affidabili per lavori nel mondo reale, dobbiamo smettere di renderli semplicemente "più intelligenti" e iniziare a insegnar loro a essere più attenti e più precisi con i contratti digitali che ricevono.

Riepilogo Tecnico: CONTRACTBENCH

Definizione del Problema: Contratti di Osservazione

Gli agenti basati su Modelli Linguistici di Grande Dimensione (LLM) sono sempre più impiegati per eseguire flussi di lavoro multi-step che coinvolgono API esterne. Sebbene i benchmark esistenti valutino se gli agenti possano raggiungere uno stato finale di obiettivo, spesso trascurano una modalità di fallimento critica in produzione: la violazione dei contratti di osservazione.

Un contratto di osservazione è definito come un artefatto restituito da uno strumento (ad esempio, un URL firmato in anticipo, un parametro di stato OAuth, un token di sessione o un webhook protetto da HMAC) che trasporta due vincoli ortogonali imposti dal sistema esterno:

Validità Temporale: L'artefatto deve essere utilizzato entro una finestra temporale specifica (Time-to-Live, TTL) prima di scadere o diventare obsoleto.
Integrità a Livello di Byte: L'artefatto deve essere trasmesso byte per byte senza alterazioni. Le pile di agenti reali introducono spesso mutazioni attraverso la ricodifica degli URL, il riordinamento dei parametri, l'intercettazione o il ritorno a capo, che invalidano le firme o i checksum.

I benchmark attuali non riescono a testare congiuntamente questi vincoli. Tendono a trattare gli output degli strumenti come semplici informazioni per la decisione successiva, permettendo agli agenti di parafrasare o perdere artefatti intermedi senza penalità. Nella realtà, una singola violazione della validità (utilizzo di un token scaduto) o dell'integrità (corruzione di una firma) invalida l'intero flusso di lavoro.

Metodologia: CONTRACTBENCH

Per colmare questa lacuna, gli autori introducono CONTRACTBENCH, un benchmark deterministico progettato per misurare la conformità ai contratti di osservazione.

Progettazione del Benchmark

Ambito: 33 task a due assi derivati da pattern reali di contratti API, inclusi URL firmati in anticipo, flussi OAuth, richieste firmate, webhook HMAC e finestre di limitazione della velocità.
Valutazione a Due Assi: I task sono categorizzati in quattro quadranti in base alla pressione che esercitano:
- Q1 (Controllo): Bassa pressione su validità/integrità (controlli di sanità mentale).
- Q2 (Validità): Isola la pianificazione temporale (ad esempio, gestione della manutenzione programmata o dei limiti di velocità).
- Q3 (Integrità): Isola la preservazione dei byte (ad esempio, gestione di token lunghi o trappole negli URL).
- Q4 (Asse Doppio): Sottopone entrambi gli assi a stress simultaneamente, riflettendo la prevalenza di artefatti limitati nel tempo e vincolati da firme in produzione.
Ambiente di Esecuzione: I task vengono eseguiti sotto un orologio virtuale per garantire la piena riproducibilità. Un server FastAPI emette etichette di fallimento deterministiche basate su specifiche API reali (ad esempio, AWS SigV4, OAuth 2.0, RFC 6585).
Protocollo di Valutazione:
- Validatori Deterministici: Nessun valutatore umano o "LLM come giudice". Un validatore programmatico consuma i log delle richieste HTTP per verificare se ogni osservazione soddisfi sia la finestra di validità che il predicato di integrità (controllo dell'hash SHA-256).
- Tassonomia dei Fallimenti: Una tassonomia a 15 etichette classifica i fallimenti in Validità (ad esempio, EXPIRED_BEFORE_USE, RATE_LIMITED), Integrità (ad esempio, MUTATED_TOKEN, SIGNATURE_MISMATCH) e categorie Meta.
- Risolvibilità: Ogni task include una soluzione oracolare che supera il validatore, dimostrando che il task è risolvibile.

Configurazione Sperimentale

Gli autori hanno valutato 38 varianti di modello su 15 famiglie, inclusi modelli proprietari all'avanguardia (Claude, serie GPT-5, Gemini) e modelli open-source addestrati all'istruzione (Qwen, Mistral, Gemma, Llama, DeepSeek). Ogni modello è stato eseguito sull'intera suite di 33 task con $k=3$ esecuzioni per task ( $n=99$ episodi per modello) a temperatura 0.

Risultati Chiave

1. I Modelli All'Avanguardia Falliscono nei Contratti di Osservazione

Nessun modello valutato supera l'80% sull'intera suite. Il miglior esecutore, Claude Opus 4.6, raggiunge il 77,8%. Ciò rivela che anche i modelli più avanzati faticano a preservare gli artefatti intermedi. Inoltre, la classificazione su CONTRACTBENCH non correla con i benchmark generici; ad esempio, Gemini 2.5 Flash e GPT-5.1 performano peggio di diversi modelli open-source, mentre Llama-3.3-70B ottiene un punteggio vicino allo 0%.

2. Barriera Emergente delle Capacità in Qwen 3.5

Si osserva una netta "barriera delle capacità" all'interno della famiglia Qwen 3.5. Le prestazioni passano dallo 0% a 4 miliardi di parametri al 56,6% a 9 miliardi, scalando in modo regolare fino al 70,7% a 397B-A17B. Sotto la barriera, gli agenti non riescono a mostrare autocontrollo a metà traiettoria (ad esempio, attendere le finestre di manutenzione); sopra di essa, dimostrano un recupero adattivo. Ciò suggerisce che la capacità è legata a specifiche ricette di addestramento piuttosto che al solo numero di parametri.

3. L'Addestramento Post-Training è Necessario ma Fragile

Necessità: I modelli base (non addestrati all'istruzione) di tutte le famiglie ottengono lo 0%, indicando che la conformità ai contratti è una capacità post-training, non una proprietà emergente pre-training.
Fragilità (Scalatura Inversa): La famiglia GPT-5 mostra una regressione non monotona a forma di "V". GPT-5.1 registra un calo significativo nella conformità (48,5%) rispetto a GPT-5 (70,7%) e GPT-5.2 (74,8%). Questa regressione è strutturata: GPT-5.1 re-introduce specificamente fallimenti a livello di integrità (ad esempio, WRONG_VALUE, MUTATED_TOKEN), suggerendo che gli aggiornamenti post-training mirati all'efficacia conversazionale possono erodere inibizioni specifiche necessarie per la conformità ai contratti (ad esempio, attendere prima di riprovare, preservare i byte esattamente).

4. Segnali di Ricompensa Azionabili

Gli autori hanno testato se le etichette di fallimento potessero servire come segnali di ricompensa in contesto. Utilizzando 42 fallimenti di GPT-5.1, hanno scoperto che fornire l'etichetta di fallimento corretta come suggerimento di coaching ha migliorato i tassi di successo di +7,1 punti percentuali rispetto a un suggerimento con etichetta errata. Ciò indica che la tassonomia fornisce segnali direzionali e azionabili per la correzione al momento del test, in particolare per i fallimenti di tipo integrità, mentre i fallimenti temporali spesso richiedono interventi architetturali (ad esempio, TTL leggibili dalla macchina) piuttosto che semplici prompt.

Significato e Contributi

Il paper rivendica tre contributi principali:

Formalizzazione dei Contratti di Osservazione: Gli autori definiscono i contratti di osservazione come una classe distinta di fallimento degli agenti governata da vincoli temporali e di integrità ortogonali, formalizzando un problema precedentemente trascurato nella letteratura sulla valutazione degli agenti.
Benchmark CONTRACTBENCH: Forniscono il primo benchmark deterministico e programmatico per questa capacità, caratterizzato da 33 task, una tassonomia di fallimenti a 15 etichette e un modello di esecuzione con orologio virtuale che elimina l'ambiguità dei giudici umani/LLM.
Insight Empirici sulla Robustezza degli Agenti: Lo studio rivela che la conformità ai contratti è una capacità emergente e non monotona, che non è garantita dalla capacità generale di utilizzo degli strumenti né migliorata costantemente dalla scalatura. Evidenzia che un addestramento post-training "utile" può regressare inibizioni specifiche richieste per un'interazione API affidabile, e che i modelli all'avanguardia attuali rimangono irrisolti su questa metrica critica di affidabilità.

Gli autori concludono che i contratti di osservazione devono diventare un obiettivo di valutazione di primo piano per garantire che gli agenti possano agire in modo affidabile sotto i vincoli inter-step imposti da sistemi esterni reali. Suggeriscono che mitigare questi fallimenti potrebbe richiedere cambiamenti architetturali (ad esempio, archiviazione di artefatti basata su handle) piuttosto che affidarsi esclusivamente a modelli più grandi o meglio sintonizzati.