Congelare i pesi di un encoder vocale da 305 milioni di parametri e usarlo per trascrivere l'arabo saudita e del Golfo: è la scommessa al centro di uno studio che mette alla prova l'encoder condiviso da Gemma 4 ed EmbeddingGemma 2. La differenza rispetto ai soliti annunci è che il backbone non viene riaddestrato. Un sistema frozen allena soltanto un lettore CTC da 22,6 milioni di parametri su un mix di layer; una variante con adattatori aggiunge 3,1 milioni di parametri low-rank, un lettore ibrido CTC/attention da 41,5 milioni e una decodifica congiunta con un modello linguistico sub-word. Il punto non è il singolo valore di word error rate, ma il rapporto tra costo di adattamento e prestazioni su varietà dialettali poco coperte dai servizi commerciali.

Il confronto con Cohere Transcribe Arabic da 2,07 miliardi di parametri, rieseguito su audio identico, mostra un framework spaccato. Il sistema congelato perde in WER, ma su cinque delle sei condizioni annotate da umani il divario nel character error rate non è statisticamente distinguibile; in compenso gira 3,4 volte più veloce su CPU con decodifica greedy. La versione adattata regge il WER su una chiamata pubblica di customer service saudita (19,20% contro 19,27%) e sul parlato emiratino pulito, è significativamente migliore sul parlato emiratino codificato per telefono, ha un CER significativamente più basso su tutte e sei le condizioni di questi set e supera in WER un riconoscitore da 0,6 miliardi di parametri sottoposto a fine-tuning su SADA. Resta indietro rispetto a Cohere soltanto sul parlato saudita di lunga durata.

Su un campione pubblico di call centre corretto da umani, il sistema si classifica quarto su quindici, dietro tre API commerciali (solo una con distacco statisticamente significativo) e davanti agli altri sistemi self-hosted per stima puntuale. Il decoder congiunto ottimizzato gira a 139 volte il tempo reale su una GPU.

La lettura strutturale è questa: per chi gestisce dati vocali in contesti regolati, l'encoder congelato riduce la superficie da riaddestrare e il numero di parametri da muovere. Non serve portare in house un modello da miliardi di parametri per ottenere una trascrizione accettabile su dialetti specifici: bastano un lettore leggero e, se serve, adattatori low-rank. Cambia il calcolo del TCO: la fase di adattamento non tocca i pesi del backbone, quindi il rischio di regressione su altre varietà è contenuto e gli aggiornamenti possono avvenire per componenti. La velocità su CPU apre spazio per deployment edge o per infrastrutture senza GPU dedicate, anche se il decoder congiunto più accurato richiede una GPU per sostenere 139 volte il tempo reale.

Il framework non è una vittoria piena. Il WER sul long-form saudita resta dietro l'API commerciale e il parlato telefonico codificato è il banco di prova più duro. C'è poi un problema di valutazione: quando i riferimenti vengono creati correggendo le bozze della macchina, il sistema che ha prodotto le bozze risulta favorito. È un effetto noto a chi costruisce dataset annotati, ma qui assume un peso specifico perché può gonfiare il ranking dei sistemi self-hosted se i transcript di riferimento non sono indipendenti.

Per chi valuta deployment on-premise, il trade-off non è più «modello piccolo contro API gigante», ma «quanto adattamento serve per portare il modello nella propria infrastruttura». AI-RADAR analizza questi trade-off su /llm-onpremise. Lo studio, con codice e risultati pubblici, offre un punto di partenza concreto: una via per l'arabo del Golfo che non passa dal cloud.