Come valutare una domanda LLM prima del rilascio

Cosa dice la guida

La guida di Anthropic di gennaio 2026 suddivide i test degli agenti in attività, esecuzioni ripetute, regole di punteggio e ambiente di test. Inoltre separa ciò che un agente dice da ciò che effettivamente fa. Ad esempio, un agente potrebbe dire di aver salvato un record quando il record non è mai stato modificato. Segna il risultato e la conversazione. Questo è un consiglio di un fornitore di modelli, non una prova che un metodo funzioni per ogni sistema.

Prova: Valutazioni demistificanti per agenti IA [1]

Scegli la decisione che il tuo test deve supportare

Scrivi la domanda di rilascio in una frase. Ad esempio: il nostro assistente di supporto può spiegare la politica dell'account senza promettere un rimborso che non può approvare? Ciò conferisce al test un utente, un compito e un rischio chiari. Un obiettivo vago come “essere più utile” può premiare una risposta semplice ma sbagliata.

Decidere la parte del flusso di lavoro da testare. Una risposta può essere sufficiente per uno strumento di sintesi. Un assistente di chat potrebbe aver bisogno di un'intera conversazione. Se un agente modifica un record, controlla anche il record salvato. Salva la versione del modello, il prompt, le impostazioni di ricerca e le autorizzazioni dello strumento. Una modifica a uno qualsiasi di questi può modificare il risultato.

Costruisci un piccolo set di test che puoi rivedere

Rubrex consiglia tre gruppi di casi: attività comuni, casi limite e guasti noti. Per ciascun caso, scrivi il comportamento atteso e il motivo per cui il caso rientra nel test. Trattenete alcuni casi durante la messa a punto del sistema. Utilizza la prima esecuzione di test per individuare requisiti poco chiari prima di utilizzare i punteggi per supportare un lancio.

Utilizza il codice per verificare le regole esatte, come i campi obbligatori o gli ID record consentiti. Utilizza una guida al punteggio per significato, dettagli mancanti e incertezza onesta. Chiedi ai revisori di valutare autonomamente un piccolo set condiviso. Discuti dove non sono d'accordo prima di affidare a un giudice automatizzato più casi. Conservare i casi che non possono essere valutati nel rapporto e spiegarne il motivo.

• Salva la versione originale e ogni risposta, comprese le richieste non riuscite.
• Eseguire la versione modificata sugli stessi ingressi e limiti.
• Ispeziona i casi migliorati e quelli peggiorati.
• Assegnare a ogni errore che blocca il rilascio un proprietario con nome.

Esempio: un assistente che spiega la politica

Supponiamo che un assistente debba citare la politica attuale, spiegare le eccezioni ed evitare di promettere approvazione. Potrebbe soddisfare le prime due regole ma fallire comunque promettendo un rimborso. Assegna un punteggio a ciascuna regola in modo che la squadra possa trovare il problema. Registra anche se la risposta ha superato tutte le regole richieste.

Supponiamo ora che un nuovo prompt corregga le citazioni ma faccia più promesse non supportate. Questo è un risultato misto. Testare un cambiamento mirato a mantenere le promesse, quindi rieseguire i casi precedenti per verificare nuovi fallimenti. Questo è un esempio di piano di test, non il risultato di un cliente Rubrex.

Dai al prossimo ingegnere abbastanza per ripetere il test

Condividi i casi, le regole di punteggio, le versioni del sistema e le risposte originali. Raggruppare i fallimenti per causa e spiegare ciò che è ancora sconosciuto. Includere passaggi per eseguire nuovamente il test e aggiungere un errore rilevato dopo l'avvio. Un altro ingegnere dovrebbe essere in grado di verificare la decisione senza bisogno della presentazione dell'autore. Quando le prove sono troppo deboli per decidere, nominare i dati mancanti e il test successivo.

Registra il significato di ciascun punteggio

Scegli le misure che rispondono alla domanda di rilascio. Per un assistente di supporto, Rubrex consiglia di tenere traccia delle risposte errate, delle richieste non supportate, delle attività completate e del costo di una risposta utile. Indica cosa copre ogni conteggio. Dieci risposte fallite su 100 risposte significano qualcosa di diverso da dieci sessioni fallite su 100 sessioni. Includere le richieste che non hanno prodotto risposta.

Un test verifica un requisito. Una suite di test verifica diversi requisiti e modi in cui il sistema può fallire. Mantieni i risultati della tua applicazione separati dai punteggi dei benchmark dei modelli pubblici. Scrivi un breve record decisionale con le versioni vecchie e nuove, i casi testati, le definizioni dei punteggi e gli errori che bloccano il rilascio. Nomina la persona a cui appartiene il prossimo test.

Domande comuni