RAG multilingue: come interrogare documenti in lingue diverse dalla domanda

Il RAG multilingue permette di fare una domanda in italiano e ottenere una risposta fondata su documenti scritti in inglese, tedesco o francese, con le fonti citate nella lingua originale. Il problema non è tecnicamente complicato, ma richiede scelte precise: dove tradurre, come indicizzare e come verificare che il sistema non perda sfumature nel passaggio tra lingue. Questo articolo spiega le tre strategie principali, i controlli di qualità da mettere in piedi e gli errori più comuni.

Cos'è il RAG multilingue e quando serve davvero

Un sistema RAG (retrieval augmented generation) va a cercare i passaggi più pertinenti nei Suoi documenti e li passa a un modello linguistico che genera una risposta citando le fonti. Finché domande e documenti sono nella stessa lingua, il problema è relativamente contenuto: resta da gestire il chunking e la ricerca ibrida, come spiegato in Come funziona il RAG, passo dopo passo. Il RAG multilingue entra in gioco quando questa condizione non è più vera: un'azienda italiana con filiali in Germania che ha manuali tecnici in tedesco e operatori che fanno domande in italiano, uno studio legale che consulta regolamenti europei in inglese e francese, un servizio clienti che riceve ticket in più lingue su una base di conoscenza prodotto scritta in un'unica lingua madre.

Il caso d'uso non è raro quanto sembra: basta avere documentazione tecnica, normativa europea o manuali di fornitori esteri perché il problema si presenti, anche se l'organizzazione lavora prevalentemente in una sola lingua. La domanda chiave da porsi prima di partire è: la risposta deve restare ancorata al testo originale (con citazione nella lingua di origine) o può essere tradotta integralmente? Questa scelta orienta tutte le decisioni successive.

Le tre strategie per la ricerca cross-lingua

Esistono tre approcci per far incontrare una domanda in una lingua con documenti in un'altra. Non sono mutuamente esclusivi: molti sistemi in produzione ne combinano due.

Tradurre i documenti in fase di indicizzazione

Si traduce ogni documento (o se ne crea una versione parallela) nella lingua principale dell'organizzazione prima di indicizzarlo. Il vantaggio è che la ricerca testuale (full-text, tipo BM25) funziona in modo nativo, senza dover gestire più lingue nello stesso indice. Lo svantaggio è doppio: si moltiplica il costo di storage e di manutenzione (ogni aggiornamento del documento originale richiede una nuova traduzione), e si introduce un livello di approssimazione tra il testo citato e il testo realmente scritto dall'autore, che può essere un problema se la fonte citata deve avere valore probatorio (contratti, norme, perizie).

Tradurre la domanda a tempo di query

L'approccio opposto: i documenti restano nella lingua originale, indicizzati e chunkati come sono; quando arriva una domanda, viene tradotta automaticamente nella lingua (o nelle lingue) dei documenti prima di lanciare la ricerca. I passaggi recuperati restano quindi fedeli al testo sorgente, e solo la risposta finale generata dal modello viene prodotta nella lingua della domanda, con le citazioni che riportano il passaggio originale. È l'approccio più robusto quando la fedeltà alla fonte conta (compliance, normativa, contrattualistica), perché non si tocca mai il documento. Il costo aggiuntivo è una chiamata di traduzione per ogni domanda, generalmente trascurabile rispetto al costo della generazione.

Embedding multilingue senza traduzione esplicita

I modelli di embedding multilingue più recenti proiettano frasi di lingue diverse in uno spazio vettoriale condiviso, dove frasi con significato simile finiscono vicine indipendentemente dalla lingua in cui sono scritte. In teoria questo permette di confrontare direttamente una domanda in italiano con un chunk in tedesco senza passare da una traduzione esplicita. In pratica la qualità varia molto a seconda della coppia di lingue, della lunghezza dei testi e del dominio (il linguaggio tecnico o giuridico è spesso meno coperto nei dati di addestramento rispetto al linguaggio generico). Per capire meglio cosa succede sotto il cofano, può essere utile Cosa sono gli embedding: spiegazione semplice per non specialisti.

Stemming, tokenizzazione e ricerca ibrida per lingua

La ricerca ibrida combina ricerca lessicale (full-text, basata su parole chiave) e ricerca semantica (basata su embedding), come spiegato in Ricerca ibrida: perché BM25 e vettori insieme battono entrambi da soli. In un contesto multilingue, la parte lessicale richiede attenzione in più: lo stemming (la riduzione delle parole alla loro radice, ad esempio 'fatturazione' e 'fatturare' allo stesso stem) è specifico per ogni lingua, e applicare lo stemmer sbagliato a un testo (ad esempio uno stemmer inglese su un testo tedesco) degrada silenziosamente la qualità della ricerca senza generare errori visibili.

• Rilevare la lingua di ogni documento al momento dell'ingestione, non assumerla a priori
• Applicare tokenizzazione e stemming specifici per lingua, non uno stemmer unico per tutto l'indice
• Gestire separatamente le lingue con morfologia molto diversa (il tedesco con le parole composte, il finlandese con le declinazioni) rispetto a lingue romanze
• Mantenere la query expansion (sinonimi, varianti) coerente con la lingua rilevata della domanda, non con quella dei documenti

Per approfondire come funziona la query expansion e dove tende a fallire anche in contesto monolingue, è utile Ricerca semantica spiegata: come funziona, query expansion e quando fallisce: gli stessi meccanismi di fallimento si amplificano quando si aggiunge una lingua in più. Anche il chunking merita una riflessione specifica: alcune lingue producono frasi molto più lunghe o più corte a parità di significato, e una strategia di taglio pensata per l'italiano può produrre chunk troppo grandi o troppo piccoli su un testo tedesco o giapponese. I principi generali restano quelli descritti in Chunking per RAG: come dividere i documenti per risposte migliori, ma vanno calibrati lingua per lingua.

Dove inserire la traduzione automatica nella pipeline (e i rischi)

Se sceglie l'approccio con traduzione a tempo di query, la traduzione automatica entra in un punto preciso della pipeline: dopo aver rilevato la lingua della domanda e prima di lanciare la ricerca. È fondamentale non confondere questo passaggio con la generazione della risposta finale, che resta nella lingua in cui l'utente ha posto la domanda. I rischi principali da conoscere sono tre.

1. Perdita di terminologia tecnica: un traduttore automatico generalista può rendere male un termine di settore (giuridico, medico, meccanico) che ha un significato preciso nel dominio ma uno diverso nel linguaggio comune
2. Ambiguità non risolta: una domanda breve e ambigua nella lingua di partenza può essere tradotta in modo diverso a seconda del contesto, cambiando il senso della ricerca
3. Nomi propri e acronimi: la traduzione automatica a volte 'traduce' nomi di prodotti, leggi o enti che dovrebbero restare invariati (ad esempio il nome di una norma o di un regolamento europeo)

Controlli di qualità: come verificare che il RAG multilingue funzioni davvero

Valutare un sistema RAG multilingue richiede un passo in più rispetto a un RAG monolingue: non basta controllare che la risposta sia corretta, bisogna controllare che lo sia anche quando la domanda e il documento sorgente sono in lingue diverse. I principi generali di valutazione (metriche, test set, monitoraggio nel tempo) sono descritti in Come valutare un sistema RAG: metriche, test set e monitoraggio; per il caso multilingue vanno declinati così.

• Costruire un test set bilanciato per lingua: non solo domande in italiano su documenti italiani, ma anche domande in italiano su documenti in lingua straniera e viceversa
• Misurare separatamente il tasso di recupero corretto (il chunk giusto è stato trovato?) e il tasso di fedeltà della risposta (la risposta riflette davvero il contenuto del chunk, senza aggiunte dovute a un'interpretazione libera in fase di traduzione o generazione?)
• Far verificare un campione di risposte da un madrelingua della lingua sorgente dei documenti, non solo da un madrelingua della lingua della domanda
• Rifare il test ogni volta che si cambia il modello di embedding o il servizio di traduzione, perché le prestazioni cross-lingua non migliorano in modo uniforme tra una versione e l'altra di un modello
• Monitorare nel tempo le coppie di lingue più frequenti nelle domande reali degli utenti, perché spesso emergono coppie non previste in fase di progettazione

Un punto spesso trascurato: quando la risposta cita un passaggio, quella citazione deve rimanere verificabile. Il metodo per controllare che una citazione corrisponda davvero al testo sorgente, in qualunque lingua sia scritto, è lo stesso descritto in Risposte dell'IA con citazioni: come verificare una risposta sui propri documenti: aprire il passaggio citato e confrontarlo riga per riga con quanto afferma la risposta.

Checklist pratica prima di lanciare un RAG multilingue

1. Decidere se la fonte citata deve restare nella lingua originale o può essere tradotta: questa scelta determina l'architettura
2. Mappare le coppie di lingue realmente in gioco (domande in italiano, inglese; documenti in italiano, tedesco, francese) e non generalizzare a 'multilingue' senza elenco preciso
3. Scegliere tra traduzione a tempo di indicizzazione, traduzione a tempo di query o embedding multilingue in base al volume di documenti, alla frequenza di aggiornamento e al valore legale delle fonti
4. Configurare stemming e tokenizzazione per lingua, non un unico motore di ricerca lessicale generico
5. Costruire un piccolo glossario di termini da non tradurre (nomi di norme, prodotti, enti)
6. Creare un test set multilingue e farlo rivedere da madrelingua prima del lancio
7. Pianificare un controllo periodico, non solo al lancio, perché i volumi di domande per lingua cambiano nel tempo

Se vuole partire senza costruire tutta questa pipeline da zero, può caricare i documenti multilingue su Kopik e lasciare che l'indicizzazione gestisca la ricerca ibrida (full-text più espansione semantica) per Lei: può creare una base gratuitamente da /dashboard/bases/new, caricare PDF, Word o Markdown in lingue diverse e interrogarla in italiano anche se parte dei documenti è in un'altra lingua. Per chi vuole integrare la ricerca cross-lingua dentro un'applicazione esistente, la documentazione su /developers descrive come interrogare una base via API o tramite un server MCP utilizzabile da Claude, Cursor o ChatGPT.

Quando il RAG multilingue non è la soluzione giusta

Non tutti i casi d'uso multilingue giustificano la complessità descritta finora. Se il volume di documenti in lingua straniera è piccolo (poche decine di pagine) e stabile nel tempo, tradurre manualmente una volta e indicizzare il risultato può essere più semplice ed economico di costruire una pipeline di traduzione automatica a tempo di query. Allo stesso modo, se le domande arrivano quasi sempre nella stessa lingua dei documenti e i casi cross-lingua sono rari, può avere senso gestirli come eccezione (con un avviso all'utente) piuttosto che costruire fin da subito un sistema generale. Vale anche la pena confrontare il RAG con l'alternativa dei modelli a contesto lungo, soprattutto quando il corpus multilingue è piccolo: la scelta tra i due approcci è discussa in RAG vs modelli a contesto lungo: quando conviene l'uno e quando l'altro.