RAG multilingv: același corpus, cinci limbi de răspuns

Un RAG multilingv arată, în diagramă, exact ca unul obișnuit. Ai un singur corpus și cinci piețe. Contractele-cadru sunt în română, documentația de produs în engleză, procedurile de securitate în poloneză, listele de preț în germană, iar manualele de service au fost traduse în maghiară acum trei ani și nu s-au mai atins de atunci.

Un coleg din Budapesta întreabă, în maghiară, care e termenul de garanție pentru o piesă. Răspunsul există — într-un contract în română și într-o anexă tehnică în engleză. Sistemul îi întoarce ce a găsit: două paragrafe în engleză, un rezumat în maghiară care sună impecabil și un termen de garanție care nu apare, ca atare, în niciunul dintre documentele citate.

Restul clusterului a tratat variații pe aceeași temă: cine întreabă, ce are voie să vadă, cât de proaspăt e documentul. Aici întrebarea e alta. Nu contează cine întreabă, ci în ce limbă e scris ce cauți — și dacă întrebarea și documentul cad, sau nu, în același loc.

Problema are patru fețe distincte, care se rezolvă separat: unde traduci (dacă traduci), cum ții terminologia stabilă pe cinci piețe, în ce limbă iese răspunsul și cum evaluezi un sistem când setul tău de test acoperă o singură limbă din cinci.

Ce se rupe într-un RAG multilingv când limbile nu coincid

Un sistem RAG monolingv are un singur punct de eșec la recuperare: nu a găsit pasajul potrivit. Unul multilingv are trei, iar două dintre ele nu se văd în log-uri.

Retrieverul preferă limba întrebării

Prima problemă e că recuperarea nu e neutră lingvistic. Chirkova și colegii, într-un studiu din 2024 despre RAG în context multilingv, au măsurat direct decalajul de calitate a recuperării între engleză și restul limbilor, plus code-switching și probleme de fluență la generarea în limbi non-engleze. Nu e o surpriză de implementare, e o proprietate a modelelor.

Un studiu din 2026 pe 13 limbi merge mai departe și arată unde se produce dauna concret: rerankerele favorizează engleza și limba originală a interogării, suprimând dovezi relevante scrise în alte limbi. Documentul corect e în corpus, e recuperat de primul strat, și cade la reordonare pentru că e „în limba greșită”.

Generatorul preferă altceva

A doua problemă apare după recuperare. O lucrare din 2025 pe opt limbi și șase modele open-weight a găsit că modelele citează preferențial sursele în engleză, cu bias amplificat pentru limbile cu mai puține resurse și pentru documentele plasate la mijlocul contextului. Concluzia care contează operațional: alegerea citării nu e mereu ghidată de cât de informativ e documentul — modelele sacrifică uneori relevanța pentru preferința de limbă.

Tradus în consecință de business: pe piața cu cel mai mic volum de conținut, sistemul e cel mai înclinat să citeze documentul din altă piață. Exact invers față de ce vrei.

A treia: nu știi că s-a întâmplat

Ambele eșecuri sunt tăcute. Răspunsul iese fluent, cu citare, în limba potrivită. Singura urmă e că sursa citată e din altă jurisdicție decât cea a întrebării — și asta se vede numai dacă limba și piața sunt câmpuri de metadate pe care le loghezi, nu detalii de afișare.

Minimul care face diferența vizibilă: pe fiecare interogare, loghează limba detectată a întrebării, limba fiecărui pasaj recuperat și limba răspunsului generat. Trei câmpuri. Cu ele, un raport de o pagină îți arată dacă piața cu volum mic primește sistematic surse din altă limbă. Fără ele, singurul semnal e o reclamație formulată vag, la trei luni după lansare.

Trei arhitecturi, trei locuri unde se mută costul

Decizia de bază nu e „ce model de embeddings iau”. E unde pui punctul de traversare între limbi. Sunt trei variante, iar fiecare mută costul în alt loc — nu îl elimină.

Traduci corpusul la ingestie

Treci fiecare document printr-o traducere automată într-o limbă-pivot, de obicei engleza, și indexezi varianta tradusă. Recuperarea redevine monolingvă, deci poți folosi un model optimizat pentru o singură limbă și un index lexical bine configurat peste el.

Costul se plătește o dată per versiune de document, dar se plătește pe tot corpusul, nu doar pe ce se caută efectiv. Avantajul real, semnalat consecvent în literatura de cross-language information retrieval: traducerea unui document beneficiază de context bogat, iar o singură greșeală de traducere are efect mic asupra recuperării — se pierde într-un text lung. Dezavantajul e că indexezi o parafrază, nu originalul, și fiecare reindexare e o nouă rundă de traducere.

Traduci interogarea la runtime

Traduci întrebarea în limba corpusului și cauți normal. E varianta cea mai răspândită, pentru că e mult mai ieftină: traduci zeci de cuvinte, nu milioane.

Prețul e că interogările sunt scurte și ambigue, iar o singură traducere greșită mută întreaga căutare. Un studiu din 2025 pe RAG multilingv a arătat că traducerea întrebării înainte de recuperare suferă de acoperire limitată — găsești ce e scris ca în întrebarea tradusă, nu tot ce e relevant. Varianta care a ieșit cel mai bine în acea evaluare a fost hibridă: recuperezi direct din corpusul multilingv, apoi traduci pasajele recuperate într-o limbă comună înainte de generare.

Un singur spațiu vectorial

A treia variantă nu traduce nimic: te bazezi pe un model de embeddings multilingv care plasează „termen de garanție” și „warranty period” aproape unul de altul în același spațiu. Mecanica e cea din cum funcționează embeddings; ce se adaugă aici e cerința ca alinierea între limbi să fie precisă, nu doar existentă.

Nu e o alegere exclusivă. În practică, majoritatea sistemelor pe cinci piețe ajung la o combinație: spațiu comun pentru recuperare, traducere pentru pasajele care ajung în context.

Terminologia nu se traduce, se declară

Aici cade partea pe care nicio arhitectură n-o repară singură. Un termen de produs, o denumire legală sau o unitate de măsură au deja un echivalent oficial pe fiecare piață — iar traducerea automată nu îl caută, îl inventează.

Cuvântul corect nu e cuvântul plauzibil

Exemplul canonic din literatura de traducere terminologică: „transformer” în chineză poate ieși 变压器 (aparatul electric), 变形金刚 (personajul) sau 变换器 (ceva care transformă). Sistemul alege una plauzibilă contextual. Într-o documentație de echipament, două din trei sunt greșeli care se propagă în fiecare răspuns generat pe baza acelui pasaj.

Problema e suficient de serioasă cât să existe o competiție dedicată: ediția din 2025 a WMT a inclus o sarcină de traducere cu constrângeri terminologice, pe perechi engleză→germană, engleză→spaniolă și engleză→rusă. Rezultatele nu sunt unanime — un sistem participant a raportat că gestionarea flexibilă, contextuală a terminologiei de către un LLM a dat traduceri mai bune decât impunerea rigidă a constrângerilor. Ce rămâne clar e că terminologia e tratată ca problemă separată de traducere, nu ca pe un efect secundar al ei.

Echivalentul oficial există deja

Pentru orice operezi în UE, o parte din muncă e făcută. IATE, baza de terminologie a instituțiilor europene, acoperă cele 24 de limbi oficiale; conform Comisiei Europene, conține în jur de 600.000 de fișe conceptuale cu peste 6 milioane de termeni, din domenii care merg de la drept și mediu la transport și prelucrarea datelor.

Practica de terminologie a Comisiei e instructivă și dincolo de bază: în textele cu efect juridic, consistența cu versiunile anterioare cântărește mai mult decât echivalentul cel mai exact. Un termen mai bun care rupe lanțul de referință cu un act anterior e o regresie, nu o îmbunătățire.

Denumirile legale și unitățile nu au traducere, au echivalent

Două categorii se comportă diferit de restul vocabularului. Denumirile de entități și de acte normative au o formă oficială per jurisdicție, iar echivalentul dintr-o altă țară nu e o traducere — e alt act, cu alt conținut. Un sistem care traduce numele unei legi românești în germană produce un șir plauzibil care nu identifică nimic; forma corectă e numele oficial, păstrat ca atare, cu o glosă explicativă alături.

Unitățile și formatele numerice sunt cazul invers: se convertesc, dar conversia e o operație, nu o traducere. Separatorul zecimal diferă între piețe, formatul de dată la fel, iar un „1.500” citit ca o mie cinci sute într-o limbă și ca unu virgulă cinci în alta e o eroare care trece nedetectată prin orice verificare de fluență. Regula simplă: valorile numerice se citează în forma din documentul-sursă, iar conversia, dacă se face, se marchează explicit ca atare.

Glosarul e artefact de produs

Concret, asta înseamnă un glosar versionat, cu o intrare per concept și o coloană per piață: termenul oficial, variantele acceptate în interogări și forma pe care sistemul are voie să o folosească în răspuns. Se ține lângă corpus, nu lângă echipa de traduceri, și se aplică în două locuri: la expansiunea interogării, ca sinonimele de piață să prindă documentul, și la generare, ca răspunsul să iasă în terminologia locală.

Fără el, fiecare reindexare rescrie tăcut vocabularul produsului tău.

Trei limbi diferite într-un singur răspuns

Într-un sistem multilingv circulă trei limbi independente: cea a întrebării, cea a sursei recuperate și cea a răspunsului. Presupunerea implicită că toate trei coincid e cea mai frecventă sursă de răspunsuri care par corecte și nu sunt.

Derapajul de limbă e documentat, nu anecdotic

Fenomenul are nume în cercetare: output language drift. Când întrebarea, instrucțiunile și exemplele sunt în limba țintă, dar contextul recuperat vine în engleză, modelele generează frecvent răspunsul în limba contextului, nu în cea cerută — comportament caracterizat într-un studiu din 2025, împreună cu o metodă de decodare care penalizează token-urile din afara limbii țintă.

Varianta mai subtilă nu e schimbarea completă a limbii, ci amestecul: răspuns în maghiară cu termenul-cheie rămas în engleză, exact acolo unde utilizatorul are nevoie de forma locală ca să caute mai departe în ERP sau în contract.

Ce declari explicit

Regula practică: limba răspunsului e o decizie de produs, nu un efect secundar al recuperării. Se setează explicit, iar sursa se declară ca atare.

Un răspuns onest într-un sistem pe cinci piețe conține trei lucruri pe care unul monolingv nu le are: în ce limbă e documentul citat, dacă pasajul a fost tradus automat pe drum și pentru ce piață e valabil documentul. Ultimul punct se leagă direct de teritoriu ca cheie de aplicabilitate, tratat pe larg în RAG pentru parteneri și distribuitori — o clauză valabilă în Polonia nu devine valabilă în România pentru că a fost tradusă convingător.

Formatul concret al unui răspuns care își arată sursele e detaliat în cum arată un răspuns bun de RAG; în multilingv, la lista de acolo se adaugă doar câmpul de limbă.

Limba, ca metadată de rutare

În pregătirea corpusului, limba apare ca metadată derivată, alături de titlul secțiunii și data din conținut. Într-un sistem pe cinci piețe, promovarea ei e obligatorie: devine cheie de filtrare, la fel ca proprietarul sau domeniul de acces.

Trei câmpuri, nu unul. Limba documentului e ce s-a detectat efectiv în text — nu ce spune numele fișierului și nu ce spune folderul. Piața e unde se aplică documentul, și nu coincide cu limba: un contract în engleză poate guverna operațiunile din România, iar același text în germană poate acoperi și Austria. Statutul de traducere spune dacă textul e original sau derivat, și din ce sursă — pentru că, atunci când originalul și traducerea spun lucruri diferite, originalul câștigă.

Detectarea automată a limbii merită tratată cu aceeași suspiciune ca extragerea din PDF: documentele mixte sunt regula. Un manual în germană cu tabelul de coduri de eroare rămas în engleză va fi etichetat greșit la nivel de fișier și corect la nivel de fragment — motiv suficient să atașezi limba pe chunk, nu pe document.

Un detaliu ușor de ratat, dar cu efect direct asupra recuperării: același conținut are lungimi diferite în limbi diferite, iar o strategie de tăiere calibrată pe un text englezesc produce fragmente cu densitate de informație diferită în germană sau maghiară. Merită recitit ghidul de chunking cu asta în minte, înainte de a fixa dimensiunea pe toate limbile deodată.

Partea lexicală a căutării rămâne, la rândul ei, per limbă: stemming, stop-words și normalizarea diacriticelor sunt configurații separate pentru fiecare limbă din corpus — contrastul complet cu partea semantică e în ce este semantic search.

Evaluarea se înmulțește cu numărul de limbi

Un set de test într-o singură limbă nu spune nimic despre celelalte patru. Nu e o precauție teoretică: e exact tiparul de eșec pe care îl produce alegerea unui model după clasament.

Ce măsoară, de fapt, benchmark-urile publice

Două confuzii merită dezamorsate. MIRACL, referința citată cel mai des pentru retrieval multilingv, acoperă 18 limbi — dar e construit explicit pentru recuperare monolingvă, unde interogarea și corpusul sunt în aceeași limbă. Nu spune nimic despre cazul tău, în care întrebarea e în maghiară și documentul în română. Româna nu e, în plus, printre cele 18.

MMTEB, extensia multilingvă a MTEB publicată în 2025, acoperă peste 500 de sarcini și peste 250 de limbi — dar autorii notează ei înșiși că distribuția e înclinată spre limbile cu multe resurse. O lucrare din 2026 care propune un benchmark dedicat pentru portugheza braziliană o spune direct: acoperirea per limbă a MMTEB rămâne limitată pentru limbile mai mici, iar MIRACL nu include portugheza. Verifică, pentru fiecare limbă din portofoliul tău, dacă apare efectiv în ediția pe care o citezi.

Ordinul de mărime pentru română vine dintr-un studiu publicat în 2025, care a construit un corpus româno-englez de peste 130.000 de perechi întrebare-răspuns text și circa 9.750 tabelare. Pe acel corpus, multilingual-e5-large a ieșit cel mai bun monolingv, iar familia qwen3-embedding a dat cel mai bun echilibru între monolingv și cross-lingv; fine-tuning-ul cu LoRA a mutat MRR-ul de la 0,4496 la 0,4872, cu cele mai mari câștiguri exact pe partea cross-lingvă. Cifrele sunt ale corpusului lor, nu ale tău — ce se transferă e ordinul de mărime și direcția, nu valoarea.

Setul tău, per limbă

Metodologia de bază e cea din evaluarea unui sistem RAG, aplicată de cinci ori. Minimul viabil: 50 de întrebări reale per limbă, cu documentul corect adnotat — inclusiv cazurile în care documentul corect e în altă limbă decât întrebarea, pentru că acolo se rupe sistemul.

Peste metricile obișnuite se adaugă două specifice: rata de derapaj de limbă, adică procentul de răspunsuri care ies în altă limbă decât cea cerută, și rata de citare încrucișată, adică de câte ori sistemul citează o sursă dintr-o altă piață decât a întrebării. A doua e cea care prinde bias-ul de limbă înainte să ajungă în fața unui client.

Pragul de decizie e simplu: dacă recall-ul pe limba cu cel mai mic volum e sub jumătate din cel de pe limba principală, nu ai un sistem multilingv. Ai un sistem monolingv cu patru piețe care primesc răspunsuri de calitatea a doua — situație în care merită recitit când nu folosești RAG pentru piețele mici, unde o pagină de FAQ tradusă corect bate un sistem semantic prost calibrat.

Întrebări frecvente

Pot folosi un singur model de embeddings pentru toate cele cinci limbi?

Da, și în general asta e varianta care se administrează cel mai simplu — un index, un pipeline. Condiția e să verifici alinierea cross-lingvă pe perechile tale reale de limbi, nu doar scorul agregat al modelului. Alinierea bună între engleză și germană nu garantează nimic pentru maghiară–română.

E mai bine să traduc documentele sau interogările?

Depinde de raportul dintre volumul corpusului și volumul de trafic. Corpus mic și stabil, cu multe întrebări per document: traduci documentele o dată. Corpus mare, care se schimbă des, cu trafic modest: traduci interogările. Literatura de specialitate nu dă un câștigător universal — traducerea documentelor beneficiază de context mai bogat, cea a interogărilor e mult mai ieftină.

Cum tratez documentele care există în mai multe versiuni lingvistice?

Le legi prin același document_id conceptual și marchezi explicit care e originalul. La recuperare, întorci varianta din limba pieței relevante; la conflict între versiuni, originalul are precedență. Fără marcaj, două traduceri ușor divergente ale aceluiași document devin doi concurenți aproape identici în spațiul vectorial.

Ce fac cu întrebările scrise fără diacritice sau cu amestec de limbi?

Le tratezi ca pe cazul normal, nu ca pe o excepție. Partea lexicală se rezolvă cu normalizare per limbă; partea semantică tolerează de obicei lipsa diacriticelor, dar nu garantat. Interogările amestecate — termen tehnic în engleză într-o frază în română — sunt frecvente în B2B și merită să intre explicit în setul de test.

Cât adaugă un sistem multilingv la costul unuia monolingv?

Costul de infrastructură crește puțin — același index, aceleași vectori. Ce crește substanțial e costul de evaluare și întreținere: cinci seturi de test, cinci glosare, cinci runde de verificare la fiecare schimbare de model. Bugetul se face pe partea asta, nu pe stocare. Punctul de plecare rămâne cât costă un sistem RAG pe o singură limbă.

Trebuie să traduc și răspunsul final?

Nu — îl generezi direct în limba țintă, cu instrucțiune explicită, și declari limba sursei citate. Traducerea răspunsului deja generat adaugă un pas în care se pot pierde exact termenii pe care glosarul îi fixa.

Un sistem multilingv nu e unul monolingv cu un pas de traducere în plus. E o decizie de arhitectură luată o dată, un glosar întreținut și cinci seturi de evaluare care rulează separat. Când cele două vocabulare aparțin însă unor organizații diferite, fără echivalent oficial și fără cine să-l aprobe, glosarul nu se mai întreține — se construiește din dovezi, sub termen; cazul e în RAG pentru due diligence. Dacă operezi pe mai multe piețe și primești deja plângeri de tipul „nu găsește nimic în poloneză”, punctul de plecare e o măsurătoare per limbă, nu o schimbare de model.

Restul cazurilor de utilizare enterprise sunt strânse în hubul Cazuri de utilizare enterprise, articolele despre mecanica vectorilor sub eticheta embeddings, iar partea de arhitectură și implementare în secțiunea AI & RAG.