La valutazione trasforma un benchmark da “occhiata al JSON” a un numero oggettivo. Il risultato di ogni modello viene valutato rispetto a un riferimento gold — l'output atteso — producendo completezza, correttezza e un punteggio di qualità complessivo su cui ordinare.
La valutazione ha bisogno di qualcosa con cui confrontarsi. Ogni scenario porta con sé un output di riferimento: la risposta corretta per la sua unica entità fissa. Costruiscilo generandolo con modelli potenti (ricerca web + un documento di fonte attendibile), incollando un risultato noto come valido e modificandolo poi a mano — e contrassegnalo come verificato quando ti fidi. Un riferimento verificato è necessario per eseguire il benchmark dello scenario, così c'è sempre qualcosa con cui confrontare. Se in seguito modifichi il riferimento — o cambi la configurazione di valutazione dello scenario — i punteggi esistenti vengono contrassegnati come obsoleti finché non rivaluti.
Il riferimento inoltre si aggiorna da solo. Un riferimento verificato resta una bozza corretta a mano e i modelli sottoposti a benchmark ne sono i revisori: ogni volta che il giudice ritiene la risposta di un candidato migliore di quella del riferimento (o considera errata quella del riferimento), ogni volta che i campioni dello scenario dimostrano che il riferimento è errato e ogni volta che un modello compila un valore lasciato vuoto dal riferimento e il giudice lo conferma, il risultato registra un rilievo. Al termine di ogni passata di valutazione i rilievi di tutti i modelli valutati vengono consolidati — prima ciò che dimostrano i campioni, poi la risposta data dalla maggior parte dei modelli — e scritti nel riferimento. Una modifica già apportata da una passata viene sostituita solo da prove più forti (i campioni, un verdetto che dichiara errato il valore o un maggior numero di modelli concordi, conteggiati su tutte le passate), mai dall’opinione di un modello in più: valutare i modelli uno alla volta non può quindi far derivare il riferimento verso l’ultimo valutato. Queste modifiche automatiche non rendono mai obsoleti i punteggi (lo fanno solo i suoi salvataggi) e ognuna di esse viene registrata insieme al valore che ha sostituito e ai modelli che l’hanno proposta.
Le esamini come revisioni: la vista Riferimento dello scenario, accanto ai suoi risultati, mostra il riferimento stesso con ogni modifica automatica evidenziata nel punto in cui si trova: il valore precedente barrato, quello nuovo, quanti modelli lo sostengono e perché. Tutto è accettato finché non lo si rifiuta; un rifiuto ripristina il valore precedente ed esclude quel percorso dalle passate future. Filtri per attributo o per prove (le modifiche basate su un solo modello sono quelle da controllare), selezioni quanto è mostrato e rifiuti in blocco.
Il problema di fondo: due risposte corrette possono essere scritte in modo diverso. Un modello che indica un attore come “R. Downey Jr.” invece di “Robert Downey Jr.” non sbaglia. Per questo ogni campo viene confrontato con una scala a livelli — prima i metodi più economici e certi, con escalation solo quando necessario:
I valori identici corrispondono. Lo stesso vale per i valori che differiscono solo per maiuscole/minuscole, spazi circostanti o precisione numerica ("Acme" = "ACME", 4.0 = 4). Gratuito e completamente deterministico.
Per il testo, il candidato e il riferimento vengono incorporati e confrontati tramite similarità del coseno. Al di sopra della soglia contano come identici — così una variante ortografica valida come «R. Downey Jr.» rispetto a «Robert Downey Jr.» è una corrispondenza, non un errore. Le date fanno eccezione: vengono confrontate come valori di calendario, mai per similarità, cosicché una data vicina ma errata («1972-03-14» rispetto a «1972-03-24») costituisce una discordanza netta anziché un coseno ingannevolmente alto. Anche i valori booleani sono di tipo esatto o niente.
I valori non decidibili in base alla similarità — tutti i campi di testo libero come sintesi e descrizioni, ogni numero non identico e un valore chiaramente diverso supportato dai suoi documenti o dalla maggior parte degli altri modelli — vengono inviati a un modello giudice. Il giudice opera alla cieca: vede i due valori come A e B, insieme alla posizione del campo nello schema (i suoi elementi padre e le relative descrizioni, il tipo, l'elemento di lista a cui appartiene) e ai suoi documenti di origine, se lo scenario ne prevede, e indica quale dei due serve meglio il campo, se entrambi sono corretti oppure se uno è errato. Un candidato giudicato equivalente o migliore del riferimento — o un riferimento giudicato errato — ottiene il punteggio pieno; una risposta più debole ottiene un punteggio parziale, una errata poco o nulla. Un numero ottiene un punteggio parziale quando il campo lo tollera (un peso molecolare di 273,37 contro 273,35, un'emivita di 12 contro 15) e viene respinto dove conta l'esattezza (un anno di uscita 2020 contro 2023). Un valore lasciato vuoto dal riferimento viene valutato singolarmente: se confermato corretto, conta come un valore che il riferimento avrebbe dovuto contenere e che il modello ha trovato — il punteggio aumenta, non si limita a non essere penalizzato — e il riferimento lo adotta.
Un'impostazione di rigore controlla la soglia di embedding: un valore più alto significa che due valori scritti in modo diverso devono essere più simili per essere considerati uguali. Il rigore, il modello giudice opzionale e il modello di embedding sono tutti definiti sullo scenario — non scelti ogni volta che si valuta — così ogni modello viene valutato in modo identico e i punteggi restano comparabili.
Gli elenchi — il cast di un film, gli effetti collaterali di un farmaco — sono l'ambito in cui i modelli differiscono di più: un modello piccolo potrebbe trovare 4 attori laddove uno potente ne trova 15. L'ordine non conta e trovare più elementi corretti dovrebbe prevalere. Per questo gli array vengono valutati come un insieme, non posizione per posizione:
Espandi una riga dei risultati per vedere esattamente quali elementi sono stati abbinati, mancati o allucinati.
Un singolo numero nasconde troppo, quindi ogni risultato include dei sotto-punteggi:
La riga espandibile mostra il dettaglio campo per campo: candidato rispetto al riferimento, quale livello della scala ha deciso e la similarità dove pertinente.
La qualità è solo un terzo della storia. Quando un benchmark alimenta la selezione dei modelli — come fonte di punteggio — la posizione del modello deriva dalla combinazione di qualità, velocità e costo, e quel rapporto è nelle Sue mani: lo imposti per tipo di scenario in Impostazioni → Organizzazione → Valori predefiniti, con somma pari a 100 per ciascuno e ripartizione uniforme per impostazione predefinita. Assegni molto peso al costo e un modello economico ma discreto supererà uno eccellente e costoso: è la risposta giusta per alcuni carichi di lavoro e quella sbagliata per altri, motivo per cui la piattaforma non decide al Suo posto. Velocità e costo sono letti rispetto agli altri risultati dello scenario su scala logaritmica: il modello più veloce o più economico ottiene 100 e uno dieci volte più lento o più costoso ottiene 0, ma un insieme compatto non viene mai dilatato per riempire l’intervallo — due modelli a 10 $ e 12 $ si collocano a 100 e 92, non a 100 e 0.
Quando uno scenario esegue un modello più di una volta (ripetizioni), ogni esecuzione viene valutata singolarmente e la riga mostra la qualità media più uno scarto di coerenza (dal valore minimo al massimo delle esecuzioni), così è facile individuare un modello corretto in media ma incostante. L'output visibile è l'esecuzione mediana per qualità.
I benchmark non si limitano all’arricchimento: uno scenario può testare anche la generazione di campioni (ogni modello inventa un JSON di esempio per la stessa richiesta in testo libero) o la generazione di schemi (ogni modello converte un campione fisso in uno schema). Ciascuna modalità ha le proprie regole di valutazione:
In entrambi i casi le colonne consuete mantengono il loro significato — passi il mouse sull'intestazione di una colonna per la definizione specifica del tipo ed espanda una riga per il dettaglio completo.
La valutazione è un passaggio separato sui risultati già salvati: non esegue mai un nuovo arricchimento, quindi non comporta mai una nuova spesa per i modelli sotto test. Genera però gli embedding del testo per confrontare i valori (ed esegue il giudice, se lo scenario ne prevede uno), operazione che scala i crediti in base all'utilizzo. Questo avviene automaticamente durante ogni esecuzione — ogni modello viene valutato appena le sue esecuzioni terminano — e di nuovo a ogni rivalutazione. Se la vostra organizzazione non ha un modello di embedding configurato (e lo scenario non ne imposta uno alternativo), la valutazione viene comunque eseguita ma ricorre al solo confronto esatto (le varianti di scrittura contano quindi come discordanze) e lo segnala. Un giudice non funzionante è diverso: se una chiamata al giudice non riesce, la valutazione si interrompe con un errore esplicito e il modello interessato non conserva punteggi parziali — un risultato è valutato del tutto o non valutato affatto, e resta rivalutabile in seguito. Le risposte del giudice vengono memorizzate nella cache per scenario in base al loro contenuto: la stessa domanda posta da un altro modello, da una ripetizione o da un altro passaggio non viene mai pagata due volte, e una rivalutazione successiva all'aggiornamento automatico del riferimento ripropone solo le domande relative ai campi modificati. Nulla di ciò che fa il giudice resta nascosto: ogni ciclo di valutazione su un modello lascia un record di valutazione nella Cronologia — una riga per ogni chiamata al giudice con prompt, risposta, token e costo, incluse le chiamate fallite, oltre al numero di domande risolte gratuitamente dalla cache — e la tabella dei risultati mostra per ciascun modello il costo del giudice, il numero di chiamate e il tempo di valutazione, accanto a un link al record. Nella scelta del giudice, tenete presente che i giudici LLM possono favorire la propria famiglia di modelli — preferite un giudice di un provider che non state sottoponendo a benchmark.
In Gestione modelli → Benchmark, impostare e verificare un riferimento nell'editor dello scenario (scegliendo lì anche il modello giudice, il modello di embedding e il livello di severità). Da quel momento, ogni esecuzione valuta automaticamente i risultati riusciti — una colonna Qualità ordinabile si popola senza ulteriori passaggi. Usare Rivaluta i risultati (il pulsante nell'intestazione o il menu ···) per rivalutare dopo aver modificato il riferimento o la configurazione della valutazione. Il badge aggiornamenti del riferimento accanto allo stato del riferimento apre il log delle modifiche apportate dai passaggi di valutazione, con un'opzione di annullamento per ogni voce.