Come progettare una valutazione IA proprietaria: dal caso d’uso a una soglia di rilascio verificabile

I benchmark pubblici sono un segnale iniziale, non una decisione di rilascio

Una tabella di benchmark risponde, nel migliore dei casi, a una domanda circoscritta: come si è comportato un modello secondo un protocollo specifico, con un insieme di attività, una versione e regole di punteggio determinate. Non risponde da sola se un assistente sarà utile, sicuro, sufficientemente rapido o sostenibile nei costi all’interno di un processo reale. La differenza è rilevante perché un prodotto non è formato soltanto da un modello. Include istruzioni, strumenti, recupero di documenti, formati di output, controlli di accesso, interfaccia, persone supervisore e procedure di eccezione.

I benchmark possono aiutare a ridurre il numero di candidati e a formulare ipotesi. Per esempio, un test pubblico orientato alla programmazione può essere pertinente quando il lavoro assomiglia alla risoluzione di incidenti software; un test di terminale può offrire indicazioni quando l’agente deve operare in terminali e ambienti reali; e un altro incentrato sulle interfacce può essere più vicino al caso quando l’attività richiede l’uso di interfacce grafiche. Tuttavia, la somiglianza apparente non elimina la necessità di testare il proprio flusso, con i vincoli e i dati che il sistema incontrerà realmente.

La letteratura pratica sui benchmark dei modelli segnala limiti quali contaminazione dei dati, differenze di configurazione e risultati che non catturano latenza né integrazione degli strumenti. Questi limiti non invalidano i test pubblici: delimitano il tipo di inferenza che consentono. L’analisi consigliabile consiste nell’usare i loro risultati come contesto esterno e nel riservare la decisione di prodotto a una valutazione locale, ripetibile e documentata.

Per esplorare questa differenza, nel cluster editoriale è opportuno includere la risorsa «Cosa possono apportare —e cosa no— i benchmark pubblici». Questa guida deve inoltre essere collegata dalla pagina matrice di apprendimento, nel blocco «Guide per implementare e verificare», e ricevere un link dalla scoperta tramite il modulo «Prima di scegliere un modello: valutalo con il tuo caso d’uso». La pubblicazione deve essere condizionata all’implementazione o alla pianificazione di tali destinazioni e della relativa navigazione nello stesso cluster.

Tradurre il problema in un’ipotesi valutabile

Il punto di partenza non dovrebbe essere «quale modello ottiene più punti», bensì una descrizione verificabile dell’attività. Identifica chi usa il sistema, quale input fornisce, quale risultato gli serve, quali azioni successive dipendono da quel risultato e cosa accade quando il sistema fallisce. Una classificazione errata di una richiesta commerciale può richiedere correzione; una risposta che attribuisce falsamente un’affermazione a un documento interno può indurre una decisione errata; un’azione esterna non autorizzata può avere conseguenze più gravi. La metrica e la soglia devono riflettere tale differenza.

Un’ipotesi utile ha forma condizionale: per un segmento definito di utenti e attività, il sistema produce un risultato che soddisfa criteri espliciti con un livello di qualità, tempo e costo compatibile con il processo, senza superare un budget di errori. Questa formulazione obbliga a decidere che cosa significhi «soddisfa». In un’estrazione strutturata può significare campi validi e corretti. In un riepilogo può richiedere copertura dei punti rilevanti, assenza di invenzioni e attribuzione alle fonti disponibili. In un agente può significare completare un’attività senza violare autorizzazioni né richiedere più intervento umano del previsto.

Microsoft descrive, per la prioritizzazione dei casi d’uso, un quadro che combina fattibilità aziendale, esperienza e convenienza, e fattibilità tecnologica. È un quadro di prioritizzazione, non un test della qualità di un modello; è comunque utile per evitare un’omissione frequente: valutare la capacità tecnica senza verificare che il caso disponga di processo, responsabile, dati, esperienza utente e beneficio operativo plausibili.

Delimitare e versionare l’intero sistema

La riproducibilità richiede di dichiarare ciò che è stato confrontato. Registra il fornitore e la versione o l’identificatore del modello, quando disponibili, la data di esecuzione, i parametri di generazione, il modello di istruzioni, il messaggio di sistema, gli strumenti disponibili, le loro versioni, lo schema di output, l’indice di recupero, la versione dei documenti e le regole di autorizzazione. Aggiungi la logica di ritentativo, validazione, fallback ed escalation umana. Se questa configurazione non può essere ricostruita, una differenza di risultato fra due esecuzioni sarà difficile da interpretare.

Non tutti i componenti cambiano con la stessa frequenza. Un fornitore può aggiornare un servizio, i documenti interni possono cambiare ogni giorno e un team può modificare un’istruzione per risolvere un errore. Il registro non impedisce tali cambiamenti, ma permette di sapere cosa è cambiato prima di attribuire un miglioramento o una regressione al modello. È particolarmente importante non confrontare un’alternativa con recupero aggiornato con un’altra basata su un indice precedente, né attribuire a una variante di modello un risultato prodotto da un prompt differente.

Congelare non implica immobilizzare il prodotto. Durante un ciclo di valutazione, significa fissare una configurazione candidata e un insieme di test prima di osservare i risultati. Al termine si può proporre una nuova versione, ma questa deve essere rivalutata rispetto allo stesso riferimento o a un riferimento esplicitamente aggiornato. Questa disciplina riduce il rischio di scegliere retrospettivamente il prompt che ha avuto fortuna nel test.

Costruire un insieme di valutazione rappresentativo e separato

Un insieme di valutazione deve rappresentare decisioni e condizioni operative, non soltanto esempi facili o memorabili. Inizia campionando attività storiche e osservando i segmenti rilevanti: lingua, lunghezza, tipo di documento, canale di input, livello di ambiguità, casi frequenti e casi ad alto impatto. Aggiungi poi casi difficili intenzionali: istruzioni contraddittorie, informazioni incomplete, documenti obsoleti, input malformati, richieste fuori ambito e situazioni nelle quali il risultato corretto è astenersi o chiedere chiarimenti.

Separa almeno due partizioni: sviluppo e test. Quella di sviluppo serve a progettare prompt, regole, strumenti e rubriche. Quella di test viene riservata a un confronto finale o a traguardi definiti. La ragione metodologica è semplice: se il sistema viene adattato ripetutamente dopo aver visto i risultati sugli stessi casi, tali osservazioni smettono di misurare la generalizzazione e diventano parte dello sviluppo. Una terza partizione di validazione può essere utile in progetti con dati sufficienti, ma non è un requisito universale; ciò che conta è documentare l’uso di ogni caso.

I dati privati comportano ulteriori obblighi pratici. Riduci al minimo i dati personali e i segreti inclusi nella valutazione, applica controlli di accesso ed evita di trasferire contenuti sensibili in ambienti non autorizzati. Questa guida non determina da sola la liceità di un trattamento né i requisiti contrattuali dei fornitori. Prima di incorporare documenti privati, è opportuno usare la risorsa prevista «Esempio di matrice di valutazione per documenti sensibili» e convalidare le condizioni applicabili con le funzioni legale, sicurezza e protezione dei dati.

I casi sintetici possono ampliare la copertura quando mancano esempi, ma non sostituiscono automaticamente la realtà operativa. Devono essere etichettati come sintetici, revisionati e mantenuti separati nei report. Se funzionano soltanto i casi creati per la dimostrazione, la valutazione non fornisce evidenza sufficiente sul comportamento in produzione.

Scegliere metriche corrispondenti all’attività e al rischio

Non esiste una metrica unica per i sistemi generativi. La corrispondenza letterale può essere ragionevole se l’output è un’etichetta chiusa o un valore esatto, ma spesso è insufficiente per riepiloghi, risposte aperte o piani d’azione. In questi casi, una rubrica umana può valutare aspetti separati: correttezza fattuale, copertura, chiarezza, rispetto delle istruzioni, uso appropriato delle fonti e riconoscimento dell’incertezza. La valutazione automatizzata può integrare questo lavoro mediante validatori di schema, regole aziendali, controllo dei campi obbligatori e test di sicurezza; non dovrebbe nascondere quali proprietà non è in grado di verificare.

Per il recupero aumentato con fonti, misura separatamente recupero e generazione. Fra gli altri segnali, puoi verificare se è stata recuperata evidenza pertinente, se le affermazioni importanti sono supportate dall’evidenza disponibile, se citazioni o riferimenti corrispondono al contenuto e se il sistema si astiene quando l’evidenza non è sufficiente. Una risposta fluida non dimostra fedeltà. La risorsa prevista «Come valutare fedeltà, copertura e citazioni nei sistemi RAG» può approfondire questi criteri.

Negli output strutturati, misura la validità dello schema, la presenza dei campi, l’accuratezza semantica di ciascun campo e il recupero dopo un errore. Un JSON formalmente valido può comunque classificare in modo errato; una classificazione corretta può risultare inutilizzabile se manca un campo richiesto. Per progettare questi test, è prevista la risorsa «Come misurare validità dello schema e recupero dagli errori».

Aggiungi metriche operative: latenza per percentile e segmento, costo per attività completata, frequenza dei ritentativi, tasso di fallback, intervento umano e successo end-to-end. Quando possibile, riporta distribuzioni oltre alle medie, perché una media può nascondere code di latenza o segmenti con risultati sistematicamente peggiori. Le soglie non derivano da una cifra universale: dipendono dal processo, dal volume, dal danno e dalla capacità di supervisione.

Progettare la rubrica e controllare il disaccordo umano

Una rubrica trasforma giudizi generali in decisioni osservabili. Invece di chiedere «la risposta è buona?», definisci dimensioni, scale ed esempi. Per l’assistente di feedback, una dimensione di fedeltà potrebbe distinguere fra: ogni affermazione rilevante supportata dal testo; piccole inferenze accettabili e segnalate; affermazioni non supportate; e attribuzioni chiaramente false. Un’altra dimensione può valutare se categoria e priorità rispettano le definizioni operative del team.

Alcuni controlli possono essere automatizzati in modo deterministico: parsing di uno schema, limiti di lunghezza, campi vietati, corrispondenza con un elenco di autorizzazioni o presenza di riferimenti richiesti. Altri richiedono interpretazione. Un valutatore basato su un altro modello può rendere più rapido lo screening, ma deve essere calibrato rispetto ad annotazioni umane su un campione rappresentativo e i suoi errori devono essere analizzati. Non è opportuno trattarlo come arbitro indipendente né usarlo per sostituire la revisione umana per conseguenze elevate.

Per misurare l’accordo, due valutatori possono essere confrontati tramite la percentuale di coincidenza su criteri semplici o tramite una misura di accordo che consideri la coincidenza attesa per caso, come kappa, purché scala e distribuzione lo consentano. Non esiste un livello universale di disaccordo che invalidi una valutazione. Come regola operativa, rivedi la rubrica se il disaccordo riguarda casi che determinerebbero il rilascio, se si concentra in una dimensione critica o se i valutatori interpretano il criterio in modo incompatibile. Documenta la revisione e, se le regole cambiano, rivaluta i casi interessati.

Confrontare in modo equo e decidere con soglie esplicite

Definisci le soglie prima di eseguire il confronto finale. Stabilisci blocchi assoluti, minimi per segmento e obiettivi operativi. Un blocco può essere un output che rivela informazioni non autorizzate, un’azione eseguita senza la conferma richiesta, una violazione di autorizzazione o un’affermazione critica senza supporto in un contesto nel quale il sistema è presentato come basato su fonti. Un minimo per segmento evita che un risultato aggregato accettabile nasconda un comportamento inaccettabile per una lingua, un tipo di documento o un gruppo di utenti.

Una decisione può avere tre esiti: rilasciare con controlli, iterare o scartare. Rilasciare con controlli è appropriato solo se i blocchi sono pari a zero nell’ambito della copertura valutata, vengono rispettati i minimi concordati ed esiste una supervisione compatibile con il rischio residuo. Iterare richiede di identificare cosa cambierà e come sarà nuovamente misurato. Scartare può essere la conclusione responsabile se non esiste una configurazione che raggiunga la soglia entro i limiti di costo, latenza o sicurezza.

Negli agenti che eseguono azioni esterne, la valutazione deve testare esplicitamente autorizzazioni, conferme, ambito e reversibilità. Non basta che l’attività termini con successo. La risorsa prevista «Test di autorizzazioni, conferme e reversibilità prima di dare azioni all’agente» deve coprire questo tipo di validazione. La guida non stabilisce requisiti normativi concreti dell’AI Act europeo: le fonti verificate fornite non sono testo normativo primario sufficiente per determinare articoli, date o obblighi applicabili. Tale revisione deve essere svolta con fonti giuridiche aggiornate e consulenza specializzata.

Monitorare dopo il rilascio e conservare il registro decisionale

Il rilascio non trasforma la valutazione in una formalità conclusa. Cambiano gli input degli utenti, i documenti recuperati, i modelli dei fornitori, gli strumenti e i modelli di abuso. Strumenta le tracce con un’appropriata minimizzazione dei dati per collegare un output alla sua configurazione, al recupero, agli strumenti, al tempo di risposta, al costo, alle validazioni, al fallback e all’intervento umano. La risorsa prevista «Come strumentare tracce, latenza e costo per attività» può servire da prosecuzione operativa.

Definisci segnali di allerta: aumento degli errori di schema, calo del successo per segmento, crescita di astensioni o ritentativi, ritardi nei percentili elevati, incremento del costo per attività, reclami sottoposti a revisione ed eventi relativi alle autorizzazioni. Campiona risultati di produzione per la valutazione umana, con procedure che rispettino i controlli applicabili ai dati. Pianifica rivalutazioni dopo cambiamenti rilevanti e anche periodicamente, persino se non viene dichiarato alcun cambiamento, poiché una dipendenza esterna può variare.

Il modello finale deve riunire una scheda di valutazione, la matrice dei risultati e un registro decisionale. La scheda include obiettivo, segmenti, rischi, configurazione versionata, provenienza dei dati e metriche. La matrice mostra risultati aggregati e per segmento, insieme ai casi critici. Il registro spiega quali evidenze sono state riesaminate, quali soglie sono state applicate, quali limiti rimangono, chi ha approvato la decisione e quando il test deve essere ripetuto. Come navigazione di chiusura, aggiungi «Passo successivo» verso un modello scaricabile o un articolo gemello sull’osservabilità. Questa chiusura non deve essere pubblicata come link attivo se la destinazione non esiste o non è pianificata nel cluster.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.