Senza valutazione un sistema Claude non è difendibile: ogni cambio di prompt, modello o strumento diventa una scommessa raccontata a parole. Che cosa si misura, su quali dati e con quale metodo di giudizio si decide prima della produzione.

Cinque metriche, e chi risponde di ciascuna

Accuratezza. Non si dichiara «buone prestazioni». I criteri di successo vanno resi specifici — «Instead of ‘good performance,’ specify ‘accurate sentiment classification.’» — misurabili, raggiungibili («Base your targets on industry benchmarks, prior experiments, AI research, or expert knowledge») e pertinenti al caso d’uso: «Strong citation accuracy might be critical for medical apps but less so for casual chatbots».

Latenza. Due grandezze da tenere distinte. La latenza di base è «the time taken by the model to process the prompt and generate the response, without considering the input and output tokens per second»; il time to first token «measures the time it takes for the model to generate the first token of the response, from when the prompt was sent» ed «is particularly relevant when you’re using streaming». Un’interfaccia in streaming si difende sul TTFT, un lavoro batch sulla latenza di base. E l’ordine di lavoro è raccomandato: «It’s always better to first engineer a prompt that works well without model or prompt constraints, and then try latency reduction strategies afterward».

Costo. La voce da tracciare non è il prezzo per milione di token ma «latency, token usage, cost per task, and error rates», su un banco di prova stabile.

Sicurezza d’uso e sicurezza informatica. Sono due metriche, non una. La prima si valuta con un classificatore binario, come nel pattern documentato per i dati sanitari, che «can account for context and identify subtle or implicit forms of PHI that rule-based systems might miss». La seconda è il tasso di successo dell’attacco: «Attack success rate (ASR) of our internal Best-of-N attacker. Lower is better». E va comunicata con l’onestà della fonte: «A 1% attack success rate—while a significant improvement—still represents meaningful risk».

Il dataset: quanti casi, e da dove vengono

La soglia d’ingresso è bassa: «20-50 simple tasks drawn from real failures is a great start». L’origine conta più del volume: fallimenti reali, non casi inventati a tavolino. E c’è un costo del rinvio: «Evals get harder to build the longer you wait. Early on, product requirements naturally translate into test cases».

Il dataset deve somigliare al traffico vero: «Design evals that mirror your real-world task distribution. Don’t forget to factor in edge cases!». Fra i casi limite indicati: input irrilevanti o inesistenti, input troppo lunghi, input utente dannosi, e «Ambiguous test cases where even humans would find it hard to reach an assessment consensus». Sul compromesso fra numerosità e raffinatezza la posizione è netta: «More questions with slightly lower signal automated grading is better than fewer questions with high-quality human hand-graded evals».

Metodologie miste: codice, giudice, essere umano

Le metodologie miste servono a coprire dimensioni diverse dello stesso compito. I valutatori a codice — confronti di stringa, test binari, analisi statica, verifica dello stato finale — sono «Fast, cheap, objective, reproducible, easy to debug»: vanno usati ovunque esista una risposta verificabile meccanicamente.

Il giudice modello copre il resto, con tre regole. Rubrica strutturata, una dimensione per volta: «create clear, structured rubrics to grade each dimension of a task, and then grade each dimension with an isolated LLM-as-judge». Via d’uscita esplicita per non forzare un verdetto: «give the LLM a way out, like providing an instruction to return ‘Unknown’». Modello diverso da quello valutato, perché è «Generally best practice to use a different model to evaluate than the model used to generate the evaluated output».

Il giudizio umano non sparisce, cambia funzione: «LLM-as-judge graders should be closely calibrated with human experts», e la pratica raccomandata è leggere trascrizioni e voti di molte prove per verificare che la valutazione misuri ciò che conta.

Stato finale, traiettoria e strumentazione

Gli oggetti da valutare sono due. Il primo è «the final state in the environment at the end of the trial»; il secondo è il percorso — chiamate agli strumenti, ragionamento, risultati intermedi — che spiega perché due esecuzioni con lo stesso esito non valgono uguale.

La Managed Agents API rende il primo un meccanismo di prodotto: dato un outcome, «the harness automatically provisions a grader to evaluate the artifact against a rubric», e «The grader uses a separate context window to avoid being influenced by the main agent’s implementation choices», con un numero di iterazioni predefinito di tre e massimo venti. La qualità dipende dalla rubrica, che va scritta come criteri verificabili: «‘The CSV contains a price column with numeric values’ rather than ‘The data looks good.’».

La traiettoria si strumenta con OpenTelemetry. Gli span coprono ogni richiesta al modello «with model name, latency, and token counts as attributes» e ogni chiamata a strumento. Da sapere prima di promettere un audit completo: «Telemetry is structural by default» e «The content your agent reads and writes is not recorded by default» — i corpi di prompt e strumenti si attivano con variabili dedicate, da usare solo se l’osservabilità è autorizzata a conservare quei dati.

Un limite da dichiarare: la documentazione Anthropic non definisce un metodo di A/B testing in produzione. Sostiene il banco di prova statico, la rubrica, il giudice calibrato e la telemetria; il disegno sperimentale è una scelta dell’organizzazione, e va presentata come tale.