💬 NLP

Asuka-Bench: Benchmarking Code Agents on Underspecified User Intent and Multi-Round Refinement

Il documento introduce Asuka-Bench, un nuovo benchmark progettato per valutare gli agenti di codice su compiti di sviluppo web simulando cicli di raffinamento multi-round del mondo reale in cui gli agenti migliorano iterativamente progetti sotto-specificati basandosi su test UI automatizzati e feedback in linguaggio naturale, rivelando significativi divari di prestazione tra gli attuali modelli.

Autori originali: Xin Wang, Liangtai Sun, Yaoming Zhu, Shuang Zhou, Jiaxing Liu, Fengjiao Chen, Lin Qiu, Xuezhi Cao, Xunliang Cai, Licheng Zhang, Zhendong Mao

Pubblicato 2026-06-05

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Xin Wang, Liangtai Sun, Yaoming Zhu, Shuang Zhou, Jiaxing Liu, Fengjiao Chen, Lin Qiu, Xuezhi Cao, Xunliang Cai, Licheng Zhang, Zhendong Mao

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

Immagina di assumere un architetto brillante ma leggermente letterale per costruire una casa.

Il Vecchio Modo (Benchmark Esistenti)
In passato, testare questi architetti era come consegnare loro una piantina perfetta di 50 pagine che elencava ogni singolo chiodo, cavo e colore della vernice. Dicevi: "Costruisci questo", e loro ti consegnavano una casa finita. Se la casa corrispondeva alla piantina, prendevano un A. Se non ci corrispondeva, prendevano un F.

Il problema è che la vita reale non funziona così. I veri clienti raramente hanno una piantina perfetta di 50 pagine. Di solito dicono: "Voglio una casa con una cucina e un posto dove dormire", e poi, una volta vista la prima bozza, si rendono conto che: "Oh, in realtà volevo che la cucina fosse più grande", oppure "Aspetta, la porta si apre dal lato sbagliato".

Il Nuovo Modo (Asuka-Bench)
Il documento presenta Asuka-Bench, un nuovo modo per testare gli "Agenti di Codice" (programmi IA che scrivono software). Invece di dare all'IA una piantina perfetta, i ricercatori le danno una richiesta vaga e disordinata, come: "Crea un sito di shopping con un elenco di prodotti e un carrello".

Poi, non si limitano a valutare il primo risultato. Configurano un team di tre persone per mettere in scena un ciclo di sviluppo del mondo reale:

Il Costruttore (Agente di Codice): Questa è l'IA che cerca di costruire il sito web basandosi sulla richiesta vaga.
L'Ispettore (Agente UI): Questo è un robot che visita effettivamente il sito web in un browser. Non legge il codice; agisce come un utente umano. Clicca sui pulsanti, prova a comprare oggetti e controlla se le pagine si caricano. È come un ispettore del controllo qualità che cammina attraverso la casa per vedere se le porte si aprono.
Il Cliente (LLM Utente): Questa è un'altra IA che osserva l'Ispettore. Se l'Ispettore trova un problema (ad esempio, "Il pulsante 'Acquista' non funziona"), il Cliente traduce il problema in una nota cortese per il Costruttore: "Ehi, il pulsante è rotto. Per favore, sistemalo".

Il Costruttore corregge quindi il sito web, e il ciclo si ripete. Questo avviene per un massimo di tre round.

L'Analogia del "DAG"
I ricercatori hanno inventato anche un modo intelligente per fornire feedback chiamato DAG (Grafo Aciclico Diretto). Immagina che questo sia come una ricetta.

Se stai cercando di cuocere una torta, non puoi decorarla con la glassa prima di averla cotta.
Nei vecchi metodi di test, se la torta era bruciata, l'ispettore avrebbe potuto lamentarsi anche della mancanza della glassa, anche se non potevi decorare una torta bruciata.
In Asuka-Bench, il sistema conosce l'ordine. Se la fase di "cottura" fallisce, il sistema impedisce all'ispettore di controllare la fase della "decorazione con la glassa". Dice solo al Costruttore: "Non hai cotto la torta". Questo evita che il Costruttore si confonda con lamentele su cose che non sono ancora avvenute.

Cosa Hanno Scoperto
I ricercatori hanno testato 8 diversi modelli di IA usando questo metodo. Ecco cosa hanno scoperto:

Alcune IA sono più brave a correggere di altre: Il fatto che un'IA sia brava a costruire la prima bozza non significa che sia brava a correggere gli errori. Alcuni modelli costruivano una bellissima prima versione ma non riuscivano a comprendere le note del "Cliente" per correggere gli errori. Altri partivano in modo disordinato ma miglioravano a ogni round di feedback.
Il divario è enorme: I migliori modelli riuscivano a completare perfettamente circa il 52% dei progetti dopo tre round di correzioni. I peggiori completavano solo l'8%. È una differenza enorme.
È ancora difficile: Nemmeno l'IA più intelligente riusciva a completare ogni singolo progetto perfettamente. Questo dimostra che, sebbene l'IA stia diventando brava, fatica ancora con la natura disordinata e di continuo scambio di messaggi del mondo reale.

In Sintesi
Asuka-Bench è un nuovo "esame di guida" per programmatori IA. Invece di chiedere loro di guidare un'auto su una pista perfettamente dritta e vuota (una piantina perfetta), gli viene chiesto di guidare nel traffico cittadino, ricevere indicazioni da un passeggero quando prendono una strada sbagliata e correggere la rotta. Si scopre che essere in grado di ascoltare e correggere gli errori è una competenza completamente diversa rispetto al semplice saper guidare in linea retta.

Riepilogo Tecnico: Asuka-Bench

Definizione del Problema

I benchmark esistenti per la generazione di codice si basano prevalentemente su un paradigma "single-turn, one-shot", in cui un agente riceve una specifica completa e univoca ed è valutato sulla sua capacità di produrre un output corretto in un unico passaggio. Questo approccio non rispecchia fondamentalmente lo sviluppo software nel mondo reale, particolarmente nello sviluppo web. In pratica, gli utenti raramente articolano specifiche complete preventivamente; i requisiti emergono e si chiariscono spesso solo dopo l'ispezione dei risultati intermedi e la fornitura di feedback correttivi. Gli attuali benchmark non riescono a valutare la capacità di un agente di interpretare intenti sottospecificati, incorporare il feedback di esecuzione e raffinare iterativamente il proprio lavoro verso un'implementazione corretta. Inoltre, molti benchmark web esistenti si concentrano sulla fedeltà visiva o assumono input completamente specificati, trascurando la correttezza funzionale e la robustezza derivanti dai cicli di interazione con l'utente.

Metodologia

Gli autori introducono Asuka-Bench, un benchmark progettato per valutare gli agenti di codice sotto intenti utente sottospecificati attraverso un raffinamento iterativo multi-round, basato sul comportamento osservabile nel browser.

Framework di Valutazione

Il benchmark opera tramite un meccanismo a ciclo chiuso che coinvolge tre agenti distinti:

Agente di Codice (Code Agent): Riceve una query utente deliberatamente sottospecificata (ad es., "Crea un sito di shopping...") e genera un progetto web iniziale. Raffina iterativamente questo progetto sulla base del feedback ricevuto.
Agente UI (UI Agent): Implementa il progetto generato in un ambiente browser ed esegue criteri di valutazione predefiniti come casi di test autonomi e interattivi. A differenza dell'analisi statica del codice, l'Agente UI giudica gli esiti in base al comportamento renderizzato (ad es., cliccare elementi, verificare aggiornamenti dei dati) piuttosto che sull'ispezione del codice sorgente.
LLM Utente (User LLM): Sintetizza i risultati pass/fail dell'Agente UI in un feedback strutturato in linguaggio naturale, che viene restituito all'Agente di Codice per il round di raffinamento successivo.

Costruzione del Dataset

Fonti: Il dataset comprende 50 task di sviluppo web derivati da tre fonti: richieste reali degli utenti de-identificate da un servizio di produzione, query formalizzate da repository open-source su GitHub e riassunti di siti web consolidati e ricchi di funzionalità.
Formalizzazione del Task: Ogni task è accoppiato con un Documento di Requisiti del Prodotto (PRD) Chiarificato che funge da ground truth. Da questo PRD, il benchmark deriva:
- Una query sottospecificata (l'input per l'Agente di Codice).
- Dati simulati (API mock, profili utente) per abilitare l'esecuzione frontend autonoma.
- Criteri di Valutazione: Un insieme strutturato di casi di test in linguaggio naturale organizzati in un Grafo Aciclico Diretto (DAG).
Tipi di Criteri: I task sono categorizzati in Presenza (esistenza di elementi), Funzionalità (comportamento interattivo) e Robustezza (gestione dei casi limite).
Protocollo Consapevole del DAG: I task di valutazione vengono eseguiti in ordine topologico. Un task viene valutato solo se le sue dipendenze prerequisito sono passate. Ciò evita i "fallimenti a cascata" in cui una causa radice blocca la valutazione a valle, garantendo che il feedback si concentri sulle cause primarie. Viene utilizzato un limite di "soddisfazione soft" ( $T=0.5$ ), in cui un task genitore è considerato soddisfatto se almeno il 50% dei suoi sottocriteri passa, minimizzando il rumore di valutazione.
Configurazione Sperimentale: Gli autori hanno valutato 8 Large Language Models (LLM) all'avanguardia attraverso due framework di agenti: OpenHands (basato su sandbox) e Claude Code (basato su CLI). Il numero massimo di round di raffinamento è stato impostato a tre. Le metriche includevano il Tasso di Completamento del Progetto (PCR), il tasso di superamento dei task pesato cumulativo e il tasso di superamento dei criteri pesato cumulativo.

Contributi Chiave

Benchmark Asuka-Bench: Il primo benchmark di generazione web che valuta sistematicamente gli agenti di codice sotto richieste sottospecificate con raffinamento interattivo multi-round, colmando il divario tra i benchmark di istruzioni statiche e lo sviluppo iterativo del mondo reale.
Protocollo di Valutazione Centrato sul Feedback dell'Utente:
- Interazione come Feedback: La valutazione è basata sul comportamento renderizzato nel browser piuttosto che sul codice sorgente.
- Valutazione Iterativa Consapevole del DAG: Eseguendo i criteri in ordine topologico e interrompendosi precocemente in caso di fallimento dei prerequisiti, il protocollo produce un tasso di riparazione dei task mediamente superiore di 10,5 punti percentuali (pp) riducendo al contempo i costi dei token di valutazione del 23–26%.
Analisi Empirica Esaustiva: Lo studio fornisce approfondimenti su come l'ambiguità dell'intento e il feedback iterativo influenzino le prestazioni, dimostrando che la capacità di riparare dal feedback è un asse di capacità distinto dalla qualità della generazione iniziale.

Risultati

Differenziazione dei Modelli: Asuka-Bench differenzia efficacemente le prestazioni dei modelli. Il Tasso di Superamento dei Task pesato varia di 38 punti percentuali tra i modelli dopo tre round.
Miglioramento Iterativo: Mentre i modelli più forti raggiungono alti Tassi di Superamento dei Task (~~90%), il Tasso di Completamento del Progetto (che richiede il superamento di tutti i task) rimane più basso (~~52%), evidenziando la difficoltà di raggiungere la piena correttezza.
Riparazione vs Generazione: La capacità di riparare gli errori dal feedback è ampiamente disaccoppiata dalla qualità della generazione del primo round. Ad esempio, Kimi-K2.6 è partito con un primo round mediocre ma è migliorato significativamente nei round successivi, superando i modelli con generazioni iniziali più forti nel punteggio cumulativo finale.
Saturazione: Il benchmark è tutt'altro che saturo; anche il modello più forte (Claude-4.6-Sonnet) completa solo il 52% dei progetti dopo tre round. Tuttavia, estendendo il modello più forte a 8 round, si ottiene il completamento del 100%, confermando che i task sono risolvibili e che il meccanismo di feedback è efficace.
Allineamento Umano: L'agente di valutazione automatizzato ha raggiunto un'accuratezza del 93,35% e un punteggio F1 del 96,52% rispetto ai giudizi degli esperti umani, convalidando l'affidabilità del framework a ciclo chiuso.

Significato

Il paper sostiene che Asuka-Bench rivela un punto cieco critico nei benchmark esistenti: l'incapacità di valutare la capacità di un agente di convergere sotto un ciclo guidato dal feedback. Spostandosi dalla valutazione statica e one-shot al raffinamento iterativo basato su intenti sottospecificati, il benchmark fornisce una misura più realistica dell'utilità di un agente nel deployment reale. I risultati suggeriscono che la "riparazione dal feedback" è una dimensione separabile della capacità del modello che i benchmark one-shot attuali non riescono a catturare. Gli autori posizionano Asuka-Bench come un passo verso i benchmark che riflettono la natura iterativa e basata sul dialogo dell'effettivo ingegneria del software, incoraggiando la comunità a andare oltre i paradigmi di valutazione statica.