Confronto LLM in polacco: 4 modelli, 12 compiti e risultati

👁 114 letture

I rilasci a pesi aperti disponibili a ottobre 2026 mi hanno offerto l’opportunità perfetta per un approfondito confronto LLM: quattro modelli, gli stessi prompt concisi e una lingua al di fuori del consueto circuito dei benchmark in inglese. Il mio test in lingua polacca si è svolto il 19 ottobre 2026 via l’API. DeepSeek V4.1 Flash 1017 e Nemotron 3.5 Super VL hanno ottenuto un punteggio di 12/12, Muse Spark Open 11/12 e Step 5 Preview 9/12.

Metodo: confronto LLM con verifiche puntuali

Ho inviato 48 richieste in totale, senza ripetere le prove per i singoli compiti. Ho applicato i medesimi prompt e le stesse impostazioni di generazione a tutti e quattro i modelli LLM. Uno script ha poi confrontato il testo restituito con una serie di criteri di controllo. I log salvati contengono il tempo di esecuzione di ogni richiesta, i completion token, il costo, il testo generato e l’esito finale (superato o fallito). Per capire nel dettaglio le dimensioni e le licenze di ciascuna architettura, puoi consultare la mia panoramica sui modelli IA a pesi aperti.

I compiti erano volutamente brevi. Alcuni prevedevano un risultato numerico univoco, mentre i quesiti di grammatica o formattazione ammettevano varianti valide. Definire ogni prova come una domanda a risposta secca sarebbe quindi impreciso. L’obiettivo era verificare se un modello riuscisse a fornire un risultato accettabile entro un budget computazionale condiviso.

• Calcolare 37 per 48 meno 125.
• Fornire il genitivo plurale polacco del sostantivo “przyjaciel”.
• Contare quante volte appare la lettera “ż” in una specifica frase polacca.
• Estrarre identificativo fiscale, importo lordo e data di una fattura inserendoli in un JSON.
• Calcolare il codice di controllo di un codice identificativo polacco partendo dalle cifre e dai pesi forniti.
• Identificare la persona più giovane in un indovinello basato sull’ordine delle età.
• Indicare il giorno della settimana corrispondente all’11 novembre 1918.
• Scrivere esattamente tre parole polacche in minuscolo dedicate all’autunno.
• Indicare il numero delle regioni amministrative della Polonia.
• Convertire 2,5 ore in secondi.
• Correggere una frase polacca contenente errori di ortografia e punteggiatura.
• Continuare la sequenza numerica 2, 6, 12, 20, 30.

L’API poteva instradare richieste successive verso infrastrutture di calcolo differenti. L’impostazione della temperatura a 0 non elimina queste differenze hardware e non sostituisce una serie di prove ripetute nel tempo. I tempi registrati descrivono unicamente le chiamate effettuate quel giorno e non un confronto in laboratorio a parità di macchina.

Risultati e costi del set di compiti

I costi indicati in tabella sono le somme arrotondate dei consumi effettivi registrati durante le sessioni. L’intera esecuzione delle 48 chiamate ha comportato una spesa complessiva registrata di $0,11081294 (circa $0,11). Queste cifre riflettono questo specifico test storico via l’API: non rappresentano preventivi commerciali attuali né stime di spesa per carichi di lavoro differenti.

Il consumo di token per il completamento ha mostrato forti discrepanze: DeepSeek ha totalizzato 1.283 token, Nemotron ne ha registrati 3.868, Muse 12.241 e Step 19.672. Questi conteggi comprendono sia i token dedicati al ragionamento interno, sia il testo effettivamente visibile nella risposta. Un modello può quindi produrre meno testo utile pur esaurendo gran parte del budget a disposizione.

I valori mediani nascondono inoltre tempi d’attesa singoli molto lunghi. Le richieste più lente sono state di 2,4 secondi per DeepSeek, 11,7 secondi per Nemotron, 126,3 secondi per Muse e ben 230,1 secondi per Step. Se sviluppi un’applicazione interattiva, la chiamata fallita più lenta può creare problemi critici, anche se la tipica risposta corretta arriva in una frazione di secondo.

I fallimenti si sono tradotti in risposte vuote

Muse Spark Open ha fallito la conversione delle ore in secondi (2,5 ore equivalgono a 9.000 secondi). Step 5 ha fallito l’istruzione delle tre parole sull’autunno, la domanda sul numero di regioni amministrative e la correzione ortografica. Ciascuno di questi tentativi non riusciti riporta nei log una risposta completamente vuota ed esattamente 6.000 completion token. Nel corso della prova, il budget massimo è andato esaurito interamente nella fase di elaborazione logica prima che il modello potesse generare la risposta finale.

Questa distinzione tecnica è essenziale. Il difetto riscontrato non è stato un calcolo errato restituito all’utente o una frase sgrammaticata, bensì l’assenza totale di una risposta sfruttabile. Poiché i registri via l’API non conservano i passaggi intermedi del ragionamento né il campo finish-reason, non posso ricostruire la deviazione interna che ha condotto il modello a saturare il limite.

Aumentare la soglia dei token o modificare i parametri di ragionamento potrebbe cambiare questi esiti. Non ho inserito queste varianti nel test. Sarebbe tuttavia errato considerare queste opzioni come una soluzione garantita o dare per scontato che il modello avrebbe fornito la risposta esatta ricevendo più tempo.

Perché ho corretto la valutazione ortografica

Il prompt sull’ortografia proponeva la frase sgrammaticata: “Wziąść parasol bo napewno bedzie padać”. Lo script di validazione iniziale richiedeva l’infinito corretto “wziąć” insieme alle forme corrette “na pewno” (sicuramente) e “będzie” (pioverà). Muse, DeepSeek e Nemotron hanno invece generato la frase: “Weź parasol, bo na pewno będzie padać”.

“Weź parasol” è una forma imperativa corretta in lingua polacca che significa “Prendi l’ombrello”. Si tratta di una resa impeccabile dell’intento comunicativo del testo originale. Ho perciò deciso di accoglierla come valida, aggiornando la regola di valutazione e assegnando un punto aggiuntivo a ciascuno di questi tre modelli. La risposta di Step è rimasta vuota al limite prefissato, lasciando invariato il suo punteggio.

Questa rettifica evidenzia un aspetto metodologico rilevante. Un test linguistico può penalizzare ingiustamente risposte legittime se il controllo automatico accetta una sola sequenza rigida di parole. Rendere trasparente questo adattamento dei criteri garantisce un’analisi più onesta rispetto alla semplice sostituzione silenziosa dei voti iniziali.

Gli altri controlli dello script sono stati volutamente tolleranti: l’algoritmo di verifica del JSON estraeva l’oggetto anche se inserito all’interno di un blocco di codice markdown; per il codice di controllo, lo script accettava la presenza della cifra corretta anche senza pretendere che l’output fosse un singolo carattere isolato. Di conseguenza, i punteggi quantificano i compiti risolti nella sostanza e non una conformità cieca a ogni vincolo sintattico accessorio.

Cosa insegna questo test a chi lavora fuori dall’inglese

Il dato pratico più evidente è che DeepSeek V4.1 Flash 1017 e Nemotron 3.5 Super VL hanno portato a termine questo set specifico senza produrre risposte vuote, mentre Muse Spark Open ha perso un punto a causa del limite di generazione. La lezione metodologica fondamentale è che i vincoli sui token di ragionamento e una validazione attenta alle sfumature della lingua sono tanto importanti quanto l’accuratezza pura del modello. Nessuna scheda tecnica commerciale può anticipare questi fattori per il tuo specifico caso d’uso.

Se desideri valutare altre lingue, costruisci prove basate sulla grammatica reale, i nomi propri locali, i formati delle date, la punteggiatura dei decimali e le forme espressive autentiche. Tradurre letteralmente questi compiti rischierebbe di cancellare proprio la particolarità linguistica esaminata: la prova di conteggio sfruttava una lettera specifica dell’alfabeto polacco, mentre il quesito grammaticale si basava sulla flessione morfologica di quella lingua.

• Verifica sempre se la risposta è stata consegnata, se il dato è corretto e se la formattazione è riutilizzabile via software.
• Esamina manualmente gli output linguistici scartati prima di confermare le statistiche finali.
• Traccia sempre i limiti imposti ai token di ragionamento e i parametri di campionamento usati durante i test.
• Ripeti le interrogazioni più rappresentative per misurare la variabilità dell’infrastruttura.
• Tieni distinte le verifiche di pura elaborazione testuale da compiti che coinvolgono scansioni, immagini, audio o video.

Nel corso di questa sessione non ho condotto verifiche in italiano, inglese, tedesco, francese, spagnolo o olandese. Il valore di questa analisi risiede nell’approccio empirico al di fuori dei consueti contesti anglofoni, non nella pretesa che questi risultati siano identici in altre lingue. Progetti complessi di scrittura estesa, traduzione stilistica, coding, tool use e gestione di contesti molto lunghi richiedono benchmark mirati. Se ti interessano i sistemi di dimensioni più contenute, capaci di girare in locale su una singola scheda da gioco, puoi leggere il mio test sulla scrittura non inglese con modelli locali su RTX 4090. Trovi tutti i miei collaudi empirici nell’archivio del Laboratorio di Nitidezza.

FAQ

Uno dei modelli ha restituito risposte fattualmente errate?

Dopo aver rettificato la regola di verifica ortografica, tutte le risposte non vuote hanno superato i controlli del rispettivo compito. Poiché alcuni test ammettevano elementi di contorno (come formattazioni di testo accessorie), questo non implica una perfetta aderenza alle istruzioni formali in senso assoluto.

I modelli LLM open source sono stati provati in locale?

No. Tutte le richieste sono state inviate via l’API. I dati raccolti non misurano le prestazioni di un’inferenza eseguita in locale, l’impatto di una scheda video specifica o la velocità di un checkpoint scaricato sul computer.

Un risultato di 12/12 certifica l’affidabilità per l’uso in produzione?

No. Certifica unicamente il successo su 12 compiti sintetici eseguiti una sola volta ciascuno. Per validare un’architettura in un contesto di produzione reale servono interrogazioni ripetute e scenari su misura per la tua applicazione.

// continua a leggereTest modelli AI settembre 2026: 7 modelli, 4 compiti, risultatiBenchmarkQuattro modelli di IA, un compito: perché scrivo ancora da soloMagazineMureka AI: prezzi, modello V9.5 e confronto con SunoStrumenti IA