EvolveTool-Bench: Evaluating the Quality of LLM-Generated Tool Libraries as Software Artifacts

1. Il Problema

Gli agenti LLM (Large Language Models) stanno diventando sempre più capaci di generare autonomamente artefatti software eseguibili a runtime (funzioni Python, client API, parser di dati) e di aggiungerli a librerie di strumenti persistenti. Tuttavia, il paradigma di valutazione attuale presenta una lacuna critica:

• Valutazione basata solo sul compito: I benchmark esistenti giudicano questi agenti esclusivamente in base al successo nel completamento del compito finale (task completion).
• Analogo ingegneristico inadeguato: Questo approccio è paragonabile a valutare un ingegnere software solo chiedendo se il suo codice "funziona", ignorando completamente aspetti fondamentali come la ridondanza, la manutenzione, la sicurezza, la regressione e il debito tecnico.
• Rischi nascosti: Le librerie di strumenti generate possono accumulare funzioni ridondanti, fallire su casi limite, rompere funzionalità precedentemente funzionanti (regressione) e non riutilizzare codice esistente, pur ottenendo punteggi alti nei benchmark tradizionali.

2. Metodologia e Design del Benchmark

Il paper introduce EvolveTool-Bench, un benchmark diagnostico progettato per trattare le librerie di strumenti generate dagli LLM come artefatti software di prima classe, soggetti a valutazione della qualità.

Struttura delle Sessioni di Task

Ogni sessione di benchmark è composta da 11 task organizzati in 6 categorie con relazioni di dipendenza note, che mimano i flussi di lavoro dell'ingegneria del software:

1. Seed: Utilizzo di librerie esistenti.
2. Gap: Implementazione di nuovo codice per colmare lacune.
3. Variant: Test del riutilizzo del codice vs. riscrittura.
4. Compose: Composizione di funzioni.
5. Regress: Rilevamento di regressioni (se un nuovo tool rompe funzionalità vecchie).
6. Adversarial: Test su casi limite e fuzzing.

Domini di Applicazione

Il benchmark copre tre domini che richiedono l'esecuzione reale di strumenti:

• Dominio A (Trasformazione Dati): Formati binari proprietari (es. ARISE Binary Records, RLE matrices) non risolvibili tramite dati di training.
• Dominio B (Orchestrazione API): Server HTTP mock con autenticazione HMAC e paginazione crittografata.
• Dominio C (Calcolo Numerico): Formati personalizzati per fitting di curve, elaborazione del segnale e ottimizzazione vincolata.

Metriche di Valutazione

Il framework definisce metriche sia a livello di singolo strumento che a livello di libreria:

• Tool Quality Score (TQS): Misura la qualità di ogni singolo strumento sintetizzato basandosi su quattro pilastri:
  • Correttezza: Superamento di test unitari nascosti.
  • Robustezza: Gestione di input avversari.
  • Generalità: Produzione di output validi su input non visti.
  • Qualità del Codice: Docstring, tipizzazione, gestione errori, lunghezza e sintassi.
• Library Health (LH): Una metrica composita che valuta la salute dell'intera libreria, includendo:
  • Tasso di riutilizzo (Reuse).
  • Ridondanza/Duplicazione (Redundancy).
  • Successo della composizione (Composition success).
  • Stabilità contro le regressioni (Regression stability).
  • Efficienza di creazione e Sicurezza.
• EvolveTool Score (ETS): Un punteggio finale ponderato che combina Task Completion, TQS, Ridondanza, LH e Stabilità del Sistema.

Setup Sperimentale

• Sistemi confrontati:
  1. No-Evolution: Solo strumenti seed (nessuna evoluzione).
  2. ARISE: Evoluzione iterativa con validazione in sandbox e "LLM-as-judge" per i reward.
  3. EvoSkill: Evoluzione a livello di strategia (prompt testuali, non codice).
  4. One-Shot: Generazione di codice senza test.
• Modelli: Claude Sonnet 4 e Claude Haiku 4.5.
• Scala: 99 task totali per configurazione (594 esecuzioni totali).

3. Risultati Chiave

Lo studio ha rivelato differenze sostanziali tra il completamento del compito e la qualità del software generato:

1. Il completamento del compito nasconde le differenze di qualità: Tutte le configurazioni hanno ottenuto un tasso di completamento del compito (TC) simile (63–68%), ma i punteggi di qualità del software (ETS) variavano notevolmente (da 0.516 a 0.612). Un benchmark basato solo sul TC classificherebbe erroneamente ARISE come l'ultimo sistema, nonostante abbia la libreria più sana.
2. L'evoluzione del codice supera l'evoluzione della strategia: ARISE (che genera codice eseguibile) ha superato significativamente EvoSkill (che genera solo prompt). EvoSkill non ha creato strumenti eseguibili e ha mostrato una salute della libreria identica al gruppo "No-Evolution".
3. Il codice non testato è peggio di nessun codice: La configurazione "One-Shot" (generazione senza test) ha ottenuto una salute della libreria del 38.3%, inferiore al gruppo "No-Evolution" (41.4%). Gli strumenti non testati si sono rivelati un passivo tecnico.
4. Il design del Reward è il collo di bottiglia: Solo l'uso di un "LLM-as-judge" come reward ha innescato un'evoluzione efficace; i reward euristici hanno prodotto zero strumenti.
5. La qualità degli strumenti è il limite attuale: Il TQS medio è basso (0.34–0.35), con la correttezza che è il punto debole principale. I test generati autonomamente dall'LLM spesso non catturano difetti che vengono invece rilevati dai test unitari nascosti del benchmark.
6. Modelli più economici possono essere migliori: La combinazione ARISE + Haiku (modello più piccolo) ha ottenuto un ETS leggermente superiore (0.612) rispetto ad ARISE + Sonnet (0.603), creando meno strumenti ma di qualità complessiva superiore.

4. Contributi Principali

1. Definizione di Metriche di Qualità: Introduzione del Tool Quality Score (TQS) e di sei metriche a livello di libreria per valutare gli artefatti software generati dagli LLM.
2. Validazione Rigorosa: Un harness di valutazione che esegue test unitari nascosti e input avversari in subprocessi sandboxed, utilizzando l'LLM come giudice per determinare quando attivare l'evoluzione.
3. Sessioni Diagnostiche Controllate: Una struttura di task sequenziali che misura specificamente la capacità degli agenti di riconoscere opportunità di riutilizzo, comporre funzioni e mantenere la stabilità della libreria.
4. Primo Benchmark di questo tipo: EvolveTool-Bench è il primo benchmark a valutare le librerie di strumenti auto-evolute come artefatti software, colmando il divario tra la ricerca sugli agenti e l'ingegneria del software.

5. Significato e Implicazioni

Il lavoro dimostra che la valutazione e la governance degli strumenti generati dagli LLM richiedono un cambio di paradigma: la libreria di strumenti in evoluzione deve essere trattata come un artefatto software di prima classe, non come una scatola nera.

• Debito Tecnico: I sistemi che accumulano codice senza validazione indipendente introducono debito tecnico e rischi di sicurezza.
• Governance: È necessario implementare meccanismi di validazione indipendenti (test unitari, analisi di regressione) per qualsiasi sistema che accumuli codice generato.
• Futuro della Ricerca: La ricerca futura deve spostarsi dall'ottimizzazione del solo "task completion" all'ottimizzazione della salute del codice, della manutenibilità e della sicurezza delle librerie generate.

In conclusione, EvolveTool-Bench evidenzia che un agente può essere "bravo" a completare un compito ma "cattivo" ingegnere software, creando librerie fragili e ridondanti. La valutazione olistica è essenziale per lo sviluppo di agenti LLM affidabili e scalabili.