Un’azienda mette in produzione un agente IA per il servizio clienti. Dopo due settimane qualcuno nota che le risposte sono meno precise di quanto sembrassero durante i test interni. Si rileggono i log dello sviluppo: il punteggio di accuratezza era salito dal 70 all’85 per cento nel giro di pochi giorni. Poi, davanti a clienti veri, quel vantaggio sparisce quasi del tutto. Non è un caso isolato: è il sintomo più comune di come oggi si misurano gli agenti costruiti sopra i modelli di intelligenza artificiale, ed è il problema che Anthropic ha provato ad affrontare con un metodo pubblicato il 28 settembre sul blog per sviluppatori legato a Claude Code.
Il punto di partenza è scomodo: buona parte delle valutazioni che le aziende costruiscono in casa non misura quello che pensano di misurare. Anthropic lo chiama, con una certa onestà, il rischio di illudersi da soli: ottimizzare un agente contro un test che non somiglia al lavoro reale, e scambiare un numero più alto per un miglioramento vero. Il tema non è nuovo agli addetti ai lavori, ma raramente qualcuno lo aveva scomposto in una procedura replicabile passo per passo.
Perché i test fatti in casa spesso mentono
Tre difetti ricorrono più di altri in chi costruisce le proprie valutazioni senza metodo. Il primo è la dimensione: dataset di poche decine di esempi, raccolti a mano in un pomeriggio, troppo piccoli per distinguere un progresso reale dal semplice rumore statistico. Il secondo è la selezione: capita spesso di costruire i casi di test scegliendo apposta le situazioni in cui l’agente attuale fallisce, perché sono le più urgenti da correggere. Il problema è che così si finisce per campionare solo le valli della curva di capacità di un modello, non una fotografia rappresentativa di ciò che l’agente incontrerà davvero una volta in produzione.
Il terzo difetto riguarda chi giudica le risposte. Molte valutazioni usano un secondo modello come arbitro, il cosiddetto LLM-as-judge, ma raramente qualcuno verifica se quel giudice è stabile: fargli valutare due volte la stessa identica risposta dovrebbe restituire lo stesso verdetto, e un modello più capace dovrebbe ottenere un punteggio più alto di uno più debole. Se nessuna delle due condizioni regge, il numero che si sta cercando di far salire non racconta nulla di affidabile, per quanto le tabelle interne sembrino promettenti.
Costruire una valutazione prima ancora di correggere qualcosa
Il primo passo del metodo, chiamato “build-eval”, non tocca ancora l’agente: serve solo a costruire un test che regga. L’ordine con cui raccogliere i casi non è casuale, e Anthropic lo mette in una gerarchia precisa: prima le trascrizioni di conversazioni reali già avvenute in produzione, poi le segnalazioni di bug arrivate dagli utenti, poi esempi scritti a mano da chi conosce bene il prodotto, e solo per ultimo dati sintetici generati apposta per l’occasione. Più si scende in questa lista, meno il test somiglierà al mondo reale in cui l’agente dovrà poi funzionare.
Per giudicare le risposte si usano due strade, a seconda del compito: una verifica programmata, un controllo automatico vero e proprio, quando la risposta corretta è vincolata e riconoscibile; un giudice basato su un modello linguistico quando il compito è aperto e serve un giudizio più sfumato. In entrambi i casi, prima di ottimizzare qualsiasi cosa, si misura quanto è rumoroso il test stesso: se il punteggio oscilla di dieci punti percentuali solo rilanciando lo stesso identico agente sugli stessi dati, ogni miglioramento sotto quella soglia è, statisticamente, privo di significato.
Il tranello dell’overfitting, spiegato con un esempio
Il secondo passo, “hillclimb”, è quello che produce i risultati concreti: si prova una modifica alla volta, sul prompt di sistema, sulle istruzioni di una skill, sulla descrizione di uno strumento o sulla scelta del modello, e se ne osserva l’effetto. La parte che fa davvero la differenza è come viene validato ogni tentativo: i dati vengono divisi in due gruppi, uno visibile durante l’ottimizzazione e uno tenuto nascosto fino alla fine. Una modifica viene accettata solo se migliora entrambi i gruppi. Se il gruppo visibile sale e quello nascosto resta piatto, è il segnale classico dell’overfitting: l’agente ha imparato l’esame, non il compito che dovrebbe svolgere.
C’è un’altra accortezza, più sottile: mantenere le risposte corrette strutturalmente fuori dalla portata dell’agente che si sta ottimizzando, in modo che non trovi scorciatoie per ingannare il giudice invece di migliorare davvero il proprio lavoro. È lo stesso principio che sta dietro al concetto di reward hacking nell’addestramento dei modelli, applicato qui a una fase molto più pratica: la messa a punto di un agente già scritto e già in uso, non l’addestramento di un modello da zero.
I numeri dietro il metodo
Anthropic ha reso pubblici due casi concreti, ripresi anche da The Neuron. Nel primo, un agente per il servizio clienti testato su 44 ticket, di cui 30 usati per l’ottimizzazione e 14 tenuti nascosti fino alla fine, il modello di partenza, Opus 4.8 impostato ad alto sforzo, otteneva un’accuratezza del 74,4 per cento a un costo di circa 4 centesimi di euro a ticket (la cifra originale di Anthropic, in centesimi di dollaro, era 4,6). Dopo il lavoro di ottimizzazione, un modello più piccolo, Sonnet 5 con basso sforzo, è arrivato al 90,5 per cento sul gruppo nascosto, a un costo inferiore a un centesimo di euro a ticket: una riduzione dei costi vicina all’80 per cento, ottenuta insieme a un’accuratezza più alta, non più bassa.
Nel secondo caso, che riguarda una skill interna che aiuta a scrivere codice contro le API di Anthropic, il punto di partenza era circa il 66 per cento di correttezza; il risultato finale, dopo 24 cicli di ottimizzazione, si è avvicinato all’88 per cento. Il miglioramento non è arrivato aggiungendo genericamente “più contesto” al prompt, ma individuando punto per punto otto funzionalità mancanti, tabelle dei tipi sbagliate e pattern di codice ormai superati: esattamente il genere di difetti che un test ben costruito fa emergere, e che un test superficiale lascia invisibili.
Un problema che riguarda chiunque costruisca agenti, non solo Anthropic
La parte più utile del metodo, per chi non lavora in Anthropic, non è la ricetta tecnica ma il promemoria che ci sta dietro: un’accuratezza più alta non equivale automaticamente a un prodotto migliore. Una valutazione ben progettata, secondo Anthropic, ha tre caratteristiche riconoscibili: un modello più forte ottiene un punteggio più alto di uno più debole, resta ancora margine sotto il cento per cento (altrimenti il test è troppo facile per dire qualcosa di utile), e il punteggio non balla in modo selvaggio se si ripete lo stesso esperimento più volte. È lo stesso tipo di rigore che serve quando si leggono le classifiche pubbliche dei modelli: come ha mostrato il verdetto indipendente su Claude Sonnet 5.5, il piazzamento in un confronto tra modelli dipende molto da come è costruito il test, non solo da quanto è bravo il modello.
Per le aziende italiane che stanno mettendo in produzione i primi agenti di intelligenza artificiale nel servizio clienti, nella fatturazione o nell’assistenza interna, la lezione pratica è che la metrica giusta non è quasi mai l’accuratezza presa da sola, ma qualcosa legato a un risultato che conta davvero: costo per compito completato, percentuale di risposte accettate senza intervento umano, ticket risolti senza dover riaprire il caso. Un punteggio che sale senza che nessuno di questi indicatori si muova è, con ogni probabilità, il segnale che si sta ottimizzando la domanda sbagliata. Vale anche per compiti più delicati della scrittura di codice, come la revisione automatica delle pull request, dove un falso senso di sicurezza pesa più di un errore evidente: lo raccontano bene anche i casi recenti in cui un agente che sembrava affidabile sulla carta ha comunque prodotto un incidente una volta arrivato a contatto con dati reali.
Il metodo di Anthropic, descritto per intero nel post ufficiale del team Claude Code, richiede tempo, dataset curati e la pazienza di accettare che un miglioramento non conta finché non regge su dati mai visti prima durante l’ottimizzazione. È un lavoro meno immediato di un numero che sale in una slide interna, ma è quello che separa un agente davvero più affidabile da uno che ha solo imparato, con più o meno consapevolezza di chi lo ha costruito, a superare il proprio esame.
