Scegliere un modello linguistico con cui lavorare in spagnolo non si risolve con una tabella di punteggi. La maggior parte delle comparazioni pubbliche si concentra su benchmark in inglese, e quando trasferisci quelle cifre a un caso reale in castigliano scopri che il modello che vinceva su MMLU perde il filo in una conversazione con modi di dire argentini o mescola terminologia catalana con quella castigliana. Questa guida non ti offre una classifica chiusa: ti offre una procedura di configurazione riproducibile affinché tu stesso misuri quale modello rende meglio nel tuo caso concreto, con prove concrete e soglie decisionali.
Passo 0: definisci cosa significa «rendimento in spagnolo» per il tuo progetto
Prima di toccare un’API o scaricare pesi, scrivi su un foglio quali compiti delegherai al modello. Non è la stessa cosa un classificatore di ticket di supporto e un generatore di riassunti giuridici. Gli assi che davvero discriminano tra modelli in spagnolo sono quattro:
- Comprensione del testo: estrarre risposte da un testo lungo senza inventare dati.
- Fluenza e registro: che il testo non suoni come una traduzione automatica dall’inglese.
- Robustezza dialettale: comportamento di fronte alle varianti rioplatense, messicana, peninsulare o andina.
- Fedeltà alle istruzioni: rispettare i formati (JSON, elenchi, lunghezze) in castigliano.
Un modello può essere eccellente nel primo e disastroso nel terzo. Secondo la documentazione ufficiale di diversi fornitori, le loro valutazioni multilingui aggregano i risultati per lingua, il che nasconde le differenze regionali. Per questo il passo 0 è imprescindibile.
Passo 1: allestisci il banco di prova con i tuoi testi reali
Raccogli tra 20 e 40 esempi tuoi. Vanno bene email di clienti, frammenti della tua base di conoscenza, pagine di prodotto o trascrizioni di chiamate. Etichetta manualmente la risposta attesa in una colonna separata. Questo dettaglio fa la differenza: i benchmark pubblici usano modelli che i modelli hanno visto in addestramento; i tuoi testi no.
Cosa includere obbligatoriamente
- Almeno cinque esempi con code-switching (castigliano con termini in inglese, abituale in ambito tecnologico).
- Due o tre con cifre e unità (date, importi, percentuali) per rilevare errori di formato.
- Un esempio con istruzione negativa: «non menzionare i prezzi» o «rispondi solo con la tabella».
- Testi con accenti, eñe e segni di apertura (¿ ¡). È un test economico che scarta modelli con tokenizzatori scarsi per lo spagnolo.
Passo 2: configura l’ambiente di confronto
Non confrontare i modelli da interfacce di chat diverse: cambiano il system prompt predefinito, la temperatura e il troncamento. Usa un unico script che chiami ogni endpoint con parametri identici. Uno scheletro in Python con la libreria standard di ciascun fornitore è sufficiente.
params = {
«temperature»: 0.2,
«max_tokens»: 800,
«top_p»: 1.0
}
Fissa una temperatura bassa (0,1–0,3) per i compiti di estrazione. Se il tuo caso è creativo, ripeti la batteria con temperatura 0,8 e confronta la stabilità tra le esecuzioni. Un modello che varia molto con lo stesso seed è difficile da integrare in produzione.
L’errore che quasi tutti commettono qui
Confrontare solo la prima risposta. I modelli grandi di solito azzeccano al primo turno e peggiorano quando il contesto cresce. Aggiungi una prova a due e tre turni con contesto accumulato di 3.000–6.000 token in spagnolo. Nella mia esperienza con assistenti di assistenza clienti, il calo più brusco compare proprio lì: il modello inizia a rispondere in inglese o perde l’istruzione di formato quando la cronologia si allunga. Questo limite non emerge in nessuna tabella comparativa pubblica.
Passo 3: definisci metriche che puoi calcolare senza un team di annotatori
Non ti serve un laboratorio. Con tre metriche semplici ottieni un segnale sufficiente:
- Correttezza esatta o per sovrapposizione: per l’estrazione, confronta con la risposta etichettata usando la corrispondenza di parole chiave o la similarità di stringhe.
- Tasso di violazione del formato: percentuale di risposte che non rispettano lo schema richiesto (JSON non valido, elenchi puntati quando si chiedeva prosa).
- Penalizzazione per anglicismi: conteggio dei termini in inglese non giustificati dal dominio. Una soglia ragionevole è più di due ogni 200 parole in testi divulgativi.
Se devi valutare la fluenza, chiedi a due colleghi di ordinare a cieco coppie di risposte. Con 30 coppie ottieni una preferenza abbastanza stabile. Non serve altro per decidere.
Passo 4: esegui la batteria e leggi i risultati con scetticismo
Lancia ogni modello tre volte per esempio e registra la varianza. Un modello con l’85% di correttezza e deviazione alta è peggiore per la produzione di uno con l’80% stabile. Documenta anche latenza e costo per 1.000 token: in spagnolo, la lunghezza media delle risposte è di solito un 10–20% maggiore rispetto all’inglese per lo stesso contenuto, e questo rende più caro l’uso reale anche se il prezzo per token sembra basso.
Cosa aspettarsi in base al tipo di modello
I modelli aperti di dimensioni medie di solito se la cavano bene nella classificazione e nell’estrazione con istruzioni chiare, ma sono deboli nelle sfumature dialettali e nel mantenere un registro formale in testi lunghi. I modelli proprietari grandi tendono a produrre un castigliano più naturale, anche se a volte «correggono troppo» e generano uno spagnolo neutro artificiale che suona strano a un lettore locale. Nessuno vince su tutto. Se il tuo prodotto è per la Spagna, prova esplicitamente con esempi che usano «vosotros» e lessico peninsulare; se è per l’America Latina, evita che il modello imponga «ordenador» dove il tuo utente dice «computadora».
Passo 5: ottimizza il prompt prima di cambiare modello
Molte differenze tra modelli scompaiono con un system prompt ben scritto in spagnolo. Includi esplicitamente la lingua di output, il registro desiderato e un esempio di risposta. I modelli interpretano meglio le istruzioni quando il prompt stesso è nella lingua di destinazione, anche se capiscono perfettamente l’inglese.
Prova questa sequenza: prima ottimizza il prompt con il modello A; poi applica lo stesso prompt al modello B. Se B migliora molto, il problema era il prompt e non il modello. Se B continua a fallire sugli stessi esempi, lì hai un limite reale che giustifica il cambio.
Passo 6: decidi con una matrice, non con un’intuizione
Assegna a ogni candidato un punteggio da 1 a 5 su quattro criteri ponderati secondo il tuo caso: correttezza nella tua batteria, stabilità tra le esecuzioni, costo totale e latenza. Moltiplica per il peso e somma. Un modello che ottiene 4 in correttezza ma 2 in stabilità raramente è la scelta giusta per un flusso automatizzato.
Aggiungi una colonna di «rischio»: se il fornitore non documenta il trattamento dei dati in spagnolo o non offre retenzione zero, quel fattore può pesare più di due punti di precisione. La trasparenza del fornitore sui suoi dati di addestramento è un segnale di qualità, non un ornamento.
Limiti che questa metodologia non risolve
Non valuta i bias culturali in modo sistematico, né copre le lingue co-ufficiali (catalano, galiziano, basco) a meno che tu non aggiunga esempi propri. Non predice nemmeno il comportamento dopo un aggiornamento del fornitore: i modelli cambiano senza avviso e la tua batteria deve essere ripetuta periodicamente. E non sostituisce una revisione umana in domini regolamentati. Se il tuo caso è sanitario o legale, la validazione da parte di esperti è obbligatoria indipendentemente dal punteggio.
Infine, tieni presente che il rendimento in spagnolo non è una proprietà fissa del modello: dipende dal tokenizzatore, dalla lunghezza del contesto e dal dominio. Un modello che brilla nella conversazione generale può fallire nella terminologia tecnica del tuo settore. L’unica comparazione che conta è quella che esegui con i tuoi dati, i tuoi parametri e i tuoi criteri di accettazione. Il resto sono indizi, non verdetti.