Il semplice fatto di ottenere una risposta da un modello AI non significa ancora che il sistema funzioni correttamente. Nel caso del software classico possiamo spesso verificare in modo univoco se una funzione ha restituito il risultato atteso. Nei sistemi AI la risposta può essere fluida, logica e convincente, eppure contenere errori.
Perciò, con lo sviluppo dell’AI, emerge un nuovo problema ingegneristico: come misurare sistematicamente la qualità di un sistema le cui risposte non sono sempre identiche?
È proprio questo l’ambito della AI evaluation, cioè della valutazione dei sistemi di intelligenza artificiale.
Ed è molto più ampio del semplice controllo se il chatbot “risponde bene”.
Il test del software classico e il test dell’AI non sono la stessa cosa
Immaginiamo una semplice funzione in un’applicazione.
L’utente inserisce: 2 + 2
Il sistema dovrebbe restituire: 4
Se restituisce 5, abbiamo un errore inequivocabile.
Possiamo preparare un test: expect(calculate("2 + 2")).toBe(4)
e ogni volta otterremo un risultato chiaro: il test passa oppure no.
Nei sistemi AI la situazione è diversa.
L’utente può chiedere: “Scrivi una risposta breve per un cliente che chiede la data di completamento dell’ordine.”
Il sistema può generare diverse risposte. Tutte possono essere linguisticamente corrette. Tutte possono sembrare professionali. Una però può contenere una data non vera, un’altra può essere troppo lunga, una terza può omettere un’informazione importante e una quarta può essere perfetta.
Non basta quindi verificare se la risposta è stata generata tecnicamente.
Bisogna verificare, se soddisfa criteri di qualità specifici.
Primo problema: una buona risposta non è sempre vera
Questa è una delle caratteristiche più tipiche dell’AI generativa.
Il modello può generare una risposta che suona molto convincente, ma che non trova riscontro nei dati di origine.
Nel caso di un sistema che usa il RAG, il problema è ancora più interessante. Il sistema può ricevere una domanda, cercare alcuni frammenti della documentazione e poi generare una risposta.
A quel punto bisogna verificare almeno tre cose:
- Sono state trovate le informazioni giuste? Il meccanismo di ricerca ha recuperato frammenti realmente pertinenti alla domanda?
- La risposta utilizza le informazioni trovate? Il modello non ha aggiunto qualcosa che nelle fonti non c’era?
- La risposta risponde davvero alla domanda? Si può infatti avere un retrieval corretto, ma una risposta finale scadente.
Proprio per questo la valutazione del RAG separa, tra le altre cose, aspetti come la pertinenza del contesto recuperato, la completezza della ricerca, la correttezza della risposta e la sua coerenza con le fonti.
Questo è un cambiamento importante nel modo di pensare ai test.
Non testiamo più solo: domanda → risposta
ma l’intera catena: domanda → ricerca → contesto → modello → risposta
Si può avere un buon modello e un cattivo sistema AI
È un’altra cosa che si dimentica facilmente.
Un’azienda può scegliere un ottimo modello linguistico e, nonostante questo, creare un prodotto AI debole.
Perché? Perché la qualità del sistema finale non dipende solo dal modello.
Contano anche:
- la qualità dei dati,
- il modo in cui viene preparato il contesto,
- il prompt,
- il modo di cercare le informazioni,
- i parametri del modello,
- gli strumenti messi a disposizione dell’AI,
- la logica dell’applicazione,
- la memoria,
- il modo di gestire gli errori,
- le protezioni,
- il modo di valutare le risposte.
Questo significa che la domanda: “Qual è il modello migliore?”
spesso è meno utile di: “Quale modello funziona meglio nel nostro specifico caso d’uso?”
Un modello eccellente nella generazione di contenuti di marketing non deve per forza essere la soluzione migliore per la classificazione dei documenti, l’analisi dei dati o la gestione dei processi aziendali.
Perciò il confronto tra modelli dovrebbe avvenire su compiti reali che il sistema deve svolgere.
Prima bisogna creare il proprio set di test
Non si può valutare in modo sensato un sistema AI se non sappiamo cosa ci aspettiamo da esso.
Per questo uno degli elementi più importanti della valutazione è la preparazione di un dataset di test, cioè un insieme di casi reali o rappresentativi.
Per esempio, un’azienda costruisce un’AI per il servizio clienti.
Invece di controllare manualmente una risposta dopo ogni modifica del prompt, si possono preparare qualche centinaio di casi:
- domande semplici,
- domande ambigue,
- domande con presupposti errati,
- domande che richiedono la ricerca di un documento,
- domande relative a eccezioni,
- domande relative ai reclami,
- domande che richiedono un rifiuto,
- domande contenenti dati che l’AI non dovrebbe rivelare.
Ogni modifica del sistema può quindi essere eseguita sullo stesso set.
Ed è proprio qui che l’AI inizia a somigliare al software classico.
Non testiamo più una singola risposta. Testiamo il comportamento del sistema sull’intero insieme di casi.
Anche il prompt si può testare
Il prompt è spesso trattato come un testo che qualcuno ha scritto una volta e lasciato in produzione.
In realtà può essere un elemento della logica applicativa.
La modifica di una sola frase può causare:
- un miglioramento delle risposte in uno scenario,
- un peggioramento delle risposte in un altro,
- una maggiore tendenza a rifiutare,
- un maggior numero di allucinazioni,
- risposte più lunghe,
- costi più alti,
- un maggiore consumo di token.
Per questo il prompt dovrebbe essere trattato in modo simile al codice.
Se modifichiamo il prompt, vale la pena sapere:
- che cosa è migliorato?
- che cosa è peggiorato?
- è comparsa una regressione?
Proprio per questo la valutazione automatica sta assumendo un’importanza sempre maggiore, e non la valutazione manuale di poche risposte di esempio.
L’AI può superare il test e restare comunque un cattivo prodotto
Supponiamo di aver preparato 100 casi di test.
Il sistema ha risposto correttamente a 95. Il risultato sembra ottimo. Ma cosa succede se le cinque risposte errate riguardano situazioni critiche?
Se il chatbot risponde a domande sugli orari di apertura, cinque errori possono essere un problema.
Se l’AI aiuta un dipendente ad analizzare documenti finanziari, medici o legali, il significato di quegli errori può essere del tutto diverso.
Perciò la sola media non basta.
Abbiamo bisogno anche di pesare i casi.
Possiamo considerare che:
- una domanda ordinaria ha peso 1,
- un errore grave ha peso 5
- un errore di sicurezza pesa 10,
- la divulgazione di un’informazione riservata pesa 100.
Allora il sistema non ottiene il “95 percento”. Otteniamo un quadro del rischio molto più utile.
Non tutto si può misurare con un solo numero
Questo è uno dei problemi più importanti della valutazione dell’IA.
Possiamo avere diverse metriche:
- Accuracy - la risposta è corretta?
- Relevance - risponde alla domanda?
- Faithfulness / groundedness - si basa sulle fonti fornite?
- Context precision - i frammenti recuperati sono pertinenti?
- Context recall - il sistema ha trovato le informazioni necessarie?
- Safety - non esegue azioni indesiderate?
- Latency - quanto deve aspettare l’utente?
- Cost - quanto costa eseguire il compito?
RAG può quindi avere una qualità di risposta molto buona, ma allo stesso tempo richiedere una quantità enorme di contesto e generare un costo inaccettabile.
Un altro sistema può essere molto economico e veloce, ma commettere troppi errori.
Non esiste quindi un unico numero universale che definisca se l’IA è “buona”. La qualità va definita nel contesto di un caso d’uso specifico.
E che dire della valutazione dell’IA da parte di un’altra IA?
Qui entra in gioco un altro meccanismo interessante.
Uno dei modi per automatizzare la valutazione è usare il modello come giudice, cioè LLM-as-a-judge.
Ad esempio:
Il modello A genera una risposta.
Il modello B riceve la domanda, la risposta e criteri specifici.
Poi valuta:
- correttezza,
- aderenza alle istruzioni,
- completezza,
- stile,
- sicurezza.
Gli strumenti di valutazione moderni permettono inoltre di combinare questo tipo di giudizio con confronti testuali classici, script personalizzati o grader basati su regole specifiche.
Questo aumenta enormemente la scala dei test. Ma non significa che l’essere umano non serva più. Anche il modello che valuta può sbagliare. Per questo, nei sistemi con maggiore importanza per il business, vale la pena combinare le valutazioni automatiche con una valutazione esperta periodica.
Il problema più grande: la regressione
Immaginiamo un sistema che funziona molto bene. Il team cambia il modello con uno più recente. La nuova versione è più veloce ed economica. Sembra quindi che tutto stia andando nella giusta direzione.
Dopo il rilascio si scopre però che:
- le risposte sono meno precise,
- il modello rifiuta più spesso di rispondere,
- usa peggio la documentazione,
- interpreta le istruzioni in modo diverso,
- in alcuni scenari inizia a fornire informazioni errate.
Questa è proprio AI regression.
Nel software classico conosciamo la regressione da anni. Anche nell’IA dobbiamo rilevarla, ma il problema è più difficile, perché il comportamento del sistema può cambiare senza un classico “bug”. Per questo ogni cambiamento importante dovrebbe essere confrontato con la versione precedente.
Modello.
Prompt.
Embedding.
Retriever.
Documentazione.
Logica dell’agente.
Parametri.
Ognuno di questi elementi può influire sul risultato.
Non basta valutare un agente solo dalla sua risposta finale
La situazione diventa ancora più difficile nel caso degli agenti IA.
Un chatbot classico può eseguire un solo compito: domanda → risposta.
Un agente può funzionare in modo completamente diverso: obiettivo → piano → strumento → risultato → passo successivo → decisione → azione → risposta.
Se l’agente non ha raggiunto l’obiettivo, vogliamo sapere non solo che ha perso.
Vogliamo sapere: dove ha commesso l’errore?
- Ha capito male il compito?
- Ha scelto lo strumento sbagliato?
- Ha passato un parametro errato?
- Ha recuperato dati sbagliati?
- Ha preso una decisione sbagliata dopo aver ottenuto il risultato?
- Ha eseguito troppi passaggi?
- Si è fermato troppo presto?
Nella ricerca sulla valutazione degli agenti si analizza sempre più spesso non solo il risultato finale, ma anche il flusso di esecuzione, l’uso degli strumenti, la pianificazione, la memoria, l’affidabilità e la sicurezza.
Questo significa che il futuro dei test dell’IA sarà in larga misura legato all’analisi dei trace, cioè dell’intero flusso di esecuzione del sistema.
L’IA ha bisogno di qualcosa di simile a CI/CD
Se l’IA fa parte di un prodotto, non si può testarla solo prima del primo rilascio.
Il sistema cambierà.
Cambierà il modello.
Cambierà il prompt.
Cambierà la base di conoscenza.
Cambierà il modo di cercare.
Cambierà la configurazione.
Per questo la valutazione dovrebbe entrare nel processo di sviluppo.
Lo schema può apparire così: cambiamento → test → valutazione → confronto con la versione precedente → decisione di rilascio
Se la nuova versione migliora la qualità in un ambito, ma supera la soglia di errore stabilita in un altro, il deployment può essere bloccato.
È una filosofia molto simile a quella del CI/CD classico, ma i criteri sono diversi.
Nel caso delle applicazioni IA possiamo verificare contemporaneamente la qualità della risposta, la correttezza, la sicurezza, il costo e la latenza. Esistono già soluzioni di ricerca che combinano la valutazione con l’observability e con gate di qualità nel processo di rilascio dei sistemi LLM/RAG.
Quindi si può testare l’IA allo stesso modo del software classico?
Sì, ma solo in parte.
L’approccio classico resta comunque necessario.
Testiamo:
- API,
- integrazioni,
- autorizzazioni,
- validazione dei dati,
- errori,
- timeout,
- sicurezza,
- prestazioni,
- logica dell’applicazione.
Ma non possiamo fermarci qui.
Si aggiunge un secondo livello: valutazione del comportamento dell’IA.
- La risposta è corretta?
- È coerente con le fonti?
- Il modello segue le istruzioni?
- Il sistema si comporta correttamente in situazioni impreviste?
- L’agente sceglie gli strumenti giusti?
- La nuova versione non ha peggiorato la qualità?
- Il costo di funzionamento rimane accettabile?
- L’utente riceve davvero valore?
Questo non è più un classico unit test.
Il miglior test dell’IA non è sempre un test di laboratorio
C’è ancora un altro elemento molto importante.
Il sistema può comportarsi benissimo su un set di test preparato, eppure avere problemi nel mondo reale. Per questo vale la pena osservare anche le interazioni reali. Non per fare di ogni utente un tester. Si tratta di poter migliorare continuamente il sistema sulla base di casi reali:
- dove gli utenti correggono l’IA,
- dove chiedono di ripetere la risposta,
- dove interrompono la conversazione,
- dove escalano il caso a un umano,
- dove l’agente non raggiunge l’obiettivo,
- dove compaiono domande insolite.
In questo modo nasce un ciclo continuo di valutazione: utente → azione dell’AI → risultato → analisi → nuovo caso di test → nuova versione del sistema
È un modello di sviluppo completamente diverso da un semplice “abbiamo implementato l’AI e funziona”.
L’AI non dovrebbe essere valutata con la domanda “funziona?”
È troppo poco.
Le domande migliori sono:
- Quanto spesso funziona correttamente?
- In quali სიტუazioni sbaglia?
- Quanto sono gravi questi errori?
- La nuova versione è migliore della precedente?
- Il sistema è sufficientemente sicuro?
- Le risposte si basano sui dati corretti?
- Quanto costa ottenere un risultato specifico?
Solo un insieme di domande del genere permette di parlare di un sistema AI maturo.
Il cambiamento più importante nel modo di pensare
Per anni nello sviluppo software ha vigito una regola semplice: il codice deve funzionare.
Nei sistemi AI bisogna ampliarla: il sistema deve funzionare bene, in modo prevedibile e misurabile.
È una differenza enorme. Perché l’AI non è una funzione che restituisce sempre lo stesso risultato. È un sistema probabilistico, il cui comportamento dipende dal modello, dai dati, dal contesto, dalle istruzioni e dall’intera architettura che lo circonda.
Per questo un’implementazione professionale dell’AI non termina nel momento in cui il modello inizia a rispondere.
Solo allora inizia la domanda: come facciamo a sapere di potergli fidare?
Ed è proprio a questa domanda che dovrebbe rispondere una valutazione ben progettata.
In futuro il testing dei sistemi AI probabilmente diventerà una parte altrettanto naturale del processo di sviluppo quanto i test unitari, integrativi o il monitoraggio. Non perché l’AI sia “pericolosa per definizione”. Semplicemente perché un sistema il cui risultato non è sempre deterministico richiede un modo diverso di misurare la qualità.
E quanto più l’AI passa dalla generazione di testo alla gestione di processi reali, all’uso dei dati, al RAG e all’esecuzione di azioni tramite agenti, tanto più importante diventa non solo la domanda “l’AI sa farlo?”, ma anche: “sappiamo dimostrare che lo fa abbastanza bene?”
