Il problema non è se un agente LLM risponde bene, ma se lo fa per la ragione giusta e senza passi laterali. Lo studio trajectory-judge parte da un ambiente deterministico di supporto clienti con strumenti, una policy oracolare che lo risolve sempre e un iniettore di guasti capace di rompere esattamente un passaggio a uno step noto. Su 400 traiettorie, cinque giudici — regole programmatiche, giudice a solo esito, rubriche per passi su due dimensioni di modello e un ensemble self-consistency — sono stati misurati su rilevamento, localizzazione del passo, tipizzazione del guasto, calibrazione e costo.

I numeri rendono concreto il punto cieco. Il giudice a esito unico rileva l'84% dei guasti loud, quelli che cambiano la risposta visibile al cliente, ma solo il 45% dei guasti silenziosi, che non alterano l'esito. Nel frattempo segnala come errate il 33% delle traiettorie corrette. Il giudice con rubrica per passi arriva al 77% di recall sui guasti silenziosi con zero falsi positivi, ma a costo triplo.

La distinzione tra guasti loud e silenti cambia l'incentivo di chi valuta gli agenti. Un team che usa metriche a esito unico può dichiarare un tasso di successo alto senza accorgersi che l'agente ha usato un percorso non autorizzato o ha ignorato un vincolo intermedio. In deployment on-premise, dove l'accesso a dati sensibili e la conformità contano, questo non è un dettaglio: un guasto silenzioso può essere una lettura non necessaria di dati personali o una chiamata a un servizio non previsto, anche quando il cliente riceve la risposta corretta. Il report mostra anche che la calibrazione dei giudici non è uniforme: il giudice a esito unico produce falsi positivi su un terzo delle traiettorie corrette, erodendo la fiducia nel sistema di valutazione stesso.

La risposta finale resta invisibile

Il dato più severo arriva sulla risposta finale. Nessun giudice la legge davvero: una promessa inventata aggiunta a una traiettoria altrimenti perfetta sfugge del tutto alle regole e all'82% dei casi al giudice a passi. Questo sposta il problema dalla valutazione del percorso alla valutazione del contenuto reale che arriva al cliente. Un agente può completare tutti gli step previsti, rispettare la rubrica e poi promettere al cliente qualcosa che non sarà mantenuto. Non è un errore di esecuzione, ma di generazione finale, e i giudici attuali non lo intercettano. L'ensemble self-consistency triplica il costo senza migliorare nulla, segno che la ridondanza campionaria non sostituisce una rubrica che guardi al contenuto.

Cosa cambia per chi valuta deployment on-premise

Per chi valuta deployment on-premise, lo studio offre un artefatto raro: ambiente, iniettore, verdetti grezzi e pipeline di analisi che ricostruiscono ogni numero offline. Questo è rilevante per la sovranità dei dati perché permette di ripetere la valutazione su dati locali senza inviare traiettorie a servizi esterni. Ma introduce anche un trade-off di costo: la rubrica per passi triplica il costo rispetto al giudice a esito unico. Chi gestisce infrastrutture locali può quantificare quel costo in TCO e decidere se la copertura dei guasti silenziosi giustifica l'investimento. AI-RADAR offre framework analitici su /llm-onpremise per valutare questi trade-off, ma la scelta dipende dal rischio operativo specifico.

La lezione strutturale è che la valutazione degli agenti LLM non può continuare a misurare solo la risposta visibile. La distinzione tra guasto silenzioso e guasto loud dovrebbe diventare una metrica di primo livello, e la lettura della risposta finale un controllo separato. Finché i giudici non leggono il contenuto che viene consegnato al cliente, il successo apparente resta una promessa non verificata.