AI-EVAL · Percorso 4: Costruire e gestire
Evaluation, Observability e Guardrails
Senza Golden Dataset e release gate ogni release AI è un esperimento sui Suoi utenti.
- Durata
- 2 giorni
- Gruppo
- da 4 a 12 persone
- Formato
- Inhouse · Da remoto · Nel lab
- Lingua
- Tedesco o inglese
- Preavviso
- da 4 settimane
- Prezzo
- 15.800 € forfettario, IVA esclusa
Erogazione a partire da quattro partecipanti effettivamente iscritti. La data viene confermata per iscritto dopo aver concordato contenuti, prerequisiti e disponibilità.
Per chi è questo track
Sviluppatori, platform engineer e responsabili tecnici che portano un sistema AI verso la produzione o già lo gestiscono. Ideale per team che finora reagiscono alle modifiche dei prompt provando e sperando.
Per chi no
Non per team senza un sistema AI in esercizio o concretamente pianificato, a loro manca l’oggetto di misura, partono con AI-RAG. La prospettiva di sicurezza sulle minacce la fornisce Secure GenAI e Agent Threat Modeling (AI-SEC).
Situazione di partenza
Il sistema gira, ma nessuno sa dimostrare se l’ultimo aggiornamento del modello ha reso le risposte migliori o peggiori. I reclami arrivano dagli utenti invece che dal monitoring, i costi in token crescono inosservati e ogni modifica ai prompt va live senza verifica. Ciò che manca non è un’opinione, è un sistema di misura.
Questo esiste dopo il track
- Un Golden Dataset per il proprio sistema: casi curati con risultati attesi, casi limite e richieste volutamente difficili
- Metriche di qualità implementate per groundedness, rilevanza e completezza, incluso un LLM-as-Judge calibrato con controprova a campione
- Tracing sull’intera catena dalla richiesta attraverso retrieval e chiamata al modello fino alla risposta, con costi e latenza per ogni passo
- Un budget di costi e latenza per tipo di richiesta con soglie di allarme
- Release gate definiti: quali valori misurati un deployment deve superare e quando scatta un rollback
Prerequisiti
Competenze di programmazione in Python e un sistema AI reale o fornito nel training come oggetto di misura. L’esperienza con pipeline CI/CD aiuta.
Preparazione prima del track
Raccoglie in anticipo 20 richieste reali al Suo sistema, di cui almeno 5 con risposta scarsa o controversa, anonimizzate nel formato fornito. Il Giorno 1 questi casi diventano il nucleo del Suo Golden Dataset. I team senza sistema proprio ricevono un sistema RAG preparato sull’ambiente Lab.
Contenuto della fornitura
- 2 giornate di formazione con Dino Bordonaro, inhouse, remote o nel Lab
- Ambiente Lab personale con sistema di riferimento preparato e stack di valutazione, più 14 giorni di coda
- Repository di codice con implementazioni delle metriche, prompt per il judge e modelli di pipeline
- Modelli per Golden Dataset, definizione dei budget e checklist dei release gate
- Certificati di partecipazione e documentazione formativa per il Suo archivio di compliance
- Sessione remota di 60 minuti 4 settimane dopo il training per la review dei propri gate
Agenda
Giorno 1
La diagnosi del volo alla cieca
Esperimento dal vivo sul sistema di riferimento: un fix del prompt in apparenza innocuo peggiora in modo misurabile metà delle risposte. Domanda al gruppo: quante delle Sue ultime modifiche sono andate live senza misurazione?
Costruire il Golden Dataset
Officina sui casi portati: formulare i risultati attesi, aggiungere casi limite e domande trabocchetto, verificare la rappresentatività. Il risultato è un dataset versionato con 30-50 casi per team.
Implementare le metriche: groundedness, rilevanza, completezza
Hands-on: valutazione automatizzata con LLM-as-Judge, calibrazione contro giudizi umani a campione, gestione degli errori di giudizio del judge. Alla fine ogni metrica gira contro il proprio dataset.
Il primo run di valutazione
Run completo del proprio dataset contro il sistema, analisi degli outlier: l’errore sta nel retrieval, nel prompt o nel judge? La classificazione dell’errore decide la correzione giusta.
Risultato della giornata: una baseline solida
Ogni team presenta la propria baseline: dimensione del dataset, valori delle metriche, outlier classificati. Domanda di verifica: su questi numeri saprebbe approvare o respingere una modifica?
Giorno 2
Tracing: rendere visibile la catena
Hands-on: strumentazione della pipeline con trace per ogni richiesta, dai risultati di retrieval alle chiamate al modello fino alla risposta. Esercizio: diagnosticare un caso negativo reale solo con il trace.
Budget di costi e latenza
Analisi dei dati di trace: quanto costa quale tipo di richiesta in token e millisecondi? Ogni team definisce budget e soglie di allarme e li ancora nel monitoring.
Guardrail prima e dopo il modello
Implementazione: filtri in ingresso contro prompt injection e fuga di dati, verifica in uscita su grounding e violazioni di formato. Esercizio di misura: cosa intercettano i guardrail e quanto costa in latenza?
Release gate e riconoscimento delle regressioni
Officina: il run di valutazione come stage obbligatoria nella pipeline di deployment, soglie per metrica, criteri di rollback. Test sul proprio sistema: una regressione inserita di proposito deve essere fermata dal gate.
Risultato della giornata: il gate tiene
Collaudo per ogni team: la regressione preparata viene riconosciuta e bloccata dal proprio release gate, la versione pulita passa. Il regolamento dei gate documentato è l’artefatto verificabile di chiusura.
Esercitazioni e quota lab
Circa il 70 per cento del tempo è lavoro di implementazione sull’ambiente Lab: costruire il dataset, scrivere il codice delle metriche, analizzare i trace, testare i gate. La prova finale è una regressione realmente inserita che il proprio gate deve intercettare.
Piattaforme
Lo stack di valutazione si basa su componenti open source e gira sul nostro ambiente Lab, a scelta contro il sistema che Lei porta o contro il nostro RAG di riferimento. I pattern sono trasferibili su ambienti Azure e on-prem, i servizi di piattaforma nella versione di volta in volta disponibile.
Prova di transfer
La prova di trasferimento è il test del gate superato il Giorno 2: regressione riconosciuta, versione pulita approvata, regolamento documentato. Partecipazione e risultati vengono documentati in modo tracciabile e verificabile in sede di audit.
Artefatti che porta con sé
- Golden Dataset del proprio sistema, versionato ed estendibile
- Suite di metriche implementata con prompt del judge calibrati
- Setup di tracing con analisi di costi e latenza per tipo di richiesta
- Definizione dei budget con soglie di allarme come documento operativo
- Regolamento dei release gate con criteri di rollback per la propria pipeline
Estensioni opzionali
- Secure GenAI e Agent Threat Modeling (AI-SEC) per la prospettiva di sicurezza oltre le metriche di qualità
- LLMOps per ambienti connessi, separati e Air-Gap (AI-OPS) per il quadro operativo completo
- Agentic Systems Engineering (AI-AGENT), se in futuro i Suoi gate dovranno verificare agenti invece di assistenti
Delimitazione
Il track mette il Suo team in condizione di costruire e gestire il proprio sistema di misura. Non è un audit del Suo sistema produttivo né un servizio di managed monitoring, per questo parliamo di un progetto.
Domande frequenti
Il nostro sistema non è ancora in produzione. Il track arriva troppo presto?
No, semmai il contrario: chi costruisce Golden Dataset e gate prima della prima release misura fin dall’inizio. L’unico requisito è un sistema funzionante come oggetto di misura, in mancanza c’è il nostro RAG di riferimento sull’ambiente Lab.
Le valutazioni con LLM-as-Judge non sono a loro volta inaffidabili?
Se non calibrate sì, per questo la calibrazione è parte centrale: i giudizi del judge vengono verificati contro campioni umani, i pattern di scostamento documentati e i prompt affinati. Impara anche quando un judge è la scelta sbagliata e reggono le verifiche basate su regole.
Da remoto funziona bene come nel Lab?
Sì, l’intero ambiente di esercitazione gira comunque sul nostro Lab e viene usato da remoto. Inhouse o nel Lab guadagna le discussioni alla lavagna, da remoto guadagna i costi di trasferta, gli artefatti sono identici.