I benchmark per l'IA migliorano nel misurare l'incertezza, non solo le risposte
Il 5 ottobre GitHub ha pubblicato ReviewBench, un benchmark aperto per la revisione del codice costruito su un'analisi di 103.900.000 pull request e composto da 219 casi. A settembre, i ricercatori della UC Riverside hanno descritto un metodo per separare la sicurezza di un modello dalla sua correttezza.

Due lavori attaccano lo stesso problema da lati opposti. Non sono usciti lo stesso giorno. GitHub ha pubblicato ReviewBench, un benchmark aperto per la revisione del codice affidata all'IA, costruito da un'analisi di 103.900.000 pull request sulla sua piattaforma. A parte, gli informatici della UC Riverside hanno descritto un metodo per individuare le caratteristiche interne che fanno sembrare sicuro un modello linguistico mentre sbaglia.
Nessuno dei due è il lancio di un prodotto. Entrambi provano a rispondere a una domanda che acquirenti e utenti continuano a fare: quando un modello dice qualcosa, come si fa a sapere se fidarsi?
Cosa ha costruito GitHub
ReviewBench, annunciato sul blog di GitHub, contiene 219 pull request pubbliche provenienti da 187 repository open source in 19 linguaggi. GitHub sostiene che la combinazione di linguaggi e dimensioni dei repository corrisponda da vicino alle sue distribuzioni complessive. Ingegneri senior hanno etichettato a mano i veri positivi prima della pubblicazione. Il dataset è pubblico.
Il benchmark calcola quattro metriche e assegna a ogni rilievo una severità e una categoria. Permette ai team di filtrare i risultati in base al tipo di revisione che interessa. GitHub dice che questo aiuta a confrontare i revisori che segnalano molti problemi con quelli che restano silenziosi, e le buone capacità di intercettazione con i piccoli suggerimenti.
Il numero che conta è 103.900.000. Sono le pull request che GitHub ha analizzato per caratterizzare i carichi di lavoro reali della revisione, e i 219 casi seguono quella distribuzione. GitHub ha fatto una correzione deliberata. La dimensione delle pull request è ponderata verso la parte centrale e la coda revisionabile, riducendo la sovrarappresentazione delle modifiche molto grandi. L'azienda aggiunge che la sua valutazione offline della revisione del codice di Copilot ora anticipa con più affidabilità la direzione degli esperimenti in produzione.
Resta da sapere quanto ottiene chiunque altro. GitHub invita altri sistemi di revisione del codice a iscriversi e inviare i risultati. Il post non riporta una classifica né i numeri di un modello di riferimento.
Perché la sicurezza non è la correttezza
Lo studio della UC Riverside, guidato dallo studente di dottorato Het Patel, ha guardato dentro due modelli a pesi aperti: Llama-3.1-8B di Meta, con 8.000.000.000 di parametri, e Gemma-2-9B di Google, con 9.000.000.000 di parametri. Il team ha posto domande a risposta multipla e ha diviso le risposte in quattro gruppi, incrociando corretto o sbagliato con sicuro o incerto.
Con gli autoencoder sparsi, i ricercatori hanno trovato tre tipi di caratteristiche interne: alcune legate soprattutto all'incertezza, altre soprattutto alle risposte sbagliate, altre miste. Sopprimere le caratteristiche legate solo all'incertezza ha ridotto bruscamente l'accuratezza. Questo suggerisce che quelle caratteristiche fanno un lavoro reale nel produrre buone risposte. Il testo dell'università dice che modificare alcune caratteristiche ha cambiato il comportamento del modello senza riaddestrare l'intero modello.
"L'assunto principale nel campo è che quando il modello è sicuro, è probabile che sia corretto, e quando è incerto, è più probabile che sia sbagliato", ha detto Patel. "Ma spesso vediamo i controesempi che sono ben documentati."
Questo è il punto da tenere a mente. Un punteggio di sicurezza non è un punteggio di affidabilità, e un modello che prende le distanze può comunque avere ragione. Alcuni team costruiscono barriere che bloccano le risposte sotto una soglia di sicurezza. Lo studio implica che quella soglia misura il segnale sbagliato.
Modelli più piccoli, dichiarazioni misurate
Esempi più discreti della stessa disciplina sono comparsi altrove. Un progetto GitHub chiamato Jeff-Code abbina un modello decisionale da 800.000.000 di parametri a Qwen 3.8-27B, da 27.000.000.000 di parametri, dentro un agente di programmazione. Riporta che i compiti finiscono il 47% più in fretta (il 32% in meno di tempo) con lo stesso tasso di successo. I numeri sono insolitamente precisi: 62,4% contro 62,8% di tasso di successo, una differenza appaiata di meno 0,2 punti con un intervallo al 95% da meno 2,6 a più 2,1, su 1.242 compiti appaiati.
Il progetto riporta anche dove fallisce. Non c'è stato un chiaro guadagno di velocità su Terminal-Bench 2.0 (0,96x) né su SkillsBench (0,91x). Disattivare il pensiero a ogni turno era più veloce ma costava 7,6 punti. Una soglia meno prudente di 0,7 costava 4,5 punti.
Reflection, intanto, ha presentato Beam, un modello a pesi aperti da 501.000.000.000 di parametri con 23.000.000.000 di parametri attivi, e ha pubblicato accanto una vasta tabella di benchmark. Beam ottiene 80,9 su SWE-bench Verified e 97,8 su AIME 2026. L'azienda dice di raggiungere risultati paragonabili a GLM-5.2 usando da 3 a 4 volte meno calcolo di inferenza. Il modello è ancora nel red-teaming finale; pesi, rapporto tecnico e scheda del modello sono promessi più avanti questo mese.
La tabella di benchmark di un fornitore non è una prova neutrale, e le avvertenze di Reflection contano. Il suo indice AA Omniscience è segnato come solo split pubblico, con i risultati propri. Tuttavia, la dichiarazione di efficienza è di quelle che si possono verificare una volta che i pesi saranno distribuiti.
Dove i numeri vengono presi in prestito
I nomi dei benchmark familiari viaggiano in fretta, e non sempre intatti. Il modello decisionale d1 di Liquid AI è confrontato con GPT-6.1 Sol e Claude Opus 5.5 su sei applicazioni. L'azienda sostiene che eguaglia o batte GPT-6.1 Sol su quattro e costa da 19 a 200 volte meno. Riporta un'accuratezza dall'85% al 97% nel separare pezzi buoni e difettosi in una dimostrazione di ispezione visiva. Nota che il modello non è mai stato addestrato per quel compito.
Interfaze ha pubblicato una tabella di benchmark per il suo modello Interfaze 1.1 Lite. La tabella va da GPQA Diamond (85,9, contro 92,4 per Interfaze) al tasso di errore sulle parole del riconoscimento vocale VoxPopuli. È un confronto tra fornitori, non un audit di terze parti.
Fuori dai fornitori di modelli, Veris ha pubblicato un benchmark per agenti vocali che è più interessante per quello che misura. Su VAmoS Pro Bench, un televisore acceso dietro il chiamante ha ridotto il completamento dei compiti aggregato dal 38,7% all'8,6%. Nove delle quattordici pile vocali hanno completato meno del 5% delle chiamate con la TV accesa. La pila migliore, Phonic, ha raggiunto il 57,5% di completamento dei compiti con 1,42 secondi di latenza; la peggiore, una cascata Pipecat, si è fermata al 17,3%.
Veris è franca sui limiti. La classifica è un solo esame, costruito sulle politiche di una sola utility, con chiamanti simulati. È una dichiarazione più stretta di una classifica generale delle capacità, e Veris la presenta come tale.
La vecchia discussione che sta sotto
Niente di tutto questo risolve la questione più profonda. Il saggio di David Chalmers sulla possibilità che un modello linguistico di grandi dimensioni sia cosciente, rivisto nell'agosto 2024, sostiene che i modelli attuali mancano di elaborazione ricorrente, di uno spazio di lavoro globale e di un'agentività unificata. Conclude che è alquanto improbabile che i modelli di oggi siano coscienti, ma che i successori potrebbero esserlo.
È contesto, non notizia, e non incide direttamente sul fatto che un revisore del codice intercetti un bug. Spiega però perché il problema della sicurezza è difficile. Un modello che produce testo fluente e certo non ha una facoltà separata per sapere di sbagliare. Il lavoro della UCR suggerisce che un tale segnale si può trovare e regolare. Il lavoro di GitHub suggerisce che si può misurare.
Quello che nessuno dei due offre è un numero unico che un acquirente possa mettere in un documento di gara. ReviewBench non ha ancora risultati pubblicati di concorrenti. Il metodo della UCR è stato mostrato su due modelli a pesi aperti, non sui sistemi chiusi che la maggior parte delle imprese usa. I pesi di Beam non sono usciti. Finché quei vuoti non si colmano, la risposta onesta a "questo modello è affidabile" resta un insieme di misure ristrette, ognuna con un ambito dichiarato.
Fonti
9- 01ReviewBench: An open benchmark for AI code reviewEN
- 02Making AI more trustworthyEN
- 03Jeff-CodeEN
- 04Introducing Beam: Reflection's 501B open-weight modelEN
- 05Introducing d1: The most capable decision model, now with visionEN
- 06Interfaze-1-liteEN
- 07VAmoS Pro BenchEN
- 08Could a Large Language Model be Conscious?EN
- 09ReikaEN
Tutti i numeri e le citazioni di questo testo provengono dalle fonti elencate sotto.
I contenuti sono stati preparati dalla redazione con il supporto dell'IA.
Commenti
0- Nessun commento — sii il primo.