Gli articoli di Millebit sono scritti con l’intelligenza artificiale a partire da fonti citate in ogni pezzo. Come lavoriamo
Convergenza su come misurare, verificare e progettare strumenti ML: trasparenza, correttezza e riusabilità
Artificial Analysis finally moves to closed benchmarks (goodbye GDPval-AA), and finds that open weights models are falling further behind than they had previously measured. Take with a grain of salt, but matches the general vibes that we haven't seen a Fable-class open model.
Lean Verified Tokenizers (https://srush.github.io/verified-tokenizer/) Training-inference mismatch kills RL runs, but yet we build messages in Jinja? Prototypes a Lean-verified Rust agent pipeline.
Sasha Rush presenta una pipeline per agenti in Rust con proprietà verificate in Lean per impedire disallineamenti tra training e inference in RL dovuti a tokenizzazione e renderizzazione. Rush, professore a Cornell, punta il dito su un fatto ignorato: messaggi, byte e token non coincidono e piccoli cambi di stringa alterano la tokenizzazione. L’attacco a «costruiamo messaggi in Jinja?» mira modelli di messaggio fragili che riscrivono il passato. Il repo certifica la catena di tokenizzazione e chiude bug invisibili in pretraining e costosi in RL.
Serve trattare la pipeline dei messaggi come codice critico: schema fisso, trasformazioni verificabili, stessa semantica tra byte e token. Così diagnostica e metriche restano affidabili, perché un rollout addestrato sul «ritorno» non viene invalidato da ricodifiche. Il giudizio della redazione: diagnosi giusta e direzione corretta. Rust e Lean non saranno lo standard di tutti, ma l’invariante verificato deve diventare un requisito.
Libghostty progress in the past 6 months. It's amazing that NOTHING IN THIS LIST was true 6 months ago, and now its ALL VERY REAL. I remember bringing up the idea of libghostty 4 years ago and most people saying "but why." I did it anyways. And here we are! Text reproduced in case its easier to read this way: As a reminder, libghostty is the highly portable, embeddable library that provides core terminal emulation, render state, and more. I always felt that a free, high qualty, lightweight, reusable terminal emulation core would benefit the developer world more than any single GUI application. And that is playing out!
Mitchell Hashimoto annuncia che libghostty, libreria di emulazione estratta da Ghostty, esiste. Sposta il focus dal prodotto al nucleo riusabile e conferma l’obiettivo: «una libreria portabile e incorporabile». Il nodo è noto: i core dei terminali sono saldati alla GUI. Qui il motore è separato, con parsing, stato e snapshot. La pagina tecnica avverte: API instabile.
Per IDE e interfacce a riga di comando il terminale diventa dipendenza sostituibile e testabile: con snapshot e formatter si congelano stati e si confrontano in CI. Il giudizio della redazione è favorevole: la separazione tra emulazione e rendering riduce debito tecnico. In produzione serve prudenza perché l’API cambia. Scelta sensata: incapsulare libghostty dietro un adapter e usarlo dove conta, nella testabilità dell’output.
Artificial Analysis passa a «benchmark chiusi» e misura un ritardo maggiore dei modelli a pesi aperti. Mollick pesa perché osserva l’uso reale. Prima AA si appoggiava a set pubblici come GDPval-AA, con rischio di contaminazione e overfitting. Il passaggio contraddice una prassi comoda per la community open e indica che una metrica più severa allarga il distacco.
Per chi sceglie modelli in azienda la conseguenza è netta: con validazioni su test non pubblici il TCO di un modello aperto sale perché servono più ingegneria, pruning di prompt e guardrail. La redazione giudica la lettura di Mollick utile come ricalibrazione, ma nota che i benchmark chiusi spostano il baricentro verso chi controlla i set e rafforzano i fornitori proprietari.