The Pulse

TiGanEval: gli agenti perdono fino a 67 punti sui requisiti non esplicitati

Un nuovo benchmark verifica se gli agenti di IA sanno dedurre i requisiti che gli utenti omettono, ma che possono essere individuati in un progetto. Per otto modelli di frontiera, i tassi di successo sono scesi di 53-67 punti percentuali qu

AI.info Team · Scritto con l’IA · 2026-10-15

«Un agente dovrebbe quindi considerare l’istruzione come un indizio, non come l’obiettivo: dovrebbe dedurre i veri requisiti dall’istruzione e dall’ambiente e soddisfarli anche quando l’utente non ne è ancora consapevole».

Scrivono Kaiming Liu e i coautori di «Instructions Are Evidence, Not Objectives: Measuring Outcome Alignment of Agents».

La frase coglie il problema al centro di un nuovo benchmark: un agente di IA può seguire la richiesta di un utente e fallire comunque, perché la richiesta omette requisiti che si possono individuare nel progetto stesso. In un articolo presentato ad arXiv il 13 ottobre, i ricercatori introducono TiGanEval per misurare questo scarto, che chiamano «allineamento ai risultati».

Quando la richiesta omette la regola

TiGanEval assegna agli agenti compiti di ingegneria del software e di ricerca i cui requisiti sono stabiliti in anticipo, ma descritti solo in parte nell’istruzione iniziale. I requisiti mancanti devono poter essere individuati nell’ambiente di lavoro, tra cui il codice, i registri e il comportamento del programma in esecuzione. Un utente simulato può aggiungere informazioni dopo aver visto le conseguenze di quanto presentato dall’agente, permettendo ai ricercatori di confrontare ciò che l’agente deduce da solo con ciò che apprende grazie alle correzioni.

L’esempio da cui parte l’articolo riguarda un nuovo tentativo di pagamento. Un utente chiede un modulo per riprovare dopo che il checkout è scaduto, ma i registri del progetto mostrano che il pagamento potrebbe essere già stato addebitato. Un agente che implementasse nuovi tentativi senza controllare quei registri potrebbe addebitare due volte l’importo ai clienti; per completare il compito occorre gestire la mancata risposta senza duplicare l’addebito.

Gli autori hanno esaminato anche 100 sequenze di interazioni tra utenti e agenti tratte da SWE-chat. Hanno rilevato che il 56% delle istruzioni iniziali ometteva requisiti emersi in seguito come necessari e che il 52% dei requisiti utili indicati successivamente avrebbe potuto essere dedotto dal progetto. Questi risultati motivano il benchmark, ma i risultati misurati degli agenti provengono da una serie distinta di compiti costruiti per TiGanEval.

Cinque requisiti per ciascuno dei 64 compiti

TiGanEval comprende 40 compiti di ingegneria del software e 24 di ricerca. Ogni compito ha cinque requisiti effettivi, mentre l’istruzione iniziale parziale non ne contempla nessuno nel 39% dei casi, ne contempla uno nel 50% e due nell’11%; nessuna istruzione iniziale ne contempla più di due. Revisori umani hanno verificato che i requisiti corrispondessero a quelli usati per la valutazione, potessero essere dedotti dalle prove disponibili e non fossero esplicitati nei file accessibili agli agenti.

I ricercatori hanno valutato 12 modelli, tra cui otto che classificano come modelli di frontiera, in tre configurazioni. «Literal» considera completa l’istruzione; «Partial» invita l’agente a esaminare il progetto e a dedurre cosa richiede il compito; «Full» gli fornisce la specifica completa. Nella condizione Partial, gli agenti potevano presentare fino a quattro soluzioni sottoposte a valutazione, con un limite complessivo di 120 turni e 360 chiamate agli strumenti per episodio.

Il feedback aiuta, ma non colma il divario

Per tutti e otto i modelli di frontiera, il tasso di successo al primo tentativo con istruzioni parziali è risultato inferiore di 53-67 punti percentuali rispetto al risultato dello stesso modello con la specifica completa. GPT-5.6-Sol, per esempio, ha completato con successo il 10,9% dei compiti con istruzioni parziali al primo tentativo, contro il 64,1% quando ha ricevuto la specifica completa. Dopo quattro tentativi, il suo tasso di successo nella condizione Partial ha raggiunto il 29,7%, ancora ben al di sotto del risultato ottenuto con le informazioni complete.

Invitare gli agenti a dedurre i requisiti ha dato risultati migliori che chiedere loro di seguire le istruzioni alla lettera. Tra i modelli di frontiera, al primo tentativo la configurazione Partial ha ottenuto da 15,7 a 34,1 punti in più della configurazione Literal. Nei tentativi successivi, tuttavia, gli agenti hanno fatto ampio affidamento sul feedback dell’utente: i modelli di frontiera hanno individuato al massimo il 17,6% dei requisiti rimasti non esplicitati prima che l’utente li segnalasse.

Una modalità di pianificazione in due fasi non ha colmato il divario nei tre modelli sottoposti a questa prova. Ha aumentato di 4,3 punti il punteggio di GPT-5.6-Luna al primo tentativo, ma non il suo tasso di successo; per Kimi-K3 e DeepSeek-V4.1-Flash sono diminuiti sia i punteggi sia i tassi di successo. Secondo l’analisi dei ricercatori, la fase di pianificazione spesso terminava prima che l’agente avesse individuato tutti i requisiti.

I limiti del benchmark contano

Gli autori hanno esaminato 100 episodi falliti nella condizione Partial e ne hanno classificati 72 come casi in cui gli agenti non avevano utilizzato le prove relative ai requisiti. Alcuni agenti hanno inventato una regola nonostante i registri del progetto indicassero il contrario; altri hanno eseguito una riproduzione che metteva in luce un problema, senza però apportare la correzione corrispondente. Il risultato sposta l’attenzione dalla capacità di un agente di eseguire una specifica nota alla sua capacità di individuare la specifica effettivamente richiesta dal compito.

TiGanEval è un test controllato, non una stima diretta delle prestazioni degli agenti utilizzati nella pratica o di fronte alle richieste quotidiane degli utenti. I suoi 64 compiti risentono di vincoli di costo e l’utente simulato risponde tramite osservazioni preparate dagli autori, anziché seguire dinamiche più complesse, come rivelare gradualmente i requisiti. Il risultato centrale del benchmark è più circoscritto: nei compiti esaminati, anche i modelli più avanzati spesso riuscivano quando ogni requisito era esplicitato, ma fallivano quando dovevano dedurne alcuni dal progetto.