Un agente può avere ragione per la strada sbagliata
Il primo criterio da portare al cliente è che valutare un agente non coincide con valutare la sua ultima frase. Microsoft Foundry organizza gli agent evaluator lungo due pratiche dichiarate: la system evaluation, che esamina l’esito end-to-end del flusso agentico, e la process evaluation, che verifica passo per passo come quell’esito è stato raggiunto. Sono domande diverse, e un agente può superare la prima fallendo la seconda.
Prendiamo una compagnia assicurativa il cui vincolo è che lo stato di un sinistro debba provenire dal sistema di record, mai da altro. L’agente risponde “la pratica è in liquidazione” e la risposta è corretta, ma l’ha dedotta da un documento di knowledge invece di chiamare il tool sul gestionale. Un evaluator di risultato passa; il vincolo architetturale è però violato, e alla prima variazione di stato la stessa risposta diventerà falsa senza che nulla sia cambiato nella configurazione. Quel difetto è visibile solo guardando il processo.
Sul versante system evaluation Foundry espone Task Completion (preview), Task Adherence (preview), Intent Resolution (preview), Customer Satisfaction (preview) e Task Navigation Efficiency. Sul versante process evaluation espone Tool Call Accuracy, Tool Selection, Tool Input Accuracy, Tool Output Utilization e Tool Call Success. Quasi tutti restituiscono un esito binario Pass/Fail, alcuni partono da una scala 1-5 poi sogliata, mentre Customer Satisfaction usa una scala Likert 1-5 su sei dimensioni fra cui helpfulness, clarity e resolution.
Le distinzioni fini contano nella scelta: Tool Call Success dice soltanto se la chiamata non è finita in errore tecnico, Tool Input Accuracy verifica i parametri secondo sei criteri stretti, Tool Output Utilization verifica che il risultato ricevuto sia stato davvero usato nel ragionamento e nella risposta. Un agente può chiamare il tool giusto, ottenere il dato e poi ignorarlo: tre evaluator diversi, tre guasti diversi. È esattamente il tipo di discriminazione che l’esame chiede di fare.
Il set di riferimento si progetta prima, non si raccoglie dopo
La documentazione sull’estensibilità di Microsoft 365 Copilot fissa un vocabolario che conviene adottare anche fuori da quella superficie: un test case è un singolo scenario composto da prompt, comportamento atteso e assertion; le assertion devono essere atomiche, binarie e verificabili; un test set le raggruppa; un grader decide se passano (keyword match, exact match, text similarity, LLM-as-judge, tool verification); un quality signal categorizza il tipo di fallimento; i grounding data forniscono i valori realistici senza cui l’assertion non è verificabile. Un’assertion come “la risposta contiene il saldo corretto” non si può misurare; “la risposta contiene 12 days”, con un dipendente di prova e un saldo noto, sì.
La stessa fonte dà indicazioni di copertura per fase — dell’ordine di 20-50 test case in prototipo, 50-100 in preproduzione, oltre 100 in produzione — e di soglia: un pass rate complessivo attorno all’80-90%, con i test di regressione centrali che devono avvicinarsi alla piena consistenza. Il consiglio operativo che chiude il cerchio sul non determinismo è eseguire le valutazioni più volte e mediare i risultati.
Alcune valutazioni richiedono una ground truth esplicita. Task Navigation Efficiency confronta la traiettoria dell’agente con una sequenza attesa e la sua modalità di confronto è una vera scelta di progetto: exact_match per una procedura regolamentata in cui ordine e contenuto non sono negoziabili, in_order_match quando l’ordine conta ma passi aggiuntivi sono tollerati, any_order_match per flussi esplorativi. Il risultato include precision, recall e F1 oltre al pass/fail.
Ogni superficie ha il proprio strumento di test
Microsoft Copilot Studio non usa gli stessi oggetti: lì si creano test set e si scelgono test method fra General quality, Compare meaning, Tool use, Keyword match, Text similarity, Exact match e Custom. General quality valuta con un LLM relevance, groundedness, completeness e abstention e non richiede risposte attese; Tool use è il metodo che verifica se l’agente ha usato gli strumenti o i topic previsti — l’analogo locale della process evaluation. In fase di authoring l’activity map mostra il piano che l’orchestratore ha scelto durante il test.
Attenzione al lessico: parte della documentazione degli evaluator vive ancora sotto percorsi /azure/foundry-classic/ e parla di “Azure AI Foundry”. È lo stesso prodotto, non due offerte concorrenti; il blueprint usa i nomi nuovi.
Valutazione, test, monitoraggio e red teaming non sono sinonimi
Questa è la confusione che l’esame punisce più spesso. La evaluation misura qualità e sicurezza su un dataset controllato e va rieseguita a ogni cambiamento significativo, prima di pubblicare; in Foundry richiede che l’agente sia stato salvato come versione, perché le versioni sono immutabili e comparabili. Il monitoring post-pubblicazione è un’altra cosa: metriche operative, continuous evaluation su traffico di produzione campionato, scheduled evaluation su dataset di test per intercettare la deriva, alert di Azure Monitor. Il tracing serve a capire perché una valutazione è fallita, non a stabilire se sia fallita.
L’AI Red Teaming Agent non misura qualità ma postura di rischio, con l’Attack Success Rate come metrica chiave, e la documentazione avverte che usa modelli generativi, quindi può produrre falsi positivi da rivedere. Infine la valutazione non sostituisce revisioni di responsible AI, content moderation, security testing e performance testing: raccomandare solo il set di evaluator, in una proposta architetturale, significa aver coperto una casella su cinque.