Il linguaggio di un modello non è il linguaggio di una società

Un modello multilingue non è equo solo perché la sua interfaccia elenca molte lingue. La copertura linguistica è una questione istituzionale, culturale e di...

Il linguaggio di un modello non è il linguaggio di una società

Sedici lingue sono un punto di partenza, non un verdetto

Il 22 luglio 2026, la Direzione generale della Traduzione della Commissione europea ha pubblicato EU MMLU, un benchmark pensato per testare i modelli linguistici di grandi dimensioni nei contesti linguistici e culturali europei. La pubblicazione è stata insolitamente onesta riguardo al divario che cercava di colmare. Molti dataset di valutazione sono stati costruiti in inglese. Un modello può ottenere buoni risultati in quel contesto e comportarsi comunque male in francese, ungherese o maltese. Il nuovo dataset inizia con sedici lingue ufficiali dell'UE, sette aree tematiche e più di mille domande tradotte e riviste da quasi 250 studenti provenienti da 21 università europee.

La parte più importante di quell'annuncio non è l'elenco delle lingue. È la frase che lo accompagna: il comportamento di un modello non può essere dedotto dalla lingua in cui sembra più fluente. Dovrebbe essere ovvio. È anche l'assunto alla base di una quantità notevole di appalti, ricerca e dibattito pubblico. Parliamo ancora di un modello linguistico come se avesse una sola mente, per poi chiedergli di indossare lingue diverse come fossero cappotti. Il cappotto cambia. La mente, le prove, i punti ciechi e il contesto sociale vengono trattati come elementi stabili.

Non lo sono. La lingua è il punto in cui una persona incontra un'istituzione. Trasporta i termini di un beneficio, il tono di un ricorso, la differenza tra consiglio e istruzione, la forma di una battuta, il nome di un luogo e i presupposti di un modulo. Quando un sistema gestisce una lingua meglio di un'altra, non produce semplicemente una frase meno elegante. Può cambiare chi viene compreso, chi viene creduto, chi può contestare un risultato e chi rinuncia prima di trovare la porta giusta.

La conclusione pratica è chiara. L'IA multilingue non è una funzione di traduzione da aggiungere dopo la costruzione del modello. È una questione di accesso, prove e autorità. Il lavoro europeo sulle tecnologie linguistiche, sui dati linguistici e sulla valutazione multilingue è prezioso perché tratta il problema come infrastruttura. Il lavoro è ancora incompleto. Un benchmark non è una garanzia, e sedici lingue non sono tutta l'Europa. Ma la direzione è giusta: smettere di chiedersi se un modello parla una lingua e iniziare a chiedersi cosa può fare in sicurezza in quella lingua, per chi, a quali condizioni, con quali prove.

La copertura linguistica è credibile solo quando le affermazioni su fonte, contesto, revisione e servizio restano collegate.

La lingua è un confine di accesso

L’Europa ha fatto della lingua un fatto istituzionale, non una preferenza privata. L’articolo 22 della Carta dei diritti fondamentali stabilisce che l’Unione rispetta la diversità culturale, religiosa e linguistica. La politica linguistica e tecnologica della Commissione affianca a tale obbligo un monito pratico: le tecnologie linguistiche richiedono un uso imparziale perché diritti e principi possano sopravvivere al contatto con il software. Non si tratta di impegni decorativi. Descrivono il confine che un sistema pubblico incontra quando un residente non riesce a leggere un avviso, non capisce perché sia stata presa una decisione o non può esprimere un fatto rilevante nella lingua in cui quel fatto esiste.

Questo confine è facile da non notare quando un team misura soltanto se una traduzione è stata prodotta. Una frase può arrivare nella lingua richiesta e fallire comunque la persona che ne ha bisogno. La traduzione potrebbe appiattire una distinzione giuridica, modificare il livello di cortesia che segnala se un funzionario sta chiedendo o ordinando, oppure usare un termine che ha un significato quotidiano ma anche un significato specialistico in un determinato servizio. Un riconoscitore vocale potrebbe trasformare una pronuncia regionale in una parola diversa. Un riassuntore potrebbe eliminare la qualifica che porta con sé la responsabilità. La scorrevolezza non ci dice se la transazione è rimasta intatta.

Immaginiamo un servizio informativo pubblico che offre la stessa spiegazione sui requisiti di ammissibilità in olandese, francese e in una lingua regionale. Le prime due modalità sono state addestrate e testate con materiale amministrativo, lettere di ricorso e conversazioni con esperti del settore. La terza modalità ha un’ottima prosa generale, ma nessuna valutazione significativa sulla terminologia propria del servizio. Una dashboard può riportare tre etichette linguistiche verdi. I residenti non ricevono tre servizi equivalenti. Un gruppo riceve una spiegazione; un altro riceve un’approssimazione; il terzo riceve un’incertezza rifinita che sembra ufficiale perché ha il logo giusto.

L’esempio è volutamente ipotetico. Non è un’affermazione su un particolare comune o fornitore. Il suo scopo è mettere in luce un errore di progettazione. Il supporto linguistico viene spesso conteggiato a livello di interfaccia, mentre l’obbligo reale si colloca più a valle nella catena. Il sistema deve sapere quali dati supportano la lingua, quali attività sono state valutate, chi ha esaminato gli errori, come gli utenti possono correggerli e quando la modalità deve rifiutarsi di rispondere. Se questi dettagli mancano, il selettore di lingua è una promessa senza contratto.

La mappa di un modello non è la mappa della società

Un modello apprende da una mappa della lingua che i suoi dati e il suo processo di addestramento rendono disponibile. Una società vive in una mappa molto più ampia. La mappa del modello contiene i testi, le registrazioni, le etichette, le traduzioni e le valutazioni che sono stati ammessi. La mappa della società contiene persone che parlano in modo diverso a casa e al lavoro, cambiano registro senza annunciarlo, prendono in prestito parole oltre confine, usano una lingua minoritaria in un’istituzione locale o scrivono in un sistema di scrittura che un benchmark non ha incluso. Una mappa è un artefatto tecnico. L’altra è un insieme di vite, diritti e obblighi.

La differenza conta anche per le lingue con grandi corpora pubblici. Una lingua nazionale non è un unico flusso uniforme. Moduli governativi, decisioni giudiziarie, linguaggio scolastico, consigli sanitari, messaggi di testo e una conversazione tra vicini usano vocabolari diversi e diverse tolleranze all’ambiguità. Un modello può essere competente nella prosa giornalistica e debole in un ricorso per prestazioni. Può gestire l’ortografia standard e avere difficoltà con un dialetto. Può tradurre una frase letterale e non cogliere il significato pragmatico veicolato da una formula di cortesia. Definire l’intera lingua come supportata nasconde il confine tra le attività.

La tecnologia linguistica ha quindi bisogno di un vocabolario più preciso. Dobbiamo distinguere la presenza di una lingua nei dati di addestramento dalla valutazione di un compito in quella lingua. Dobbiamo distinguere una traduzione di riferimento da un elemento di test scritto in modo indipendente. Dobbiamo distinguere la lettura di una scrittura dalla comprensione del registro di una comunità. Dobbiamo distinguere la capacità di un sistema di generare testo dalla sua autorità di consigliare, classificare o decidere. Ogni distinzione è un piccolo pezzo di documentazione. Insieme impediscono che un'ampia affermazione venga assemblata a partire da prove ristrette.

C'è una ragione istituzionale per essere rigorosi. I servizi pubblici non sono liberi di scegliere la lingua più semplice e definire efficiente il risultato. Una banca, un ospedale, un datore di lavoro o un fornitore di software possono avere obblighi legali diversi, ma ciascuno decide quanto attrito una persona deve assorbire per essere compresa. Un percorso multilingue che fallisce in silenzio trasferisce il costo all'utente. L'utente deve trovare un traduttore, ripetere una storia, accettare un risultato peggiore o abbandonare il processo. Il sistema riporta il successo perché ha restituito una stringa. La persona sperimenta l'esclusione con una grammatica eccellente.

Cosa significa realmente "risorse limitate"

Le risorse limitate sono spesso trattate come una proprietà di una lingua, come se alcune lingue arrivassero alla porta del modello con meno risorse e dovessero scusarsi per l'inconveniente. È più utile trattarle come una proprietà di un compito, di un set di dati e di una decisione di governance. Una lingua può avere materiale letterario sostanziale ma pochi dati etichettati per un classificatore medico. Può avere testo parallelo ma quasi nessuna registrazione vocale. Può essere rappresentata in un corpus senza i diritti o i metadati necessari per una particolare implementazione. Può avere dati in una forma standard mentre le persone interessate usano una varietà regionale.

La politica di tecnologia linguistica della Commissione europea lo afferma chiaramente. I dati linguistici sono il fondamento degli strumenti linguistici e le competenze umane sono una parte necessaria di uno sviluppo di successo. Un modello ha bisogno di testo o parlato, algoritmi, potenza di calcolo e persone che comprendano la lingua e il dominio. Rimuovere uno qualsiasi di questi elementi cambia il sistema. Più potenza di calcolo non può creare una conversazione mancante. Più esempi non possono riparare un'etichetta che confonde due categorie legali. Un modello più grande non può decidere quale fonte una comunità considera autorevole.

Il lavoro con risorse limitate non è quindi un invito ad abbassare lo standard. È un motivo per rendere lo standard visibile. Se un compito ha poco materiale di valutazione, dillo. Se una metrica è instabile per una coppia di lingue, segnala l'instabilità. Se la revisione umana è stata limitata, identifica l'ambito della revisione invece di presentarla come una garanzia generale. Se un percorso è utile per la bozza ma non per le decisioni, metti quel confine dove un acquirente e un utente possano vederlo. La scarsità onesta è più sicura di un silenzio che sembra abbondante.

Il panorama linguistico europeo rende questa disciplina inevitabile. La Commissione descrive un insieme complesso di lingue ufficiali, regionali e minoritarie e ha sostenuto iniziative come la European Language Grid, l'agenda European Language Equality e lo Spazio comune europeo dei dati linguistici. Questi progetti non sono una soluzione unica e non dovrebbero essere descritti come tale. Sono pezzi di un ecosistema in cui dati, strumenti, diritti, competenze e istituzioni pubbliche possono incontrarsi. La forma istituzionale è importante quanto il modello al suo interno.

Il livello dei diritti arriva prima del benchmark

È forte la tentazione di parlare dei modelli linguistici come se la lingua fosse un canale di input neutro. Non lo è. L'input può contenere dati personali, una caratteristica protetta, un toponimo locale, un dettaglio medico o la registrazione di una persona che chiede aiuto. La fonte può essere protetta da diritto d'autore o soggetta a una riserva. Un output tradotto può essere usato in una decisione anche se il percorso di traduzione non è mai stato valutato per quel contesto. Il problema linguistico del modello è già un problema di diritti prima ancora che qualcuno scelga un punteggio.

Le linee guida della Commissione sulla tecnologia linguistica collegano i dati linguistici sia al diritto d'autore sia alla protezione dei dati. Questo collegamento dovrebbe cambiare il modo in cui i team progettano le pipeline. Un corpus non è semplicemente un insieme di frasi. Ha un'identità di origine, condizioni di acquisizione, stato di licenza o di diritti, metadati su lingua e scrittura, segnali di qualità, finalità e regole di conservazione. Se un elemento viene corretto o ritirato, l'organizzazione deve sapere quali artefatti derivati sono stati interessati. Altrimenti un modello successivo può ripetere un vecchio errore con la sicurezza di un modulo appena stampato.

È qui che la provenienza dimostra il suo valore. La provenienza non è una nota a piè di pagina che dice che i dati provengono da qualche parte. È l'insieme di relazioni che consente a un revisore di passare da un risultato alle prove pertinenti e viceversa. Nel lavoro multilingue, queste relazioni devono sopravvivere a traduzione, trascrizione, normalizzazione, segmentazione e valutazione. Una frase tradotta per un benchmark non è intercambiabile con la frase di partenza. Un'etichetta creata da un revisore non è intercambiabile con un'etichetta ereditata da un'altra lingua. La trasformazione fa parte delle prove.

Non esiste l'obbligo che ogni utente veda un registro di ricerca. Esiste l'obbligo che un'organizzazione possa rispondere a una domanda seria quando arriva. Quale versione della risorsa linguistica è stata usata? Quale compito supportava? Quali esperti linguistici l'hanno revisionata? Cosa ha fatto il sistema quando la confidenza era bassa? Un reclamo è stato trattato come una correzione a una singola risposta o come una possibile classe di errori? Il percorso linguistico diventa affidabile quando queste domande hanno responsabili e registrazioni.

L'Europa sta costruendo infrastrutture linguistiche, non solo pulsanti di traduzione

La descrizione della Commissione europea dello Spazio comune europeo dei dati linguistici è utile perché non riduce il progetto a un rilascio di modelli. L'obiettivo è una piattaforma e un mercato per raccogliere, condividere e riutilizzare dati linguistici multilingui e multimodali, mantenendo al contempo il controllo nelle mani delle organizzazioni e delle persone che generano i dati. Questa formulazione indica un'idea diversa di progresso. Il lavoro non consiste solo nel produrre una frase migliore. Consiste nel rendere le risorse linguistiche scopribili, consapevoli dei diritti, riutilizzabili e responsabili nell'amministrazione pubblica, nella ricerca e nell'industria.

La European Language Grid ha compiuto una mossa simile portando strumenti e risorse di tecnologia linguistica specializzata in un catalogo comune. Un catalogo non dimostra che ogni servizio funzioni per ogni compito. Rende però più facile ispezionare una dipendenza nascosta. Un team può chiedere cosa fa lo strumento, quale lingua supporta, da dove provengono i suoi dati e se la licenza corrisponde all'uso previsto. È infrastruttura poco appariscente. È anche il modo in cui un continente con molte istituzioni evita di ricostruire la stessa capacità linguistica in stanze scollegate.

L'infrastruttura conta perché la coda lunga del lavoro linguistico non si risolve con un singolo modello di punta. Un ente pubblico può aver bisogno di riconoscimento vocale per un accento regionale, estrazione terminologica per un dominio specializzato, memoria di traduzione per la legislazione, riconoscimento di entità nominate per i toponimi, o un modo per confrontare due versioni di un documento senza perdere i segni diacritici. Un'azienda può aver bisogno di una distribuzione locale perché il materiale non può lasciare la sua giurisdizione. Un gruppo di ricerca può aver bisogno di un dataset con una provenienza chiara piuttosto che di un altro punteggio anonimo.

In questo approccio c'è una scelta politica silenziosa. Dati e strumenti sono trattati come capacità che l'Europa dovrebbe poter ispezionare e plasmare, non come un servizio che arriva da un altrove invisibile. Questo non significa che i sistemi europei siano automaticamente buoni o che i fornitori commerciali altrove non possano essere utili. Significa che una lingua è troppo importante per restare priva di un vocabolario pubblico per i suoi dati, le sue lacune e la sua valutazione. La sovranità comincia dal sapere ciò che il sistema non può vedere.

Tradurre non è un semplice passaggio neutro

La traduzione è spesso collocata tra due componenti in un diagramma di architettura, come se fosse un tubo che trasporta il significato da un lato all'altro. La traduzione reale è una sequenza di decisioni. Quale testo di partenza è autorevole? Quali parole devono rimanere esatte? Quale ambiguità va preservata? Quale riferimento culturale richiede una spiegazione? Quale registro è appropriato per un avviso pubblico? Quale entità non deve essere tradotta? Quale data, numero o unità di misura va resa secondo la convenzione del lettore? Un modello può prendere queste decisioni rapidamente. La velocità non le rende invisibili.

Si consideri la differenza tra tradurre una frase sul meteo e tradurre un avviso su una scadenza. Nel primo caso, un piccolo errore di stile può essere fastidioso. Nel secondo, un numero o un verbo modale può alterare ciò che una persona crede di dover fare. Il modello linguistico sottostante può avere lo stesso budget di token e la stessa visualizzazione di confidenza. Le conseguenze sociali non sono le stesse. La valutazione deve quindi seguire il compito, non fermarsi a un punteggio linguistico generale.

La pagina della Commissione sul proprio uso delle lingue illustra il punto senza drammatizzare. La traduzione automatica può fornire un'idea di base, ma qualità e accuratezza variano notevolmente da un testo all'altro e tra coppie di lingue. È una frase pubblica utile perché rifiuta di trasformare un servizio in un oracolo. Dà al lettore il permesso di usare una traduzione come orientamento, conservando al contempo una ragione per cercare una versione umana o autorevole quando la posta in gioco lo giustifica.

Per i team di prodotto, l'implicazione è un insieme di percorsi espliciti. Una traduzione a basso rischio può essere restituita direttamente con uno stato chiaro. Un percorso legale o medico può richiedere una revisione umana, un collegamento alla fonte o un rifiuto. Una bozza interna può affiancare la fonte alla traduzione. Un'interfaccia vocale può ripetere un nome critico e chiedere conferma. La scelta non è tra automazione totale e nessuna automazione. È tra una pipeline che dichiara i suoi passaggi di consegna e una che li nasconde dietro un paragrafo scorrevole.

La frase sopravvive, la situazione no

I modelli lavorano su rappresentazioni. Le società lavorano su situazioni. Quando una traduzione passa dall'una all'altra, piccoli dettagli possono diventare l'intero significato. Una frase educata in una lingua può suonare evasiva in un'altra. Un termine che distingue un diritto statutario da un servizio discrezionale può essere ridotto a una parola generica per aiuto. Un idioma può essere tradotto letteralmente e diventare senza senso, o tradotto liberamente e perdere il riferimento che identifica una comunità. Nessuno di questi fallimenti richiede un output assurdo. La risposta pericolosa è quella che sembra ordinaria.

Il rilascio di EU MMLU tocca esattamente questo territorio. I suoi criteri di qualità chiedono che i benchmark multilingue testino non solo significato e difficoltà, ma anche idiomi, umorismo, riferimenti culturali, formati di date e numeri e differenze nel tono o nella cortesia attesi. Questo è un importante ampliamento dell'obiettivo di valutazione. A un modello linguistico non si chiede solo se può produrre una frase grammaticalmente corretta. Gli si chiede se la frase appartiene alla situazione in cui una persona agirà sulla base di essa.

The mention of humour is not an invitation to make the benchmark entertaining. It recognises that humour is a stress test for context. A literal translation can preserve words and destroy the joke. A culturally adapted translation can preserve the effect while changing the reference. In a public information service, the same mechanism appears without laughter. A proverb, a local place-name or a formal greeting can signal who is speaking and what relationship the message creates.

When teams say that a model understands a language, they should ask which layer they mean. Does it recognise the script? Segment words correctly? Identify entities? Translate the proposition? Preserve the legal force? Follow a local convention? Keep the speaker’s level of certainty? Handle a non-standard spelling? Reply in the right register? These are separate capabilities. A single label called multilingual conceals the work required to establish each one.

Why evaluation must travel with language

Evaluation is often added at the end because teams want a number to attach to a model. Multilingual systems make that order impossible. The test data determines what counts as an error. The language determines how a sentence can fail. The domain determines which failure matters. The user determines whether the system’s answer is an aid or an obstacle. Evaluation has to travel with all four.

The European research paper Towards Multilingual LLM Evaluation for European Languages demonstrates the scale of the problem. The authors assess 40 language models across 21 European languages, examine translated versions of five widely used benchmarks and publish a framework that includes EU20-MMLU, EU20-HellaSwag, EU20-ARC, EU20-TruthfulQA and EU20-GSM8K. The paper does not claim that translating an existing benchmark automatically makes it fair. It treats translation services, benchmark construction and cross-language comparability as things to investigate.

That is the right posture. A translated test item can inherit a difficulty change, a cultural assumption or a clue that did not exist in the original. A model may score higher because the translated wording makes the answer easier, not because the model became more capable. It may score lower because a grammatical construction is unnatural in the target language, even though the underlying reasoning is sound. Both outcomes are evidence about the test as well as the model.

Human review remains necessary, but human review also needs a contract. Who reviewed the item? Were reviewers native speakers, domain specialists, or both? Did they review isolated sentences or the task in context? Were disagreements recorded? Did the benchmark preserve alternate acceptable answers? A language expert can tell us that a phrase is wrong. A domain expert can tell us why the wrongness changes a decision. A credible evaluation often needs both and must say which one it had.

The point is not to make every system pass an endless examination before anyone can use it. It is to prevent a narrow test from being mistaken for a wide claim. If a model has been evaluated on short factual questions in standard written language, report that. Do not let the result silently become a claim about spoken interaction, legal drafting, local government, children, older people or every register in the language.

Un punteggio diventa utile quando restano visibili i confini del compito, della lingua, del contesto e della revisione umana.

La lezione del maltese e del basco

Un articolo presentato alla conferenza LREC-COLING 2024 ha studiato la valutazione della traduzione automatica dall'inglese al maltese e dallo spagnolo al basco. Gli autori hanno esaminato la metrica di valutazione COMET, raccolto valutazioni umane dirette e verificato come la metrica si comportasse quando adattata alle due coppie linguistiche. La loro conclusione è modesta ma significativa: le prestazioni della metrica possono migliorare con la messa a punto, ma possono anche essere molto sensibili alla distribuzione dei punteggi nei dati di addestramento, soprattutto in contesti con poche risorse.

Non è la storia di una metrica che fallisce. È la storia di ciò da cui dipende un punteggio. Una metrica addestrata su una distribuzione può comportarsi diversamente quando le si chiede di giudicarne un'altra. Una coppia linguistica con meno materiale di valutazione può far sembrare il punteggio più decisivo di quanto sia. Un sistema comodo da confrontare può comunque essere un pessimo indicatore di ciò che i parlanti considerano una buona traduzione. I giudizi umani non rendono perfetta la valutazione, ma mettono in luce i punti in cui una misura automatica dà per scontato qualcosa.

Un altro studio del 2024, Benchmarking Low-Resource Machine Translation Systems, confronta sistemi disponibili pubblicamente su quattro insiemi di dati e 26 lingue e pubblica i risultati tramite BENG, una piattaforma FAIR per la valutazione della generazione del linguaggio naturale. Anche qui il contributo non è una classifica universale. È un confronto più ispezionabile. Efficienza ed efficacia sono considerate insieme e l'elenco delle lingue è visibile. Il lettore può chiedersi se il benchmark includa il percorso che gli interessa, invece di accettare un unico numero di sintesi.

Questi studi offrono una lezione europea di misura. La parte difficile non è inventare un altro punteggio. È costruire una valutazione che permetta al lettore di vedere di chi è la lingua, di chi è il compito e di chi è la definizione di qualità che ha prodotto il punteggio. Quando questo contesto manca, un numero diventa un attraversamento di frontiera senza passaporto. Può superare la presentazione, ma nessuno può stabilire da dove provenga.

La copertura linguistica può essere una proprietà di sicurezza

Le discussioni sulla sicurezza si concentrano spesso sui contenuti che un sistema dovrebbe rifiutare, sugli attacchi che dovrebbe respingere o sugli errori che dovrebbe individuare. La lingua aggiunge un'altra domanda: il sistema sa riconoscere quando è fuori dalle sue competenze? Un percorso che funziona in una lingua può fallire più spesso in un'altra mantenendo lo stesso tono sicuro di sé. Se l'interfaccia non rende visibile questa differenza, gli utenti non possono calibrare la loro fiducia.

Questo è particolarmente importante quando la lingua fa parte di un'interazione critica per la sicurezza. Un paziente può descrivere un sintomo in una varietà regionale. Un lavoratore può segnalare un pericolo usando un termine locale. Un residente può presentare un ricorso con una convenzione ortografica che un normalizzatore tratta come rumore. Un modello può essere tecnicamente accurato sul suo benchmark e operativamente insicuro per quella via. La domanda rilevante non è se il sistema possa generare una risposta plausibile. È se i controlli di sicurezza siano stati valutati sulla lingua e sulla situazione che ha davanti.

La sicurezza non richiede di trattare ogni via linguistica come un'emergenza speciale. Richiede di abbinare il controllo alla conseguenza. Un risultato di ricerca a basso rischio può esporre le sue fonti e invitare a una correzione. Un'interfaccia di triage medico può indirizzare input linguistici incerti a un professionista formato. Un flusso di lavoro per documenti legali può tenere fonte e traduzione affiancate e richiedere l'approvazione prima della pubblicazione. Un sistema vocale può chiedere all'utente di ripetere un nome piuttosto che selezionare silenziosamente l'entità familiare più vicina. Queste sono scelte ingegneristiche ordinarie quando la lingua è trattata come parte del confine del sistema.

Il rifiuto stesso richiede progettazione linguistica. Dire a un utente che un sistema non può rispondere non basta se il rifiuto è opaco, paternalistico o non disponibile nella lingua dell'utente. Il sistema dovrebbe dire cosa non è riuscito a stabilire, quali informazioni sarebbero utili e quale via umana o autorevole è disponibile. Altrimenti un controllo di sicurezza diventa un'altra barriera di accesso. Il principio linguistico dell'Europa è messo alla prova più chiaramente quando un sistema non può fornire la risposta richiesta.

La progettazione operativa di un servizio multilingue

Un servizio multilingue affidabile ha una forma operativa facile da descrivere e sorprendentemente difficile da mantenere. Primo, nomina il compito. Traduzione, trascrizione, classificazione, recupero, sintesi e generazione non sono intercambiabili. Secondo, nomina la via linguistica, inclusi scrittura e qualsiasi confine regionale o di dominio rilevante. Terzo, registra il materiale di origine e le trasformazioni applicate. Quarto, definisce il percorso di revisione e escalation. Quinto, dice all'utente cosa il sistema può e non può affermare.

Questi passaggi non sono una richiesta di una burocrazia gigantesca. Sono il minimo necessario per rendere verificabile una promessa linguistica. Se un fornitore dice che un modello supporta il finlandese, un acquirente dovrebbe poter chiedere se ciò significa generazione di testo, riconoscimento vocale, traduzione da quali lingue o tutto quanto sopra. Se un team di prodotto dice di supportare una lingua regionale, dovrebbe dire se il supporto si basa su dati nativi, dati tradotti, un piccolo set di valutazione o una revisione di esperti. Se la risposta è sconosciuta, sconosciuto è uno stato valido.

Il servizio ha anche bisogno di una politica di modifica. Nuovo materiale di formazione, un nuovo tokenizer, un nuovo modello di traduzione, una nuova lista di terminologia o una nuova popolazione di utenti possono cambiare il comportamento linguistico. Una release che migliora una via può far regredire un'altra. Un risultato di benchmark dell'anno scorso non descrive automaticamente il sistema di oggi. Registri di versione, test comparativi e una via per segnalare errori specifici della lingua rendono il servizio manutenibile piuttosto che cerimoniale.

La manutenzione ha un lato umano. Gli esperti linguistici hanno bisogno di un modo per vedere gli errori che colpiscono le loro comunità. I team di dominio hanno bisogno di un modo per distinguere un errore di traduzione da un'ambiguità di policy. Gli operatori hanno bisogno di un modo per mettere in pausa una via senza aspettare che un fornitore di modelli interpreti un reclamo. Gli utenti hanno bisogno di un modo per dire che il sistema ha frainteso una parola, un contesto o il nome di una persona. Un servizio multilingue non è completo quando il modello è distribuito. È abbastanza completo da essere responsabile quando arriva il prossimo problema linguistico.

Provenienza attraverso una pipeline linguistica

La provenienza diventa concreta quando seguiamo un singolo elemento di significato attraverso un sistema. Si comincia con un paragrafo di origine. Se ne registrano la lingua, la scrittura, l'autore o l'istituzione quando noti, i diritti e lo scopo. Se è segmentato, si preserva la relazione con l'originale. Se è tradotto, si conservano la fonte e il traduttore o il processo di traduzione. Se un revisore modifica la formulazione, si registra come un nuovo stato, non come una sostituzione silenziosa. Se il paragrafo diventa un elemento di benchmark, si portano con sé il compito, la chiave di risposta, la lingua e il registro di revisione.

In fase di esecuzione, la stessa disciplina si applica al contrario. Si registra quale percorso linguistico ha gestito la richiesta, quale versione di modello o strumento è stata eseguita, quali prove di origine sono state recuperate, quale stato di incertezza o rifiuto è stato raggiunto e quale azione umana è seguita. Il registro non deve esporre contenuti privati a ogni operatore. Deve però rendere i fatti materiali disponibili a un revisore autorizzato. Senza di essi, un incidente linguistico diventa un dibattito sulle impressioni.

È qui che la provenienza multilingue si distingue da un registro di controllo generico. Un timestamp e un nome di modello ci dicono che qualcosa è accaduto. Non ci dicono se la fonte è stata tradotta, se la risposta ha cambiato un formato numerico, se un'entità nominata è stata normalizzata o se il revisore lavorava nella lingua di destinazione. Il percorso di trasformazione è la prova. Una risposta breve può nascondere una lunga catena di decisioni.

C'è una piccola virtù olandese in questo approccio: mantenere il registro abbastanza noioso da poterlo usare un martedì pomeriggio. Un registro di provenienza non dovrebbe essere un'etichetta da museo scritta per un controllo che potrebbe non arrivare mai. Dovrebbe aiutare un operatore a rispondere alla domanda successiva, a fermare il percorso giusto e a spiegare il risultato a una persona che non ha alcun interesse per il tuo diagramma di architettura. Una buona governance linguistica è leggermente monotona. È così che sai che potrebbe sopravvivere al contatto con il lavoro.

Le scelte nascoste in una traduzione

Ogni sistema di traduzione porta con sé scelte che meritano un nome. La tokenizzazione decide come viene suddiviso l'input. La normalizzazione decide quali distinzioni vengono preservate o scartate. L'allineamento decide quali parti di due testi vengono trattate come equivalenti. La terminologia decide quali parole sono stabili. La decodifica decide come viene selezionato l'output. La post-elaborazione decide cosa vede il lettore. Nessuno di questi passaggi è intrinsecamente sbagliato. Ciascuno può creare un errore specifico della lingua che è invisibile in una demo generale.

Prendiamo un nome proprio. Un sistema può tradurlo, traslitterarlo, preservarlo o sostituirlo con un'ortografia familiare. Per una poesia, diverse scelte possono essere difendibili. Per un documento d'identità, solo una può essere accettabile, e quella può dipendere dall'autorità emittente. Prendiamo un'unità di misura o una data. I valori possono rimanere matematicamente equivalenti mentre la forma diventa ambigua per un lettore. Prendiamo un sostantivo o un pronome di genere. Una traduzione può introdurre informazioni che la fonte ha trattenuto, o cancellare una distinzione che la fonte ha fatto deliberatamente.

La risposta progettuale non è congelare la lingua. È dichiarare la politica e rendere visibile l'eccezione. Un elenco terminologico può proteggere i termini legali. Una regola per le entità nominate può impedire che una città diventi una persona. Una vista che preserva la fonte può consentire a un revisore di confrontare originale e output. Un'escalation umana può essere attivata da un nome a bassa confidenza, da un disaccordo tra percorsi o da un compito classificato come ad alto impatto. Il modello rimane utile perché i suoi confini fanno parte del flusso di lavoro.

I modelli linguistici di grandi dimensioni rendono più difficile vedere le scelte operate, perché l'output è fluido. Un output fluido è un'interfaccia meravigliosa e una spiegazione inaffidabile. Il sistema può produrre una frase che suona come scritta da un madrelingua, ma che seleziona il senso sbagliato di una parola. Può preservare l'argomento generale, ma perdere una negazione. Può tradurre un'espressione locale in un'espressione standard che cambia la posizione di chi parla. Questo è il motivo per cui la qualità linguistica non può essere rappresentata dalla sola grammatica. Il significato ha una forma sociale.

Scritture, dialetti, registri e istituzioni

Il supporto linguistico viene spesso annunciato a livello del nome di una lingua, ma i lettori incontrano scritture, varietà e registri. Un sistema che gestisce l'ortografia standard moderna può avere difficoltà con i documenti storici. Un riconoscitore vocale può gestire l'audio in studio e fallire in una stazione affollata. Un chatbot rivolto al pubblico può rispondere in un registro formale mentre l'utente ha bisogno di un linguaggio semplice. Un'istituzione può usare un termine che differisce dal linguaggio comune per un motivo giuridicamente importante.

Non sono casi limite nel senso dispregiativo del termine. Sono i punti in cui la lingua incontra il mondo. Un nome regionale può fare la differenza tra un indirizzo corretto e una consegna fallita. Una parola dialettale può essere l'unica parola che una persona conosce per un sintomo. Una frase formale può segnalare che un messaggio ha effetto giuridico. Una variante di scrittura può determinare se un documento è ricercabile. Se un benchmark esclude questi percorsi, può comunque essere utile, ma non può sostituire l'intera lingua.

Testare tutte le varietà non è sempre possibile. La risposta onesta è descrivere il sottoinsieme supportato e invitare a fornire prove sul resto. Un sistema può dichiarare di essere stato valutato sull'olandese scritto standard per il riepilogo di informazioni pubbliche, senza avanzare alcuna pretesa sul riconoscimento vocale regionale. Può aggiungere un test per il frisone o il basco senza fingere che l'aggiunta risolva ogni questione relativa alle lingue regionali e minoritarie. La specificità non è una debolezza. Dice agli utenti dove si trova il limite minimo.

Le istituzioni dovrebbero anche resistere all'idea che una singola via linguistica nazionale sia automaticamente neutrale. Il linguaggio amministrativo può essere inaccessibile ai parlanti della stessa lingua. Accessibilità e multilinguismo si sovrappongono perché entrambi chiedono se il lettore può comprendere e agire. Il lavoro linguistico della Commissione include strumenti di semplificazione e testi accessibili proprio per questo motivo. Una frase può essere linguisticamente corretta e comunque istituzionalmente inutilizzabile.

Quando l'interfaccia è fluida ma sbagliata

I fallimenti linguistici più difficili non sono spettacolari. Sono risposte che superano la prova visiva. Un riepilogo include i nomi giusti ma cambia chi è responsabile. Una traduzione preserva i sostantivi ma trasforma una raccomandazione in un'istruzione. Un classificatore comprende l'argomento ma perde una negazione. Un sistema vocale riconosce le parole ma non l'esitazione di chi parla. Un utente legge l'output nella propria lingua e presume che la fluidità sia un segno di cura.

Dovremmo progettare per questa classe di errori invece di aspettare che un esempio bizzarro diventi un titolo di giornale. Confrontare fonte e output per i contenuti ad alto impatto. Preservare i marcatori di incertezza. Mantenere le citazioni o i riferimenti ai documenti. Chiedere conferma quando un numero, un nome o una scadenza sono centrali. Rendere visibile il percorso all'operatore. Offrire un meccanismo di correzione che non richieda all'utente di sapere quale componente ha fallito. Questi controlli sono piccoli, ma trasformano una traduzione in una transazione ispezionabile.

La revisione umana non dovrebbe essere descritta come una linea di difesa magica. I revisori hanno limiti di tempo, lacune di dominio e le proprie assunzioni linguistiche. Un'interfaccia di revisione utile fornisce loro la fonte, l'output, il contesto e il motivo dell'escalation. Registra il disaccordo invece di appianarlo. Se i revisori correggono ripetutamente un termine, l'organizzazione può migliorare la terminologia o modificare il confine del compito. Se il disaccordo rivela che la fonte stessa è ambigua, l'azione giusta potrebbe essere chiedere all'autore, non addestrare il modello più duramente.

Gli operatori hanno anche bisogno di un modo per vedere le prove negative. Quali lingue non sono state valutate? Quali attività non hanno revisione umana? Quali richieste sono state rifiutate? Quali utenti hanno abbandonato il percorso dopo una traduzione? Un'assenza può essere un segnale. Un grafico di copertura verde che omette i percorsi falliti è una mappa della superficie di marketing, non del servizio.

La competenza umana non è un pulsante di riserva

La politica europea sulla tecnologia linguistica mette linguisti, data scientist, ingegneri informatici e specialisti di dominio nella stessa frase. Questo è un requisito di progettazione, non un elenco di professioni da invitare a una riunione di lancio. Ogni persona vede un fallimento diverso. Il linguista vede una costruzione innaturale o una distinzione persa. L'ingegnere vede un problema di segmentazione o di instradamento. Lo specialista di dominio vede un pericoloso errore di categoria. L'operatore vede una coda di cui nessuno può assumersi la responsabilità. La persona che usa il servizio sperimenta una decisione che non ha più senso.

La competenza umana dovrebbe entrare in gioco prima che il benchmark venga congelato. Un esperto di lingua può aiutare a selezionare materiale di test che rappresenti registri reali piuttosto che solo frasi pulite. Un esperto di dominio può identificare i termini che non devono deviare. Un rappresentante della comunità può dire a un team quale formulazione risulta ufficiale, familiare o offensiva. Un responsabile dei dati può spiegare quale provenienza è disponibile e quale no. Questi input modellano il contratto del sistema. Non sono decorazioni dopo che le scelte tecniche sono state fatte.

C'è un costo, naturalmente. Una buona revisione richiede tempo e paga le persone per conoscenze che spesso sono trattate come invisibili. Quel costo fa parte del supporto linguistico. L'alternativa è esternalizzarlo agli utenti, che pagano con confusione e ricorsi, o al personale, che traduce e ripara il percorso in modo informale. Un sistema che sembra economico perché ignora la competenza linguistica non è efficiente. Ha semplicemente spostato la fattura.

Cosa deve rivelare un benchmark equo

Un benchmark multilingue dovrebbe iniziare con un'affermazione abbastanza piccola da poter essere testata. L'affermazione potrebbe essere che un sistema può rispondere a domande di informazione pubblica in un insieme di lingue, preservare date e numeri e rifiutare quando mancano le prove nella fonte. Potrebbe essere che un percorso di traduzione gestisca una particolare coppia di lingue e dominio a un livello di qualità definito. Potrebbe essere che un riconoscitore vocale possa trascrivere una varietà specificata in condizioni acustiche specificate. Il benchmark è un contratto per quella affermazione.

Il contratto richiede più di un elenco di lingue. Dovrebbe esporre l'attività, la fonte, il dominio, il registro, la scrittura, la direzione, la lunghezza del contesto, le condizioni di input, le risposte di riferimento, le varianti accettabili, le metriche, la revisione umana e l'incertezza. Dovrebbe indicare se gli elementi sono stati scritti originariamente in ciascuna lingua o tradotti. Dovrebbe registrare chi li ha rivisti e quali disaccordi sono rimasti. Dovrebbe separare i risultati aggregati dai risultati per lingua. Dovrebbe mostrare abbastanza esempi da permettere a un lettore di capire cosa sta misurando il punteggio.

I criteri dell’EU MMLU sono utili perché ampliano il significato di equità. Una rappresentazione equilibrata delle lingue ufficiali dell’UE è una parte. Mantenere significato, difficoltà e valore di verifica tra le lingue è un’altra. Testare i valori e i contesti culturali dell’UE, inclusi modi di dire, umorismo, riferimenti, formati di date e numeri, tono e cortesia, rende il benchmark uno strumento sociale oltre che tecnico. I criteri non eliminano il giudizio. Rendono il giudizio ispezionabile.

I progettisti di benchmark dovrebbero pubblicare le fette di errore, non solo le medie. Un modello può avere un buon punteggio medio mentre fallisce ogni elemento che coinvolge un registro o un tipo di numero particolare. Un percorso può essere efficiente in una direzione e lento o costoso nell’altra. Una metrica può correlare con il giudizio umano in una lingua e diventare instabile in un’altra. Le viste per lingua e per attività non sono un lusso. Sono il modo in cui un acquirente evita di acquistare la media mentre implementa l’eccezione.

Infine, un benchmark dovrebbe dichiarare ciò che non può dirci. Un test scritto non stabilisce le prestazioni vocali. Un punteggio di traduzione non stabilisce l’affidabilità legale. Un insieme di lingue ufficiali non stabilisce il supporto per le lingue regionali o minoritarie. Un punteggio alto non stabilisce che una persona possa contestare una decisione. Il limite non è un imbarazzo. È il bordo della mappa, e gli utenti devono vederlo prima di salpare.

Un punteggio è una legenda della mappa, non il territorio

I numeri sono utili perché impongono un confronto. Sono pericolosi perché invitano a una conclusione più ampia della misurazione. Un punteggio può dirci come un sistema si è comportato su un campione definito con un metodo definito. Non può dirci come una comunità vivrà il sistema senza un ponte di presupposti. Il ponte può essere solido. Deve essere nominato.

Supponiamo che un sistema migliori su un benchmark multilingue dopo il fine-tuning. Questa è prova di prestazioni migliorate su quella valutazione. Non è automaticamente prova che il sistema sia più sicuro in un servizio pubblico. Il servizio può usare una terminologia diversa, un contesto più lungo, input vocale, un registro diverso o un flusso di lavoro a valle che trasforma un suggerimento in una decisione. Il benchmark può comunque essere prezioso. Diventa più prezioso quando l’organizzazione dice quale parte del servizio rappresenta.

La stessa disciplina si applica a energia, velocità e costo. Un percorso in una lingua a basse risorse può richiedere più revisione umana o un contesto di recupero più ampio. Non è un difetto da nascondere in una media. È una proprietà del servizio che dovrebbe informare la progettazione. Le istituzioni europee hanno trascorso decenni a costruire servizi di traduzione e linguistica perché il costo pratico della diversità linguistica è reale. Un sistema di IA non abolisce quel costo emettendo testo rapidamente.

Non c’è vergogna nello scegliere un percorso più ristretto. Un team può supportare meno attività bene, pubblicare il confine e aggiungere lingue man mano che le prove crescono. Questo è meglio che dichiarare ogni lingua e chiedere agli utenti di scoprire le lacune. L’istinto europeo per uno standard è più forte quando è abbinato all’istinto olandese di verificare se la cosa funziona in un mercoledì qualunque.

Costruisci per 24, testa oltre 24

L’Unione Europea ha 24 lingue ufficiali e di lavoro, e il servizio di traduzione della Commissione opera in tutte. Quel numero crea una base utile per le infrastrutture pubbliche. Non definisce la vita linguistica dell’Europa. Le lingue regionali, minoritarie, non territoriali e migranti modellano anche comunità e istituzioni. Un sistema costruito per 24 può comunque escludere persone che non usano uno di quei percorsi, o che usano una lingua ufficiale in una forma che il sistema non ha valutato.

Costruire per 24 è quindi una responsabilità di rendere concreto il livello di base, non un permesso di fermarsi. Una rotta linguistica deve portare con sé le proprie prove. Un ente pubblico dovrebbe poter dire quali lingue ufficiali sono coperte per quali attività, quale revisione umana esiste e dove gli utenti possono ottenere una versione autorevole. Dovrebbe inoltre avere un modo per imparare dalle lingue al di fuori del set iniziale senza trasformare la comunità in un laboratorio di test non retribuito.

Testare oltre 24 significa più che aggiungere una lingua di novità a una demo. Significa lavorare con parlanti, istituzioni e ricercatori per decidere qual è il compito, a cosa può servire il materiale di partenza e cosa conta come errore dannoso. Il processo può produrre una capacità piccola e accuratamente delimitata. È comunque un progresso. Una rotta modesta con un contratto chiaro può valere più di un'affermazione impressionante che nessun operatore può difendere.

Cosa vogliamo rendere esplicito

Da Dweve, affrontiamo questo argomento dal lato dell'infrastruttura. Loom è descritto nel nostro materiale di prodotto pubblico come un modello cognitivo compilato per attività i cui componenti linguistici producono un grafo di risultati governato, mentre l'apprendimento dei vincoli, la composizione dei grafi, i risolutori e la verifica detengono l'autorità decisionale. Questa è una posizione architetturale, non un'affermazione di prestazioni multilingue. Non rende corretta una rotta linguistica. Rende però difficile nascondere un obbligo: l'output linguistico non dovrebbe essere l'unico luogo in cui esistono il ragionamento e le prove del sistema.

Il nostro lavoro su Ground Truth fa lo stesso punto su una scala più umana. Le persone hanno bisogno di un linguaggio condiviso sufficiente per distinguere un modello da un flusso di lavoro, una previsione da una prova e una risposta fluente da un risultato verificato. Nei sistemi multilingue, quel vocabolario ha bisogno di un'altra parola: rotta. Una risposta in olandese, una in francese e una in basco non sono semplici resa di un unico evento interno se prove, terminologia, revisione e comportamento in caso di errore differiscono. La rotta fa parte dell'affermazione.

Questa posizione è deliberatamente meno entusiasmante che dire che un unico modello capisce l'Europa. È anche più utile. Vogliamo che un sistema mostri cosa ha ricevuto, quali fonti e vincoli ha potuto usare, cosa non è riuscito a stabilire e quando un essere umano dovrebbe subentrare. La lingua è una superficie attraverso cui una persona incontra quel lavoro. La superficie dovrebbe essere chiara, ma non dovrebbe poter cancellare la struttura sottostante.

Non siamo esenti dagli standard qui descritti. Un campo di provenienza non ripara dati mancanti. Un percorso deterministico non dimostra che una traduzione sia equa. Un confine di elaborazione europeo non conferisce competenza linguistica. L'unico modo onesto per fare un'affermazione multilingue è continuare a testare, pubblicare i limiti e lasciare che gli esperti di lingua mettano in discussione la rotta. Il nome del prodotto non è una prova. La documentazione lo è.

Uno standard pratico per i team

I team che decidono se introdurre una funzionalità di IA multilingue possono iniziare con una breve serie di domande. Cosa deve fare esattamente il sistema in ogni lingua? Quali persone sono coinvolte se sbaglia? Quale materiale di partenza è autorevole? Come sono stati creati gli elementi di test, e da chi? Quali registri, scritture, dialetti e domini rientrano nell'affermazione? Cosa fa il sistema quando non riesce a stabilire il significato? Chi può mettere in pausa la rotta? Come può un utente correggere una risposta senza diventare il linguista non retribuito del progetto?

Le domande diventano concrete quando sono legate ad artefatti. Tieni una scheda di rotta linguistica con l'attività, le varietà linguistiche supportate, le famiglie di fonti, lo stato dei diritti, le versioni di modelli e strumenti, i risultati della valutazione, le modalità di errore note e il responsabile della revisione. Conserva esempi di errori con il loro contesto, non solo un punteggio. Tieni la fonte accanto a una traduzione ad alto rischio. Conserva un motivo di escalation che un operatore possa comprendere. Tieni un registro delle modifiche quando cambiano un tokenizer, un elenco di terminologia, un benchmark o un modello.

I team di procurement possono chiedere ai fornitori risultati per lingua e per attività, invece di una sola media multilingue. Possono chiedere se un benchmark è stato tradotto o scritto in lingua originale, se sono disponibili valutazioni umane, come vengono gestiti i percorsi per le lingue a basse risorse e se il fornitore può esportare le prove necessarie per una revisione. Possono chiedere cosa succede quando una lingua non è supportata, perché un rifiuto e un fallback silenzioso hanno conseguenze molto diverse.

I team di prodotto possono progettare l'interfaccia per mostrare il percorso e il livello di confidenza senza fingere che un numero di confidenza sia una probabilità di verità. Possono conservare i collegamenti alle fonti, usare un linguaggio semplice nei rifiuti e rendere visibili le azioni di revisione. Possono evitare l'espressione supporta tutte le lingue a meno che non possano definire il verbo. Supportare può significare visualizzare testo, accettare input, tradurre, riassumere, rispondere, classificare, parlare o gestire un flusso di lavoro regolamentato. Un selettore di lingua non è una specifica.

I team di ricerca possono pubblicare dataset con provenienza e percorsi di correzione. Possono includere risultati negativi e segnalare quando una metrica non si generalizza bene. Possono invitare le comunità linguistiche alla valutazione prima che un modello venga dichiarato pronto, e pagare per la loro competenza. Possono resistere alla pressione di trasformare un risultato limitato in un'affermazione universale. Il benchmark più prezioso potrebbe essere quello che spinge un team a rimuovere una frase dalla propria pagina di prodotto.

La società dietro il modello

Un modello linguistico può essere molto bravo a produrre linguaggio senza sapere cosa il linguaggio fa in una società. Può prevedere una frase, tradurre un paragrafo e rispondere a una domanda senza cogliere la relazione istituzionale portata dalle parole. Questo divario non è la prova che il modello sia inutile. È la prova che il linguaggio è più di un tipo di dato.

La risposta dell'Europa non dovrebbe essere una competizione per contare le lingue in una model card. Dovrebbe essere uno sforzo sostenuto per rendere i dati linguistici, i diritti, le competenze, la valutazione e il controllo pubblico parte della stessa infrastruttura. Il lavoro sulla tecnologia linguistica della Commissione, il Language Data Space, la European Language Grid e il benchmark EU MMLU vanno tutti in quella direzione. I ricercatori europei stanno testando cosa succede quando i benchmark tradotti vengono trattati come domande di ricerca piuttosto che come strumenti indiscussi. Il lavoro merita attenzione perché rende tecnicamente visibile un vecchio fatto politico: le persone non vivono l'Unione in una sola lingua.

La prossima volta che un fornitore dice che un modello è multilingue, chiedete cosa contiene questa affermazione. Quali lingue? Quali attività? Quali comunità? Quali fonti? Quale revisione? Quale rifiuto? Quale registro delle modifiche? La domanda non è ostile. È l'inizio ordinario della responsabilità.

Una società non diventa giusta perché una macchina sa ripetere le sue parole. Diventa più giusta quando le persone possono entrare nelle sue istituzioni, capire cosa sta succedendo, contestare un risultato ed essere ascoltate nella lingua che porta la loro vita. Un modello può aiutare in questo lavoro. Non può definirlo. La lingua di un modello è una capacità tecnica. La lingua di una società è una responsabilità condivisa.

Fonti