Nello sviluppo di strumenti aziendali basati su modelli linguistici complessi, la revisione qualitativa degli output permette di individuare risposte palesemente errate, poco pertinenti o formulate male, ma non è sufficiente per stabilire se il modello stia effettivamente identificando la risposta corretta al problema per cui è stato progettato. Un output può essere fluido, coerente e plausibile, superare una revisione interna e risultare comunque sbagliato quando viene confrontato con ciò che è realmente accaduto. Questa differenza diventa particolarmente rilevante quando l’LLM non svolge soltanto una funzione di assistenza alla produttività, ma contribuisce ad analisi di qualità dei dati, controlli di conformità, gestione di record segnalati o diagnosi di errori operativi.
La valutazione qualitativa normalmente utilizzata in questi progetti consiste nel sottoporre un campione di risposte a una persona esperta del dominio, che le confronta con la propria aspettativa di una buona risposta e interviene sul prompt quando gli output appaiono insoddisfacenti. Questo metodo è efficace nell’intercettare problemi evidenti, come risposte fuori tema, errori macroscopici o formattazione inadeguata, ma tende a fallire proprio sugli errori più pericolosi: spiegazioni tecnicamente credibili che identificano con sicurezza una causa sbagliata. In assenza di una verità esterna con cui confrontare la risposta, un ragionamento autorevole e ben costruito può essere facilmente scambiato per una diagnosi corretta.
Un’alternativa consiste nel costruire un eval harness, cioè un’infrastruttura di valutazione sistematica che confronti gli output del modello con una ground truth nota. Il metodo è stato applicato allo sviluppo di un sistema destinato all’analisi delle cause principali dei problemi emersi durante migrazioni di dati. Il sistema riceveva un evento di data drift e produceva un elenco ordinato delle cause considerate più probabili. Il primo prototipo generava spiegazioni apparentemente precise e convincenti e superava le revisioni qualitative, ma quando veniva testato su casi nei quali la causa reale era già conosciuta mostrava un tasso di errore sufficientemente elevato da rendere necessaria una metodologia di valutazione diversa.
La prima componente dell’eval harness è stata quindi la costruzione di un dataset sintetico nel quale la risposta corretta fosse nota per definizione. Sono state introdotte intenzionalmente anomalie controllate all’interno di una pipeline di test, tra cui modifiche dello schema, errori nella logica di trasformazione e cambiamenti nel comportamento del sistema sorgente. Per ogni esperimento veniva registrata esattamente la causa introdotta e il modello veniva successivamente eseguito sull’evento di drift generato. In questo modo la risposta corretta non doveva essere dedotta a posteriori: coincideva con la modifica deliberatamente inserita nel sistema.
La costruzione di scenari sintetici utili ha richiesto però di evitare casi eccessivamente semplici. Le prime versioni del dataset producevano segnali troppo puliti e facilmente interpretabili rispetto a quelli osservabili in produzione. Per rendere la valutazione più rappresentativa sono stati aggiunti rumore, segnali sovrapposti e situazioni nelle quali più spiegazioni plausibili erano presenti contemporaneamente. Questa complessità ha trasformato il dataset sintetico da semplice raccolta di test controllati a strumento più efficace per prevedere il comportamento del modello nelle condizioni operative reali.
La seconda componente è stata una funzione di scoring adatta a un sistema che non produce una singola risposta, ma una classifica di cause probabili. Una valutazione binaria corretto-sbagliato non sarebbe stata sufficiente, perché individuare la causa reale come terza possibilità non equivale a collocarla al primo posto. Il punteggio è stato quindi costruito su due dimensioni distinte. La prima, Presence, misura se la causa corretta compare almeno tra le risposte generate. La seconda, Rank, valuta la posizione assegnata alla causa corretta rispetto alle alternative errate. Le due misure vengono combinate in un punteggio ponderato che premia sia la capacità del modello di individuare la risposta giusta sia quella di attribuirle una priorità adeguata.
La terza componente consiste nell’eseguire sistematicamente il modello sull’intero dataset invece di affidarsi a controlli manuali su un numero limitato di esempi. Una valutazione completa permette di identificare pattern che difficilmente emergerebbero attraverso verifiche a campione, come categorie di problemi gestite con elevata affidabilità, tipologie di errore sistematicamente confuse dal modello e combinazioni di segnali associate a risposte sbagliate ma formulate con particolare sicurezza.
I risultati hanno mostrato differenze marcate tra le diverse categorie di anomalia. Gli scenari relativi alle modifiche dello schema sono risultati quelli meglio gestiti: quando l’evidenza era sufficientemente distintiva, il modello riusciva generalmente a individuare in modo affidabile un cambiamento avvenuto a monte della pipeline. I bug nella logica di trasformazione hanno invece prodotto prestazioni inferiori. In questi casi il modello tendeva spesso a riconoscere correttamente la categoria generale dell’errore, ma attribuiva la deriva alla modifica specifica sbagliata, soprattutto quando più cambiamenti erano stati introdotti in rapida successione.
Le situazioni più problematiche sono risultate quelle caratterizzate da segnali sovrapposti. Quando due cause differenti si verificavano a breve distanza temporale, aumentava sensibilmente la frequenza delle spiegazioni errate accompagnate da un elevato livello di sicurezza. Proprio questo comportamento ha evidenziato uno dei limiti più importanti della valutazione qualitativa: la confidenza espressa dal modello non risultava correlata in modo affidabile alla correttezza della diagnosi. Nei casi peggiori, il sistema tendeva anzi a produrre alcune delle risposte più sicure proprio quando stava commettendo gli errori più significativi.
Questa osservazione modifica anche il modo in cui deve essere interpretato un eventuale confidence score prodotto dall’LLM. Una stima di sicurezza non può essere utilizzata automaticamente come indicatore dell’accuratezza senza essere prima calibrata rispetto a un insieme di casi con risposta nota. Se il modello mostra elevata confidenza anche nelle categorie in cui sbaglia più frequentemente, una soglia basata esclusivamente sulla sicurezza dichiarata rischia di automatizzare proprio le decisioni meno affidabili.
Per gli strumenti aziendali che influenzano analisi, gestione degli alert o decisioni operative, diventa quindi necessario distinguere esplicitamente tra valutazione della qualità percepita e valutazione dell’accuratezza. Verificare che una risposta sembri ragionevole misura proprietà come fluidità, chiarezza e coerenza, ma non dimostra che la conclusione sia corretta. La verifica effettiva richiede casi nei quali la risposta giusta sia conosciuta indipendentemente dal modello e metriche capaci di confrontare sistematicamente l’output con quella ground truth.
La parte più impegnativa di questo processo è proprio la costruzione del dataset di riferimento, perché obbliga a definire con precisione cosa significhi essere corretti nello specifico caso d’uso. Una volta stabilita questa definizione, la funzione di scoring e l’infrastruttura necessaria per automatizzare le valutazioni risultano relativamente semplici. Senza una ground truth ben definita, invece, anche un sistema di evaluation sofisticato rischia di misurare caratteristiche secondarie dell’output senza verificare la proprietà che dovrebbe realmente garantire: la capacità del modello di fornire la risposta corretta.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)