Che cosa rende un criterio “di validazione”

Un criterio di validazione ha tre parti e tutte e tre vanno fissate prima di eseguire il test: la metrica, la soglia di superamento e il dataset su cui la misuri. Se la soglia la scegli dopo aver letto i risultati, quella non è validazione: è giustificazione. Come architetto il tuo compito non è trovare il modello migliore in assoluto, ma dichiarare in anticipo che cosa significa “abbastanza buono” per quel processo aziendale e chi ha l’autorità di dire che il gate è superato.

Microsoft Foundry impone questa disciplina a livello di prodotto. Quando registri un custom evaluator (in preview) nel catalogo del progetto, la soglia è un parametro di inizializzazione obbligatorio: pass_threshold per gli evaluator code-based, threshold per quelli prompt-based. Non c’è un percorso che ti permetta di lanciare la run e decidere dopo. Le tre forme disponibili non sono intercambiabili e la scelta fra loro è architetturale:

  • code-based: una funzione Python grade() che restituisce un float fra 0.0 e 1.0. Gira in una sandbox senza accesso di rete, con limiti di dimensione del codice e di tempo per chiamata. Perfetta per formato, lunghezza, presenza di un disclaimer obbligatorio; inadatta a interrogare il tuo gestionale.
  • prompt-based: un judge prompt valutato da un modello, con scoring ordinal, continuous o binary e un output JSON con result e reason. È la scelta per il giudizio soggettivo, come tono di voce o aderenza al brand.
  • endpoint-based: un endpoint HTTP tuo, quando servono accesso a dati esterni, modelli proprietari o logiche che eccedono i limiti della sandbox.

Vincolo da ricordare quando disegni la suite: ogni evaluator dichiara i propri supported_evaluation_levels (turn o conversation) e non puoi mescolare livelli incompatibili nella stessa run. Se il criterio aziendale è “l’agente ha risolto il caso entro la conversazione”, quel criterio vive a livello conversation e va in una run separata da quelli per singolo turno.

Scegliere le metriche prima di vedere i numeri

Il catalogo built-in di Foundry ti dà il vocabolario: Coherence e Fluency fra i general purpose; Similarity, F1 Score, BLEU, GLEU, ROUGE, METEOR fra quelli di similarità testuale; Retrieval, Groundedness, Groundedness Pro (preview), Relevance, Response Completeness (preview) per il RAG; Task Adherence (preview), Intent Resolution (preview), Tool Call Accuracy, Tool Selection per gli agenti; e la famiglia risk and safety. La documentazione suggerisce anche le combinazioni: per un’applicazione RAG, Retrieval più Groundedness più Relevance più content safety; per un’applicazione agentica, Tool Call Accuracy più Task Adherence più Intent Resolution.

Attenzione a due trappole di lettura. La prima: i model benchmarks e le leaderboard (quality index, Attack Success Rate, latenza P50/P90/P95/P99, throughput) confrontano modelli su dataset pubblici, e la doc stessa avverte che quei dataset possono saturarsi nel tempo. Servono a restringere la rosa, non a validare la tua soluzione: quella si valuta sui tuoi dati. La seconda: se stai facendo fine-tuning in Foundry, il criterio di validazione non è un gate una tantum. La documentazione dice esplicitamente che il fine-tuning va ripetuto quando i dati cambiano o quando esce un base model aggiornato, e che dati non rappresentativi producono over-fitting, under-fitting o bias. Un criterio maturo include quindi la condizione di ri-validazione e il baseline contro cui confrontarsi (di norma il modello di partenza con il prompt attuale).

Su un altro asse ci sono i modelli custom di AI Builder: document processing, prediction, object detection e le varianti custom di category classification ed entity extraction si costruiscono, si allenano e si pubblicano, mentre i prebuilt si usano e basta. Il criterio di accettazione per un modello custom lo scrivi tu; per un prebuilt scegli soltanto se il comportamento osservato è compatibile con il processo.

Scenario tipico d’esame: una compagnia assicurativa vuole automatizzare l’estrazione dei dati dai moduli di sinistro e pone il vincolo che nessun campo importo possa essere scritto a sistema senza revisione. Il criterio non è un unico numero di accuratezza: è una soglia per campo, più una regola che instrada sotto soglia a revisione umana.

Validare le best practice di un prompt di Copilot

Per gli agenti di Microsoft 365 Copilot, la documentazione sull’evaluation dà un impianto preciso: un test case è un prompt più un comportamento atteso più delle assertion, e dev’essere indipendente, ripetibile e specifico; i test case si raccolgono in un test set; ogni assertion viene giudicata da un grader (keyword match, exact match, text similarity, LLM-as-judge, tool verification); i risultati si etichettano con quality signal come policy accuracy o source attribution; e i grounding data rendono l’assertion verificabile, perché “contiene il saldo corretto” non è verificabile mentre “contiene 12 days” lo è. La stessa pagina indica una copertura di 20-50 test case in prototipo, 50-100 in preproduzione, oltre 100 in produzione, un pass rate complessivo del 80-90 per cento, regressioni vicine al 100 per cento di consistenza e run ripetute con media dei risultati, perché il comportamento è variabile.

Validare le best practice di un prompt significa verificare che le instructions contengano quello che le rende deterministiche: tono, verbosità e formato di output dichiarati (altrimenti il modello li inferisce), task atomici, struttura Markdown coerente, riferimento esplicito ad azioni e knowledge source, un output contract e un passaggio finale di self-evaluation. Due regole hanno peso architetturale: per impedire al modello di attingere alla conoscenza interna si imposta discourage_model_knowledge nel manifest, e le istruzioni non vanno mai scaricate su un documento SharePoint per aggirare il limite di 8.000 caratteri, perché il contenuto di una knowledge source non è contenuto di istruzione affidabile ed è esposto ai classificatori XPIA. In Microsoft Copilot Studio il prompt builder permette di costruire, testare e salvare prompt riusabili, con supervisione umana dichiarata come passaggio necessario prima che l’output informi una decisione di business.

Che cosa verifica l’esame

L’esame verifica che tu sappia quale strumento risponde a quale domanda, non che ricordi i nomi delle metriche. L’evaluation misura accuratezza, completamento del task, uso degli strumenti e coerenza; non sostituisce la revisione di responsible AI, la moderazione dei contenuti, il security testing, la ricerca sugli utenti né i test di performance. Il monitoring è ciò che osservi in produzione dopo la pubblicazione; il testing è l’attività manuale e di tracing con cui debug una singola versione. Nel ciclo di vita di un agente in Foundry l’ordine è dichiarato: si salvano le versioni (immutabili), si fa debug con il tracing (preview), si eseguono le evaluation prima di pubblicare e dopo ogni cambiamento significativo, poi si monitora.

Terza distinzione, la più fraintesa: l’AI Red Teaming Agent produce un Attack Success Rate ed è misura di robustezza alle sollecitazioni avversarie, non di qualità; i suoi risultati sono generati da modelli, quindi non deterministici e soggetti a falsi positivi, e vanno rivisti prima di agire. Le Foundry Guardrails (già content filter) sono un controllo che agisce a runtime, non un criterio di validazione. Se una domanda ti chiede come dimostrare a un comitato che una nuova versione dell’agente non ha peggiorato le risposte, la risposta è una evaluation ripetibile su un test set con soglie dichiarate, non un filtro di contenuto né una campagna di red teaming.