Každá lokalizační pipeline postavená na RAG má stejnou slepou skvrnu

Pokud lokalizační pipeline používá retrieval augmented generation k vkládání glosářových termínů do kontextového okna modelu, má problém s recall ve vyhledávání, který dosud nikdo nezměřil.

Vzorec je vždy stejný: vytvořit embedding vstupního textu, pomocí cosine search prohledat termbank, vložit top-k výsledky do promptu. Výstup je gramaticky správný. Terminologie je špatně. Chyba zůstane neviditelná, pokud někdo neovládá oba jazyky a nezná glosář.

Nejdřív jsme postavili tuhle naivní verzi. Pak jsme změřili recall vyhledávání vůči produkčním glosářům – a ukázalo se, že systém v reálných payloadech přehlíží většinu použitelných termínů.

Proč embeddingy vět míjejí glosářové termíny?#

Glosářový termín má 1–3 slova. „Localization engine.“ „Access token.“ „Deployment pipeline.“

Vstupní text je objekt JSON s hodnotami od dvou slov (popisek tlačítka) po dvě stě slov (popis produktu). Když se celý řetězec „Configure the localization engine for production deployment“ převede do embeddingu, výsledný vektor zachytí sémantický význam celé věty – něco o konfiguraci a produkčních systémech. Pro glosář relevantní fráze „localization engine“ se v reprezentaci na úrovni věty rozplyne.

Kosinová podobnost mezi tímto větným vektorem a glosářovou položkou „localization engine“ se pohybuje v rozmezí 0,6–0,7. Pod prahem vyhledávání. Termín ve vstupu existuje. Retrieval systém ho mine.

Problém je v granularitě: reprezentace na úrovni vět dotazují cíle na úrovni frází. Embeddingový model věrně reprezentuje význam věty jako celku. Jednotlivé termíny přitom nezabírají žádnou samostatnou oblast ve vektorovém prostoru.

Zjistili jsme to tou složitější cestou. V produkčních payloadech – vnořených objektech JSON s 20–50 klíči a hodnotami různé délky – vyhledávání na úrovni vět míjelo většinu použitelných glosářových termínů. Lokalizační request bez problémů doběhl. Výstup zněl plynule. Jenže z „localization engine“ se stával „translation tool“ – gramaticky správné, významově blízké, terminologicky chybné. A pipeline hlásila úspěch.

Jak rozklad na n-gramy zlepšuje vyhledávání v glosáři?#

Ukázalo se, že řešením je před embeddingem rozložit vstup na jednotky na úrovni frází. Každá textová hodnota se změní na sadu překrývajících se oken n-gramů:

Input: "Configure the localization engine for production"

1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
          engine for, for production]
3-grams: [configure the localization, the localization engine,
          localization engine for, engine for production]

Každý n-gram se stává samostatným dotazem pro vyhledávání. „Localization engine“ se dotazuje glosáře jako samostatná fráze – a najde odpovídající shodu s vysokou podobností.

Pipeline rozkladu:

1. Rekurzivně extrahovat všechny textové hodnoty z vnořených struktur JSON
2. Rozdělit je na věty, odstranit HTML a značky anotací
3. Normalizovat bílé znaky, odstranit okolní uvozovky, zrušit escape sekvence formátování
4. Vygenerovat z každé věty překrývající se 1-gramové, 2-gramové a 3-gramové fráze

Odstavec o 50 slovech vytvoří přibližně 150 n-gramů. Typický API payload s 20 klíči vytvoří 1 000–3 000 prohledatelných frází. Každá fráze se převede do embeddingu samostatně a každý embedding spustí dotaz na nejbližší sousedy nad vektorovým indexem glosáře.

Rozdíl jsme změřili na stejných produkčních payloadech, které odhalily původní problém. Glosářové termíny se teď nacházejí bez ohledu na větný kontext, který je obklopuje – termín o 2 slovech ukrytý v popisu produktu o 200 slovech se vyhledá se stejným recall jako samostatný štítek.

Jak funguje adaptivní vyhledávání pro různé velikosti glosářů?#

Rozklad na n-gramy a dávkové embeddingy jsou správný přístup pro velké glosáře. U malých se ale ukázaly jako výpočetně neefektivní.

Lokalizační engine nakonfigurovaný s 8 glosářovými termíny se vyřeší rychleji přímým vložením – jeden databázový dotaz, deterministický výsledek, pod jednu milisekundu. Lokalizační engine s 2 000 termíny vyžaduje vector search – limity kontextového okna a rozmělňování relevance znemožňují vložit vše přímo.

Pro každý request fungují tři režimy vyhledávání, vybírané podle kardinality glosáře pro daný pár jazyků:

Práh kardinality, který odděluje preload od search, vychází z profilování latence na produkčním provozu a průběžně se upravuje podle toho, jak se mění výkon embeddingových modelů, rozložení velikostí glosářů a charakteristiky infrastruktury. Původní hodnota, kterou jsme nasadili, vydržela přibližně tři týdny, než telemetrie ukázala, že je čas ji posunout. Od té doby jsme ji upravovali opakovaně – zjistili jsme totiž, že optimální práh driftuje s tím, jak enginy nabírají další glosářové termíny a jak se mezi aktualizacemi poskytovatelů mění vlastnosti embeddingových modelů.

Latence vyhledávání škáluje se složitostí glosáře, ne s velikostí payloadu. Lokalizační engine s 10 termíny se vyřeší v jednotkách milisekund bez ohledu na délku vstupu. Lokalizační engine s 500 termíny používá celou pipeline rozkladu, ale stále se vejde do latenčního rozpočtu robustního kroku background workflow.

Jak se kalibruje práh podobnosti pro vyhledávání v glosáři?#

Každý embedding n-gramu dotazuje vektorový index na nejbližší sousedy nad prahem podobnosti. Shody pod tímto prahem se zahazují jako šum.

Práh zároveň určuje přesnost i recall vyhledávání:

• Příliš benevolentní: do promptu pronikají nesouvisející termíny. Model vidí glosářový kontext, který se na vstup nevztahuje, a občas se jím řídí – výsledkem je výstup, který používá terminologii z nesouvisející domény.
• Příliš přísný: legitimní varianty formulací a morfologické tvary se vyloučí. „Deploying“ se neshodne s glosářovou položkou „deploy.“ Recall klesá.

Zjistili jsme, že správný práh se liší podle páru jazyků. Vyhledávání angličtina→němčina má jiné rozložení podobnosti než angličtina→japonština, kde se morfologická vzdálenost mezi zdrojovými n-gramy a glosářovými položkami strukturálně liší. Jeden globální práh vytvářel napříč měřenými páry jazyků nekonzistentní recall.

Práh se teď průběžně kalibruje podle skóre kvality pro jednotlivé páry jazyků z nezávislé scoring pipeline. Když scoring systém zaznamená nárůst nedodržování glosáře (termíny přítomné ve vstupu, ale chybějící ve výstupu), recall vyhledávání se zhoršil a práh se uvolní. Když scoring odhalí, že model používá nerelevantní terminologii, zvýšil se počet false positive vložení a práh se zpřísní.

Tato kalibrace běží každý týden. Musí – chování embeddingových modelů se mezi aktualizacemi poskytovatelů mění, rozložení glosářů se posouvá s tím, jak týmy přidávají termíny, a charakteristiky vstupních textů se vyvíjejí s růstem produktů.

Jak se získané glosářové termíny vkládají do lokalizačního modelu?#

Získané glosářové položky se dělí do dvou tříd omezení, které se v systémovém promptu modelu vynucují odlišně:

Nepřekládatelné termíny – řetězce ve zdrojovém jazyce, které se musí v cílovém výstupu objevit beze změny. Názvy značek, technické identifikátory, názvy produktů. Model je zachová doslova.

Vlastní překlady – mapování zdroj→cíl, která přebíjejí vlastní úsudek modelu. „Localization engine“ se musí změnit na „moteur de localisation.“ Model s nimi zachází jako s nevyjednatelnými lexikálními omezeními.

Obě třídy se do systémového promptu vkládají jako pravidla s výslovnou prioritou nad výchozím chováním modelu. Hierarchie promptu tak vynucuje dodržování glosáře nad jazykovými preferencemi modelu.

Tohle rozlišení je důležité při skórování: nezávislý scoring model kontroluje, zda byly nepřekládatelné termíny zachovány beze změny a zda byly vlastní překlady použity přesně. Dvě ověřovací kritéria pro dva typy omezení. Brzy jsme zjistili, že jejich sloučení do jediné kategorie „glosář“ dělá skórování nespolehlivým – termín zachovaný doslova, i když měl být přeložen (nebo naopak), by při jednotné kontrole vyšel jako správný.

Jak ověřujete kvalitu lokalizace v jazycích, kterými nemluvíte?#

Celá retrieval i localization pipeline může proběhnout bez chyby a přesto vytvořit terminologicky nesprávný výstup. Přehlédnutý glosářový termín nevytvoří žádný chybový signál. Chybně použitý vlastní překlad vrátí 200. Pipeline uspěje. Výstup je špatně.

Tohle je mezera v observabilitě lokalizace, kterou většina týmů nikdy nezacelí.

Vyhledávání je propojené s nezávislým asynchronním skórováním. Po dokončení lokalizačního requestu vyhodnotí samostatné scoring modely výstup vůči konfiguraci lokalizačního engine:

• Dodržování glosáře – byly nepřekládatelné termíny zachovány? Byly vlastní překlady použity přesně?
• Dodržování instrukcí – byla dodržena pravidla specifická pro daný jazyk?
• Vlastní skórovací kritéria – kvalitativní dimenze definované lokalizačním týmem pro každý engine

Skórovací modely běží na jiné infrastruktuře než lokalizační model. Pracují asynchronně v procesech na pozadí a spouštějí se po každém požadavku, který projde lokalizačním enginem s aktivním skórováním. Jeden model lokalizuje, jiný skóruje. Hodnocení napříč modely eliminuje problém sebehodnocení.

Výsledky skórování se promítají zpět do kalibrace retrievalu:

1. Skórování odhalí rostoucí trend nedodržování glosáře u dané jazykové dvojice
2. Analýza ukáže, že recall retrievalu klesl – práh se posunul vzhledem k aktuálnímu rozložení glosáře
3. Práh se upraví, recall se obnoví a skóre dodržování se stabilizuje

Právě tato smyčka dělá systém samokorigujícím. Skórování přináší observabilitu, kterou samotný retrieval postrádá. Bez ní týmy nasazují lokalizovaný obsah do jazyků, kterými nemluví, aniž by měly jakýkoli signál, jestli se glosář, který vytvořily, skutečně používá.

Proč se recall retrievalu v čase sčítá?#

Každý lokalizační požadavek, který správně použije termíny z glosáře, posiluje konzistenci terminologie napříč produktem. Každý požadavek, který nějaký termín mine, zavádí drift – jedna část rozhraní říká „lokalizační engine“, jiná „lokalizační nástroj“ a třetí „lokalizační modul“. Napříč 30 jazyky a při týdenních releasích se tyto nekonzistence vrství.

Rozdíl mezi vysokým a nízkým recallem retrievalu není rozdíl v kvalitě jednoho požadavku. Je to mechanismus, který v čase násobí konzistenci. Vysoký recall znamená, že glosář se prosazuje jednotně napříč každou částí rozhraní, každým jazykem i každým releasem. Nízký recall znamená, že glosář zabere jen občas – strukturálně je to téměř stejné, jako by žádný glosář neexistoval, jen degradace přichází pomaleji.

Co to znamená pro lokalizační inženýring#

Zde popsaný problém retrievalu není specifický pro jednu implementaci. Je strukturální pro jakýkoli systém, který se snaží o lokalizaci se zohledněním glosáře pomocí vyhledávání založeného na embeddingu. Nesoulad granularit mezi reprezentací vstupu na úrovni vět a cíli glosáře na úrovni frází existuje bez ohledu na to, jaký embeddingový model, jaká vektorová databáze nebo jaké LLM generuje výstup.

Týmy, které budují lokalizační automatizaci, stojí před volbou: buď přijmou retrieval na úrovni vět s jeho neviditelnou mezerou v recallu, nebo vybudují dekompoziční a kalibrační infrastrukturu, která ji uzavírá. Druhá cesta vyžaduje tři systémy – dekompozici na n-gramy, adaptivní retrieval a skórovací smyčku, která se promítá zpět do správy prahových hodnot. Každý z těchto systémů má vlastní provozní rytmus: logika dekompozice se vyvíjí se změnami vstupních formátů, prahy retrievalu se posouvají s růstem glosářů a kritéria skórování se zpřesňují podle toho, jak se lokalizační týmy učí, které dimenze jsou pro jejich obsah důležité.

Retrieval augmented localization v produkční kvalitě není jednorázové řešení, ale průběžná inženýrská praxe – systém, který se neustále buduje, instrumentuje, sleduje a ladí. Disciplína lokalizačního inženýringu, která se kolem této práce formuje, odráží provozní realitu: lokalizační infrastruktura vyžaduje stejnou soustavnou pozornost jako backendové služby, CI/CD pipeline a observability stacky.

Další kroky#

FAQ#

Co je retrieval augmented localization (RAL)? Retrieval augmented localization obohacuje každý lokalizační požadavek o termíny z glosáře, pravidla hlasu značky a instrukce specifické pro daný jazyk v čase inference – stejný vzorec retrieve-inject, na kterém stojí RAG, aplikovaný na lokalizaci. V kontrolované studii napříč pěti poskytovateli LLM a pěti evropskými jazyky snížil RAL počet terminologických chyb o 17–45 % ve srovnání se stejnými modely bez obohacení kontextu.

Proč embedding na úrovni věty míjí termíny z glosáře? Termíny v glosáři mají obvykle 1–3 slova. Když se embedují jako součást celé věty, rozpustí se v sémantickém vektoru věty. Embedding zachytí význam věty jako celku – „lokalizační engine“ uvnitř věty „Nakonfigurujte lokalizační engine pro produkci“ se samostatně neprojeví. Kosinová podobnost mezi vektorem věty a položkou glosáře pak klesne pod práh retrievalu.

Jak dekompozice na n-gramy zlepšuje recall retrievalu? Místo embedování celých vstupních řetězců systém před embedováním rozloží text na překrývající se fráze typu 1-gram, 2-gram a 3-gram. Každá fráze se pak stává samostatným retrieval dotazem. Dvouslovný termín z glosáře ukrytý v odstavci o 200 slovech tak dosáhne stejného recallu jako samostatný štítek – protože se dotazuje nezávisle na okolním kontextu.

Kolik režimů retrievalu systém používá? Tři. Skip (nula položek glosáře – retrieval není potřeba), preload (pod prahem kardinality – všechny položky se načtou přímo) a vector search (nad prahem – plná dekompozice na n-gramy a embedding). Režim se vybírá pro každý požadavek podle kardinality glosáře pro konkrétní jazykovou dvojici.

Jak se udržuje práh podobnosti? Práh se každý týden kalibruje podle skóre kvality pro jednotlivé jazykové dvojice z nezávislé skórovací pipeline. Když roste trend nedodržování glosáře, práh se uvolní, aby se zlepšil recall. Když do promptů pronikají nerelevantní termíny, práh se zpřísní. Různé jazykové dvojice vyžadují různé prahy kvůli odlišným morfologickým vzdálenostem.

Jak funguje skórování napříč modely pro kvalitu lokalizace? Po dokončení každého lokalizačního požadavku samostatný model – běžící na jiné infrastruktuře – vyhodnotí, zda byly termíny z glosáře správně použity, zda byly dodrženy instrukce specifické pro daný jazyk a zda byla splněna vlastní kritéria kvality. Jeden model lokalizuje, jiný skóruje. Tím se odstraňuje zkreslení sebehodnocení a vzniká observabilita, kterou samotný retrieval postrádá.

Co se stane, když je recall retrievalu nízký? Nízký recall retrievalu znamená, že se glosář uplatňuje nekonzistentně – jedna část rozhraní dostane správný termín, jiná ne. Napříč více než 30 jazyky a při týdenních releasích se tyto nekonzistence postupně mění v terminologický drift. Glosář existuje, ale neprosazuje se. V horizontu měsíců je to strukturálně téměř stejné, jako by žádný glosář neexistoval.

Co je mezera v observabilitě lokalizace? Lokalizační pipeline může proběhnout bez chyby a přesto vytvořit terminologicky nesprávný výstup. Opomenuté termíny z glosáře nevytvářejí žádný chybový signál – API vrátí 200 a překlad je gramaticky správně. Mezera v observabilitě je prostor mezi „pipeline proběhla úspěšně“ a „terminologie je správně“. Nezávislé skórování tuto mezeru uzavírá tím, že u každého požadavku měří dodržování glosáře.