Un agente al 60% può aver fallito: il vero test è ciò che consegna

Quando valutiamo un agente AI, continuiamo spesso a premiare ciò che riesce a fare lungo il percorso: ha trovato le fonti, ha aperto le pagine giuste, ha compilato metà dei campi, ha costruito una parte del documento. È una misura utile per capire dove si rompe il sistema. Ma per chi deve usare davvero il risultato c’è un problema molto più semplice: il file finale funziona oppure no?

Il benchmark KNOWS, presentato nel paper The Hard Part Comes After Search, mette esattamente questa differenza sotto stress. Non chiede agli agenti soltanto di navigare il web o rispondere a una domanda: assegna 110 attività lunghe che richiedono ricerca, sintesi e produzione di un artefatto finale in Google Docs, Slides o Sheets. Il risultato più interessante non è che gli agenti sbagliano. È che possono ottenere punteggi parziali dignitosi e, contemporaneamente, consegnare pochissimi lavori davvero completi.

Il 60% di un processo non è necessariamente il 60% del valore

Nel paper il miglior sistema completa integralmente meno del 3% dei task. Eppure le metriche di successo parziale sono molto meno drammatiche. Non è una contraddizione: misurano due cose diverse.

Un workflow lungo non è una somma lineare di piccoli successi. Se devo produrre una presentazione, posso recuperare correttamente i dati, sintetizzare le fonti e creare quasi tutte le slide. Ma se una tabella è illeggibile, un grafico usa dati sbagliati o la struttura visiva rende incomprensibile il risultato, il documento può essere inutilizzabile. KNOWS osserva proprio questo fenomeno: alcuni fallimenti nei passaggi visuali compromettono l’artefatto anche quando l’agente supera più della metà degli altri step di valutazione.

Il progresso di un agente è una metrica tecnica. L’utilità dell’artefatto finale è una metrica operativa. Confonderle produce demo convincenti e sistemi fragili.

È una distinzione che conta molto quando si passa dalla demo all’automazione reale. Come ho già scritto parlando di software che agisce invece di limitarsi a conversare, il problema cambia quando il modello entra in una catena operativa. Non basta più chiedersi se “sa fare” una cosa: bisogna verificare se il sistema arriva in fondo in modo ripetibile e controllabile.

KNOWS valuta il lavoro dopo la ricerca

I 110 task del benchmark terminano con un documento, una presentazione o uno spreadsheet. Secondo gli autori, sono attività complesse e aperte che combinano recupero di informazioni dal web, ragionamento, organizzazione dei contenuti e manipolazione di interfacce. Gli evaluator mescolano controlli deterministici e giudizi di modelli per verificare sia requisiti precisi sia proprietà più difficili da ridurre a un confronto esatto.

Questa scelta sposta l’unità di misura. Il target non è il click corretto e nemmeno la risposta testuale plausibile. È un oggetto che qualcun altro dovrebbe poter aprire e usare. Il dataset pubblico contiene 110 righe e viene versionato per gestire il problema inevitabile dei contenuti web che cambiano nel tempo.

Il modello non è il sistema

C’è un secondo risultato ancora più utile del numero “meno del 3%”: lo stesso modello può comportarsi in modo molto diverso cambiando harness, action space e interfaccia degli strumenti. In altre parole, misurare soltanto il modello nasconde una parte importante dell’architettura.

Questo vale anche fuori dai benchmark. Un agente può avere ottime capacità di ragionamento e fallire perché riceve errori inutilizzabili, perché l’interfaccia espone azioni ambigue, perché non possiede un meccanismo affidabile per controllare ciò che ha appena prodotto o perché il sistema non gli consente di correggere un passaggio senza rifare tutto. È lo stesso motivo per cui la forma degli errori diventa parte dell’API quando il client è un agente.

Dire “questo modello ha ottenuto X” è quindi una scorciatoia. La performance osservata appartiene al sistema completo: modello, prompt, strumenti, rappresentazione dello stato, interfaccia, feedback, evaluator e possibilità di recupero dagli errori.

Da task completion a deliverable acceptance

Se portiamo questa lezione nei workflow aziendali, il criterio di accettazione dovrebbe assomigliare meno a una percentuale di step completati e più a un collaudo del deliverable. Un report non è “finito” perché sono state eseguite 18 azioni su 20. È finito quando contiene i dati richiesti, i calcoli tornano, i riferimenti sono verificabili e la forma permette a una persona di usarlo senza ripararlo manualmente.

Questo suggerisce almeno tre livelli di verifica. Il primo riguarda i checkpoint intermedi: servono per diagnosticare dove il processo si rompe. Il secondo riguarda invarianti e vincoli deterministici: campi presenti, formule valide, struttura corretta, link funzionanti. Il terzo riguarda la qualità dell’artefatto nel suo insieme: coerenza, leggibilità, completezza e aderenza allo scopo.

Il punto non è eliminare le metriche parziali. Sono preziose per sviluppare il sistema. Il punto è non usarle come sostituto del risultato finale.

Il fallimento critico pesa più di dieci successi marginali

Nei processi lunghi esistono passaggi con peso molto diverso. Se un agente raccoglie nove informazioni corrette e sbaglia quella che alimenta una formula centrale, il conteggio “9 su 10” descrive male il danno. Se genera venti slide formalmente presenti ma rompe la gerarchia visiva della slide che contiene la decisione, il problema non è un cinque per cento di incompletezza.

Per questo i workflow agentici seri hanno bisogno di dipendenze esplicite, quality gate e verifiche finali. Non perché il modello debba essere perfetto, ma perché il sistema deve sapere quali errori sono recuperabili e quali invalidano l’output.

Un agente affidabile non è quello che sbaglia poco in media. È quello inserito in un sistema che riconosce gli errori che contano prima di consegnarli.

La parte difficile viene dopo il “wow”

KNOWS ha limiti dichiarati: 110 task non rappresentano tutto il lavoro possibile, l’ambiente web cambia e il perimetro principale degli artefatti è Google Workspace. Quindi il “meno del 3%” non va trasformato nell’ennesimo numero assoluto sull’intelligenza degli agenti.

Va letto per quello che misura: quando chiediamo a un sistema di attraversare un workflow lungo e consegnare qualcosa di utilizzabile, il divario fra progresso locale e successo globale diventa enorme. È un risultato molto meno spettacolare di una demo in cui l’agente clicca da solo. Ed è molto più utile per progettare software.

La domanda corretta, quindi, non è più “quante azioni riesce a fare l’agente?”. È: “quale evidenza ho che ciò che ha consegnato può davvero uscire dal workflow?”. Finché non misuriamo quello, stiamo valutando il movimento. Non il lavoro.