Embeddingi dla języka polskiego: jak wybrać model do RAG

Firma z branży usług profesjonalnych wdrożyła RAG na 4 000 umów i procedur wewnętrznych. Pierwsze testy z popularnym modelem chmurowym dały recall@5 na poziomie 58%. Po zamianie na BGE-M3 uruchomiony lokalnie recall wzrósł do 79%. Różnica wynikała z jednego powodu: polska fleksja. Słowo „zamówienia" w dopełniaczu i „zamówienie" w mianowniku to dla prostego modelu dwa różne tokeny, dla BGE-M3 dwa punkty blisko siebie w przestrzeni wektorowej.

Polski ma bogatą fleksję: rzeczowniki odmieniają się przez 7 przypadków, czasowniki przez osoby, liczby i rodzaje. Jedno pojęcie pojawia się w dokumentach jako „dostawca", „dostawcy", „dostawcą", „dostawcy" (l.mn.). Modele trenowane głównie na angielskim traktują każdą formę jako odrębny token i uczą się tylko tych form, które widziały wystarczająco często w korpusie.

Dochodzą diakrytyki. Użytkownicy wyszukując wpisują często „zlecenie" zamiast „zlecenie" albo „wez" zamiast „weź". Model dobry dla polskiego powinien umieszczać obie formy blisko siebie w przestrzeni wektorowej, nie traktować ich jak różne słowa.

Trzecia kwestia to mieszany język dokumentów. Umowy, procedury ISO, korespondencja handlowa zawierają terminy angielskie (compliance, vendor, deliverable), skróty (NDA, SLA, KPI) oraz polskie zdania. Model monolingual dla polskiego może nie znać tych terminów w kontekście angielskim. Model wielojęzyczny radzi sobie lepiej, bo widział oba języki w tym samym zdaniu.

Przy wyborze modelu sprawdź pięć parametrów.

Wielojęzyczność z bogatym korpusem słowiańskim. Nie każdy model „wielojęzyczny" trenował na polskim w równej proporcji. BGE-M3 i multilingual-e5-large mają udokumentowany korpus europejski. Modele oparte na mBERT lub starszej wersji LaBSE radziły sobie gorzej z polską fleksją.

Wymiar wektora i pamięć. Wyższy wymiar (1536 vs 768) nie zawsze daje lepsze wyniki, za to zawsze wymaga więcej pamięci RAM w bazie wektorowej. Przy 100 000 fragmentów po 1024 wymiary indeks HNSW zajmuje około 400-500 MB. Przy 1536 wymiarach to 600-800 MB.

Długość kontekstu modelu. Embedding zamienia cały fragment na jeden wektor. Jeśli model obsługuje tylko 512 tokenów (około 350 słów), a Twoje dokumenty mają strony umów, tracisz informacje z dalszej części fragmentu. BGE-M3 obsługuje do 8192 tokenów w trybie ColBERT, standardowo 512. E5-large: 512. Dla długich dokumentów liczy się wtedy strategia chunkingu.

Self-hosting i RODO. Jeśli przetwarzasz umowy, dane kadrowe lub korespondencję handlową, self-hosting jest domyślnym wyborem. Model lokalny (przez Ollama lub bezpośredni serwer ONNX) nie wysyła fragmentów dokumentów do zewnętrznych API. To nie kwestia preferencji, lecz podstawa zgodności z RODO art. 28 (umowa powierzenia przetwarzania).

Szybkość indeksowania. Przy 50 000 fragmentów model działający na CPU serwera (np. BGE-M3 przez Ollama) zajmuje 40-90 minut przy pierwszym indeksowaniu. Model przez API chmurowe: 5-15 minut. Dla przyrostowego reindeksowania różnica jest mniejsza, ale warto ją uwzględnić w architekturze.

Wnioski praktyczne: przy projektach z RODO i dokumentami mieszanymi BGE-M3 lokalnie jest pierwszym wyborem. Przy projektach bez danych osobowych i z potrzebą szybkiego startu text-embedding-3-small przez API skraca czas wdrożenia o 2-4 tygodnie. Modele PL-only warto rozważyć wyłącznie przy indeksach czysto polskojęzycznych i bez angielskiej terminologii.

Ocena na benchmarkach publicznych (MTEB, BEIR) mówi mało o tym, jak model zachowa się na Twoich umowach czy procedurach ISO. Potrzebujesz własnego golden seta.

Zbuduj zestaw 50-100 par: pytanie reprezentatywne dla rzeczywistych zapytań użytkowników + lista 3-5 dokumentów, które powinny się pojawić w wynikach. Pytania zbieraj od faktycznych użytkowników systemu, nie wymyślaj ich przy biurku.

Następnie zmierz dwie metryki:

Recall@5 — ile z oczekiwanych dokumentów pojawia się w top 5 wynikach. Dobry wynik dla dokumentów firmowych: 70-80%. Poniżej 60% model nie nadaje się bez hybrydowego wsparcia BM25.

MRR (Mean Reciprocal Rank) — jak wysoko w liście wyników pojawia się pierwszy trafny dokument. Im wyżej, tym mniej kontekstu trzeba przesłać do modelu generatywnego, co obniża koszty tokenów.

Ewaluację warto przeprowadzić na dwóch do trzech modelach równolegle: zindeksuj ten sam zestaw fragmentów, odpytaj tym samym zestawem pytań, porównaj liczby. Narzędzia do tego: RAGAS (open source, Python) lub własny skrypt obliczający recall i MRR w 50 linijkach kodu.

Opisany wzorzec ewaluacji szczegółowo omawiamy w artykule o ewaluacji RAG.

Po wyborze modelu pipeline wygląda następująco.

Parsowanie dokumentów: PDF, DOCX, e-maile przez OCR lub parser natywny. Usunięcie nagłówków/stopek. Dla umów warto wyodrębnić sekcje numerowane jako osobne fragmenty.

Chunking: 300-600 tokenów na fragment z 10-15% nakładaniem. Przy długich klauzulach umownych nakładanie 20% zmniejsza ryzyko utraty kontekstu na granicy fragmentu. Szczegóły opisujemy w artykule o przygotowaniu danych pod AI.

Embeddingi: przekaż fragmenty do modelu (lokalnego lub przez API), zapisz wektory w bazie wektorowej (Qdrant, pgvector).

Wyszukiwanie: przy zapytaniu użytkownika oblicz embedding zapytania, wykonaj wyszukiwanie ANN, opcjonalnie połącz z BM25 (wyszukiwanie hybrydowe), przefiltruj przez reranker.

Generowanie odpowiedzi: przekaż top 3-5 fragmentów jako kontekst do LLM. Sprawdź, czy odpowiedź jest zakorzeniona w kontekście (faithfulness).

Pełne omówienie wyszukiwania semantycznego w firmie znajdziesz w artykule Wyszukiwanie semantyczne i embeddingi w firmie.

BGE-M3 był trenowany na wielojęzycznym korpusie obejmującym języki słowiańskie, w tym polski. W testach na polskich dokumentach prawnych i technicznych osiąga recall@5 o 10-20 punktów procentowych wyższy niż modele bazujące wyłącznie na angielskim lub starszym mBERT. Różnica jest szczególnie widoczna przy zapytaniach w formach przypadkowych (dopełniacz, narzędnik), które użytkownicy piszą naturalnie, a dokument zawiera formę mianownikową.

Kiedy Twój indeks zawiera wyłącznie polskie dokumenty bez terminologii angielskiej, a zależy Ci na jak najwyższej precyzji przy prostych zapytaniach faktograficznych. Modele PL-only (np. sdadas/Polish-RoBERTa-base-finetuned-polish-question-answering) mogą dawać nieznacznie lepsze wyniki przy czystym polskim tekście. Przy dokumentach mieszanych PL/EN lub korespondencji z angielskimi skrótami przewaga szybko znika.

Na typowym serwerze z 16 GB RAM i CPU (bez GPU) indeksowanie 10 000 fragmentów po 400 tokenów zajmuje 15-30 minut. Przy 50 000 fragmentach: 60-90 minut. Przeliczenie embeddingów odbywa się raz; kolejne zapytania są szybkie (kilkanaście milisekund). Jeśli zależy Ci na szybszym pierwszym indeksowaniu, warto rozważyć serwer z GPU lub API chmurowe (dla danych nieobjętych RODO).

Tak, ale każda kolekcja musi używać konsekwentnie tego samego modelu podczas indeksowania i odpytywania. Mieszanie modeli w jednym indeksie jest niedozwolone: wektory z różnych modeli nie są geometrycznie porównywalne. Jeśli chcesz zmienić model, musisz przeindeksować całą kolekcję. Dlatego decyzja o modelu powinna poprzedzać zbudowanie indeksu produkcyjnego.

Jeśli Twoje dokumenty zawierają dane osobowe (imiona, numery PESEL, adresy w korespondencji), ich wysłanie do zewnętrznego API embeddingów wymaga umowy powierzenia przetwarzania z dostawcą (art. 28 RODO) i analizy DPIA przy wysokim ryzyku. Self-hosting modelu lokalnie eliminuje ten problem: fragmenty dokumentów nigdy nie opuszczają Twojej infrastruktury. Przed wdrożeniem sprawdź też ocenę gotowości swojej organizacji do wdrożenia AI.