Sebbene i modelli di base siano migliorati, la vera svolta che ne consente un uso affidabile in produzione deriva da pratiche di valutazione rigorose
Valutazioni ben progettate aiutano product manager, responsabili della governance dell’IA e CTO a distribuire agenti IA in modo sicuro e su larga scala, trasformando l’IA da strumento isolato a vantaggio competitivo.
Questa fiducia nasce dalla valutazione del comportamento degli agenti IA rispetto a richieste di utenti reali, casi limite e scenari specifici del settore che riflettono l’effettivo contesto aziendale, non da un benchmark pubblico che afferma: «Questo modello è il migliore»
L’obiettivo è giustificare tale fiducia attraverso risultati misurabili. Avere successo significa definire concretamente e in termini misurabili che cosa è "valido", in linea con le esigenze aziendali e la propensione al rischio: accuratezza fattuale, tono appropriato, velocità o efficienza dei costi.
Integrando la valutazione nell’intero sistema (strumentazione, registrazione, test A/B, misure di sicurezza) e bilanciando rigore ed efficienza, i team potranno distribuire più rapidamente soluzioni più robuste.
La maggior parte delle aziende accetta che i dipendenti sperimentino con ChatGPT o Gemini. È invece meno comune impiegare gli LLM in flussi di lavoro o contesti ad alto rischio.
Spesso per validi motivi: la qualità è stata incostante e il rischio di allucinazioni o comportamenti indesiderati ha superato i potenziali vantaggi offerti dalla tecnologia.
Nell’ultimo anno, questo equilibrio tra rischi e benefici è cambiato sensibilmente. Se in parte ciò è dovuto al miglioramento delle prestazioni dei modelli di base, molto dipende dalla crescente disciplina adottata nella valutazione (o «eval»). Le eval offrono a noi e ai nostri clienti la fiducia necessaria per distribuire in poche settimane agenti su larga scala e rivolti alla clientela.
Questa guida illustra gli elementi fondamentali delle eval e spiega come progettarle, implementarle e gestirle per i casi d’uso in produzione.
L’obiettivo della valutazione non è trovare un modello perfetto, ma generare una fiducia giustificata nel fatto che il modello si comporti in linea con le esigenze aziendali, le aspettative degli utenti e la propensione al rischio dell’organizzazione.
Alla base di ogni strategia di valutazione c’è una domanda semplice: Che cosa significa ottenere un risultato «valido»? La risposta deve essere specifica. Per un’organizzazione, un risultato «valido» può significare accuratezza fattuale entro tolleranze rigorose; per un’altra, può dare priorità alla velocità, all’efficienza dei costi o a un tono di voce distintivo. Ogni vincolo operativo, dai dati utilizzabili agli obblighi normativi applicabili, contribuisce a plasmare questa definizione.
È essenziale che ciò che è 'valido' includa componenti effettivamente misurabili. Se il successo consiste nel fornire indicazioni finanziarie utili, l’utilità deve tradursi in attributi: correttezza fattuale, avvertenze appropriate, ragionamento personalizzato e limiti di sicurezza. Una volta definito in termini misurabili che cosa è «valido», occorre stabilire come analizzare e interpretare i risultati. Agire in base a questi risultati trasforma la valutazione in un metodo, anziché in una semplice formulazione di giudizi.
Ogni pipeline di valutazione si basa su tre pilastri interconnessi:
Input/benchmark: esempi rappresentativi e realistici per le prestazioni generali e set di dati interni selezionati per verificare l’idoneità al settore.
Comportamento del modello: come viene chiamato il modello (generazione aumentata tramite recupero, sintesi, recupero di informazioni strutturate, uso di strumenti).
Metriche: come misurare e interpretare le prestazioni.
Gli input devono rappresentare il mondo con cui il sistema interagirà. Le indicazioni più significative derivano da esempi reali: richieste dei clienti, scenari finanziari o casi specifici del settore. Solo verificandolo rispetto a questi esempi è possibile capire se il modello coglie davvero le sfumature richieste dagli utenti e soddisfa le esigenze aziendali.
Il comportamento del modello, ad esempio il modo in cui riceve il prompt, vengono orchestrati il recupero e l’uso degli strumenti e viene fornito il contesto, conta quanto il modello stesso. Due modelli identici possono comportarsi in modo molto diverso a seconda di come vengono distribuiti. Questo livello deve quindi essere incluso nella progettazione della valutazione.
Infine, ci sono le metriche. I numeri da soli raramente raccontano tutta la storia, ma metriche ben scelte rendono interpretabile il comportamento del sistema. Latenza, accuratezza, sicurezza, coerenza, bias, costi e soddisfazione degli utenti formano nel complesso un quadro multidimensionale di un sistema in produzione. L’abilità consiste nello scegliere metriche in linea con i KPI del progetto o dell’azienda e capaci di evidenziare le qualità più importanti per gli utenti. Le metriche più semplici sono spesso più accurate e meno costose, mentre scelte inadeguate possono fuorviare i team. Ecco come affrontare la scelta delle metriche:
Esempi di metriche ben scelte:
Chatbot per il servizio clienti: tasso di risoluzione al primo contatto (il problema dell’utente è stato risolto senza escalation?), tempo medio di gestione, punteggio di soddisfazione degli utenti, tasso di escalation agli operatori umani
Strumento di ricerca finanziaria: accuratezza delle citazioni (% di affermazioni con fonti adeguate), precisione fattuale convalidata rispetto ai dati reali, pertinenza del recupero (ha trovato i documenti giusti?), coerenza del ragionamento valutata da esperti del settore
Assistente per la generazione di codice: correttezza della sintassi, tasso di superamento dei test, numero di vulnerabilità di sicurezza, tempo necessario per ottenere una soluzione funzionante
Esempi di metriche scelte male:
Usare solo la lunghezza della risposta come indicatore della qualità (più lunga ≠ migliore)
Misurare la velocità senza considerare il compromesso con l’accuratezza
Monitorare i punteggi di fiducia del modello senza confrontarli con l’effettiva correttezza
Affidarsi esclusivamente alla perplessità interna del modello senza una convalida rivolta agli utenti
Errori comuni relativi alle metriche da evitare:
Metriche in conflitto: ottimizzare contemporaneamente velocità ed esaustività senza riconoscere il compromesso
Overfitting sui benchmark: ottenere il 95% sul set di test, ma fallire in produzione perché gli utenti reali si comportano diversamente
Per un cliente del settore dei servizi finanziari altamente regolamentato, l’accuratezza della soluzione di deep research era fondamentale. Abbiamo creato set di dati di domande e risposte realizzati da esperti e li abbiamo combinati con set generati da strumenti, così da valutare la precisione, la capacità del sistema di selezionare gli strumenti giusti e recuperare le informazioni corrette, ottenendo una visione equilibrata dell’accuratezza e della qualità del ragionamento. L’aspetto fondamentale era misurare più dimensioni: accuratezza fattuale (convalida degli esperti), qualità del recupero (precisione/recall dei documenti pertinenti) e coerenza del ragionamento (valutazione strutturata del flusso logico).
Quando usare un LLM come giudice per valutare una qualità ricca di sfumature
L’approccio LLM-as-a-judge usa un secondo modello di IA come valutatore, sostituendo la revisione umana con un punteggio di qualità automatizzato e scalabile. L’approccio LLM-as-a-judge viene spesso usato impropriamente quando metriche più semplici possono fornire l’accuratezza necessaria. Può essere utile quando i controlli deterministici non riescono a cogliere la qualità, ad esempio se la metrica è semantica (utilità, aderenza alle fonti, qualità del ragionamento, tono, interpretazione delle policy) e non è possibile assegnare un punteggio deterministico. Potrebbe essere necessario ottenere feedback scalabili su molte varianti di prompt/modello e definire criteri chiari e uno schema per i risultati strutturati. Per sfruttarlo al meglio, segui questi passaggi:
Definisci esplicitamente le dimensioni dei criteri: correttezza, aderenza alle fonti, conformità alle policy, attuabilità, tono.
Usa risultati strutturati (schema JSON) per le risposte del giudice.
Acquisisci sia punteggi binari di superamento sia testo diagnostico per analizzare gli errori.
Calibra a ogni ciclo di rilascio i risultati del giudice rispetto a campioni etichettati da persone.
Per i settori ad alto rischio, usa due giudici o controlli periodici del consenso.
Monitora nel tempo la deriva del giudice e il tasso di disaccordo.
Un set di dati di benchmark è un insieme fisso e selezionato di esempi di test con risposte note, usato per valutare i modelli con coerenza e confrontare equamente i risultati tra le versioni. Solitamente include input (ad esempio, richieste degli utenti), risultati previsti o giudizi di riferimento e criteri/etichette di valutazione per assegnare i punteggi. I test dei benchmark pubblici servono a confrontare le prestazioni dei modelli più avanzati e possono offrire un primo orientamento, durante la progettazione del sistema, su quale modello potrebbe essere adatto.
Per il tuo sistema, tuttavia, non puoi usare questi benchmark come indicatore delle prestazioni nel contesto aziendale, perché presentano problemi noti:
Contaminazione: i modelli possono essere stati addestrati sui dati del benchmark; valutarli sullo stesso set equivale ad assegnare un voto usando un formulario con le risposte.
Saturazione: tutti i modelli migliori raggiungono già i punteggi massimi, perciò miglioramenti o peggioramenti si limitano a pochi punti percentuali e spesso rientrano nella normale variabilità dei risultati dei test.
Ambito ristretto: i dati dei benchmark non riflettono le attività reali, perché sono fortemente selezionati e ripuliti. Alcuni sono persino generati da LLM e non riflettono la complessità e i casi limite presenti nei tuoi dati (refusi, formulazioni insolite, immagini con disturbi).
Uno studente chiede all’applicazione di aiutarlo a risolvere problemi formulati a parole.
Esempio di benchmark pubblico utilizzabile: GSM8K (ragionamento matematico della scuola primaria)
Set facoltativo più difficile: MATH.
Perché questo benchmark è utile:
Consente di confrontare rapidamente quale modello è migliore nel ragionamento matematico generale,
È un buon primo filtro prima di investire in eval complete del prodotto.
Perché è comunque necessario un set di dati proprietario:
La tua app presenta requisiti che GSM8K non verifica:
La terminologia e l’ordine degli argomenti del tuo programma didattico,
Lo stile delle spiegazioni per la fascia d’età interessata,
Come gestire domande ambigue o ricche di refusi poste dagli studenti,
Regole delle policy (ad esempio, quando fornire suggerimenti anziché risposte complete).
Una convalida efficace dipende dalla creazione di benchmark di valutazione specifici per l’applicazione. Questi set di dati devono derivare da interazioni reali, casi limite tipici e modalità di errore plausibili. Può essere un compito difficile quando si implementa un nuovo prodotto o processo. Nella maggior parte dei casi, tuttavia, è possibile raccogliere dati da un prodotto esistente o il prima possibile, anche durante una fase iniziale di test. Dopo lo sviluppo dell’applicazione, questi benchmark devono evolversi insieme al prodotto, diventando nel tempo più ricchi e rappresentativi.
Caso di studio: creazione di un benchmark personalizzato per un assistente di retail banking
Un chatbot bancario risponde a domande su budget, spese e transazioni. I benchmark pubblici di domande e risposte/text-to-SQL non coglievano rischi bancari fondamentali come SQL injection, fughe di dati o mantenimento del contesto su più turni. Abbiamo creato un benchmark personalizzato che rispecchia la pipeline di agenti di questo prodotto.
Componenti del benchmark personalizzato in questa base di codice:
Suite di red teaming con prompt dannosi per SQL injection, estrazione di dati personali, sovrascrittura del prompt e fughe di dati tra sessioni
Tolleranza zero sulla sicurezza: ogni tentativo di SQL injection, estrazione di dati personali o fuga di dati tra sessioni deve essere respinto.
Accuratezza nel mantenimento del contesto: le richieste riformulate devono preservare l’intento e le entità dell’utente.
Conclusione: considera la creazione del benchmark una funzionalità del prodotto. L’infrastruttura attuale dimostra che la valutazione end-to-end è integrata, ma la copertura e le dimensioni dei campioni devono crescere per riflettere i rischi bancari reali (attacchi multi-intento, aggiramento delle misure di sicurezza e richieste dipendenti dal contesto). Il benchmark deve ampliarsi insieme ai nuovi agenti e alle misure di sicurezza.
Il legame tra il benchmark specifico dell’applicazione e la scelta del modello è fondamentale. Il benchmark non rivela solo se una soluzione funziona, ma anche quale combinazione di dimensioni del modello e tecniche di post-addestramento offre le prestazioni necessarie con il miglior rapporto costi-benefici. I miglioramenti più efficaci per i modelli preaddestrati (la sigla «PT» in ChatGPT) non derivano da un nuovo addestramento, ma dai metodi di "post-addestramento".
Questi metodi mirano a definire le informazioni a cui il modello può accedere, come vengono strutturate e come il modello viene guidato e orchestrato durante l’inferenza. Tecniche di post-addestramento come:
Prompt basati sulla chain of thought e allocazione dinamica delle risorse di calcolo (ragionare più a lungo sui problemi più difficili)
Autocoerenza, con la generazione di più risultati e la selezione del migliore
Costruzione e orchestrazione del contesto, come Retrieval-Augmented Generation (RAG), esempi few-shot e flussi di lavoro agentici
Uso di strumenti e accesso a conoscenze esterne, che consentono al modello di agire oltre i propri parametri interni
Strategie di rappresentazione e archiviazione delle conoscenze, progettate per il recupero e il ragionamento efficienti su dati strutturati e non strutturati
Sebbene queste tecniche di post-addestramento possano migliorare notevolmente le prestazioni del sistema, introducono anche dei compromessi. Ogni ulteriore livello di orchestrazione, recupero o ragionamento aumenta la complessità del sistema, il tempo di inferenza e i costi operativi. Se applicata con attenzione, tuttavia, la giusta combinazione di tecniche di post-addestramento permette spesso di usare modelli più piccoli, veloci ed economici, soddisfacendo comunque i requisiti prestazionali. Anziché aumentare le dimensioni del modello, si ottengono le prestazioni attraverso una migliore progettazione del sistema.
Questo equilibrio è intrinsecamente specifico per ogni applicazione e deve basarsi sulle relative eval per determinare la combinazione ottimale di tecniche. Consentiranno di individuare il punto oltre il quale un’ulteriore orchestrazione non produce più vantaggi significativi, permettendo ai team di scegliere il livello minimo di complessità post-addestramento necessario per raggiungere le prestazioni desiderate.
Una soluzione di IA deve essere considerata come un sistema completo: database, API, interfacce utente, livelli di orchestrazione, infrastruttura di monitoraggio e altro ancora. La valutazione deve quindi estendersi all’intero stack. Occorre monitorare le parti fondamentali del sistema per mantenere visibili i potenziali problemi e accelerare responsabilmente.
Monitorare le parti fondamentali del sistema significa:
Dotare le pipeline degli strumenti necessari per produrre risultati misurabili.
Registrare gli esperimenti per osservare l’effetto di ogni modifica.
Usare semplici confronti A/B prima di distribuire modifiche importanti, così da verificare eventuali regressioni.
L’iterazione basata sui dati accorcia il percorso dal prototipo alla produzione, senza punti ciechi. Registrazione e monitoraggio sono importanti anche per comprendere l’uso effettivo dell’applicazione. Ecco un esempio per garantire l’osservabilità:
Passaggio 1: la richiesta dell’utente arriva con request_id, user_segment, intent.
Passaggio 2: la traccia registra versione del modello, versione del prompt, documenti recuperati e chiamate agli strumenti.
Passaggio 3: il giudice LLM assegna un punteggio alla risposta (correctness, groundedness, policy_risk).
Passaggio 4: il motore di regole valuta le soglie.
Passaggio 5: se viene superata una soglia, attiva un avviso e indirizza alla procedura di fallback/revisione umana.
Passaggio 6: l’errore viene aggiunto alla coda di triage e poi al backlog del benchmark.
Gli utenti reali raramente si comportano esattamente come previsto dai progettisti. Alcuni fraintendono le istruzioni. Altri sondano intenzionalmente i punti deboli. Questi casi limite non sono anomalie, ma segnali preziosi. Una pipeline di valutazione ben implementata li acquisisce, li analizza e li integra nei test futuri. Iterare rapidamente senza punti ciechi è possibile solo quando la valutazione è integrata nel sistema, non aggiunta a sviluppo ultimato.
Consigliamo di integrare misure di sicurezza e monitoraggio fin dal primo giorno:
Monitora regolarmente le metriche e le regressioni del modello usando il benchmark specifico dell’applicazione.
Acquisisci e verifica casi limite o input avversari, aggiungendoli al set di dati del benchmark specifico dell’applicazione.
Assicurati che queste metriche di valutazione siano allineate ai KPI principali.
Metti regolarmente alla prova il set di dati e il benchmark per assicurarti di non ignorare nuovi rischi o essere soggetto a bias.
Implementa avvisi automatici per il deterioramento delle metriche (ad esempio, se l’accuratezza scende sotto l’85%, attiva una revisione).
Mantieni un processo di revisione umana per le decisioni ad alto rischio (consulenza legale, indicazioni mediche, transazioni finanziarie).
Ogni esecuzione del benchmark consuma risorse di calcolo ed energia. Ogni esperimento ridondante aumenta i costi. Una valutazione responsabile deve bilanciare rigore ed efficienza.
È possibile adottare alcune misure pratiche per evitare che consumi energetici e costi vadano fuori controllo:
Usa modelli più piccoli quando possibile, eseguendo gli esperimenti iniziali su modelli meno costosi e passando a modelli più grandi solo dopo aver convalidato l’approccio.
Memorizza nella cache i prompt e le chiamate API.
Pianifica le attività tenendo conto dei consumi energetici (elaborazione in batch, istanze spot, priorità flessibile).
Monitora l’uso delle risorse di calcolo insieme alle prestazioni.
Allo stesso modo, presta attenzione alle nuove normative sull’IA. Anche in assenza di leggi dedicate, restano applicabili i quadri normativi esistenti e le misure necessarie, tra cui:
Protezione dei dati:
Assicurati che i set di dati dei benchmark non contengano dati personali senza un consenso adeguato
Implementa policy di conservazione dei dati per le richieste registrate
Fornisci meccanismi per le richieste di cancellazione dei dati
Uguaglianza e bias:
Verifica le prestazioni nei diversi gruppi demografici
Includi una rappresentanza eterogenea nella creazione del benchmark
Diritti umani e trasparenza:
Documenta chiaramente per gli utenti i limiti del modello
Fornisci spiegazioni per le decisioni ad alto rischio
Consenti la supervisione umana per le applicazioni critiche
La valutazione non è un evento isolato, ma un sistema in evoluzione. In un settore in rapida evoluzione, il vantaggio dipende dalla velocità con cui si riesce a testare, apprendere e adattarsi, così da distribuire modelli e nuove soluzioni con maggiore efficacia.
Integrando la valutazione come attività centrale di ingegneria e gestione del prodotto, i team possono innovare più velocemente e in maggiore sicurezza. Inizia definendo che cosa significa ottenere un buon risultato nel contesto della tua applicazione di IA, configura una piattaforma di valutazione e falla evolvere per disporre di un benchmark specifico per l’applicazione che, a ogni iterazione, dia fiducia nella sua idoneità alla produzione.