Challenging the Abilities of Large Language Models in Italian: a Community Initiative

Di /
stato della ricerca deep learning

Novità CALAMITA per LLM in italiano: di cosa parla il paper e panoramica

Se ti occupi di Large Language Models e ti stai chiedendo quali siano le novità sulla valutazione degli LLM in italiano, questo paper CALAMITA è il punto di riferimento da conoscere. L’idea di fondo è semplice da raccontare ma ambiziosa da realizzare: prendere sul serio l’italiano e costruire un benchmark nativo, ricco e vario, che misuri davvero cosa sanno fare i modelli, invece di limitarsi a tradurre test pensati per l’inglese.

Il paper è firmato da un collettivo molto ampio di autori, guidato da Malvina Nissim, Danilo Croce, Viviana Patti, Pierpaolo Basile e Giuseppe Attanasio insieme a decine di ricercatrici e ricercatori distribuiti su 31 istituzioni, a cavallo tra mondo accademico, centri di ricerca e industria. Le università coinvolte coprono buona parte del territorio italiano – tra cui University of Turin, University of Bologna, University of Trento, University of Pisa, University of Florence, University of Siena, University of Bari Aldo Moro, University of Milano-Bicocca, University of Pavia, Sapienza University of Rome e University of Rome Tor Vergata, oltre a atenei come Kore University of Enna, University of Naples “L’Orientale” e Bocconi University – e una serie di università e centri europei come University of Groningen, University of Geneva, LMU Munich, Universitat de Barcelona, University of the Basque Country (UPV/EHU), Heriot-Watt University, European University Institute, Idiap Research Institute e Instituto de Telecomunicações. A questi si aggiungono importanti centri di ricerca e realtà industriali quali Fondazione Bruno Kessler, ILC-CNR, ISTI-CNR, Expert.ai, Galileo Net, Alpha Test e il gruppo editoriale ANSA, a testimonianza di una collaborazione realmente interdisciplinare e multi-settore.

Gli autori partono da un dato di contesto importante: nei grandi modelli come LLaMA, l’italiano rappresenta meno dello 0,1% dei dati di training. Questo significa che, anche se il modello sembra cavarsela bene in italiano, la sua preparazione è in realtà basata quasi tutta su altre lingue, soprattutto l’inglese. Per valutare seriamente queste capacità non basta quindi prendere benchmark famosi e tradurli: servono dati nativi, creati da persone che conoscono nativamente lingua e cultura.

Da qui nasce CALAMITA, che sta per “Challenge the Abilities of LAnguage Models in ITAlian”. È un’ iniziativa coordinata dall’Associazione Italiana di Linguistica Computazionale (AILC) e coinvolge più di 80 contributors da università, aziende, media e settore pubblico, distribuiti su 31 istituzioni diverse. Non è il classico progetto di un singolo laboratorio: è una campagna nazionale, con accesso al supercomputer Leonardo per eseguire le valutazioni su larga scala.

Il benchmark raccoglie oltre 20 task principali e quasi 100 sotto-task, che coprono competenze linguistiche di base, ragionamento, conoscenza enciclopedica, fairness, factual relevance, traduzione, riassunto, code generation e molto altro. All’interno ci sono sfide molto diverse tra loro: giochi linguistici, esami di scuola guida, detection di misoginia, risoluzione di rebus verbalizzati, generazione di titoli giornalistici, question answering su Wikipedia, comprensione di testi scolastici, text-to-SQL in italiano, e così via.

Per questa prima grande campagna di valutazione, il paper testa quattro LLM open-weight:

  • LLaMA3.1-8B
  • LLaMA3.1-70B
  • Anita-8B, una variante di LLaMA3.1-8B ottimizzata per l’italiano tramite instruction-tuning
  • Minerva-7B, un modello addestrato da zero con un mix 50% italiano e 50% inglese, più del codice.

Lo scopo non è “trovare il vincitore”, ma capire come influiscono la dimensione del modello, la quantità di italiano nel training e il tipo di task. Per farlo, gli autori aggregano i risultati non in un unico punteggio, ma per categorie di abilità (ragionamento, fairness, traduzione, ecc.) e discutono dettagliatamente pattern, punti di forza e debolezze.

A livello di risultati, emergono alcuni messaggi chiave. Il primo è che, in questa fotografia, “bigger is better”: LLaMA3.1-70B è quasi sempre il modello migliore su più di 100 sotto-task, con pochissime eccezioni. Il secondo è più sorprendente: avere più italiano nel training non basta. Anita-8B, che è una versione di LLaMA3.1-8B instruction-tuned su istruzioni in italiano, spesso va peggio della baseline LLaMA3.1-8B generale, ed è competitivo solo in alcune categorie specifiche come fairness e code. Minerva-7B, pur essendo metà italiano e metà inglese nei dati di pre-training, rimane in generale il peggiore dei quattro modelli, con risultati deboli in molte abilità, tranne qualche eccezione in traduzione e in task specifici.

Terzo messaggio: molti task rimangono difficili o addirittura “non risolti”. Nei rebus, per esempio, anche il modello più grande arriva a un’accuratezza di esatta soluzione intorno all’1%, a testimonianza di quanto sia ancora complesso il ragionamento multi-step in italiano. In altre sfide, come l’esame di scuola guida o la generazione di titoli, i modelli mostrano limiti pratici molto concreti, dalle allucinazioni alla scarsa aderenza a vincoli di lunghezza o tono.

Infine, CALAMITA non è pensato come un benchmark “statico”, ma come un rolling benchmark: un processo continuo che permette di aggiungere nuovi task, nuovi modelli e nuove analisi nel tempo, mantenendo vivo il confronto sulle novità nella valutazione degli LLM in italiano. L’idea dichiarata è che questa esperienza possa diventare una guida completa per altre comunità linguistiche che vogliono organizzarsi in modo simile.

Risorse: Github, Paper, Github Project. Non esiste al momento un singolo dataset monolitico “CALAMITA” da scaricare in blocco: i dati sono organizzati come più dataset separati, principalmente su Hugging Face, uno per ciascuna challenge, e sono collegati a partire dal sito del leaderboard e dalla documentazione ufficiale.

Indice

Come funziona il benchmark CALAMITA: metodologia collaborativa e pipeline di valutazione

Se ti stai chiedendo come funziona concretamente il benchmark CALAMITA, questa sezione è la guida pratica alla “macchina” che sta dietro al paper.

Tutto comincia con una call alla comunità. AILC pubblica una chiamata per proposte di challenge: i gruppi interessati inviano una pre-proposal in cui descrivono il task, il tipo di dati, la motivazione scientifica e l’impatto che potrebbe avere sulla valutazione di LLM in italiano. Le proposte selezionate vengono poi sviluppate in challenge complete, con dataset, linee guida, metriche e report.

Ogni team è responsabile di progettare un dataset in italiano (o centrato sull’Italia) che non sia una semplice traduzione di benchmark esistenti, ma che rifletta situazioni realistiche: articoli di giornale, conversazioni, testi scolastici, documenti legali, esami ufficiali, puzzle linguistici, contenuti fact-checked e così via. Molti dataset sono pubblicati su Hugging Face, altri sono accessibili con condizioni specifiche, ad esempio quando contengono materiale sensibile o dati soggetti a restrizioni.

Per partecipare al benchmark, ogni team deve fornire tre ingredienti fondamentali, descritti nel repository GitHub “calamita2024”: un dataset in formato standard (idealmente su Hugging Face), una descrizione chiara del prompting da usare e la definizione delle metriche di valutazione. Il prompting è importante perché quasi tutti i task, anche quelli che sembrano pura classificazione, vengono formulati come generazione di testo: il modello riceve un input testuale e deve produrre una risposta in linguaggio naturale, che poi viene mappata in una classe o confrontata con un target.

Dal lato infrastruttura, CALAMITA costruisce una pipeline centralizzata basata su una fork del famoso lm-eval-harness (ribattezzata CALAMITA-harness). Questa pipeline si occupa di caricare i dataset, applicare i prompt definiti dai team, eseguire i modelli sui nodi del supercomputer Leonardo e calcolare automaticamente le metriche, salvando tutte le uscite in modo riproducibile.

Un aspetto interessante, utile se vuoi capire bene come funziona la valutazione, è che la pipeline non impone un unico tipo di metrica. Per alcuni task si usa l’accuracy, per altri F1, per altri ancora metriche di generazione come ROUGE, BLEU, ChrF o COMET, e talvolta metriche ad hoc definite dagli stessi organizzatori del task. Proprio per questo, il paper insiste molto sulla necessità di metriche “task-representative”, cioè davvero allineate a ciò che il task vuole misurare, invece di schiacciare tutto in un unico punteggio di leaderboard.

Una volta che i modelli sono stati eseguiti su tutti i task, i risultati vengono raccolti e pubblicati in diversi modi. I report di challenge spiegano nel dettaglio cosa è successo task per task; il paper CALAMITA offre una vista di insieme, con analisi aggregate per categoria di abilità; il sito del leaderboard mostra invece la fotografia sintetica, utile per chi vuole rapidamente vedere “come si posiziona un modello” rispetto agli altri.

Risultati CALAMITA nel dettaglio: cosa sanno fare davvero i modelli LLM in italiano

Passiamo ora a una guida completa ai risultati. Come si comportano davvero i modelli sui vari tipi di task? E cosa ci raccontano questi numeri su punti di forza e debolezza degli LLM in italiano?

Per evitare di ridurre tutto a un unico punteggio, gli autori aggregano i risultati per categorie di abilità: ragionamento formale, commonsense, conoscenza fattuale, competenze linguistiche, fairness, traduzione, code, summarization. Dopo aver associato ogni sotto-task a una o più abilità, calcolano sia una media “normale” delle metriche per categoria, sia una media su punteggi normalizzati per vedere chi vince più spesso, indipendentemente dall’unità di misura. Questo doppio sguardo permette di capire sia se un’area è globalmente difficile, sia quanto sono stabili i vantaggi di un modello rispetto agli altri.

Il primo pattern evidente riguarda la dimensione del modello. Se guardiamo i risultati complessivi e aggregati, LLaMA3.1-70B è quasi sempre in testa: su più di un centinaio di sotto-task, solo in pochissimi casi viene superato da un modello più piccolo. Questo vale sia per categorie “classiche” come knowledge e reasoning, sia per ambiti più delicati come fairness sui dati italiani. Allo stesso tempo, le prestazioni assolute non sono affatto “perfette”: in nessuna categoria i punteggi medi superano il 70%, e in summarization e code si rimane spesso ben sotto il 50%.

Più complesso è il discorso su lingua di training e specializzazione. Le due varianti di LLaMA sono modelli massicciamente multilingue, dove l’italiano è una frazione minuscola della mixture di training. Nonostante questo, sono proprio loro a dominare gran parte delle abilità. Anita-8B nasce come adattamento di LLaMA3.1-8B, usando instruction-tuning su istruzioni tradotte e sintetiche in italiano; in teoria dovrebbe essere “più brava in italiano”, ma nei risultati del benchmark questo vantaggio non si vede quasi mai. LLaMA3.1-8B resta nettamente migliore in commonsense, factual, linguistica, reasoning, traduzione e sintesi, mentre Anita-8B mostra qualche segnale positivo solo in fairness e code. Minerva-7B prova ancora un’altra strada: è addestrato da zero con metà testi in italiano e metà in inglese, più una componente di codice, ma usa un corpus totale molto più piccolo rispetto alla famiglia LLaMA. Il risultato è che, salvo eccezioni, si comporta peggio su quasi tutte le abilità, segno che la scala del training conta più del “quanto” italiano c’è nei dati.

Ci sono però delle eccezioni istruttive, che aiutano a capire dove l’italiano nativo può fare la differenza. Nei task di machine translation tra inglese e italiano, per esempio, Minerva-7B si avvicina alle prestazioni dei modelli più grandi e supera Anita-8B, probabilmente grazie alla forte presenza di contenuti bilingui nella sua fase di pre-training e al fatto che le challenge di traduzione GFG e MAGNET sono proprio centrate sulla coppia it-en.

Per vedere meglio cosa succede nel concreto, vale la pena guardare alcuni task emblematici.

Nel task BEEP, basato sull’esame di scuola guida italiano, i modelli devono rispondere a domande su codice della strada, sicurezza, pronto soccorso, assicurazioni e documenti, con valutazioni che imitano l’esame ufficiale. Quando si simula un test completo, creando batterie di 30 domande e richiedendo non più di tre errori per “passare”, i modelli piccoli falliscono sistematicamente, con una media di circa dieci errori a test, e perfino LLaMA3.1-70B fatica a raggiungere un livello affidabile per l’uso reale. Le categorie più generali, come sicurezza stradale e pronto soccorso, risultano più facili, mentre sezioni molto specifiche come documentazione e dotazioni del veicolo mettono seriamente in difficoltà tutti i modelli.

Nel task EurekaRebus, dedicato alla risoluzione di rebus “verbalizzati”, i modelli devono compiere ragionamenti multi-step, rispettare vincoli sul numero di lettere e ricostruire una soluzione finale da frammenti. Anche con suggerimenti sulla lunghezza delle parole, il miglior modello ottiene un’accuratezza di esatta soluzione di circa l’1%, con tutti gli altri praticamente a zero. È un segnale forte sul fatto che, anche quando vediamo performance impressionanti su altre metriche, il ragionamento strutturato in italiano è ancora lontano dall’essere risolto. Forse servono molti più token?

Il task GATTINA testa la generazione di titoli per articoli di divulgazione scientifica da testate come ANSA Scienza e Galileo. Qui i modelli devono cogliere il contenuto dell’articolo, sintetizzarlo in poche parole e rispettare lo stile giornalistico. Le analisi qualitative mostrano che sia i modelli piccoli sia quelli grandi faticano con aspetti come concisione, tono e aderenza al contenuto: spesso producono titoli troppo “espliciti”, rumorosi o addirittura fuorvianti rispetto all’articolo, a volte con sfumature click-bait che gli umani tendono a evitare.

Nel task GITA4Calamita, che valuta il commonsense fisico in italiano attraverso brevi storie, i modelli devono riconoscere conflitti logici (per esempio, cucinare su un fornello spento) e valutare la plausibilità degli stati fisici descritti. In termini di accuratezza complessiva sulla classificazione delle storie, LLaMA3.1-70B supera l’87%, mentre LLaMA3.1-8B si ferma intorno al 72%, Anita-8B scende sotto il 60% e Minerva-7B si attesta poco sopra il 38%. Tuttavia, sulla parte più sottile di “physical state recognition”, anche i modelli migliori mostrano grandi lacune, e le predizioni corrette sono lontane da una copertura completa dei casi impossibili.

Nel task MACID, dedicato al riconoscimento di azioni in contesti multimodali semplificati, i modelli devono individuare la frase “intrusa” rispetto a un set di quattro frasi simili. L’accuratezza complessiva oscilla fra circa 0,27 per Minerva-7B e 0,58 per LLaMA3.1-70B, con valori intermedi per LLaMA3.1-8B e Anita-8B. Le analisi mostrano che i modelli tendono a basarsi molto sulla superficie lessicale (ad esempio sul verbo diverso) più che sul concetto sottostante, segno che la rappresentazione astratta dell’azione è ancora fragile.

Infine, il task Mult-IT, una grande batteria di domande a scelta multipla su cultura generale, logica, matematica e altri ambiti, mostra un’altra faccia dei limiti attuali. Le categorie di cultura generale, geografia e storia raggiungono accuracies intorno al 75%, mentre le domande di logica e matematica scendono verso il 44%, ben sotto la media complessiva. Le analisi di overlap delle risposte rivelano inoltre molti casi in cui tutti i modelli danno la stessa risposta sbagliata, a volte su migliaia di domande, segnalando “blind spot” sistematici condivisi.

In sintesi, i risultati di CALAMITA ci raccontano tre cose fondamentali. Primo, le novità sui modelli più avanzati (come LLaMA3.1-70B) non cancellano il fatto che molti task in italiano restano molto difficili. Secondo, la scala del modello domina l’effetto della specializzazione linguistica: aggiungere italiano con instruction-tuning, da solo, non basta a ribaltare i rapporti di forza. Terzo, la difficoltà è spesso nel task, non solo nel modello: all’interno della stessa categoria, la variabilità di performance tra un dataset e l’altro può essere più grande di quella tra i modelli, segno che la formulazione del task e la definizione delle metriche pesano enormemente.

Guida completa ai concetti chiave per leggere il paper CALAMITA

Per affrontare il paper senza perdersi, è utile chiarire alcuni concetti che tornano continuamente e che vale la pena avere ben in testa prima di iniziare la lettura.

Il primo è la differenza tra dataset e benchmark. Un dataset è una collezione di esempi costruita per un certo scopo; un benchmark è un insieme strutturato di task e metriche usato per confrontare modelli in modo sistematico. CALAMITA non è solo un dataset, ma un benchmark esteso che integra decine di dataset diversi, con una pipeline comune per eseguirli e confrontarli.

Il secondo concetto chiave è quello di taxonomy di abilità. Invece di ragionare solo per task (driver’s license, rebus, fact-checking), gli autori raggruppano ogni sotto-task in categorie astratte come commonsense, reasoning formale, competenze linguistiche, fairness, factual knowledge, translation, summarization, code. Questo permette di porsi domande del tipo: un modello migliora più nel ragionamento o nella correttezza fattuale? C’è correlazione tra fairness e commonsense? Le sfide stilistiche della generazione sono più difficili della semplice classificazione?

Il terzo pilastro è il prompting. Quasi tutti i task di CALAMITA sono formulati in forma generativa: al modello non viene chiesto solo di scegliere “A/B/C”, ma di produrre una risposta testuale che poi viene interpretata come output. Questo rispecchia meglio il modo in cui gli LLM vengono usati nella pratica e consente di valutare non solo l’accuratezza, ma anche artefatti stilistici, allucinazioni, scarsa aderenza alle istruzioni e così via. Per capire le sezioni tecniche del paper, ti sarà utile avere ben chiaro che “classification as generation” è lo schema base adottato quasi ovunque.

Un altro tema fondamentale è quello delle metriche. Il paper insiste sul fatto che usare una singola metrica aggregata sarebbe fuorviante. In traduzione si usano BLEU, ChrF, COMET e BLEURT; in summarization si combinano ROUGE e metriche semantiche come SBERT; nei task di fairness si guardano indicatori più sottili di bias o neutralità; nei puzzle linguistici si usano accuracy e F1 su sotto-componenti specifiche. L’idea chiave è che la metrica deve essere allineata alla natura del task: se stai valutando neutralizzazione di genere, per esempio, ti interessa molto più l’uso corretto di forme inclusive che non la sola somiglianza superficiale rispetto al testo di riferimento.

C’è poi il concetto, centrale nel paper, di native data rispetto a dati tradotti o sintetici. Molti benchmark multilingue recenti si basano su traduzioni automatiche di dataset pensati per l’inglese o su dati generati a partire da prompt in inglese. Il rischio è quello di misurare la qualità della traduzione, o la robustezza a errori di traduzione, più che l’effettiva capacità del modello di muoversi dentro la lingua e la cultura target. CALAMITA fa una scelta diversa: punta su dati nati in italiano, costruiti da annotatori madrelingua per riflettere casi d’uso realistici, dalla scuola guida alla satira politica, dalla cronaca scientifica alle sfumature di misoginia implicita.

Infine, un concetto organizzativo ma molto importante è quello di rolling benchmark. A differenza di molte campagne “one-shot” (un’edizione, qualche risultato e poi il silenzio), CALAMITA è pensato come processo continuo: i risultati di oggi sono la base su cui costruire nuovi task, nuove metriche, nuove ondate di modelli. Nel leggere il paper, conviene quindi vederlo non solo come fotografia di un momento, ma come versione 1.0 di una guida completa alla valutazione di LLM in italiano, destinata a evolversi.

Quiz: metti alla prova la tua comprensione di CALAMITA

Perché è nata l’iniziativa CALAMITA?

La motivazione principale nasce dal fatto che la valutazione sistematica degli LLM oltre l’inglese è ancora molto indietro rispetto al boom di questi modelli. L’italiano è poco rappresentato nei dati di training dei grandi LLM, e per anni ci si è affidati a benchmark tradotti o sintetici che non catturano bene la realtà della lingua e della cultura italiana. CALAMITA nasce quindi per colmare questo vuoto, fornendo un benchmark nativo, ricco e realistico, e al tempo stesso un quadro metodologico condiviso per la comunità italiana di NLP.

Quanti modelli vengono valutati e cosa li differenzia?

Nel paper vengono valutati quattro LLM open-weight: LLaMA3.1-8B, LLaMA3.1-70B, Anita-8B e Minerva-7B. LLaMA3.1-8B e 70B sono modelli multilingue di grandi dimensioni, con poco italiano nel training ma tantissimi token complessivi. Anita-8B è una variante di LLaMA3.1-8B instruction-tuned su istruzioni in italiano, mentre Minerva-7B è un modello addestrato da zero con un mix bilanciato di testi in italiano e inglese più codice, ma su un corpus complessivo più piccolo. Ciò che li differenzia è quindi la scala e la strategia di esposizione all’italiano.

Cosa scopre il paper sul rapporto tra dimensione del modello e prestazioni?

La risposta breve è che, in questo scenario, la dimensione del modello vince quasi sempre. LLaMA3.1-70B domina la maggior parte dei task e delle categorie di abilità, superando sistematicamente i modelli più piccoli, con poche eccezioni marginali. Allo stesso tempo, le prestazioni assolute non sono tali da chiudere il problema: molti task rimangono difficili, e in alcune aree, come summarization e code, le medie di categoria restano sotto il 50%.

L’italiano nel training migliora sempre le performance sui task in italiano?

No, ed è uno dei risultati più interessanti. Anita-8B, pur essendo specificamente migliorata per l’italiano tramite instruction-tuning, si comporta spesso peggio della baseline LLaMA3.1-8B su abilità come reasoning, factual knowledge, linguistica, traduzione e summarization, ed è solo leggermente migliore in fairness e code. Minerva-7B, nonostante abbia metà dei dati di pre-training in italiano, va generalmente peggio di tutti, tranne in alcuni task di traduzione e in casi particolari come ECWCA. Il messaggio è che scala, qualità e diversità dei dati contano almeno quanto (se non più di) la mera quantità di italiano.

Che tipo di task dimostrano che gli LLM sono ancora molto lontani da capacità “umane”?

Due esempi emblematici sono EurekaRebus e BEEP. Nei rebus verbalizzati, anche il modello più grande ottiene accuracies di esatta soluzione intorno all’1%, a dimostrazione che il ragionamento multi-step con vincoli formali è ancora un tallone d’Achille. Nel task BEEP, che simula l’esame di scuola guida, i modelli piccoli falliscono sistematicamente, e perfino LLaMA3.1-70B non garantisce un tasso di “promozione” sufficiente per un uso affidabile nella pratica.

Perché gli autori insistono tanto sulle metriche “task-representative”?

Poichè in un benchmark così eterogeneo, usare una singola metrica o un punteggio aggregato rischia di nascondere proprio gli aspetti più interessanti. Un task di riassunto ha esigenze molto diverse da un compito di fact-checking o da un puzzle linguistico; ridurre tutto a una sola cifra penalizzerebbe alcuni task e renderebbe impossibile capire cosa funziona e cosa no in dettaglio. Le metriche “task-representative” permettono di valutare non solo se la risposta è tecnicamente corretta, ma se rispecchia davvero lo scopo del task, che si tratti di neutralizzazione di genere, aderenza a vincoli di lunghezza, correttezza logica o sensibilità culturale.

Cosa significa che CALAMITA è un “rolling benchmark”?

Significa che CALAMITA non è pensato come un esperimento isolato, ma come un processo continuo. Nuovi task possono aggiungersi nel tempo, nuovi modelli possono essere valutati usando la stessa pipeline, e la comunità può aggiornare metriche, analisi e criteri man mano che emergono nuove esigenze e nuove novità nel mondo degli LLM in italiano. Il paper rappresenta la prima grande “edizione” di questo processo, ma non l’ultima.

Studi collegati e altre novità sulla valutazione degli LLM multilingue

Per capire fino in fondo la portata di CALAMITA, vale la pena collocarlo nel panorama più ampio dei benchmark per LLM.

Storicamente, la valutazione dei modelli di linguaggio è stata guidata da benchmark come GLUE e SuperGLUE, pensati per testare competenze linguistiche generali in inglese, e da suite come XTREME, che portano alcune di queste idee in contesti multilingue. Più recentemente, benchmark come MMLU e AGIEval hanno puntato su domande in stile esame, misurando la conoscenza di dominio e le capacità di problem solving attraverso test standardizzati.

Nel mondo italiano, una tradizione importante è quella di EVALITA, la serie di campagne di valutazione su molteplici task di NLP, dalla sentiment analysis al parsing, che ha fatto da “palestra” per la comunità molto prima dell’era degli LLM. CALAMITA si inserisce idealmente in questa tradizione, ma ne aggiorna profondamente il paradigma, spostando il focus dalla costruzione e valutazione di modelli specifici per singoli task alla valutazione sistematica di LLM generali su una grande varietà di abilità.

Altri lavori recenti hanno esplorato benchmark specifici per lingue diverse dall’inglese, come lo spagnolo o il basco, o hanno proposto metodi per costruire benchmark multilingue tramite traduzione o generazione sintetica. Molti di questi approcci, però, faticano a catturare aspetti sottili come le differenze culturali, la pragmatica, la figuratività o fenomeni come la misoginia implicita, che sono fortemente radicati nel contesto socio-culturale della lingua.

In questo quadro, CALAMITA porta alcune novità importanti. Prima di tutto, è fortemente comunitario e distribuito: i task nascono da gruppi diversi, con prospettive e competenze differenti, e vengono coordinati sotto un’unica cornice metodologica. Questo riduce il rischio di avere un benchmark “sbilanciato” verso le preferenze di un singolo gruppo di ricerca e aumenta la copertura di domini applicativi reali.

Secondo, CALAMITA insiste sul valore dei dati nativi. Molti dei task più interessanti, come VeryfIT per il fact-checking, PejorativITy per il linguaggio misogino, GATTINA per i titoli scientifici o BEEP per l’esame di scuola guida, sarebbero difficili da ottenere tramite mera traduzione di dataset esistenti: nascono da contesti italiani specifici, con fonti autorevoli italiane (fact-checker, ministeri, testate giornalistiche, materiali scolastici).

Terzo, CALAMITA combina la dimensione benchmark con quella di framework operativo. Grazie a un’infrastruttura come CALAMITA-harness e all’accesso a risorse di calcolo nazionali, diventa relativamente facile testare nuovi modelli su tutta la suite di task, mantenendo la riproducibilità e l’allineamento metodologico. Questo è particolarmente rilevante in un mondo in cui emergono continuamente nuove release di LLM, dove sapere “come funziona CALAMITA” e come collegare la propria ricerca a questo benchmark può fare la differenza in termini di comparabilità dei risultati.

Guardando al futuro, il messaggio del paper è chiaro: se vogliamo che i sistemi basati su LLM funzionino davvero bene in italiano, non possiamo limitarci ad aspettare che arrivino modelli “più grandi e più generali”. Servono iniziative come CALAMITA, che costruiscano dati nativi, metriche intelligenti e processi comunitari per valutare in modo serio e continuativo le capacità dei modelli. Questo paper è, in pratica, la guida completa alle novità sulla valutazione degli LLM in italiano, e un blueprint che altre comunità linguistiche possono usare per seguire la stessa strada.

Torna in alto