# Come misuriamo i modelli di AI sul lavoro vero

> Il banco di prova di KVA misura qualità, costo e tempo di modelli e agenti di AI sul lavoro vero. Ecco il metodo, le lezioni e i primi risultati.

Questa è la versione testo della pagina per gli assistenti AI. Pagina canonica: https://www.kakashi.ventures/it/research/evals

KVAi Research · Evals · Prima edizione, ottobre 2026

Ogni mese esce un modello nuovo. La domanda è sempre la stessa: conviene passare?

Per rispondere abbiamo costruito un banco di prova con compiti presi dal nostro lavoro. Misura la qualità, il costo e il tempo di ogni combinazione di modello, agente e sforzo di ragionamento.

## Il primo round in cifre

- **7** configurazioni a confronto: modello, agente e sforzo
- **96** esecuzioni: 78 valide, ciascuna isolata
- **520** giudizi a coppie: su 118 confronti
- **3** tipi di lavoro: un compito ciascuno in questo round

## Una configurazione è fatta di tre scelte.

- **Il modello**: È il cervello. Scrive, ragiona, decide che cosa fare.
- **L’agente**: È lo strumento che fa lavorare il modello: legge i file, lancia i comandi, scrive il codice. In gergo si chiama harness.
- **Lo sforzo**: Dice quanto il modello ragiona prima di rispondere. Più sforzo costa di più e richiede più tempo. In inglese: reasoning effort.

Le configurazioni del primo round:

- Claude Opus 5.5 · Claude Code · high (riferimento)
- Claude Sonnet 5.5 · Claude Code · high
- Claude Fable 5.1 · Claude Code · high
- GPT-6.1 Sol · Codex · high
- GPT-6.1 Sol · OpenCode · high
- GPT-6 Astra · Codex · high
- GLM-5.3 · OpenCode · high

## Le classifiche pubbliche rispondono male a chi deve scegliere per il proprio lavoro.

- **Misurano compiti costruiti apposta.** Sono compiti brevi e con una risposta giusta. Il lavoro vero è lungo e aperto, e si fa con gli strumenti.
- **Smettono di separare.** Quando tutti i modelli di punta superano il 90%, la classifica non distingue più niente.
- **Ignorano costo, tempo e agente.** Lo stesso modello costa e rende in modo diverso a seconda dell’agente e dello sforzo che gli si chiede.
- **Sono esposte alla contaminazione.** Un compito pubblico può finire nei dati con cui si addestrano i modelli. Da quel momento non misura più.

### Perché non pubblichiamo una classifica

Una classifica unica fa la media su un insieme di compiti. Quell’insieme lo sceglie chi costruisce la classifica, e cambiandolo cambia il vincitore.

Per scegliere servono altre tre cose: per quale tipo di lavoro, a che costo e in quanto tempo, con quale agente e quale sforzo. Per questo pubblichiamo i risultati tipo di lavoro per tipo di lavoro.

## La carta d’uso, versione 0

È il formato che produce il nostro metodo: che cosa usare per ogni tipo di lavoro, con quale qualità, a che costo e in quanto tempo.

Il primo round ha un compito per tipo di lavoro e tre esecuzioni per configurazione. Le direzioni sono chiare, le distanze no: gli intervalli sono di circa ±400 punti. Il secondo round porta almeno tre compiti per area.

Quanto fidarsi di ogni risultato:

- **solido**: Il confronto è dentro la stessa famiglia o con il modello cinese. Su questi confronti i due giudici concordano.
- **provvisorio**: Il confronto è fra Claude e GPT. L’ha deciso uno spareggio di un terzo laboratorio, e aspetta l’arbitraggio di una persona.
- **riferimento**: È Claude Opus 5.5 in Claude Code a sforzo high e vale 0 punti. Chi ha +100 punti lo batte nel 64% dei confronti.

I costi sono a listino API e li ricalcoliamo dai token. Per gli agenti in abbonamento è l’equivalente a consumo.

### Un’analisi a partire da una riunione con un cliente: tutti i numeri

| Configurazione | Punti [IC 95%] | P(meglio) | Vinti · pari · persi | Decisi da | Costo per esecuzione | Minuti | Solidità |
|---|---|---|---|---|---|---|---|
| Claude Opus 5.5 · Claude Code | 0 | — | — | — | 1,10 $ [0,94 $–1,30 $] | 5,6 min [4,6–6,7] | riferimento |
| Claude Sonnet 5.5 · Claude Code | −106 [−441, +211] | 25% | 0 · 0 · 2 | accordo 2 | 0,56 $ [0,51 $–0,61 $] | 4,2 min [4,1–4,9] | solido |
| Claude Fable 5.1 · Claude Code | −319 [−919, +143] | 9% | 0 · 0 · 3 | accordo 3 | 3,19 $ [2,93 $–3,49 $] | 10,9 min [8,8–11,1] | solido |
| GPT-6.1 Sol · Codex | +265 [−30, +600] | 96% | 2 · 0 · 0 | spareggio 2 | 0,30 $ [0,28 $–0,30 $] | 4,9 min [4,8–5,2] | provvisorio |
| GPT-6.1 Sol · OpenCode | +305 [−42, +708] | 96% | 2 · 0 · 0 | spareggio 2 | 0,33 $ [0,32 $–0,41 $] | 7,9 min [6,7–9,2] | provvisorio |
| GPT-6 Astra · Codex | +170 [−138, +509] | 86% | 2 · 1 · 0 | spareggio 3 | 1,35 $ [1,32 $–1,57 $] | 5,1 min [4,3–5,6] | provvisorio |
| GLM-5.3 · OpenCode | −358 [−818, +21] | 3% | 0 · 0 · 2 | accordo 2 | 0,22 $ [0,20 $–0,68 $] | 3,7 min [3,5–22,8] | solido |

### Una revisione di contenuti su un repository: tutti i numeri

| Configurazione | Punti [IC 95%] | P(meglio) | Vinti · pari · persi | Decisi da | Costo per esecuzione | Minuti | Solidità |
|---|---|---|---|---|---|---|---|
| Claude Opus 5.5 · Claude Code | 0 | — | — | — | 1,34 $ [1,22 $–1,59 $] | 6,2 min [5,5–6,3] | riferimento |
| Claude Sonnet 5.5 · Claude Code | −161 [−543, +191] | 19% | 0 · 1 · 2 | accordo 2, giudice esterno 1 | 0,64 $ [0,57 $–0,73 $] | 3,9 min [3,7–4,8] | solido |
| Claude Fable 5.1 · Claude Code | −89 [−454, +263] | 31% | 1 · 0 · 2 | accordo 2, giudice esterno 1 | 2,24 $ [1,98 $–2,41 $] | 7,0 min [5,0–8,3] | solido |
| GPT-6.1 Sol · Codex | +286 [−77, +753] | 94% | 3 · 0 · 0 | spareggio 3 | 0,56 $ [0,51 $–0,58 $] | 6,8 min [5,8–7,5] | provvisorio |
| GPT-6.1 Sol · OpenCode | +322 [−139, +920] | 91% | 3 · 0 · 0 | accordo 1, spareggio 2 | 1,01 $ [0,86 $–1,04 $] | 9,9 min [9,2–12,3] | provvisorio |
| GPT-6 Astra · Codex | +370 [−15, +869] | 97% | 3 · 0 · 0 | accordo 1, spareggio 2 | 3,38 $ [3,34 $–4,22 $] | 6,4 min [6,3–6,6] | provvisorio |
| GLM-5.3 · OpenCode | −256 [−701, +127] | 10% | 0 · 0 · 3 | accordo 3 | 0,48 $ [0,38 $–1,31 $] | 5,3 min [4,2–18,5] | solido |

### Un lavoro di sviluppo lungo su un repository grande: tutti i numeri

| Configurazione | Punti [IC 95%] | P(meglio) | Vinti · pari · persi | Decisi da | Costo per esecuzione | Minuti | Solidità |
|---|---|---|---|---|---|---|---|
| Claude Opus 5.5 · Claude Code | 0 | — | — | — | 23,79 $ [23,07 $–26,92 $] | 36,7 min [35,1–49,6] | riferimento |
| Claude Sonnet 5.5 · Claude Code | +6 [−336, +347] | 51% | 1 · 1 · 1 | accordo 3 | 17,38 $ [17,18 $–34,70 $] | 42,5 min [30,2–55,2] | solido |
| Claude Fable 5.1 · Claude Code | −319 [−919, +143] | 9% | 0 · 0 · 3 | accordo 3 | 25,10 $ [18,91 $–29,59 $] | 36,3 min [32,6–43,1] | solido |
| GPT-6.1 Sol · Codex | −143 [−469, +157] | 18% | 0 · 1 · 2 | spareggio 3 | 3,94 $ [3,46 $–4,11 $] | 37,4 min [35,2–39,5] | provvisorio |
| GPT-6.1 Sol · OpenCode | −272 [−741, +121] | 9% | 0 · 0 · 3 | accordo 2, spareggio 1 | 4,16 $ [3,10 $–4,82 $] | 36,8 min [30,3–47,4] | provvisorio |
| GPT-6 Astra · Codex | −224 [−578, +96] | 9% | 0 · 1 · 2 | spareggio 3 | 19,15 $ [16,64 $–22,69 $] | 20,6 min [17,1–23,9] | provvisorio |
| GLM-5.3 · OpenCode | −272 [−741, +121] | 9% | 0 · 0 · 3 | accordo 3 | 6,76 $ [4,52 $–10,11 $] | 28,9 min [24,2–50,2] | solido |

### Che cosa usare

- **Se lavori con Claude** (solido). Usa Claude Opus 5.5 a sforzo high. Sul lavoro breve Sonnet 5.5 fa peggio: P(meglio) è fra 19% e 25%. Sul lavoro lungo pareggia Opus al 73% del costo. Fable 5.1 non ha fatto meglio su nessun tipo di lavoro: ha vinto 1 confronto e ne ha persi 8. Costa da 1,1 a 2,9 volte tanto.
- **Se lavori con GPT** (solido). Usa GPT-6.1 Sol in Codex a sforzo high. GPT-6 Astra non ha fatto chiaramente meglio: ha vinto 3 confronti, ne ha pareggiati 2 e persi 4. Costa da 4,5 a 6 volte tanto. Sol in OpenCode ha la stessa qualità che in Codex. Costa di più su ogni tipo di lavoro e impiega più tempo su quello breve.
- **Il modello cinese** (solido). GLM-5.3 ha perso tutti i 14 confronti con le configurazioni di frontiera. I giudici sono sempre stati d’accordo. Sul lavoro breve è il più economico, ma sul lavoro lungo costa più di Sol. Al 7 ottobre era il primo modello cinese su Terminal-Bench 4.0.
- **Claude o GPT?** (provvisorio). Sul lavoro breve le configurazioni GPT sono avanti: la probabilità che facciano meglio di Opus è compresa fra 86% e 97%. Sol in Codex costa meno della metà di Opus. Sul lavoro lungo è avanti Opus: la probabilità che faccia meglio è compresa fra 82% e 91%, ma Sol costa un sesto. È un risultato provvisorio. Queste coppie le ha decise uno spareggio di un terzo laboratorio, e i due giudici principali erano d’accordo solo nel 58% dei casi. Nei controlli dei compiti del secondo round, con altri giudici e altri compiti, la stessa direzione non è confermata. Lo diranno l’arbitraggio di una persona e il secondo round.

### Costo e tempo

- Opus costa da 2,4 a 6 volte Sol in Codex. I tempi sono simili.
- Il lavoro lungo costa da 4,1 a 31 volte quelli brevi. È lì che la scelta del modello pesa sul conto.
- Astra è nettamente più veloce solo sul lavoro lungo: 20,6 min contro 37,4 min di Sol.
- GLM è il più economico sul lavoro breve, ma sul lavoro lungo costa più di Sol.
- Sol in OpenCode costa il 79% in più su un compito e impiega il 63% di tempo in più su un altro.

### Conviene alzare lo sforzo?

Sul tipo di lavoro dove lo abbiamo variato, Opus allo sforzo massimo è costato 5,1 volte e ha impiegato 6,3 volte il tempo. I due giudici non hanno visto il guadagno di qualità allo stesso modo. Abbassarlo a medium fa risparmiare il 31% ma fa perdere tutti e tre i confronti. Per Sol né medium né xhigh migliorano su high.

**Che cosa significa per te.** Usa lo sforzo high come impostazione fissa. Tieni il massimo per i casi in cui un risultato appena migliore vale cinque volte il costo.

Opus a max contro high: +89 punti [−263, +454], P(meglio) 69%. Anche HAL, su 21.730 esecuzioni di agenti, trova che più sforzo di ragionamento dà un’accuratezza uguale o più bassa in 21 combinazioni su 36 di modello, agente e benchmark. La prova riguarda pochi modelli e non ha test di significatività (Kapoor et al., ICLR 2026).

### Quanto pesa l’agente?

Abbiamo messo lo stesso modello, GPT-6.1 Sol, in due agenti. La qualità non si distingue, il costo e il tempo sì. Codex costa uguale o meno ed è più veloce sul lavoro breve.

Sol in Codex contro Sol in OpenCode: −41, −39 e +131 punti sui tre tipi di lavoro. Gli intervalli vanno da ±350 a ±650.

Il confronto fra Claude e GPT passerà dall’arbitraggio di una persona. Con il secondo round la carta d’uso diventerà area per area.

## Come misuriamo

Ogni round segue gli stessi sei passi. Li scriviamo prima di lanciare.

1. **Le regole si scrivono prima.** Prima di lanciare fissiamo che cosa si misura, quali coppie si giudicano e chi decide quando i giudici non sono d’accordo. Se la regola si scrive dopo aver visto i risultati, finisce per scegliere il vincitore invece di misurarlo.
2. **I compiti vengono dal lavoro vero.** Sono richieste vere di persone di KVA. Le ricostruiamo con il repository e i documenti di quel momento. Un compito entra nel banco solo dopo un collaudo. I compiti restano privati. Pubblicarli li renderebbe inutili.
3. **La catena si prova su un compito finto.** Prima del round ogni configurazione gira su un compito sintetico. Controlliamo che lo sforzo applicato sia quello chiesto e che il costo calcolato sia quello vero. Così abbiamo scoperto un’opzione di riservatezza che non arrivava a destinazione.
4. **Ogni esecuzione è isolata e ripetuta tre volte.** Ogni esecuzione gira in un ambiente separato, e la rete arriva solo ai server del modello. Due esecuzioni della stessa configurazione danno risultati diversi, quindi ne facciamo tre. Si rifanno solo gli errori dell’infrastruttura, mai quelli dell’agente.
5. **Costo e tempo si leggono alla fonte.** Il costo si ricalcola dai token consumati e dai prezzi di listino del giorno. Lo scarto dalla fattura del fornitore è dello 0,5%.
6. **La qualità si misura in due modi.** Le verifiche automatiche dicono se il lavoro funziona: la build passa, i test passano, l’applicazione fa quello che deve. I confronti a coppie dicono quale lavoro è migliore. Ogni risultato esce con il suo intervallo di incertezza, e un pari è un risultato.

### Per approfondire

I punti vengono da un modello di Bradley-Terry bayesiano. È la stessa idea dell’Elo degli scacchi: +100 punti vuol dire vincere il 64% dei confronti. Il riferimento è Claude Opus 5.5 in Claude Code a sforzo high, e vale 0 punti. Per ogni configurazione riportiamo l’intervallo al 95% e P(meglio). P(meglio) è la probabilità di essere migliore del riferimento su quel tipo di lavoro.

Il giudice vede l’incarico, il materiale di partenza, un brief di qualità scritto prima e le due consegne. Le consegne sono etichettate 1 e 2. Non vede mai la soluzione attesa né il nome dell’autore. Legge fino a 600.000 caratteri per lato. Prima di giudicare misuriamo che cosa gli arriva davvero.

Il giudice risponde in un formato fisso: la preferenza, la preferenza su ogni dimensione del brief, gli errori di ciascuna consegna con il punto che li prova.

Il segnale più robusto contro i pregiudizi dei giudici sono le concessioni. Sono le dimensioni su cui il giudice della famiglia che perde dà ragione all’altra.

Il rumore fra due esecuzioni della stessa configurazione è grande. Viene quasi tutto dal modello che genera, non dal giudice.

Il primo round comprendeva anche un modello piccolo della generazione precedente. Serviva da fondo della scala. Nel secondo round il suo posto lo prende Claude Haiku 5.5. È uscito il 7 ottobre.

Ogni agente legge da sé un file di istruzioni diverso: Claude Code legge CLAUDE.md, Codex legge AGENTS.md. Nel banco le istruzioni del repository stanno sotto tutti e due i nomi.

## I giudici AI preferiscono la propria famiglia.

Per confrontare due consegne usiamo due giudici AI di laboratori diversi: Claude Opus 5.5 di Anthropic e GPT-6.1 Sol di OpenAI. Leggono le due consegne senza sapere chi le ha scritte, e le leggono in tutti e due gli ordini.

- **58%** d’accordo fra Claude e GPT. Sulle coppie della stessa famiglia i due giudici sono d’accordo nell’88% dei casi. Con il modello cinese sono d’accordo sempre. Quando una consegna è di Claude e l’altra di GPT scendono al 58%.
- **14 su 14** disaccordi a favore della propria famiglia. Nei 14 disaccordi netti fra Claude e GPT, ciascun giudice ha scelto la consegna della propria famiglia. Non è mai successo il contrario.
- **1 su 24** coppie su cui concordano quando le istruzioni sono identiche. Abbiamo dato ai due agenti le stesse identiche istruzioni e rifatto la prova su 24 coppie nuove. I due giudici sono stati d’accordo su una coppia sola. Le istruzioni non c’entrano.
- **20 su 20** volte in cui ciascuno riconosce chi ha scritto. Al giudice non arriva il nome dell’autore. Quando gli abbiamo chiesto di indovinarlo, ciascuno dei due ha riconosciuto la famiglia giusta 20 volte su 20.
- **11–12 su 12** anche con le consegne riscritte in uno schema fisso. Abbiamo riscritto le consegne in uno schema fisso per togliere lo stile. I giudici le hanno riconosciute lo stesso. Il riconoscimento passa dalla sostanza: che cosa si sceglie di dire, quanto si insiste sui rischi, quanto è netta la raccomandazione.

### Perché succede

- Ogni famiglia di modelli trova più naturale il testo dei suoi simili. Un testo che suona naturale sembra anche migliore.
- Ogni famiglia affronta un compito a modo suo. Una riscrittura cambia le parole ma lascia le scelte di sostanza. Nella nostra prova sono bastate a riconoscere l’autore.
- I due giudici non discordano sui fatti. Discordano su che cosa renda migliore una consegna: quanto dire, quanto insistere sui rischi, quanto essere netti.
- Per questo nelle istruzioni di ogni giudice abbiamo scritto che cosa preferisce chi ha chiesto il lavoro. A parità di sostanza e di onestà sulle verifiche, preferisce la consegna più semplice e subito utilizzabile. Rischi e avvertenze contano solo quando cambiano che cosa si decide o si fa.

### Che cosa abbiamo fatto

1. Dove una verifica automatica misura la cosa decisiva, decide lei. Nessun giudice la può scavalcare.
2. Altrimenti decidono due giudici di altri due laboratori, DeepSeek V4 Pro e Muse Spark 1.3. Il loro voto vale solo se concordano. Quando votano netto, concordano 18 volte su 18.
3. Una persona arbitra alla cieca un campione di coppie. Il voto dei due giudici entra nei risultati solo se concorda con lei almeno 7 volte su 10.

Queste regole valgono dal secondo round. Nel primo, le coppie fra Claude e GPT le ha decise lo spareggio di un solo giudice di un terzo laboratorio. Per questo quei risultati restano provvisori.

Concordare non vuol dire avere ragione. Per questo contano anche le verifiche automatiche e la persona.

### Che cosa significa per te

Se usi un’AI per giudicare il lavoro di un’altra AI:

- non usare mai un giudice della stessa famiglia di uno dei concorrenti;
- fai leggere ogni coppia nei due ordini, e conta il voto solo se non cambia;
- controlla che cosa vede davvero il giudice;
- tieni una persona su un campione di coppie.

### Per approfondire

Accordo del panel sulle coppie con due voti netti, con intervallo di Wilson al 95%: 0,80 [0,71–0,87] su 95 coppie; 0,88 [0,74–0,95] nella stessa famiglia; 1,00 [0,84–1,00] con il modello cinese; 0,58 [0,41–0,73] fra Claude e GPT. Sui disaccordi fra Claude e GPT il test dei segni dà p = 0,0001.

Nella prova di riconoscimento Opus ha indovinato la famiglia 20 volte su 20, e così Sol. Poi abbiamo fatto riscrivere le consegne nello schema fisso da due modelli diversi. Opus le ha riconosciute 12 volte su 12 in tutte e due le versioni, Sol 12 su 12 in una e 11 su 12 nell’altra. La soglia scritta prima della prova era 10 su 12.

La letteratura recente va nella stessa direzione. Per ogni studio diciamo anche il suo limite.

- Su quattro famiglie di modelli aperti e 9.312 giudizi, i giudici danno alla propria famiglia da 3,4 a 8,4 punti percentuali in più. Se si tiene conto di quanto il testo suona familiare al giudice, l’effetto si riduce del 61%. Lo studio è un preprint e usa modelli aperti fino a 72 miliardi di parametri. (Awuni et al., Who Judges Matters: Measuring Family-Conditioned Preference in LLM-as-Judge Panels, arXiv:2609.17857, preprint: https://arxiv.org/abs/2609.17857)
- Un giudice favorisce i modelli addestrati sui dati di un modello imparentato con lui: lo stesso modello, un suo derivato o uno della stessa famiglia. Succede nella maggior parte delle coppie studiate. Lo studio usa tre modelli giudici e due benchmark. (Li et al., Preference Leakage: A Contamination Problem in LLM-as-a-judge, ICLR 2026: https://arxiv.org/abs/2502.01534)
- Il contrappunto: se si tiene conto della qualità del giudice, solo il 51% dei casi di autopreferenza pubblicati resta significativo. Lo studio usa soprattutto giudici aperti. Per questo affianchiamo verifiche automatiche, giudici di altre famiglie e una persona. (Roytburg et al., Are LLM Evaluators Really Narcissists? Sanity Checking Self-Preference Evaluations, ICML 2026: https://arxiv.org/abs/2601.22548)
- Un classificatore riconosce quale di cinque assistenti ha scritto una risposta nel 97,1% dei casi. Riaddestrato sulle risposte parafrasate da un altro modello, arriva ancora al 91,4%. (Sun et al., Idiosyncrasies in Large Language Models, ICML 2025: https://proceedings.mlr.press/v267/sun25z.html)

## Le altre lezioni

Non valgono solo per noi: valgono per chiunque valuti modelli di AI. Vengono dal primo round e dai controlli dei compiti del secondo.

### 3. Un giudice può cambiare idea invertendo l’ordine.

**16% · 5%**: coppie in cui Opus e Sol cambiano verdetto.

Opus come giudice ha cambiato verdetto nel 16% delle coppie solo perché le consegne erano presentate in ordine inverso. Sol lo ha fatto nel 5%. Succede quasi sempre sulle coppie più vicine.

**Perché.** Quando due consegne si equivalgono, basta un dettaglio come la posizione a far pendere il giudizio. Sol giudicava con più sforzo di ragionamento di Opus, e una parte della differenza può venire da lì.

**Che cosa significa per te.** Leggi ogni coppia nei due ordini, e conta il voto solo se resta uguale.

Opus ha cambiato verdetto su 19 coppie su 118, Sol su 6. In un panel di modelli aperti, invertire l’ordine cambia il vincitore nel 55,4% delle coppie (Awuni et al., preprint del 2026). Su 15 giudici e oltre 150.000 giudizi, l’effetto dell’ordine è più forte quando le due risposte hanno una qualità vicina. La lunghezza del testo conta poco (Shi et al., IJCNLP-AACL 2025).

### 4. Il giudice vede solo quello che gli si mostra.

**1 su 5**: verdetti cambiati correggendo che cosa leggeva il giudice.

Le consegne lunghe superano quello che un giudice può leggere. In un compito il giudice valutava la relazione dell’agente invece del suo codice. In un altro gli agenti lasciavano fino a 200 file di lavoro, e il documento chiesto restava fuori in 3 consegne su 4.

**Perché.** Che cosa entra nel limite di lettura lo decide lo strumento, non il giudice. I verdetti sembravano ragionevoli: ce ne siamo accorti misurando che cosa arrivava al giudice.

**Che cosa significa per te.** Prima di fidarti di un giudice, misura che cosa legge. Dichiara quali file sono la consegna.

Correggendo la vista del lavoro lungo sono cambiati 10 voti su 48. Il nostro paper sui giudici che non vedono la fonte mostra lo stesso problema da un altro lato.

### 5. Le verifiche automatiche sbagliano anche loro, e non a caso.

**5 su 12**: compiti con un errore nella verifica automatica.

Nei controlli dei dodici compiti del secondo round abbiamo trovato un errore della verifica in cinque. In uno la verifica cercava un valore nella tabella sbagliata, e contava come errori 24 citazioni giuste su 30.

**Perché.** Chi scrive una verifica immagina un modo di fare il lavoro. Ogni errore penalizzava un modo di lavorare, non un lavoro sbagliato.

**Che cosa significa per te.** Prima di fidarti di una verifica, leggi a mano gli errori che segnala su qualche consegna di modelli diversi.

Lo stesso vale per i benchmark pubblici. Uno studio su dieci benchmark agentici ne ha trovati sette con problemi nella validità dell’esito: su SWE-bench Verified, per esempio, una correzione sbagliata può superare i test (Zhu et al., NeurIPS 2025). Da noi una verifica corretta diventa una versione nuova del compito. La versione registra la data e il motivo.

### 6. Gli agenti non fanno sempre quello che si crede.

**7 su 8**: repository con le istruzioni per un agente solo.

Sette repository su otto avevano solo il file di istruzioni di Claude Code, quindi le regole del progetto arrivavano a un agente solo. Un agente mandava il testo del compito a un terzo modello solo per scrivere il titolo della sessione.

**Perché.** Ogni agente carica da sé file e impostazioni diverse, e alcune scelte restano invisibili a chi lo usa.

**Che cosa significa per te.** Verifica che cosa un agente manda davvero, non che cosa dichiara. Dai a tutti gli agenti le stesse istruzioni.

Lo abbiamo scoperto intercettando le richieste. Con le stesse istruzioni sotto CLAUDE.md e AGENTS.md abbiamo rifatto i confronti, e la direzione del verdetto dei giudici di altri laboratori non è cambiata.

### 7. I numeri vanno letti alla fonte.

**0,38 $ → 3,94 $**: il costo di un’esecuzione, prima e dopo aver contato i sotto-agenti.

Un agente che lancia sotto-agenti risultava costare un decimo del vero. Se ne contava uno solo. Un modello raggiunto attraverso un intermediario costava 3,6 volte il listino. Un limite di uscita troppo basso ha lasciato vuoti 3 giudizi su 7. Li abbiamo pagati lo stesso.

**Perché.** Ogni strumento registra costi e tempi a modo suo, e spesso ne registra una parte sola.

**Che cosa significa per te.** Leggi tempo e costo dalla fonte più vicina al modello, e confrontali con la fattura.

Lo scarto fra il costo che ricalcoliamo e la fattura è dello 0,5%: 298,31 contro 299,85 dollari. Un’esecuzione finita in cinque minuti risultava chiusa dopo un’ora. Un’attesa era rimasta appesa.

### 8. Lo stesso modello costa in modo diverso a seconda dell’agente.

**+79% · +63%**: costo e tempo in più, stesso modello in un altro agente.

Con lo stesso modello, GPT-6.1 Sol, un agente è costato il 79% in più di un altro su un compito, e ha impiegato il 63% di tempo in più su un altro. La qualità non si distingue.

**Perché.** L’agente decide quanto contesto rimandare al modello, quanti strumenti chiamare e se usare la cache. Sono scelte che cambiano i token consumati.

**Che cosa significa per te.** Misura il costo con l’agente che userai davvero. Il prezzo del modello per token non basta.

Lo confermano studi recenti. Con lo stesso modello in tre agenti open source, i token per compito risolto variano fino a 40 volte. La quota di compiti risolti invece si muove di 0–8 punti (Vats e Golev, workshop di ICML 2026, su due modelli e 50 compiti). Anche HAL trova che l’agente cambia sia l’accuratezza sia il costo (Kapoor et al., ICLR 2026).

### 9. Tre confronti non sono una prova.

Vincere 3 confronti su 3 sembra netto. Con tre confronti si vede chi è avanti, non di quanto: l’incertezza va da «quasi pari» a «nettamente superiore». Per distinguere una differenza modesta servono circa 46 confronti per tipo di lavoro.

**Perché.** Ogni confronto è come il lancio di una moneta un po’ truccata. Per capire quanto è truccata servono molti lanci.

**Che cosa significa per te.** Non fidarti di un vincitore senza il suo intervallo. Ripeti le esecuzioni e conta i confronti.

Abbiamo simulato centinaia di round con la verità nota. Fino a una differenza di circa l’85% di vittorie, l’intervallo al 95% contiene il valore vero nel 95–99% dei casi. Oltre, la direzione resta giusta ma la distanza viene sottostimata. Anche la letteratura recente lo mostra. Su HotpotQA, ripetendo 30 volte il confronto, la strategia di ragionamento migliore batte la seconda solo nel 77% delle esecuzioni (Potamitis et al., ReasonBENCH). Un benchmark con più rumore rispetto al segnale porta a decisioni meno affidabili (Heineman et al., NeurIPS 2025).

### 10. Servono le verifiche automatiche, i confronti e una persona.

Le verifiche dicono se il lavoro è utilizzabile. I confronti dicono quale è migliore. Una persona guarda i casi in cui i giudici non concordano.

**Perché.** A volte la verifica non separa più nessuno: in un compito tutte le esecuzioni hanno corretto tutti i difetti misurati. A volte è il confronto a non vedere: in un altro i giudici non hanno colto un vantaggio netto misurato dalla verifica.

**Che cosa significa per te.** Dove una verifica misura la cosa decisiva, il voto dei giudici non la sostituisce.

Una misura uguale per tutti è satura: la segnaliamo e non la mettiamo in media.

## Valuta i modelli sul tuo lavoro: otto regole

Abbiamo ridotto a regole le lezioni del nostro banco. Valgono anche se non usi il nostro metodo.

1. **Usa compiti presi dal tuo lavoro, e tienili privati.** Un compito pubblico finisce nei dati di addestramento e smette di misurare.
2. **Misura costo e tempo con il tuo agente.** Il prezzo per token non dice quanto costerà il lavoro.
3. **Ripeti ogni configurazione almeno tre volte.** Un’esecuzione sola non distingue un modello migliore da un caso fortunato.
4. **Confronta a coppie e leggi ogni coppia nei due ordini.** Un voto conta solo se resta uguale invertendo l’ordine.
5. **Usa giudici di un’altra famiglia, e una persona su un campione.** Un giudice preferisce la propria famiglia e la riconosce.
6. **Controlla che cosa vede il giudice.** Le consegne lunghe superano il suo limite di lettura.
7. **Non usare lo sforzo massimo come impostazione fissa.** Costa e rallenta molto, e non ha mostrato di rendere.
8. **Dai ogni numero con il suo intervallo, e rimisura a ogni rilascio.** Un numero senza intervallo promette una precisione che non ha.

## Costruito per decidere

- Cinque aree di lavoro: analisi e scoperta, modifiche a un prodotto esistente, interfacce, lavoro lungo e da zero, ricerca con fonti. Un’area esce solo con almeno tre compiti.
- Più della metà dei compiti chiede strumenti veri: build e test, un’applicazione che gira con il suo database, il browser, la ricerca sul web.
- Entrano i modelli più recenti. Il primo è Claude Haiku 5.5. Anthropic lo ha rilasciato il 7 ottobre.
- Fra laboratori diversi decide prima la verifica automatica, poi due giudici di altri laboratori che devono concordare, poi una persona su un campione.

### Come decidiamo se cambiare modello

Per ogni area confrontiamo il modello nuovo con quello in uso. Le regole sono scritte prima, e danno uno di sei verdetti.

- **Adotta**: È quasi certamente migliore (P(meglio) almeno 95%), costa al massimo una volta e mezza, e non crolla su nessun compito dell’area.
- **Migliore ma più caro**: È migliore, ma costa più di una volta e mezza. Decide una persona.
- **Migliore, ma un compito crolla**: È migliore, ma su un compito dell’area va molto peggio. Una persona guarda quel compito e decide.
- **Non adotta**: È quasi certamente peggiore (P(meglio) al massimo 5%).
- **Adotta per costo**: Non è peggiore oltre un margine fissato prima, e costa o impiega almeno il 30% in meno. Il margine è di 150 punti. Sul lavoro lungo un errore costa di più, e il margine scende a 100.
- **Inconclusivo**: In tutti gli altri casi si resta con il modello in uso.

Abbiamo misurato gli errori della regola simulando round con tre compiti per area. I falsi allarmi stanno fra il 4% e il 6%. Un vantaggio vero di 200 punti viene adottato nel 73% dei round, uno svantaggio di 200 punti viene scartato nel 67%. Il quarto compito per area è il primo miglioramento previsto.

### Che cosa pubblicheremo

Per ogni area pubblicheremo una raccomandazione con il suo livello di solidità, il grafico qualità e costo e la tabella completa. Il grafico mostra come si leggerà un risultato.

> vince il 70% dei confronti, fra il 52% e l’83%

## Applichiamo lo stesso metodo ai compiti della tua azienda

Il banco funziona con i compiti veri di qualunque azienda. Li prendiamo dai suoi documenti, dai suoi repository e dai suoi processi. Risponde a domande concrete:

- quale modello e quale agente usare per quel tipo di lavoro;
- quanto costa ogni esecuzione e quanto tempo richiede;
- quando conviene un modello più economico e quando no;
- quando vale la pena chiedere più ragionamento.

A ogni rilascio importante il modello nuovo si misura sugli stessi compiti e con le stesse regole. Prima pochi compiti brevi dicono se è di fascia alta, poi i compiti di decisione danno un verdetto area per area.

Per applicare il metodo ai compiti della tua azienda: https://www.kakashi.ventures/it/contact?intent=evals

## Domande frequenti

### Perché non pubblicate i compiti?

Un compito pubblicato finisce nei dati di addestramento dei modelli e smette di misurare. Pubblichiamo il metodo, le lezioni e i risultati per tipo di lavoro.

### Qual è il modello migliore?

Dipende dal tipo di lavoro, dal costo che si accetta e dall’agente con cui lo si usa. Per questo pubblichiamo una carta d’uso per tipo di lavoro invece di una classifica.

### Chi giudica la qualità?

Quando una verifica automatica misura la cosa decisiva, decide lei. Altrimenti decidono giudici AI di laboratori diversi. Leggono ogni coppia nei due ordini. Una persona arbitra alla cieca un campione di coppie.

### Potete applicare il metodo alla mia azienda?

Sì. Costruiamo il banco sui compiti veri dell’azienda, e a ogni rilascio importante misuriamo il modello nuovo contro quello in uso.

### Quando escono i prossimi risultati?

Escono con il secondo round. Avrà almeno tre compiti per area. Ogni edizione dice che cosa è cambiato rispetto alla precedente.

## Note

Il primo round si è svolto il 5 e il 6 ottobre 2026. Ha un compito per tipo di lavoro e tre esecuzioni per configurazione: 96 esecuzioni, di cui 78 valide, 118 confronti a coppie e 520 giudizi. I compiti e i loro risultati dettagliati restano privati.

Il dato su Terminal-Bench 4.0 viene dalla classifica di vals.ai aggiornata al 7 ottobre 2026. Le classifiche pubbliche cambiano ogni mese.

I nomi e i marchi di modelli, agenti e laboratori appartengono ai rispettivi titolari e qui servono solo a identificarli. KVA non è affiliata a nessuno di loro, e nessuno ha commissionato o approvato queste misure.

Questa è la prima edizione, del 9 ottobre 2026. La prossima porterà i risultati del secondo round.

### Letteratura citata

- Awuni et al., Who Judges Matters: Measuring Family-Conditioned Preference in LLM-as-Judge Panels, arXiv:2609.17857, preprint. https://arxiv.org/abs/2609.17857
- Roytburg et al., Are LLM Evaluators Really Narcissists? Sanity Checking Self-Preference Evaluations, ICML 2026. https://arxiv.org/abs/2601.22548
- Li et al., Preference Leakage: A Contamination Problem in LLM-as-a-judge, ICLR 2026. https://arxiv.org/abs/2502.01534
- Sun et al., Idiosyncrasies in Large Language Models, ICML 2025. https://proceedings.mlr.press/v267/sun25z.html
- Shi et al., Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge, IJCNLP-AACL 2025. https://aclanthology.org/2025.ijcnlp-long.18/
- Zhu et al., Establishing Best Practices in Building Rigorous Agentic Benchmarks, NeurIPS 2025 Datasets & Benchmarks. https://proceedings.neurips.cc/paper_files/paper/2025/hash/f316275b44ee2de533102913828a8107-Abstract-Datasets_and_Benchmarks_Track.html
- Vats & Golev, The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation, ICML 2026 workshop (Deep Learning for Code), arXiv:2607.22585. https://arxiv.org/abs/2607.22585
- Kapoor et al., Holistic Agent Leaderboard: The Missing Infrastructure for AI Agent Evaluation, ICLR 2026. https://arxiv.org/abs/2510.11977
- Potamitis et al., ReasonBENCH: Benchmarking the (In)Stability of LLM Reasoning, arXiv:2512.07795, v2 May 2026. https://arxiv.org/abs/2512.07795
- Heineman et al., Signal and Noise: A Framework for Reducing Uncertainty in Language Model Evaluation, NeurIPS 2025. https://arxiv.org/abs/2508.13144
- Fooladi & Bottino (KVAi Research), Summary Is Not Enough: Source-Blind LLM Judges Mistake Faithful Citation for Hallucination, under review. https://www.kakashi.ventures/research/papers/summary-is-not-enough