Heroes / Perché / misurato

La tesi del progetto, messa alla prova in pubblico: che cosa è stato misurato, che cosa è stato scritto prima di misurare e che cosa questa pagina non dice ancora. Ogni numero di questa pagina è copiato dal file del repository che lo ha misurato, e quel file è nominato accanto.

• Misurato: che cosa rileva il compilatore. Rifiuta gli sbagli plausibili per cui esistono le sue regole, e con quelle regole spente gli stessi sbagli passano. Il meccanismo →
• Scritto prima di misurare: la prova della tesi. L’unico numero che riporterà, che cosa vorrà dire ciascun esito e che cosa si aspetta l’autore, fissati in un commit insieme ai compiti sigillati. Le regole della prova →
• Provato, ma non è una prova a favore: un collaudo. Dieci compiti di collaudo hanno dimostrato che lo strumento funziona, e non dicono nulla sulla tesi. Il collaudo →
• Il primo giro sui compiti sigillati è finito pari. Con le regole e senza, i modelli hanno risolto gli stessi compiti entro tre tentativi; sulla misura fissata prima del giro, questo si chiama non conclusivo. Le cifre si dichiarano alla soglia di pubblicazione. Perché le cifre aspettano →

La tesi

Un linguaggio progettato perché ogni sbaglio plausibile di un modello sia un errore di compilazione produrrà programmi funzionanti spendendo meno token in totale di un linguaggio convenzionale, anche se ogni singolo programma costa più token da scrivere.

Il modello di cui parla la tesi è un LLM, un grande modello linguistico: il tipo di modello AI che scrive codice. I token sono i frammenti di testo che un modello legge e genera. La tesi poggia su una formula del documento di progetto:

costo reale = token del programma × (1 + tasso di riscrittura)

Accorciare la sintassi riduce i token necessari per scrivere un file. Correggere un errore richiede invece altri passaggi: il modello legge il messaggio, rilegge il codice, riscrive una funzione e riprova la compilazione. Evitare una correzione può quindi far risparmiare più token di una sintassi più breve. Tutto il ragionamento →

La formula ha due fattori, e il documento di progetto dice con parole sue che solo il primo è misurato. Il secondo, quanto spesso un programma va riscritto, richiede un modello nel giro, quindi finché un modello non ci viene messo la formula è una regola di progetto e non una regola verificata. La prova che mette un modello nel giro è qui sotto, con le sue regole scritte prima che parta.

Misurato: che cosa rileva il compilatore

heroes mutate prende programmi funzionanti e ci pianta uno sbaglio plausibile alla volta: due argomenti scambiati, un nome scritto male, un caso dimenticato. Poi chiede se il compilatore rifiuta il risultato, due volte: una con tutte le regole, e una con le regole proprie di Heroes spente (--permissive), così la differenza fra le due è quello che aggiungono quelle regole. Un mutante è un programma modificato, e killed vuol dire che il compilatore lo ha rifiutato. Lo strumento dà un tasso per ogni tipo di sbaglio e avverte di non fonderli mai in un unico titolo, perché la misura è il tasso di ciascun tipo.

Letta un tipo alla volta, la tabella mostra tre cose. Alcuni sbagli li rilevano solo le regole proprie di Heroes: un argomento posizionale dove serviva un’etichetta, un nome che ne nasconde un altro scritto uguale. Altri li rilevano già i controlli ordinari, un refuso in un nome o interi mescolati a decimali, e lì le regole non aggiungono nulla e non sono contate a loro favore. E alcuni non li rileva nessun controllo, come un refuso dentro una stringa, e la tabella lo dice. La tabella vera e propria, ogni riga in parole semplici e rieseguita ogni volta che viene pubblicata, sta nel capitolo sugli errori.

Quello che si misura qui è il compilatore: se rifiuta uno sbaglio piantato da uno strumento. Non si misura se un modello fa quegli sbagli, quanto spesso, né se rifiutarli fa risparmiare qualcosa. Quella è la tesi stessa, e la sua prova è la sezione che segue.

Scritto prima di misurare: la prova della tesi

La tesi parla di modelli, quindi la sua prova mette dei modelli nel giro. Il panel di progetto ha fissato le regole di quella prova e l’autore le ha ratificate prima che un modello girasse sui compiti su cui sarà giudicato; le regole sono nel verbale di quella seduta. In parole semplici:

• Compiti tenuti lontani dagli occhi. 40 compiti di programmazione scritti dall’autore, e altri venti di riserva, ciascuno descritto in inglese e giudicato da casi nascosti: entrano argomenti e file, escono l’output stampato e il codice di uscita, e a parte l’unico esempio che il compito mostra, il modello i casi non li vede mai. Ogni compito invita di proposito a uno sbaglio plausibile. I compiti sono sigillati, come mostra la parte che segue, e a nessun modello ne era stato dato uno prima del giro che li valuta, secondo quanto riferisce l’autore.
• Heroes contro sé stesso, con le sue regole spente. La prova non mette Heroes contro un altro linguaggio. Un modello scrive un programma per un compito, e quell’unico programma viene giudicato in tre modi, i tre bracci della prova: strict, con tutte le regole e il messaggio completo del compilatore; brief, le stesse regole e un messaggio breve; e control, il braccio di controllo, con le 27 regole proprie di Heroes spente, ognuna con un significato fissato perché il programma venga costruito ed eseguito lo stesso. Strict contro brief è quanto vale il messaggio; brief contro control è quanto valgono le regole.
• Lo stesso aiuto in ogni braccio. Dopo un rifiuto il modello vede il messaggio del compilatore; dopo un programma che compila, l’output dell’unico esempio che il compito mostra, accanto a quello atteso; i casi nascosti, mai. Al massimo cinque tentativi.
• Tre modi di fallire. Rifiutato dal compilatore; fermato in modo evidente mentre gira; oppure silenzioso, un programma che finisce normalmente e stampa la risposta sbagliata. Quello silenzioso è il fallimento di cui parla la tesi.
• Un solo numero, scelto in anticipo. Quanti programmi sono verdi, la parola del progetto per un programma che passa tutti i casi nascosti, entro il terzo tentativo: il braccio strict meno quello di controllo, su un modello, Claude Sonnet 5.5, con la specifica nel prompt, inviata attraverso l’API di Anthropic con un prompt fisso. Gli altri modelli, Haiku 5.5, Opus 5.5 e Fable 5.1 come tetto con cui confrontarsi, e tutto il resto vengono riportati anch’essi, ciascuno marcato come esplorativo.

Perché un conteggio di programmi funzionanti, se la tesi parla di token: la ragione della seduta è che ciò che la tesi promette a chi legge è un programma che funziona, con il riscontro che avrebbe chi lo usa. Il giro riporta anche, per ogni braccio, i due fattori della formula (i token del programma e quante riscritture ha richiesto) e i token spesi finché un programma funziona; quelli sono esplorativi, e lo dicono dove vengono riportati.

La previsione, come è stata fissata

La preregistrazione è un file solo, prediction.md, scritto nello stesso commit dei compiti sigillati. Seguono le sue parole, copiate da quel file e controllate contro di esso a ogni build del sito. Prima, l’unico numero:

**`green@3`(strict, full message) − `green@3`(control) on `claude-sonnet-5-5` in the `spec`
context**, over the 40 tasks at three samples each (panel 226's R2). `green@k` is *the hidden cases
passed by turn k under the compiler's feedback*. The interval is **the cluster bootstrap over
tasks**, the task the cluster and its three samples never nine independent pairs, 2,000 resamples,
the seed in the run's provenance; the test is **McNemar's mid-p over the discordant pairs**, the
exact conditional p reported beside it and never as the primary's. **The smallest effect of
interest is 10 percentage points**: a confirmed difference under it is reported as confirmed and
small, never as success. Everything else is exploratory and says so where it is reported.

In parole semplici: la quota di programmi strict verdi entro il terzo tentativo, meno quella del braccio di controllo. Accanto va un intervallo in cui è probabile che cada la differenza vera, calcolato ricampionando i compiti 2.000 volte, e un test che conta solo le coppie in cui i due bracci non sono d’accordo. Una differenza sotto i 10 punti percentuali (una differenza fra due percentuali) viene riportata come piccola, mai come un successo. Poi, che cosa vorrà dire ciascun esito:

- **Confirmed**: the bootstrap interval's lower bound is above 0.
- **Falsified**: its upper bound is below 0.
- **Inconclusive**: otherwise. **Rule, the author's choice (1a)**: an inconclusive result is
  published as inconclusive, with its interval as measured. n is not extended once the result is
  seen, since extending a sample after reading it inflates the false positives it then reports;
  the reserve is drawn only to replace a task the canary burns or the adjudication finds
  ambiguous.

Confermata se l’intervallo sta tutto sopra lo zero, smentita se sta tutto sotto, non conclusiva altrimenti. Un risultato non conclusivo viene pubblicato come non conclusivo, e dopo aver visto il risultato non si aggiungono compiti. Poi, che cosa si aspetta l’autore:

- `green@1`: the strict arm **below** the control by **5 to 15 points**, the price of refusing at
  turn 1, before any feedback.
- `green@3`: the strict arm **above** the control by **at least 10 points**, the smallest effect
  of interest.
- The silent rate at turn 3: the strict arm's **at most half** the control's.

The trial on the assistant's ten tasks (measurement 050) is not evidence for or against these:
those tasks tempt no trap, and its arms were level by turn 3 with no discordant pair of 90.

L’autore si aspetta che le regole costino al primo tentativo, il braccio strict da 5 a 15 punti sotto il controllo, e che ripaghino entro il terzo, almeno 10 punti sopra, con al più la metà dei fallimenti silenziosi del controllo. Il numero dei compiti è fissato: 40 compiti, 3 campioni ciascuno, per ogni modello e braccio. Il collaudo qui sotto doveva servire a dimensionarlo, da quanto spesso i bracci non sono d’accordo; entro il terzo tentativo non ha trovato nessuna coppia in disaccordo, quindi la probabilità che la prova rilevi un effetto reale è dichiarata sconosciuta invece di essere calcolata da un numero che non c’è.

Lo stesso file si chiude con il protocollo e i digest di ciò che il giro userà, in un solo blocco: il compilatore, il prompt e la sua struttura, lo strumento, la specifica che il prompt contiene, i modelli e le loro impostazioni. Il report mette ogni giro a confronto con quel blocco, campo per campo, e stampa ogni differenza come una deviazione.

Il sigillo, e come controllarlo

Una prova che un modello ha letto durante l’addestramento misura la sua memoria, non il linguaggio, e questo repository è pubblico, quindi un compito messo in chiaro finirebbe nella prossima raccolta di testi dal web. Per questo i compiti sono nel repository cifrati, con chiavi che tiene l’autore e che non vengono mai scritte su una riga di comando né in un file del repository. Un digest è l’impronta di un testo: basta cambiare un carattere e cambia tutta. Queste due righe sono quelle che il congelamento ha scritto per la suite e per la sua riserva, ciascun digest calcolato dai digest dei compiti che contiene:

suite c24a5b813f6bba6da2f8ca28f63aa15f76a790be5e012e74468f6924f7ad2274 held-out 40 canary

suite b27ea1a9949cd555646f816f73ac5473276156eea7bd5556eeb019a700f77dd4 held-out 20 canary

Quei digest sono calcolati sul testo e sui casi dei compiti, quindi si possono controllare quando l’archivio sarà aperto. Due cose invece si controllano già oggi, da un clone del repository, con i soli file:

$ cd tests/thesis/held-out
$ shasum -a 256 -c suite.enc.sha256 reserve.enc.sha256
suite.enc: OK
reserve.enc: OK
$ git log --format=%H -- prediction.md hashes.txt hashes-reserve.txt suite.enc reserve.enc
a4e09e061130af837a1ed66d61cf247fb10afe4a

Il primo comando controlla i due archivi cifrati contro i digest scritti accanto a loro. Il secondo elenca ogni commit che abbia mai cambiato la previsione, i digest o gli archivi, e ne stampa uno: il commit che li ha fissati. Una modifica successiva a uno qualsiasi di loro stamperebbe una seconda riga; e qualunque risultato, una volta nel repository, si può mettere a confronto con questo commit per vedere quale è venuto prima.

La CI del progetto, i controlli automatici che girano a ogni push su GitHub, ha un job che apre l’archivio dentro una macchina di GitHub, con le chiavi custodite come suoi segreti, e stampa soltanto conteggi e digest, mai il testo di un compito; dove le chiavi non ci sono, come in una copia del repository, dice di non aver attestato nulla invece di passare come se l’avesse fatto. Ogni compito porta inoltre una stringa casuale unica, un canary: prima di un giro a ogni modello si chiede di completarle una per una, e un compito la cui stringa un modello completa esattamente stava nei suoi dati di addestramento, quindi viene sostituito dal compito successivo della riserva. La stessa sonda, fatta girare sui compiti di collaudo prima del congelamento con quattro modelli: 44 sonde, 0 completate.

L’archivio si apre da solo. Entro 30 giorni dalla prima release pubblicata dopo il primo giro su questi compiti, o dal giorno in cui i canary dichiarano bruciata la suite, quale dei due venga prima, l’autore fa il commit delle chiavi e ogni compito diventa leggibile da chiunque. Fino ad allora la chiave viene data a chi la chiede, alla sola condizione di non ripubblicarla, e ogni consegna è annotata nel README della cartella sigillata.

Il collaudo: la prova che lo strumento funziona, non una prova della tesi

Prima del congelamento lo strumento è stato provato su dieci compiti scritti dall’assistente AI che scrive il compilatore. Per una regola del progetto quei dieci compiti non entrano mai in un numero pubblicato: una suite scritta dall’assistente misura quello che l’assistente già si aspetta. Nessuno è stato scritto per invitare a uno sbaglio. Quello che il collaudo può mostrare è che lo strumento misura, quanto costa un giro e dove il protocollo andava riparato. Non può mostrare se la tesi regge, e niente in questa sezione è offerto come prova che regga.

Tre modelli, i dieci compiti, tre campioni ciascuno, la specifica nel prompt; quanti dei 30 programmi di ogni modello e braccio erano verdi al primo tentativo, ed entro il secondo, il terzo e il quinto:

| model | green@1 strict / brief / control | green@2 | green@3, every arm | green@5 | mean turns to green |
|---|---|---|---|---|---|
| Haiku 5.5 | 16 / 16 / 16 | 27 | 28 | 28 | 1.5 |
| Sonnet 5.5 | 18 / 18 / 20 | 29 | 29 | 29 | 1.4 strict, 1.3 control |
| Opus 5.5 | 23 / 23 / 24 | 29 strict, 30 control | 30 | 30 | 1.3 strict, 1.2 control |

• Il braccio strict paga al primo tentativo ed è pari entro il terzo. Una coppia è lo stesso compito e campione giudicato in due bracci, e il braccio strict ne perde una quando il controllo è verde e lui no. Ne ha perse 3 al primo tentativo (Sonnet 5.5 2, Opus 5.5 1), 1 al secondo (Opus 5.5), nessuna al terzo, e non ne ha vinta nessuna a nessun tentativo. L’unico numero che riporterà la prova vera, letto qui su Sonnet 5.5, è +0,0 punti: 29 e 29, e nemmeno una coppia in cui i due bracci non siano d’accordo.
• I fallimenti silenziosi sono stati gli stessi in ogni braccio. Entro il terzo tentativo: 1 contro 1 per Haiku 5.5 e per Sonnet 5.5, 0 per Opus 5.5, gli stessi sbagli in ogni braccio, che nessuna regola nomina. Lo stesso collaudo fatto attraverso la riga di comando di Claude Code invece che con l’API, in una tabella a parte e mai sommata a quella dell’API, ha avuto tutti i suoi 270 campioni verdi entro il terzo tentativo, in ogni braccio.
• Senza la specifica, nessun modello ha scritto un programma che girasse giusto. 0 verdi su 270, ogni modello e ogni braccio, con cinque tentativi e ogni volta i messaggi del compilatore; per ogni modello e braccio, trenta tentativi, l’intervallo probabile va ancora da 0,0 a 11,4%, perché trenta tentativi senza un successo non dimostrano un tasso pari a zero. Le prime risposte hanno scritto il main di qualche altro linguaggio (Sonnet 5.5 ha scritto def main 26 volte su 30), e cinque delle trenta prime risposte di Opus 5.5 dicevano che il linguaggio era loro sconosciuto. Un programma è arrivato in fondo stampando una risposta sbagliata, solo nel braccio di controllo, e il resoconto lo chiama un aneddoto, non un tasso. Quindi le righe qui sopra misurano quello che la specifica insegna, a partire da niente che i modelli si portassero dietro.

Letto come lo legge il resoconto: pari è quello che dieci compiti possono dire. Questi compiti non sono stati scritti per invitare a uno sbaglio; i compiti sigillati, ognuno una trappola, sono dove una differenza potrebbe vedersi. La preregistrazione dice la stessa cosa di sé, nelle ultime righe citate sopra.

Il collaudo è stato fatto due volte. Il resoconto del primo dice, nelle correzioni scritte sotto, che ogni prima richiesta era andata a Haiku 5.5, qualunque modello nominasse: un difetto dello strumento, trovato quando una regola che tiene ogni risposta al modello nominato dalla sua richiesta ha fermato un giro successivo. Il collaudo è stato rifatto con ogni modello nominato, e i numeri qui sopra sono quelli del secondo.

Non ancora su questa pagina: il numero della tesi

Il giro sui compiti sigillati c’è stato. Con le regole e senza, i modelli hanno risolto gli stessi compiti entro tre tentativi, e ogni programma riuscito in un modo è riuscito anche nell’altro. Letto contro la previsione qui sopra, quella che c’era prima del giro, questo risultato è non conclusivo: il giro non sa dire se le regole aiutano. Un risultato non conclusivo si pubblica come non conclusivo, ed è questo. Le cifre dietro, e il resto di quello che il giro ha letto, non sono ancora su questa pagina.

Il sito dirà il numero della tesi alla soglia di pubblicazione del progetto, il passaggio per annunciare una cosa finita, e non prima: con le parole della pagina di quella soglia, dirlo senza averlo misurato pubblica un’opinione con i decimali.

Perché la tesi: le scelte di progetto. Che cosa dice il compilatore quando rifiuta: il capitolo sugli errori. E che cosa Heroes ha escluso: i no.