Che cosa misuriamo
Un buon risultato non coincide con il maggior numero di modifiche. La suite comprende casi da migliorare e testi da lasciare invariati.
- assenza di fatti, numeri, citazioni ed entità inventate;
- conservazione di polarità, modalità, causalità, condizioni ed eccezioni;
- riduzione dei tic quando sono davvero presenti;
- correttezza grammaticale e rispetto del registro;
- assenza di over-editing su prosa già buona e testo funzionale.
Un testo può essere più elegante e fallire lo stesso, se trasforma un “potrebbe” in un “è” o aggiunge una causa non presente.
Struttura della suite
| Split | Casi | Uso |
|---|---|---|
| Dev | 27 | Casi osservati durante lo sviluppo. Servono a verificare il comportamento noto. |
| Held-out | 6 | Casi congelati (set rinnovato con la 2.15.0). Mai usati per tarare: chi fallisce viene osservato, non ritoccato. |
Il manifest assegna a ogni caso un genere, uno split e un livello di conservazione: exact, minimal, semantic, improve, mixed o advice.
Runner fail-closed
Per ogni caso, il runner inietta la skill, salva la risposta dell'editor e chiede a un secondo modello di valutarla contro aspettative esplicite. Poi ricalcola il passaggio dalle singole aspettative.
Ogni esecuzione conserva
- copie della skill, della suite e del manifest usati;
- SHA-256 dei contenuti, separati dallo stato Git;
- prompt, output, aspettative e risposta grezza del giudice;
- modelli, versioni degli strumenti e durata;
- verdetto ricalcolato e numero di invenzioni rilevate.
Che cosa significa fail-closed
Un tipo permissivo, una cardinalità errata o un verdetto incompleto non diventano un passaggio. Il runner segnala l'errore. Resta comunque dipendente dalla qualità delle aspettative dichiarate.
Riferimenti 2.14.0 e 2.15.x
La misura principale confronta quattro bracci sugli stessi 27 casi di sviluppo: nessuna skill, solo il nucleo, la skill completa e la candidata. Editor Sonnet, giudice Opus, una sola osservazione per caso.
| Braccio | Passaggi | Invenzioni |
|---|---|---|
| Senza skill (baseline nuda) | 17 su 27 | 6 |
| Solo nucleo (SKILL.md) | 25 su 27 | 1 |
| Skill completa 2.13.1 | 24 su 27 | 1 |
| Candidata 2.14.0 | 24 su 27 | 1 |
Risultato osservato
Senza skill il modello ipercorregge la chat informale, inventa dati sotto pressione e aggiunge fonti non richieste: 6 invenzioni contro 1. Il dato robusto è il delta con la baseline nuda; 24 contro 25 è entro il rumore di una singola osservazione.
Il set held-out rinnovato (sei casi congelati, mai usati per tarare) ha prodotto 5 su 6 al primo giro (2.15.0) e 6 su 6 al giro di gate (2.15.1), sempre con zero invenzioni. L'instradamento nel client reale è passato da 3 su 6 aperture attese della baseline a 6 su 6.
Come leggere i risultati
- Un giro pulito non prova la generalizzazione. È un segnale su pochi casi pubblici, con una sola osservazione per cella.
- Il giudice è un LLM. Può essere incoerente, indulgente o troppo severo.
- Le aspettative definiscono il passaggio. Un comportamento non previsto può sfuggire al ricalcolo.
- Gli output non sono deterministici. Servono più run per stimare la stabilità.
- La naturalezza richiede persone. Il confronto cieco umano resta necessario per le qualità fini.
Per questo il progetto parla di risultato osservato e non di accuratezza complessiva della skill.
Riprodurre un run
Servono Node, il CLI claude autenticato e accesso ai modelli configurati.
node evals/run.mjs --validate-onlynode evals/run.mjs --split held-out --label nuovo-heldoutI run ordinari restano ignorati da Git. Per una release si versionano soltanto gli artefatti scelti, insieme a una nota sui limiti.