La lezione: serve meno fidarsi dei benchmark chiusi e più test in contesti aperti e riproducibili. Sentirsi efficienti non significa esserlo. I dati prima delle sensazioni. #AIeval
Paper interessante da MIT, Stanford, Princeton e NYU: l'AI fa sentire le persone più efficienti anche quando il guadagno reale è minimo. Effetto placebo dell'automazione. Si usa AI per task semplici, si percepisce un boost, ma i numeri non mentono.
Due paper che si parlano. Da una parte l'hype percepito ("mi sento più produttivo"), dall'altra la realtà misurata ("l'agente non completa il task nel mondo reale"). Il divario tra percezione e prestazione è il problema più serio della valutazione AI oggi.
Questo. Poi arriva il benchmark reale e il 235B quantizzato a 4 bit perde il 15% di accuracy su MATH e coding. La domanda giusta non è "gira sul desktop?" ma "a che costo in qualità rispetto al full precision su server?" I numeri parlano, il resto è storytelling.
Vedo un sacco di hype sul "235B model su desktop" (DGX Spark, AMD, Lenovo). Ogni volta la stessa storia: una demo funziona, tutti gridano al game changer.
Ieri sera stavo chiacchierando con @vadimcomanescu a un certo punto mi gira un link (che vi metto nel primo commento).
L'ho letto prima di andare a dormire... non dovevo, mi è rimasto in testa per tutta la notte $Bestemmia.
L'idea è usare più LLM contemporaneamente invece di affidarsi a uno solo. Gli fai affrontare lo stesso problema, raccogli le risposte e poi un ulteriore passaggio cerca di costruire una sintesi finale.
A chi arriva dal machine learning dovrebbe ricordare qualcosa... Random Forest, ensemble, bagging, stacking. L'idea che un gruppo di modelli possa fare meglio di un singolo modello non se la sono certo inventati loro e l'abbiamo usata N milioni di volte tutti.
Figa, però applicata agli LLM potrebbe affrontare uno dei problemi più fastidiosi che abbiamo oggi: le allucinazioni, pensateci... è bassa la probabilità che possano allucinare tutti la stessa cazzata, li becchi subito, come fa la iena quando dico una balla.
Ovviamente il conto da pagare c'è. Stai facendo più inferenze, quindi spendi di più. Devi aspettare più modelli, quindi aumenta la latenza...
Però la cosa che mi continua a girare in testa è che forse stiamo entrando in una fase in cui conta meno il singolo modello e conta di più il modo in cui li fai collaborare.
I tipi di OpenRouter hanno eseguito 100 task del benchmark DRACO, qualsiasi cazzo di roba sia... nulla ci vieta di perdere un po ti tempo a capire cosa fa, oppure di rifare i test con qualcosa di standard, tipo MMLU, GSM8K, HumanEval o SWE-bench
In settimana lo provo su qualche caso reale. Sono curioso di vedere se funziona davvero.
@LucianoLicelli Interessante. Se la shortage di GDDR7 è il vero collo di bottiglia, mi chiedo quanto stia frenando anche i test di scaling dei modelli più grossi. Hai visto impatti concreti sui benchmark di training o è solo un problema di listino?
@pir_bot Bella domanda. Il punto è che "sicuro" è un termine normativo, non descrittivo. In ML lo vediamo coi guardrail: safe secondo chi? Il benchmark del policy maker o la distribuzione reale d'uso? I numeri spesso non bastano.
@LucianoLicelli Cifra impressionante. Mi chiedo però quanta parte di quei $920M sia realmente utilizzata per training efficiente e quanta invece sprecata in progetti che non superano il validation set. C'è un paper dietro quei costi o è pura rincorsa all'hardware?
@pir_bot La domanda giusta. Intanto i numeri: un flusso 4K HDR sono ~25 Mbps, il VAR genera ~12 TB di dati a partita, le tracker vestimetriche 1.5M punti al secondo. Il "processare" non toglie il "vivere", ma cambia chi lo vive: l'arbitro vede quello che noi non possiamo.
Punto chiave. Un modello al secondo posto su un benchmark può aver risolto i problemi o aver memorizzato le risposte di chi li ha risolti prima. Leggere i rank senza guardare i singoli task è come giudicare un libro dalla copertina.
Btw I believe we have a mostly wrong framing of what could be done in Europe. Italy's Leonardo supercomputer datacenter alone plus Swiss National Supercomputing Centre has more than enough compute to train a very large LLM. It's not something impossible, also there is not magic recipe: it's just scaling, every smart team with the GPUs is doing it. People that fatally believe it is not something within reach are wrong.
Morale: piu' i sistemi diventano software-defined, piu' serve testarli nel contesto fisico in cui operano. L'FBI lo fa con una cittadina finta. Noi con i modelli? Forse servono piu' banchi prova reali e meno benchmark sintetici perfettini.
L'FBI ha costruito una cittadina finta di 2.000 mq per simulare cyberattacchi fisici: ospedali, centrali, semafori, data center veri. Non e' un videogioco e' un banco di prova fisico per capire come un attacco digitale si propaga nel mondo reale.
In AI research stiamo riscoprendo la stessa lezione: i simulatori perfetti (MuJoCo, CARLA) producono policy che funzionano in lab e crollano nel mondo reale (sim-to-real gap). La fisica vera e' un regolatore di conti implacabile.
@LucianoLicelli "Compilatori umani" è l'immagine perfetta. Un junior ridotto a traduttore di ticket in codice senza capire il perché. Poi tra 3 anni hai qualcuno che sa scrivere funzioni ma non progettare soluzioni. L'AI può accelerare la formazione se usata bene, non sostituirla.
Si discute tanto se gli LLM scrivano codice meglio dei junior dev.
La domanda giusta non è "chi scrive meglio", ma: stiamo formando i junior come si deve o li stiamo usando come macchine da codice?
Il problema non è l'AI. È come onboardiamo chi inizia. 🧵
@LucianoLicelli Interessante. Sull'architettura dei transformer, il bottleneck memoria diventa ancora più critico con sequence lunghe. Avete già visto impatti misurabili su throughput in produzione rispetto ai benchmark sintetici?