Jak wybrać model embeddingowy (również dla języka polskiego)

Kiedy klient zgłasza się z wymaganiem „wdróżcie nam RAG nad dokumentacją techniczną", pierwsza dyskusja zazwyczaj schodzi na duży model językowy: Claude czy GPT? Llama czy Mistral? Lokalnie czy cloud? Model embeddingowy pozostaje poza obszarem zainteresowania — większość zespołów sięga po OpenAI text-embedding-ada-002, bo widziała go w pierwszym quickstarcie, albo po cokolwiek, co właśnie wyskoczyło w dokumentacji używanego frameworka.

Rzeczywistość z praktyki: model embeddingowy to miejsce, w którym rozstrzyga się 15–20 % całkowitej jakości pipeline'u retrieval. Źle dobrany model sprawi, że trafne dokumenty znajdziecie w top-20 wyników, ale nie w top-5 — i LLM odpowie z nieistotnego kontekstu. Dla treści w języku polskim efekt ten jest wyraźniejszy niż dla angielskiego, bo większość popularnych modeli jest dominująco trenowana na danych EN. Niniejszy artykuł daje konkretny framework wyboru — wraz z tym, co działa i co nie działa w przypadku polszczyzny.

Co robi model embeddingowy — i dlaczego wybór ma znaczenie

Model embeddingowy przekształca tekst (dokument, pytanie, zdanie) w wektor — listę liczb, gdzie podobne teksty mają geometrycznie bliskie wektory. Retrieval szuka następnie wektorów bliskich zapytaniu. Wszystko inne w pipeline'ie RAG zależy od tego, czy „blisko w przestrzeni" naprawdę oznacza „semantycznie trafne".

Dwa wymiary, w których modele się różnią:

Wymiar wektora (768, 1 024, 3 072, 4 096) — wyższy wymiar pozwala uchwycić więcej informacji semantycznej, ale zwiększa wymagania pamięciowe, koszt przechowywania i latencję similarity search. Nowoczesne modele Matryoshka umożliwiają zmniejszenie wymiaru po treningu (np. z 3 072 do 768) przy minimalnej utracie jakości — jest to istotne przy skalowaniu do dziesiątek milionów wektorów.

Okno kontekstowe — ile tokenów model efektywnie „przetwarza" przy embeddowaniu jednego chunka. Starsze modele miały efektywne okno około 512 tokenów nawet przy nominalnym limicie 8 192; nowoczesne modele (BGE-M3, Qwen3-Embedding, NV-Embed-v2) radzą sobie z długimi dokumentami bez wyraźnej utraty jakości. Dla pipeline'u RAG z document-aware chunkingiem jest to bezpośrednio istotne — jeśli Państwa chunki mają 600–800 tokenów, model z efektywnym oknem 512 tokenów je przytnie.

MTEB: pomocnicze narzędzie orientacyjne, nie dogmat

MTEB (Massive Text Embedding Benchmark) to najczęściej stosowany benchmark dla modeli embeddingowych. Mierzy wyniki w dziesiątkach zadań: retrieval, clustering, classification, semantic similarity. Wyniki są publicznie dostępne na leaderboardzie Hugging Face i stanowią dobry punkt startowy.

Trzy ograniczenia, które należy mieć na uwadze:

• MTEB jest przede wszystkim angielski. Track wielojęzyczny istnieje, ale obejmuje tylko wybrane języki — polski nie jest standardową ścieżką językową MTEB. Wyniki na MTEB multilingual są zatem orientacyjne, nie gwarancją polskiej jakości.
• Dane benchmarkowe różnią się od Państwa danych. Model z wynikiem MTEB 70 może na konkretnych treściach domenowych (dokumentacja techniczna, teksty prawne, instrukcje serwisowe) osiągać znacznie gorsze wyniki niż model z wynikiem 65, trenowany na zbliżonym typie treści.
• Wyniki benchmarku nie mierzą latencji ani ceny. Model z MTEB 70 i latencją 400 ms jest dla aplikacji real-time gorszym wyborem niż model z MTEB 67 i latencją 15 ms.

MTEB jest zatem dobrym narzędziem do zestawienia shortlisty 3–5 kandydatów. Ostateczną decyzję podejmujcie na podstawie testu na własnych danych.

Modele open-weight: kiedy i dlaczego

Dla firm z obszaru SK/EU argument za self-hosted modelem embeddingowym jest silniejszy niż za samym LLM. Model embeddingowy:

• Działa na zwykłym serwerze GPU. BGE-M3 obsługuje typowy serwer GPU z latencją rzędu kilkudziesięciu milisekund na żądanie. To nie ta sama klasa wymagań sprzętowych co 70B LLM.
• Żadnych wycieków danych. Dokumenty pozostają w Państwa infrastrukturze — istotne dla regulowanych branż i zgodności z GDPR.
• Przewidywalny koszt. Zamortyzowany koszt serwera GPU jest stały; cena cloud API rośnie liniowo z wolumenem.
• Możliwość dostosowania. Przy wystarczającej liczbie danych domenowych można model douczyć (fine-tune) na Państwa tekstach — w przypadku cloud API nie jest to możliwe.

BGE-M3 (BAAI/FlagEmbedding) jest w 2026 produkcyjnym standardem dla open-weight wielojęzycznych nasadzeń. W jednym przebiegu łączy trzy typy retrieval: dense (semantyczny), sparse (oparty na słowach kluczowych w stylu BM25) i multi-vector (w stylu ColBERT, dokładniejszy). 100+ języków, w tym polski. Okno kontekstowe 8 192 tokeny. Wymiar 1 024 (dense). To nasz wewnętrzny default dla klientów z UE korzystających z lokalnego nasadenia.

Qwen3-Embedding (rodzina modeli firmy Alibaba, w tym wariant 8B) osiąga w 2026 najwyższe wyniki na MTEB multilingual leaderboardzie — około 70,58 dla Qwen3-Embedding-8B. Elastyczny wymiar Matryoshka (32–4 096), długie okno kontekstowe 32 768 tokenów. Dla retrieval w językach innych niż angielski jest to aktualnie najsilniejszy open-weight kandydat, jeśli dysponują Państwo wystarczającymi zasobami sprzętowymi (model 8B wymaga rzędu 16 GB VRAM przy pełnej precyzji, mniej przy kwantyzacji).

Llama-Embed-Nemotron-8B (NVIDIA) plasuje się w czołówce multilingual MTEB (250+ języków, open-weight, bezpłatny). Jeśli posiadają Państwo sprzęt NVIDIA i potrzebują maksymalnych wyników w kategorii open-weight, to silny kandydat.

Do szybkiego prototypowania lub niskokosztowych nasadzeń wystarczają mniejsze modele z rodziny sentence-transformers — all-mpnet-base-v2 lub paraphrase-multilingual-mpnet-base-v2 — jednak ich wyniki dla polskiego są wyraźnie niższe niż BGE-M3.

Cloud API modele: kiedy mają sens

Cloud embedding API (OpenAI, Google, Cohere, Voyage AI) mają sens w trzech sytuacjach:

1. 1.Nie dysponują Państwo własnym GPU. Nasadenie nad cloud API jest prostsze, bez zarządzania sprzętem.
2. 2.Wywołania są sporadyczne i wolumen niski. Przy kilku tysiącach żądań dziennie amortyzacja własnego serwera się nie opłaca.
3. 3.Wymagania multimodalne. Jeśli embeddują Państwo kombinację tekstu i obrazów (np. katalogi z rysunkami technicznymi), modele cloud, takie jak Cohere Embed v4, mają tu wyraźną przewagę.

OpenAI text-embedding-3-large (3 072 wymiary, Matryoshka, ~0,13 USD/1M tokenów) to niezawodny, dobrze udokumentowany wybór dla treści angielskich. Dla polskiego jego wyniki są nieco niższe niż u modeli zoptymalizowanych pod wielojęzyczność.

OpenAI text-embedding-3-small (~0,02 USD/1M tokenów) jest interesujący cenowo — dla angielskiego oferuje dobry stosunek wydajności do kosztów, ale dla wielojęzyczności zalecamy 3-large lub przejście na Cohere.

Cohere Embed v4 wyróżnia się dwiema właściwościami: okno kontekstowe 128 000 tokenów (ekstremalnie długie dokumenty bez konieczności chunkingu) i natywna obsługa multimodalna (tekst + obrazy). Cena ~0,12 USD/1M tokenów. Dla firm embeddujących dokumentację techniczną z obrazami lub schematami to istotna kombinacja.

Gemini Embedding 001 (Google) utrzymuje w 2026 jedno z najwyższych wyników na MTEB English (~68), z obsługą Matryoshka od 768 do 3 072 wymiarów. Cena ~0,004 USD/1k znaków. Dla angielskiego retrieval to silny wybór cloud; dla polskich treści obowiązuje ta sama uwaga co przy modelach OpenAI.

Język polski: co działa, a co nie

Polski nie jest osobną ścieżką językową w standardowym benchmarku MTEB. Zweryfikowane benchmarki specyficzne dla języka polskiego dla modeli embeddingowych nie są publicznie dostępne. Co wiemy z praktyki i z pokrewnych benchmarków (MIRACL, MKQA):

• Modele trenowane przede wszystkim na angielskim (starsze ada-002, all-MiniLM) osiągają dla polskich tekstów wyniki wyraźnie poniżej swojego benchmarkowego skóru EN.
• BGE-M3, Qwen3-Embedding i Llama-Embed-Nemotron obejmują język polski jako część wielojęzycznego zestawu treningowego — ich wyniki są zbliżone do wyników na pokrewnych językach słowiańskich (czeski, słowacki), co w praktyce sprawdza się dobrze.
• Dla polskiej dokumentacji technicznej (instrukcje maszyn, projekty elektryczne, normy PN) przeprowadzaliśmy wewnętrzne testy BGE-M3 vs. OpenAI text-embedding-3-large — BGE-M3 konsekwentnie osiągało o 8–12 % wyższą precision@5. To nie dramatyczna różnica, ale przy bardziej złożonych treściach kumuluje się.
• Jeśli dysponują Państwo wystarczającą ilością polskich danych domenowych (~5 000+ dokumentów), można douczyć model embeddingowy na własnych treściach (fine-tuning przez bibliotekę sentence-transformers). W regulowanych branżach (prawo, medycyna) może to podnieść precision o kolejne 5–10 %.

Dla hybrydowego wyszukiwania (BM25 + wektory) obowiązuje zasada, że dla polskich treści z precyzyjną terminologią (numery norm, artykuły ustaw, kody części) warstwa BM25 keyword jest ważniejsza niż w przypadku angielskiego — model embeddingowy może normalizować formy morfologiczne („napędu" vs. „napęd"), ale dokładne ciągi tekstowe BM25 wychwytuje pewniej.

Wymiar vs. jakość vs. koszt: praktyczny framework

Wyższy wymiar nie oznacza lepszej wydajności. Modele Matryoshka pozwalają na trening w pełnym wymiarze (3 072 lub 4 096) i inference w zredukowanym (256, 512, 768) — strata jakości jest minimalna, a zysk na szybkości i koszcie przechowywania jest realny.

Orientacyjne zakresy dla różnych scenariuszy:

• Szybki PoC, treść angielska, cloud: text-embedding-3-small (1 536 wym., niski koszt) lub text-embedding-3-large zredukowany do 512 wym. przez Matryoshka.
• Produkcja cloud, wielojęzyczne treści EU: Cohere Embed v4 (multimodal + długi kontekst) lub Gemini Embedding 001.
• Self-hosted, treści PL/CZ/SK: BGE-M3 jako default. Dla większego modelu z wyższym wynikiem: Qwen3-Embedding-8B lub Llama-Embed-Nemotron-8B.
• Skalowanie do dziesiątek milionów wektorów: rozważcie redukcję wymiaru Matryoshka (np. do 768) — przy 50 M wektorów oszczędność na storage jest znacząca.
• Treści multimodalne (tekst + obrazy): Cohere Embed v4 lub Voyage AI voyage-multimodal-3.5.

Aby porównać konkretne bazy wektorowe, w których będą Państwo przechowywać te embeddingi, przejdźcie do artykułu Bazy wektorowe — porównanie Qdrant, Weaviate, pgvector, Milvus.

Domain fit: najczęściej pomijany czynnik

Wynik benchmarku MTEB mówi o średniej wydajności na zróżnicowanych zestawach testowych. Państwa realne treści są wąskie i specyficzne:

• Dokumentacja maszynowa (opisy rysunków, instrukcje serwisowe, normy ISO) — techniczny język z precyzyjną terminologią, skrótami, numerami części. Dense embedding uchwyci semantykę; warstwa BM25 uchwyci precyzyjne kody. Tryb hybrydowy BGE-M3 jest tu zaletą.
• Teksty prawne (kodeks pracy, umowy, normy) — formalny język, odesłania do artykułów, nacisk na dokładne brzmienie. Testy pokazują, że model douczony domenowo (fine-tuned na polskich tekstach prawnych) przewyższa model generyczny o 10–15 % precision.
• Wewnętrzna firmowa KB (maile, zapisy ze spotkań, dokumenty procesowe) — zmienny język, różne style pisania. Tu model generyczny sprawdza się dobrze; douczanie ma sens dopiero przy dużym wolumenie (50k+ dokumentów).
• Katalog produktowy (SKU, opisy, parametry techniczne) — krótkie teksty, dokładne dopasowania. Dla e-commerce lub katalogu dystrybutora BM25 ma wyraźny udział; model embeddingowy uzupełnia semantykę („niebieska śruba z gwintem metrycznym" = „M6 niebieska śruba DIN 912").

Przed wyborem modelu odpowiedzcie sobie na pytanie: jaki odsetek Państwa zapytań wymaga rozumienia semantycznego, a jaki — dokładnego dopasowania leksykalnego? Dla firm przemysłowych z dokumentacją techniczną hybrydowe retrieval jest prawie zawsze właściwym wyborem — a przy hybrydowym retrieval potrzebny jest model embeddingowy, który natywnie obsługuje sparse wektory (BGE-M3), lub gotowość do zarządzania osobnym indeksem BM25.

Ewaluacja: jak przetestować przed wdrożeniem

Decyzji nie podejmujcie wyłącznie na podstawie MTEB — zbudujcie mini zestaw ewaluacyjny:

1. 1.Wybierzcie 100–200 realnych zapytań odzwierciedlających Państwa produkcyjny use-case.
2. 2.Dla każdego zapytania ręcznie zidentyfikujcie „idealne" dokumenty źródłowe (ground truth).
3. 3.Uruchomcie retrieval (top-5 lub top-10) dla każdego modelu kandydackiego.
4. 4.Zmierzcie precision@5 i recall@10 — procentowy udział trafnych dokumentów w top-5/10.
5. 5.Porównajcie również latencję i koszt embeddowania całego korpusu.

Ten test za 2–3 dni pracy pokaże realną różnicę między modelami na Państwa danych. Doświadczenie z praktyki: na treściach angielskich kandydaci różnią się o 3–8 % precision. Na polskich treściach technicznych różnice są wyraźniejsze — widzieliśmy różnice 15–20 % między słabszym modelem EN-primary a BGE-M3.

Aby ocenić cały pipeline RAG (nie tylko retrieval, ale też jakość generowania), przejdźcie do artykułu Jak ewaluować RAG (RAGAS).

Najczęstsze pytania

Czy BGE-M3 jest wciąż aktualnym wyborem w 2026?

Tak. BGE-M3 pozostaje produkcyjnym standardem dla open-weight wielojęzycznych nasadzeń właśnie dzięki unikalnej kombinacji retrieval dense + sparse + multi-vector w jednym przebiegu — żaden inny model open-weight nie oferuje tego w jednym modelu. Qwen3-Embedding-8B osiąga wyższe wyniki MTEB, ale wymaga więcej sprzętu i nie zapewnia natywnego sparse retrieval. Dla większości klientów z UE dysponujących istniejącym serwerem GPU BGE-M3 pozostaje dobrym defaultem.

Czy do języka polskiego potrzebuję specjalnego modelu?

Niekoniecznie. BGE-M3, Qwen3-Embedding i Llama-Embed-Nemotron obejmują język polski jako część swojego zestawu treningowego i działają w praktyce. Specjalnie trenowany polskojęzyczny model embeddingowy nie istnieje jako publiczny SOTA open-weight model w 2026. Jeśli dysponują Państwo dużym wolumenem polskich danych domenowych (10k+ dokumentów), douczenie generycznego modelu wielojęzycznego na własnych treściach może dać lepszy wynik — to jednak osobny projekt, nie rozwiązanie z pudełka.

Czy mogę użyć jednego modelu embeddingowego do retrieval i rerankingu?

Nie — model embeddingowy (bi-encoder) i reranker (cross-encoder) są architektonicznie różne. Model embeddingowy koduje wektory dokumentów i zapytań niezależnie (szybko); reranker ocenia parę (zapytanie + dokument) łącznie (dokładniej, wolniej). Do kompletnego pipeline'u potrzebujecie obu — więcej w artykule RAG pipeline — 3 ustawienia jakości.

Ile kosztuje embeddowanie całej firmowej bazy wiedzy?

Zależy od wolumenu. Orientacyjnie: 1 milion tokenów przy OpenAI text-embedding-3-large kosztuje ~0,13 USD; przy 3-small ~0,02 USD. Dla korpusu 10 000 stron PDF (~5 M tokenów) jednorazowy koszt embeddowania wynosi rzędu kilkudziesięciu dolarów przy cloud API. Przy self-hosted BGE-M3 koszt jest praktycznie zerowy po opłaceniu serwera GPU. Re-embeddowanie (przy zmianie modelu lub chunkingu) to ten sam koszt ponownie — dlatego warto wybrać właściwy model od razu.

Kiedy fine-tuning modelu embeddingowego ma sens?

Gdy posiadają Państwo treści domenowe, gdzie model generyczny systematycznie zawodzi (precision poniżej 70 %), dysponują dostateczną ilością danych (typowo 5 000+ trafnych par zapytanie–dokument) i mają system produkcyjny, w którym każdy punkt procentowy precision ma wartość biznesową. Branże regulowane (prawo, medycyna) to klasyczny przykład. Dla zwykłej wewnętrznej bazy wiedzy fine-tuning przekracza potrzeby — BGE-M3 lub Qwen3-Embedding wystarczy.

*MP Industrial Solutions pomaga firmom zaprojektować i wdrożyć architekturę RAG — od wyboru modelu embeddingowego, przez strategię chunkingu, po bazę wektorową i harness ewaluacyjny. Jeśli stoją Państwo przed wyborem lub chcą zmierzyć wydajność istniejącego nasadenia, chętnie przeprowadzimy bezpłatny 90-minutowy audit Państwa pipeline'u.*