RAG wielojęzyczny (PL/EN/DE): 7 decyzji o indeksach, embeddings i normalizacji nazw własnych

1. Wprowadzenie: czym jest wielojęzyczny RAG (PL/EN/DE) i gdzie sprawia najwięcej trudności

RAG (Retrieval-Augmented Generation) to podejście, w którym model generatywny odpowiada na pytania z pomocą zewnętrznej bazy wiedzy: najpierw wyszukuje najbardziej pasujące fragmenty dokumentów, a dopiero potem tworzy odpowiedź na ich podstawie. W wariancie wielojęzycznym system musi działać spójnie dla treści i zapytań w kilku językach — tutaj: polskim, angielskim i niemieckim — często w sytuacji, gdy użytkownik pyta w jednym języku, a źródła są w innym.

W praktyce wielojęzyczny RAG bywa potrzebny tam, gdzie wiedza jest rozproszona między zespołami i krajami: dokumentacja produktowa, procedury, specyfikacje, korespondencja, raporty, treści prawne lub techniczne. Celem nie jest „tłumaczenie całego świata”, tylko trafne odnajdywanie i bezpieczne streszczanie właściwych fragmentów niezależnie od języka wejścia i języka źródeł.

Najważniejsza różnica względem RAG jednojęzycznego polega na tym, że dopasowanie semantyczne i leksykalne przestaje być „przezroczyste”. To, co w jednym języku jest oczywistym dopasowaniem, w innym może rozjechać się na poziomie znaczeń, form fleksyjnych, składni, a nawet zapisu nazw własnych. W efekcie wielojęzyczny RAG częściej cierpi na:

• spadek recall (system nie znajduje istotnych fragmentów, bo zapytanie i dokument „mijają się” językowo),
• spadek precision (system znajduje fragmenty podobne „tematycznie”, ale nie dotyczące właściwego wariantu pojęcia w danym języku),
• niestabilność odpowiedzi (to samo pytanie w PL/EN/DE prowadzi do innych kontekstów i innego wnioskowania).

Najwięcej trudności pojawia się zwykle w czterech obszarach:

• Warstwa wyszukiwania: mechanizmy podobieństwa i rankingu muszą radzić sobie z różnymi językami, a także z mieszanymi zapytaniami (np. zdanie po polsku z terminami po angielsku). Nawet jeśli embeddingi są „multilingual”, wyniki mogą faworyzować jeden język lub rodzaj sformułowań.
• Warstwa językowa: polski i niemiecki wnoszą dodatkowe wyzwania związane z odmianą, złożeniami, diakrytyką i wariantami zapisu. To wpływa zarówno na wyszukiwanie, jak i na interpretację intencji użytkownika.
• Nazwy własne i terminologia: encje (produkty, działy, dokumenty, skróty) bywają zapisywane inaczej w PL/EN/DE lub mają lokalne aliasy. Bez ujednolicenia system potrafi traktować je jak różne byty albo łączyć błędnie różne nazwy w jedną.
• Operacyjny koszt i ryzyko: wielojęzyczność zwiększa koszty utrzymania (więcej wariantów indeksowania, monitoringu jakości i oceny), a także ryzyko „dryfu znaczeń” — odpowiedź może brzmieć poprawnie, ale opierać się na kontekście z innego języka lub z innej wersji terminu.

Wielojęzyczny RAG (PL/EN/DE) wymaga więc świadomych decyzji projektowych już na starcie: jak organizować zasoby, jak reprezentować tekst w wektorach, jak obchodzić się z tłumaczeniem oraz jak utrzymać spójność nazw własnych i terminów. Bez tego system może działać poprawnie „średnio”, ale zawodzić dokładnie tam, gdzie użytkownik oczekuje najwyższej precyzji: w szczegółach, wyjątkach i lokalnych wariantach językowych.

Decyzja 1: architektura indeksów — wspólny indeks vs indeksy per język (plus wariant hybrydowy)

Pierwszą decyzją w wielojęzycznym RAG (PL/EN/DE) jest to, jak zorganizować indeks(y) do wyszukiwania. To wybór, który wpływa na prostotę utrzymania, trafność wyników, koszty infrastruktury oraz to, jak łatwo kontrolować zachowanie systemu dla każdego języka.

Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

W praktyce najczęściej rozważa się trzy podejścia: wspólny indeks, indeksy per język oraz wariant hybrydowy.

Opcja A: wspólny indeks dla wszystkich języków

Wspólny indeks oznacza, że dokumenty (chunki) w PL/EN/DE trafiają do jednej przestrzeni wyszukiwania, a język jest co najwyżej metadanymi. To podejście upraszcza architekturę i dobrze działa, gdy użytkownicy często zadają pytania „mieszane” lub nie wiadomo, w jakim języku padnie zapytanie.

• Kiedy ma sens: wielojęzyczne repozytoria, jedna globalna baza wiedzy, częste wyszukiwanie „ponad językami”, wiele zapytań w EN do treści w DE/PL (i odwrotnie).
• Główna korzyść: prostota — jeden indeks do budowy, wersjonowania i monitorowania; łatwiejsze „globalne” wyszukiwanie.
• Główne ryzyko: większa podatność na „rozjeżdżanie” wyników między językami (np. dominacja treści w jednym języku), jeśli nie ma jasnych reguł filtrowania/rerankingu oraz konsekwentnie ustawionych metadanych językowych.

Opcja B: indeksy per język (oddzielne dla PL, EN, DE)

W tym podejściu każdy język ma osobny indeks. Zapytanie trafia do indeksu wybranego na podstawie wykrycia języka, ustawień użytkownika lub kontekstu aplikacji. Rozdzielenie pomaga kontrolować jakość wyników i uniknąć „przecieków” między językami, ale wymaga dodatkowej logiki routingu i synchronizacji.

• Kiedy ma sens: treści są w praktyce „lokalne” (użytkownik oczekuje wyników w swoim języku), istnieją różnice wersji dokumentów między krajami/językami, albo trzeba odrębnie stroić wyszukiwanie i relewancję.
• Główna korzyść: większa przewidywalność wyników w danym języku; łatwiejsze egzekwowanie polityk (np. tylko DE dla pewnych ról/rynków) oraz osobne cykle aktualizacji.
• Główne ryzyko: większy narzut operacyjny (więcej indeksów do utrzymania), potencjalne „gubienie” wiedzy, gdy odpowiedź istnieje tylko w innym języku, a routing tego nie uwzględni.

Opcja C: wariant hybrydowy (najczęściej spotykany kompromis)

Hybryda łączy zalety obu podejść. Najczęściej spotykane warianty to: globalny indeks jako „fallback” oraz indeksy per język jako domyślne; albo wspólny indeks, ale z twardym filtrem językowym i dopuszczaniem cross-lingual tylko w określonych sytuacjach.

• Kiedy ma sens: gdy system ma domyślnie odpowiadać w języku użytkownika, ale czasem powinien sięgnąć do treści w innym języku (np. brak wyników, niska pewność, zapytania techniczne, dokumentacja źródłowa tylko w EN).
• Główna korzyść: kontrolowany cross-lingual retrieval bez utraty jakości dla scenariuszy „monojęzycznych”.
• Główne ryzyko: większa złożoność reguł — trzeba jasno zdefiniować, kiedy wolno mieszać języki i jak unikać sytuacji, w której wynik jest poprawny merytorycznie, ale nieużyteczny językowo.

Jak wybrać w praktyce (kryteria szybkiej decyzji)

• Oczekiwana polityka językowa odpowiedzi: jeśli odpowiedź zawsze ma być w języku użytkownika, indeksy per język lub hybryda zwykle dają lepszą kontrolę; jeśli dopuszczasz treści „ponad językami”, wspólny indeks upraszcza start.
• Asymetria zasobów: gdy większość wiedzy jest w jednym języku (często EN), wspólny indeks może częściej „ściągać” wyniki z dominującej części; per-język ogranicza to zjawisko.
• Różnice wersji treści: jeżeli te same dokumenty istnieją w różnych wersjach dla PL/DE/EN (nie tylko tłumaczenia), separacja indeksów ułatwia utrzymanie spójności i uniknięcie kolizji.
• Wymogi dostępu i zgodności: gdy uprawnienia, retencja lub zakres treści różnią się per kraj/język, per-język lub hybryda zwykle jest bezpieczniejsza.
• Operacje i koszty: im więcej indeksów, tym więcej procesów: budowa, walidacja, monitoring, reindeksacje. Wspólny indeks wygrywa prostotą, hybryda jest kompromisem.

Dobór architektury indeksów warto traktować jako decyzję „o sterowaniu ruchem”: czy system ma domyślnie szukać lokalnie (per język), globalnie (wspólny), czy lokalnie z kontrolowanym przełączaniem na globalne (hybryda). Ta decyzja ustawia ramy dla kolejnych wyborów dotyczących jakości dopasowania, obsługi wariantów językowych i pracy z nazwami własnymi.

Decyzja 2: wybór embeddingów — modele wielojęzyczne vs dedykowane, konsekwencje dla recall/precision

W wielojęzycznym RAG (PL/EN/DE) embeddingi decydują o tym, czy zapytanie i fragmenty dokumentów „spotkają się” w tej samej przestrzeni semantycznej. To wpływa bezpośrednio na recall (czy w ogóle znajdziesz właściwe fragmenty) oraz precision (czy w top-K dominują trafne wyniki, a nie semantycznie podobne, ale błędne). Wybór zwykle sprowadza się do dwóch rodzin podejść: modele wielojęzyczne oraz modele dedykowane per język.

1) Modele wielojęzyczne: jedna przestrzeń semantyczna dla PL/EN/DE

Modele wielojęzyczne starają się mapować teksty z różnych języków do wspólnej przestrzeni, tak aby zapytanie po polsku mogło skutecznie odnaleźć fragment po niemiecku (i odwrotnie). To podejście jest naturalne, gdy:

• użytkownicy pytają w jednym języku, a wiedza jest rozproszona w wielu,
• potrzebujesz wyszukiwania cross-lingual (np. PL → DE),
• chcesz ograniczyć złożoność utrzymania (jeden model, jedna metryka podobieństwa, jedna konfiguracja).

Konsekwencje dla recall/precision: modele wielojęzyczne często podnoszą recall w scenariuszach cross-lingual (bo „rozumieją” zbliżone znaczenia między językami), ale mogą obniżać precision w domenach o gęstej terminologii lub przy podobnych semantycznie pojęciach, które w różnych językach mają subtelnie inne użycie. Zyskujesz zasięg, czasem kosztem ostrości rankingu.

2) Modele dedykowane per język: maksymalizacja jakości w obrębie języka

Modele dedykowane są trenowane (lub dostrajane) pod konkretny język. W praktyce zwykle lepiej „czują” morfologię, idiomy i składnię danego języka, co bywa kluczowe dla PL i DE. Sprawdzają się, gdy:

• większość zapytań i dokumentów jest w tym samym języku,
• ważniejsza jest precyzja top wyników niż możliwość wyszukiwania między językami,
• masz osobne korpusy per język o różnej jakości i chcesz je niezależnie optymalizować.

Konsekwencje dla recall/precision: w obrębie jednego języka modele dedykowane często poprawiają precision (mniej „fałszywych przyjaciół” semantycznych), ale bez dodatkowych zabiegów potrafią obniżać recall w zapytaniach cross-lingual, bo przestrzenie embeddingów nie są porównywalne między językami.

3) Najczęstsze kompromisy (co realnie „psuje” wyniki)

• Różna granularność znaczeń między językami — to samo słowo/skrót może mieć inne zakresy w PL/EN/DE; wielojęzyczne embeddingi czasem „sklejają” te znaczenia.
• Terminologia domenowa — im więcej specjalistycznych nazw, tym ważniejsze staje się dopasowanie do domeny; modele ogólne (zwłaszcza wielojęzyczne) mogą mieszać terminy bliskie znaczeniowo.
• Morfologia (PL/DE) — odmiany i złożenia potrafią zmieniać dystrybucję tokenów; modele dedykowane często lepiej utrzymują precyzję dla wariantów fleksyjnych.
• Długość i styl tekstu — krótkie zapytania (np. 2–4 słowa) są bardziej wrażliwe na wybór modelu; różnice w precision w top-3 bywają wtedy największe.

4) Porównanie podejść (perspektywa praktyczna)

5) Proste reguły wyboru (bez nadmiaru teorii)

• Jeśli użytkownicy pytają w różnych językach i oczekujesz trafień w dokumentach w innym języku → zacznij od modelu wielojęzycznego.
• Jeśli prawie zawsze PL pyta o PL, DE pyta o DE, a krytyczna jest jakość top wyników → rozważ modele dedykowane.
• Jeśli masz mocno domenowe słownictwo i obserwujesz „semantyczne pomyłki” → testuj dedykowane embeddingi (lub wariant wielojęzyczny dostrojony domenowo, jeśli dostępny).

6) Minimalny test jakości, który warto zrobić od razu

Niezależnie od wyboru, oceń embeddingi na małym, ręcznie przygotowanym zestawie pytań i oczekiwanych fragmentów (PL/EN/DE), mierząc osobno:

• Recall@K — czy poprawny fragment pojawia się w top-K,
• Precision@K — jaki odsetek top-K jest faktycznie trafny,
• Cross-lingual hit-rate — czy zapytania w jednym języku znajdują właściwe odpowiedzi w drugim.

Wyniki tych trzech liczb zwykle szybciej ujawniają, czy model wielojęzyczny „przynosi” realne korzyści, czy tylko poszerza zasięg kosztem jakości rankingowej.

# szkic: porównanie dwóch modeli embeddingów na tym samym zbiorze
# (pseudokod – zależnie od użytej biblioteki i wektordb)
models = ["multilingual", "per_language_pl_en_de"]
metrics = {}
for m in models:
  index = build_index(embeddings=m)
  metrics[m] = evaluate(index, queries, gold_passages, k=10)
print(metrics)

Decyzja 3: strategia translacji — tłumaczenie zapytań, dokumentów czy obu stron (koszt, latency, drift)

W wielojęzycznym RAG (PL/EN/DE) translacja bywa „ukrytym” elementem, który najbardziej wpływa na koszt, opóźnienia i stabilność znaczenia w całym pipeline. Decyzja nie sprowadza się do pytania „czy tłumaczyć”, tylko co tłumaczyć (zapytania, dokumenty, oba) i kiedy (offline vs online), aby nie popsuć dopasowania w wyszukiwaniu i nie wprowadzić semantycznych przekłamań. W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo różnice w kosztach i jakości potrafią być odczuwalne natychmiast po wdrożeniu.

Trzy podstawowe warianty

• Tłumaczenie zapytań (query translation) — użytkownik pyta w PL/DE, system tłumaczy na język(y) korpusu i dopiero wtedy wyszukuje.
• Tłumaczenie dokumentów (document translation) — dokumenty są tłumaczone (zwykle offline) do jednego języka „pivot” albo do kilku wersji językowych i dopiero te wersje są indeksowane.
• Tłumaczenie obu stron (dual translation) — zapytania są tłumaczone, a dokumenty równolegle trzymane w tłumaczeniach; celem jest maksymalny recall kosztem złożoności i kosztów.

Porównanie: koszt, latency, ryzyko driftu

Co najczęściej psuje jakość (i dlaczego)

• Niejednoznaczność krótkich zapytań: w PL/DE łatwo o skróty, fleksję i elipsy; tłumaczenie może „zgadnąć” zły sens i obniżyć recall.
• Terminologia i nazwy własne: MT potrafi „przetłumaczyć” coś, co powinno zostać bez zmian (np. nazwa produktu, modułu, procedury), co powoduje rozjazd między pytaniem a dokumentem.
• Asymetria języków: niemiecki składa złożenia, polski odmienia, angielski bywa bardziej skrótowy — dosłowne tłumaczenie nie zawsze zachowuje tę samą granularność pojęć.
• Różnice w rejestrze: dokumenty formalne vs pytania użytkowników; tłumaczenie może „wygładzać” styl i gubić słowa-klucze.

Wybór „pivot language” i jego konsekwencje

Częsta praktyka to przyjęcie języka pośredniego (najczęściej EN) jako wspólnego mianownika. Ułatwia to spójność procesu, ale ma skutki uboczne:

• Plusy: prostsza kontrola jakości, jeden tor przetwarzania, łatwiejsze logowanie i debug.
• Minusy: ryzyko utraty niuansów przy podwójnym tłumaczeniu (np. DE → EN → PL) oraz „anglicyzacja” terminów, co może obniżyć trafność dla użytkowników PL/DE.

Minimalne zasady projektowe (bez wchodzenia w implementację)

• Decyduj na podstawie rozkładu języków: jeśli 80–90% dokumentów jest w jednym języku, tłumaczenie zapytań bywa wystarczające; przy mocno mieszanym korpusie rośnie sens wariantów z tłumaczeniem dokumentów lub obu stron.
• Rozdziel „język wyszukiwania” od „języka odpowiedzi”: nawet gdy wyszukujesz w EN, finalna odpowiedź może (i zwykle powinna) być generowana w języku użytkownika.
• Traktuj translację jako komponent z własną obserwowalnością: loguj wersję tłumaczenia, wejście/wyjście i czas; błędy MT często wyglądają jak „błędy retrievalu”.
• Unikaj kaskadowych tłumaczeń bez kontroli: im więcej kroków MT, tym większe ryzyko driftu i trudniejsza diagnostyka.

Krótki szkic przepływu (wariant: tłumaczenie zapytań)

// 1) wykryj język zapytania
// 2) przetłumacz zapytanie do języka indeksu (np. EN)
// 3) wykonaj retrieval
// 4) wygeneruj odpowiedź w języku użytkownika (PL/DE/EN)

Kluczowe jest, by strategię translacji dobrać do wymagań biznesowych: czy ważniejsza jest szybkość (latency i koszty runtime), czy maksymalne pokrycie (recall) w scenariuszach cross-lingual, oraz jak dużą tolerancję masz na drift semantyczny w treści i nazwach.

Decyzja 4: normalizacja nazw własnych, terminologii i encji — NER, aliasy, transliteracje, słowniki firmowe

W wielojęzycznym RAG (PL/EN/DE) nazwy własne i terminologia są częstym źródłem „cichych” błędów wyszukiwania: użytkownik wpisuje zapytanie w jednym wariancie (np. skrót, odmiana, pisownia bez znaków diakrytycznych), a dokument zawiera inny. Normalizacja to zestaw praktyk, które sprawiają, że ten sam byt (firma, produkt, moduł systemu, standard, lokalizacja, osoba, identyfikator) jest rozpoznawany i indeksowany spójnie niezależnie od języka i zapisu.

W tej decyzji chodzi o wyważenie dwóch celów:

• Recall — znaleźć dokumenty mimo różnic w pisowni, języku i odmianie.
• Precision — nie mieszać podobnych nazw (np. skróty, homonimy) i nie „przepinać” encji na zły byt.

Co dokładnie normalizować?

• Nazwy organizacji, produktów i systemów: różne wersje (pełna nazwa vs skrót), pisownia z/bez łączników, warianty językowe.
• Terminy dziedzinowe: synonimy i tłumaczenia (PL/EN/DE), wersje historyczne nazewnictwa, skróty branżowe.
• Encje „twarde”: kody, numery, identyfikatory, nazwy plików, adresy URL — tu kluczowa jest standaryzacja formatu (np. wielkość liter, separatory).
• Toponimy i nazwy własne z diakrytykami: warianty bez polskich/niemieckich znaków, różne transliteracje.

Trzy filary: NER, aliasy i słowniki firmowe

1) NER (Named Entity Recognition) pomaga wykrywać encje w dokumentach i zapytaniach, aby traktować je jako „specjalne tokeny” (np. kandydaci do kluczy metadanych lub pól indeksu). W praktyce NER jest najbardziej przydatny, gdy:

• masz dużo nazw własnych, które nie są dobrze reprezentowane w embeddingach (np. nowe nazwy produktów, skróty wewnętrzne),
• potrzebujesz wysokiej precyzji przy filtrowaniu lub rankingowaniu (np. dopasowania po konkretnych bytach),
• występują częste omyłki OCR lub niejednolita interpunkcja w źródłach.

2) Aliasowanie to mapowanie wielu wariantów zapisu na jedną reprezentację kanoniczną (np. „Nazwa Pełna” ⇄ „skrót” ⇄ „wariant bez znaków”). Aliasowanie bywa prostsze i skuteczniejsze niż „liczenie na embeddings”, gdy różnice są czysto powierzchniowe (pisownia, skróty, kolejność członów).

3) Słowniki firmowe (glossary/terminology) są kluczowe, gdy Twoja domena ma własny język: wewnętrzne nazwy modułów, procesów, ról czy dokumentów. Dobrze utrzymany słownik umożliwia:

• spójne etykietowanie encji (kanoniczne nazwy),
• kontrolowane synonimy i odpowiedniki językowe (PL/EN/DE),
• reguły „nie tłumaczyć” (np. nazwy produktu pozostają w oryginale),
• odróżnianie terminów podobnych (kontrola znaczeń, uniknięcie nadmiernego łączenia).

Transliteracje i warianty znaków (PL/DE) — kiedy mają znaczenie

W praktyce najczęstszy problem to zapytania bez znaków diakrytycznych oraz niemieckie warianty (np. ä/ae, ö/oe, ü/ue, ß/ss). Niezależnie od tego, czy używasz wyszukiwania leksykalnego, wektorowego czy hybrydowego, warto zapewnić mechanizm dopasowania takich wariantów. Najbezpieczniej traktować to jako równoległe formy: zachować oryginał, ale mieć też „złagodzoną” wersję do dopasowań.

Normalizacja w indeksie vs w zapytaniu

Praktycznie zawsze warto robić normalizację po obu stronach: dokumentów (podczas ingestu) i zapytań (w runtime). Różni się jednak odpowiedzialność:

• Ingest: wyciąganie encji (NER), budowa pól kanonicznych, trwałe słowniki aliasów, walidacja terminologii.
• Zapytanie: lekkie przekształcenia (diakrytyki, warianty ß/ss), podbicie zapytania o aliasy, wykrycie kandydatów-encji.

Minimalny schemat danych: kanon + warianty + źródło

Dobra normalizacja nie polega na „zastąpieniu” tekstu — raczej na dopisaniu ustrukturyzowanych sygnałów. Minimalny, praktyczny zestaw:

• entity_canonical: ustandaryzowana nazwa (jedna na byt),
• entity_aliases: lista wariantów (pisownia, skróty, warianty bez znaków),
• entity_type: typ encji (np. organizacja/produkt/lokalizacja/identyfikator),
• entity_source: skąd pochodzi mapowanie (słownik firmowy, NER, reguła, ręczne oznaczenie).

// Przykładowa reprezentacja encji (schemat poglądowy)
{
  "entity_type": "product",
  "entity_canonical": "…",
  "entity_aliases": ["…", "…"],
  "entity_source": "glossary"
}

Typowe pułapki

• Nad-normalizacja: zbyt agresywne łączenie różnych bytów (np. wspólny skrót dla wielu nazw) pogarsza precyzję i powoduje „hallucynacyjne” skojarzenia w odpowiedziach.
• Brak kontroli wersji słownika: zmiany w aliasach/kanonie bez wersjonowania utrudniają reindeksację i analizę regresji jakości.
• „Tłumaczenie” nazw, które powinny pozostać stałe: część nazw własnych nie powinna być lokalizowana — lepiej dodać aliasy niż podmieniać formę.
• Rozbieżność między NER a słownikiem: model może wyłapywać encje inaczej niż słownik; potrzebne są priorytety (np. słownik > NER) i mechanizmy konfliktów.

Efektem tej decyzji jest spójna warstwa encji, która stabilizuje wyszukiwanie w PL/EN/DE: poprawia trafienia dla nazw własnych i terminów domenowych, a jednocześnie ogranicza fałszywe dopasowania dzięki kanonowi, aliasom i kontrolowanemu słownikowi.

Decyzja 5: odmiana i składnia w PL/DE — lematyzacja, tokenizacja, query rewriting, fuzzy matching

Polski i niemiecki potrafią „zepsuć” wyszukiwanie w RAG nie dlatego, że są wielojęzyczne, ale dlatego, że są morfologicznie i składniowo wymagające. W PL dominuje bogata odmiana przez przypadki i swoboda szyku, w DE dochodzą złożenia, odmiana rodzajników oraz produktywne tworzenie długich rzeczowników. Jeśli pipeline retrievalu ignoruje te cechy, rośnie liczba missów (niski recall) albo dopasowań pozornych (spada precision).

1) Lematyzacja: kiedy pomaga, a kiedy szkodzi

Lematyzacja (sprowadzanie do formy podstawowej) najczęściej poprawia recall w PL/DE dla wyszukiwania leksykalnego (BM25/TF-IDF), bo „skleja” odmiany w jedną reprezentację. W praktyce decyzja nie jest binarna: możesz lematyzować tylko zapytanie, tylko dokumenty, albo utrzymywać warianty równolegle.

• Pomaga, gdy zapytania są krótkie i użytkownicy wpisują dowolne formy odmienione.
• Szkodzi, gdy istotne są formy fleksyjne jako sygnał (np. rozróżnienie znaczeń zależnych od przypadku) lub gdy lematyzator popełnia błędy dla domenowych terminów.
• Minimum higieny: jeśli nie lematyzujesz, rozważ przynajmniej dopasowania tolerujące odmianę (np. poprzez n-gramy) w warstwie leksykalnej.

2) Tokenizacja: diakrytyki, łączniki, liczby i złożenia

Tokenizacja to nie tylko „podział na słowa”. W PL/DE błędy tokenizacji często przekładają się na brak dopasowania po stronie indeksu leksykalnego oraz gorszą jakość cech pomocniczych (np. filtrowania lub rerankingu).

• Diakrytyki: warto obsłużyć wyszukiwanie w wariantach (z i bez znaków) — najlepiej jako osobne pola indeksu lub jako analiza z wariantami, aby nie tracić precyzji.
• Znaki łącznika: zapisy z „-” i bez „-” powinny się odnajdywać (np. różne konwencje w dokumentach i zapytaniach).
• Liczby i jednostki: rozdzielanie „10kW” vs „10 kW” oraz formatów dat/wersji wpływa na recall w dokumentacji technicznej.
• DE złożenia: warto rozważyć tokenizację, która oprócz całego złożenia indeksuje także składniki (albo subwordy), by zapytania krótkie trafiały w długie rzeczowniki.

3) Query rewriting: „dopasuj intencję”, nie tylko string

Query rewriting w PL/DE bywa prostym sposobem na zwiększenie trafień bez agresywnego fuzzy match. Chodzi o przepisanie zapytania do formy bardziej „indeksowalnej”: ujednolicenie zapisu, rozwinięcie wariantów, lekkie przeformułowanie składni.

• Ujednolicenie zapisu: warianty diakrytyczne, ß vs ss, warianty z łącznikiem.
• Uproszczenie fleksji: sprowadzenie do formy bliższej hasłom w dokumentach (np. mianownik), jeśli nie stosujesz pełnej lematyzacji.
• Rozszerzenie o warianty: dopisanie alternatywnych form (np. popularne skróty), ale z limitem, by nie rozwodnić zapytania.

Praktyczna zasada: rewriting powinien być odwracalny i kontrolowany (loguj wersję oryginalną i przepisane zapytanie), aby łatwo diagnozować spadki precision.

4) Fuzzy matching: bezpieczniki na literówki i warianty, ale z umiarem

Fuzzy matching (dopasowanie „prawie takie samo”) jest kuszące w językach z diakrytykami i długimi słowami, ale w PL/DE potrafi szybko zalać wyniki szumem. Dlatego zwykle traktuje się go jako ostatnią warstwę ratunkową albo ogranicza do wybranych pól.

• Najlepsze zastosowanie: literówki, brak polskich znaków, warianty ß/ss, pojedyncze niezgodności w długich tokenach.
• Ryzyko: krótkie słowa i częste morfemy w PL (lub fragmenty złożeń w DE) mogą dawać wiele fałszywych trafień.
• Bezpieczniki: minimalna długość tokenu dla fuzzy, ograniczenie liczby dopuszczalnych zmian, niższa waga fuzzy w rankingu oraz filtrowanie po języku/polu.

Prosty schemat łączenia technik (lexical + semantyka)

W praktyce te decyzje najczęściej lądują w hybrydowym retrievalu: semantyka (embeddingi) łapie parafrazy, a warstwa leksykalna (BM25 + analiza językowa) zabezpiecza dopasowania „twarde” (formy, liczby, zapisy). Poniżej minimalny pseudokod logiki zapytania, pokazujący kolejność „od najbezpieczniejszego” do „najbardziej agresywnego”.

// 1) Oryginalne zapytanie (lexical + vector)
q0 = query

// 2) Rewriting: normalizacja zapisu + warianty (kontrolowane)
q1 = rewrite(q0)   // np. diakrytyki, ß/ss, łączniki

// 3) Retrieval hybrydowy z analizą językową
candidates = union(
  bm25_search(q1, analyzer="pl/de"),
  vector_search(q0)
)

// 4) Fuzzy jako fallback (ograniczony)
if low_recall(candidates):
  candidates += bm25_fuzzy_search(q1, min_len=6, max_edits=1)

// 5) Reranking i wybór kontekstu
return rerank(candidates)

Kluczowa decyzja brzmi: czy próbujesz „naprawić język” w indeksie (lematyzacja/tokenizacja), czy w zapytaniu (rewriting), czy dopiero w dopasowaniu (fuzzy). Dla PL/DE najczęściej wygrywa kombinacja: lekka normalizacja + rozsądna analiza językowa w indeksie, a fuzzy tylko warunkowo.

Decyzja 6: chunking i metadane w kontekście języka — granice segmentów, pola językowe, filtrowanie

W wielojęzycznym RAG (PL/EN/DE) chunking i metadane decydują o tym, czy system w ogóle ma szansę zwrócić właściwy fragment w odpowiednim języku i kontekście. Nawet dobre embeddingi nie pomogą, jeśli segmenty są „pocięte” w miejscach psujących sens albo jeśli w indeksie brakuje jednoznacznej informacji o języku, wersji dokumentu i relacjach między tłumaczeniami. Ta decyzja sprowadza się do trzech obszarów: jak wyznaczać granice chunków, jakie metadane zbierać oraz jak filtrować i re-rankować wyniki, żeby unikać mieszania języków i błędnych dopasowań.

1) Granice segmentów: spójność znaczenia vs porównywalność między językami

W PL/EN/DE struktura zdań i długość jednostek tekstu bywa różna: tłumaczenia mogą być krótsze lub dłuższe, a niemieckie złożenia potrafią zagęścić informację w mniejszej liczbie „słów”. To sprawia, że chunkowanie „co N znaków” albo „co N tokenów” łatwo rozrywa definicje, wyjątki i warunki.

• Chunking strukturalny (po nagłówkach, akapitach, punktach list) zwykle lepiej utrzymuje sens i ułatwia cytowanie źródeł, zwłaszcza w dokumentach formalnych (procedury, regulaminy, instrukcje).
• Chunking zdaniowy bywa korzystny dla krótkich odpowiedzi i precyzyjnego dopasowania, ale wymaga dobrego sklejenia kontekstu (np. sąsiednie zdania), bo część informacji jest rozproszona.
• Chunking hybrydowy (struktura + limit długości + niewielkie nakładanie) najczęściej daje stabilne wyniki w wielojęzyczności, bo minimalizuje ryzyko urwania definicji w połowie, a jednocześnie trzyma segmenty w „rozsądnym” rozmiarze dla wyszukiwania.

W praktyce warto celować w segmenty, które odpowiadają naturalnym jednostkom wiedzy: definicji, regule, krokowi procedury, warunkowi. Jeśli dokument ma równoległe wersje PL/EN/DE, chunkowanie powinno też ułatwiać mapowanie fragmentów między językami (np. po numerach sekcji, identyfikatorach punktów, ścieżkach nagłówków), nawet jeśli długość tekstu się różni.

2) Metadane językowe: minimum, które ratuje retrieval

W środowisku PL/EN/DE metadane nie są dodatkiem, tylko mechanizmem sterowania wyszukiwaniem. Najczęstsze problemy wynikają z sytuacji, gdy w jednym indeksie lądują różne języki bez jednoznacznej etykiety lub gdy tłumaczenia traktowane są jak niezależne dokumenty bez relacji.

• language: jawny kod języka na poziomie chunku (a nie tylko dokumentu), bo w praktyce zdarzają się wstawki w innym języku, cytaty lub dwujęzyczne sekcje.
• source_id oraz source_type: identyfikacja źródła (np. dokument, strona, plik) i jego typ, co pomaga mieszać wiedzę z różnych repozytoriów bez chaosu.
• doc_version i effective_date: kontrola aktualności, szczególnie gdy istnieją różne rewizje oraz równoległe publikacje w kilku językach.
• section_path (ścieżka nagłówków) lub identyfikator rozdziału: wspiera zarówno trafność (kontekst), jak i późniejsze cytowanie.
• translation_group_id: wspólny identyfikator dla wersji językowych tego samego dokumentu lub sekcji, umożliwiający świadome wybieranie „tej samej” treści w języku użytkownika.

Jeśli metadane są ubogie, system często zaczyna „zgadywać” język i kontekst na podstawie podobieństwa semantycznego, co w PL/EN/DE kończy się mieszaniem wyników i spadkiem zaufania użytkownika do odpowiedzi.

3) Filtrowanie i priorytety: jak nie mieszać języków w wynikach

Wielojęzyczny retrieval powinien mieć jasne zasady: kiedy zwracamy wyniki tylko w języku zapytania, kiedy dopuszczamy inny język oraz jak zachować spójność w cytowanych źródłach. Bez tego łatwo o sytuację, w której odpowiedź jest po polsku, ale źródła po niemiecku (albo odwrotnie), co dla użytkownika bywa nieakceptowalne.

• Filtr języka jako domyślna reguła: jeśli użytkownik pisze po PL, najpierw szukaj w PL; analogicznie dla EN/DE. To prosta decyzja, która znacząco stabilizuje UX.
• Fallback między językami: gdy w języku zapytania brakuje wyników lub mają niską jakość, dopiero wtedy dopuszczaj inne języki, najlepiej z czytelnym oznaczeniem w źródłach.
• Priorytet wersji kanonicznej: jeśli organizacja uznaje jeden język za źródłowy (np. EN), można nadawać mu wyższy priorytet w sytuacjach spornych, ale bez łamania oczekiwań użytkownika co do języka odpowiedzi.
• Filtrowanie po wersji i dacie: ograniczanie wyników do aktualnej wersji dokumentu zapobiega sytuacji, w której system cytuje nieobowiązujące fragmenty w jednym języku, a aktualne w innym.

Kluczowe jest, aby filtrowanie nie było „twardym kagańcem” kosztem recall, lecz świadomą polityką: najpierw spójność językowa i aktualność, a dopiero potem kontrolowane rozszerzanie zakresu.

4) Chunking a cytowalność i zaufanie do źródeł

W RAG liczy się nie tylko znalezienie fragmentu, ale też możliwość wskazania użytkownikowi sensownego źródła. W tekstach PL/EN/DE różnice w długości zdań i stylu tłumaczeń sprawiają, że zbyt małe chunki gubią kontekst, a zbyt duże utrudniają precyzyjne wskazanie miejsca w dokumencie.

• Zbyt małe chunki: rośnie ryzyko wyrwania wyjątku lub definicji z kontekstu, co prowadzi do błędnych uogólnień.
• Zbyt duże chunki: spada precyzja dopasowania, a cytowanie staje się mało użyteczne (użytkownik dostaje „ścianę tekstu”).

Dobrze zaprojektowane granice segmentów oraz metadane rozdziału/sekcji pozwalają zachować równowagę: system wyszukuje precyzyjnie, a jednocześnie potrafi pokazać źródło, które użytkownik jest w stanie szybko zweryfikować.

5) Co warto ustalić jako „politykę” na starcie

• Jakie są domyślne granice chunków dla dokumentów strukturalnych, a jakie dla treści bardziej narracyjnych.
• Czy język jest przechowywany na poziomie dokumentu, czy obowiązkowo na poziomie chunku.
• Jak system ma się zachować, gdy istnieją równoległe wersje PL/EN/DE: czy traktować je jako niezależne, czy wiązać przez translation_group_id.
• Jakie filtry mają być domyślne: język, wersja, aktualność, typ źródła.
• Jak raportować użytkownikowi sytuacje, gdy wynik pochodzi z innego języka niż zapytanie (żeby unikać „cichego” przełączania kontekstu).

Decyzje o chunkingu i metadanych są często niedoszacowane, bo wydają się „inżynierią danych”, a w praktyce bezpośrednio determinują trafność, spójność językową oraz wiarygodność odpowiedzi w systemach PL/EN/DE.

Decyzja 7: ewaluacja jakości per język — zestawy testowe, metryki retrieval/answering, monitoring i regresje

Wielojęzyczny RAG (PL/EN/DE) najczęściej „psuje się” nie dlatego, że przestaje działać globalnie, tylko dlatego, że jeden język zaczyna odstawać: spada trafność wyszukiwania, rośnie liczba halucynacji, odpowiedzi stają się niekonkretne albo mieszają języki. Dlatego decyzje o indeksach, embeddingach i normalizacji nazw własnych powinny być spięte oddzielną ewaluacją dla PL, EN i DE, a nie jednym uśrednionym wynikiem.

1) Zestawy testowe per język: co mierzyć i jak je zbudować

Podstawą jest posiadanie reprezentatywnych pytań i oczekiwań osobno dla każdego języka, najlepiej z podziałem na typy użycia. W praktyce w firmowych dokumentach najszybciej wychodzą różnice między językami w trzech obszarach: (1) terminologia i nazwy własne, (2) wymagania zgodności i procedury, (3) treści „długiego ogona” (rzadkie tematy, rozproszone wzmianki).

• Zbiór zapytań: pytania krótkie (keywordowe) i pełne (zdaniowe), w każdym języku osobno, bez zakładania, że są one dosłownymi tłumaczeniami.
• Złoty standard kontekstu: wskazanie dokumentów/fragmentów, które powinny zostać odnalezione; to kluczowe, by oddzielić problem retrieval od problemu generowania.
• Oczekiwana odpowiedź: nie zawsze jako jedna „idealna” odpowiedź, ale jako lista faktów/warunków, które muszą się pojawić (szczególnie przy politykach, procedurach, SLA).
• Tagowanie przypadków: osobno oznaczaj zapytania z nazwami własnymi, skrótami, numerami dokumentów, jednostkami miar, datami, oraz pytania wymagające cytowania źródeł.

Warto dopilnować, by w każdym języku znaleźć zarówno treści natywnie napisane w tym języku, jak i takie, które są tłumaczeniami, bo ich styl i konsekwencja terminologiczna bywają inne i inaczej wpływają na wyniki.

2) Metryki retrieval: ocena „czy system znalazł właściwy materiał”

W RAG wielojęzycznym metryki retrieval są często bardziej stabilnym wskaźnikiem niż ocena samej odpowiedzi. Pomagają szybko wykryć, czy spadek jakości wynika z indeksu/embeddingów/normalizacji, czy z zachowania modelu generatywnego.

• Recall@k: czy w top-k znalazł się właściwy dokument/fragment; krytyczne przy zapytaniach regulacyjnych i proceduralnych.
• MRR / nDCG: czy właściwe źródło jest wysoko w rankingu, a nie „gdzieś w top-20”; ważne dla latency i kosztu (mniej chunków do przekazania do LLM).
• Coverage nazw własnych: odsetek zapytań, gdzie retrieval zwrócił kontekst zawierający właściwe encje (np. nazwy produktów, systemów, ról, lokalizacji) w danym języku.
• Stabilność per język: porównuj rozkłady wyników (nie tylko średnie), bo różnice często ujawniają się w ogonie (najtrudniejsze zapytania PL lub DE).

Dobrą praktyką jest raportowanie tych metryk w przekroju: PL vs EN vs DE, a także w przekroju typów pytań (z nazwami własnymi, z numerami dokumentów, wieloznaczne, „jak zrobić”, „kto jest odpowiedzialny”, itd.).

3) Metryki answering: ocena „czy odpowiedź jest poprawna, zgodna i użyteczna”

Nawet idealny retrieval nie gwarantuje dobrej odpowiedzi, szczególnie gdy pojawia się mieszanie języków, parafrazy zmieniające znaczenie albo pomijanie wyjątków. W wielojęzycznym RAG warto rozdzielać jakość odpowiedzi na kilka prostych osi, które da się konsekwentnie oceniać.

• Faktyczność i zgodność ze źródłami: czy odpowiedź wynika z dostarczonych fragmentów i nie dodaje nieuzasadnionych twierdzeń.
• Kompletność: czy odpowiedź zawiera wszystkie kluczowe warunki/wyjątki (często problematyczne w dokumentach prawnych i proceduralnych).
• Język i forma: czy odpowiedź jest w oczekiwanym języku, nie przełącza się na inny, i używa firmowej terminologii.
• Użyteczność operacyjna: czy użytkownik po odpowiedzi wie, co zrobić dalej (np. kroki, wymagane dane, odwołanie do właściwej sekcji dokumentu).

W przypadku firmowych dokumentów szczególnie ważne jest, by ocena obejmowała również zachowanie w trybie „nie wiem”: gdy brakuje podstaw w źródłach, system powinien to jasno komunikować i wskazywać brakujące informacje, zamiast zgadywać.

4) Monitoring produkcyjny: widoczność różnic między PL/EN/DE

Jednorazowa ewaluacja nie wystarczy, bo na wyniki wpływają aktualizacje treści, zmiany w indeksowaniu, nowy model embeddingów, a nawet przesunięcia w zachowaniach użytkowników. Monitoring powinien od początku rozróżniać języki i dawać sygnały ostrzegawcze, zanim pojawią się zgłoszenia.

• Segmentacja po języku: logowanie wykrytego języka zapytania i języka zwróconych źródeł, by wyłapać niepożądane „cross-lingual” dopasowania.
• Wskaźniki jakości pośredniej: częstotliwość ponowień zapytania, doprecyzowań, przełączania na inny język, skracania/wydłużania pytań — osobno dla PL/EN/DE.
• Analiza top-k źródeł: które dokumenty najczęściej zasilają odpowiedzi w danym języku; nagłe zmiany mogą sygnalizować drift w embeddingach lub w normalizacji nazw.
• Alerty regresji: progi spadku Recall@k/MRR lub wzrostu „no-answer” w jednym języku traktuj jako zdarzenie, nawet jeśli globalna średnia wygląda dobrze.

5) Regresje: jak bezpiecznie wprowadzać zmiany w RAG

Wielojęzyczne systemy są podatne na sytuację, gdzie poprawa w EN pogarsza PL lub DE. Dlatego zmiany warto wdrażać w sposób kontrolowany i mierzalny.

• Testy regresyjne per język: stały, niezmienny zestaw krytycznych pytań dla PL, EN, DE; powinien zawierać przypadki z nazwami własnymi i terminologią wrażliwą na odmianę.
• Porównania „przed/po”: oceniaj osobno retrieval i answering, aby szybko zlokalizować źródło pogorszenia.
• Akceptacja różnic: zdefiniuj, jakie odchylenie jest dopuszczalne dla każdego języka; unikaj jednego progu globalnego.
• Canary/A-B: jeśli to możliwe, wypuszczaj zmiany na części ruchu i obserwuj metryki w rozbiciu na język i typ zapytania.

Na zakończenie – w Cognity wierzymy, że wiedza najlepiej działa wtedy, gdy jest osadzona w codziennej pracy. Dlatego szkolimy praktycznie.

Rekomendacje praktyczne dla dokumentów firmowych (PL/EN/DE)

• Buduj zestawy testowe wokół procesów: pytania powinny odzwierciedlać realne scenariusze (procedury, polityki, instrukcje), a nie tylko definicje.
• Wymagaj cytowania źródeł tam, gdzie liczy się zgodność: w obszarach regulacyjnych i proceduralnych testuj, czy system wskazuje właściwy fragment i nie „uogólnia” wyjątków.
• Uwzględnij warianty nazw własnych: skróty, aliasy, odmiany, różne zapisy (w tym błędy użytkowników); te przypadki często różnicują PL/DE względem EN.
• Osobno oceniaj pytania cross-lingual: np. zapytanie po polsku o dokument po angielsku; to częsty firmowy przypadek i wymaga własnych kryteriów sukcesu.
• Zadbaj o „negatywy”: dodaj pytania, na które dokumenty nie zawierają odpowiedzi; mierz, czy system poprawnie odmawia i nie halucynuje.
• Raportuj wyniki wprost per język: decyzje optymalizacyjne podejmuj na podstawie profilu ryzyka w danym języku, nie na podstawie średniej z trzech.

Jak tworzyć instrukcje obsługi zgodne z normami w Adobe FrameMaker? 11 kwietnia 2026

KNIME + Python/R w jednym workflow: hybrydowe pipeline’y, które da się utrzymać 09 kwietnia 2026