Modele embeddingów po polsku - bge-m3, multilingual-e5 czy PolDense? Test na 900 pytaniach

Model embeddingów zamienia tekst na wektor liczb, dzięki czemu RAG, chatbot czy wyszukiwarka znajdują fragmenty podobne znaczeniowo do pytania, a nie tylko te z tymi samymi słowami. Który wybrać do polskich tekstów? Reguła z mojego testu na 900 prawdziwych pytaniach klientów: jeśli licencja Gemma Ci odpowiada, weź PolDense-150M (81,3 NDCG@10, 149 mln parametrów, działa na zwykłym CPU). Jeśli potrzebujesz licencji MIT lub Apache, weź multilingual-e5-large (80,7) albo bge-m3 (79,7, najodporniejszy na pytania bez polskich znaków i z literówkami). Do ok. 1 mln fragmentów wystarczy serwer z CPU, powyżej potrzebujesz GPU albo API. Cokolwiek wybierzesz, dodaj prefiks zapytania, którego wymaga model - bez niego PolDense traci prawie 30 punktów.

Który model embeddingów wybrać do polskiego RAG? Przetestowałem 10 modeli i BM25 na 900 prawdziwych pytaniach klientów: wyniki, odporność na brak polskich znaków i literówki, prefiks, który zabiera 30 punktów, ranking PIRB, ceny API, koszt przy dwóch skalach, licencje i kod.

W tym wpisie pokazuję wyniki mojego testu 10 modeli i BM25 na polskich pytaniach klientów, co się dzieje, gdy ktoś pisze bez polskich znaków albo z literówką, jak jeden zapomniany prefiks psuje wyniki, co mówi oficjalny polski benchmark PIRB, ile kosztują modele przez API i lokalnie przy dwóch skalach, jakie licencje pozwalają na użycie w firmie i jak przetestować modele na własnych danych - z kodem.

Czy w ogóle potrzebujesz modelu embeddingów - pierwsza decyzja

Najprostsza alternatywa to wyszukiwanie po słowach kluczowych (BM25), które masz za darmo w Postgresie czy Elasticsearchu. W moim teście BM25 osiągnęło 47,7 NDCG@10, a najlepszy model embeddingów 82,7. Na pierwszym miejscu właściwy fragment był w 33% przypadków przy BM25 i w 67% przy najlepszym modelu. Powód jest prosty: klient pyta „jak oddać towar”, a w dokumentacji jest „procedura zwrotu”, a polska odmiana sprawia, że „zwrot”, „zwrotu” i „zwrocie” to dla BM25 trzy różne słowa.

Mój test: 10 modeli na 900 pytaniach klientów

Jak testowałem: zbiór Allegro FAQ z konkursu PolEval 2022 - 900 prawdziwych pytań klientów i 921 fragmentów odpowiedzi (średnio 50 słów). Dla każdego pytania znane są poprawne fragmenty. Każdy model zamieniał na wektory wszystkie fragmenty i pytania, a ja sprawdzałem, czy właściwy fragment trafia na górę listy. Wszystko na 4-rdzeniowym procesorze Intel Xeon, bez GPU, z prefiksami zalecanymi przez autorów modeli (październik 2026).

Co z tego wynika:

• Polskie modele wygrywają w swojej wadze. PolDense-68M z 68 mln parametrów wypada lepiej niż wielojęzyczne modele ośmiokrotnie większe (mmlw-large, Qwen3-0.6B) i niemal równo z bge-m3.
• Popularny model to nie znaczy dobry po polsku. Qwen3-Embedding-0.6B, chętnie polecany w zagranicznych rankingach, zajął przedostatnie miejsce wśród modeli - na poziomie najmniejszego e5.
• Liczba parametrów nie mówi o szybkości. PolDense-68M jest mniejszy od mmlw-base, ale na CPU wolniejszy, bo obsługuje teksty do 8192 tokenów i bez specjalnych bibliotek przyspieszających (dostępnych głównie na GPU) liczy wolniej.
• Różnica między pierwszym a piątym modelem to 3,6 punktu. Wybór między nimi powinien wynikać z licencji, szybkości i odporności na błędy w pytaniach, a nie z samego rankingu.

Polskie znaki i literówki - test, którego nikt nie robi

Klienci często piszą „jak zwrocic towar” zamiast „jak zwrócić towar”. Sprawdziłem więc, co się dzieje, gdy z tych samych pytań usunę polskie znaki (dotyczyło to 92% pytań) albo wstawię jedną literówkę w dłuższym słowie:

Wnioski: bge-m3 jest najbardziej odporny - przy pytaniach bez polskich znaków i z literówkami traci najmniej, więc w wyszukiwarce dla klientów indywidualnych bywa pewniejszym wyborem niż model z wyższym wynikiem na czystych danych. Najbardziej cierpi BM25 i najmniejsze modele. Nie usuwaj polskich znaków z dokumentów „na wszelki wypadek” - modele uczono na poprawnym polskim i tylko pogorszysz wyniki.

Prefiks, o którym wszyscy zapominają

Wiele modeli wymaga, żeby przed pytaniem dopisać krótki prefiks: „query: ” w e5, „zapytanie: ” w mmlw, „[query]: ” w PolDense. To nie jest kosmetyka. Policzyłem, co się dzieje, gdy go pominiesz:

Bez prefiksu najlepszy model w teście spada niemal do poziomu prostego wyszukiwania po słowach. Taki błąd nie wywala aplikacji ani nie pokazuje komunikatu - wyniki są po prostu gorsze i nikt nie wie dlaczego. Dlatego prefiks trzymaj w jednym miejscu w kodzie razem z nazwą modelu i dodawaj go tylko do pytań, nie do dokumentów (chyba że model wymaga też prefiksu dokumentu, jak e5 z „passage: ”).

from sentence_transformers import SentenceTransformerMODEL = "OPI-PIB/PolDense-150M"QUERY_PREFIX = "[query]: "  # zmieniasz model? zmień też prefiksmodel = SentenceTransformer(MODEL, device="cpu")def embed_documents(texts: list[str]):    return model.encode(texts, batch_size=16, normalize_embeddings=True)def embed_query(text: str):    return model.encode(QUERY_PREFIX + text, normalize_embeddings=True)docs = ["Zwrot towaru możesz zgłosić w ciągu 14 dni w zakładce Moje zakupy.",        "Fakturę VAT pobierzesz po zaksięgowaniu płatności."]D = embed_documents(docs)q = embed_query("jak oddac towar ktory mi nie pasuje")print(docs[int((D @ q).argmax())])

Ranking PIRB - szerszy obraz na 41 zadaniach

Mój test to jeden typ danych: krótkie odpowiedzi FAQ. Szerszy obraz daje Polish Information Retrieval Benchmark (PIRB), który utrzymuje Ośrodek Przetwarzania Informacji: 41 zadań, od prawa i medycyny po pytania z portali internetowych. Wybrane wyniki (średnie NDCG@10, stan na 9 października 2026):

Kolejność w PIRB jest podobna do mojej: polskie modele PolDense na górze, e5-large przed bge-m3, a Qwen3-0.6B daleko w tyle. Różnica jest w skali wyników - PIRB zawiera dużo trudniejszych zadań (np. prawo), więc średnie są niższe. Ciekawostka z PIRB: wariant hybrydowy bge-m3 (55,75) wypadł minimalnie gorzej niż sam wariant gęsty (55,98), więc „hybryda zawsze pomaga” to mit - trzeba ją sprawdzić na swoich danych.

Modele przez API - OpenAI, Gemini, Voyage

Modele przez API nie są w PIRB, a bez kluczy nie mogłem ich uczciwie przetestować, więc nie podaję dla nich wyników po polsku. Ceny (październik 2026):

API ma sens, gdy nie chcesz utrzymywać serwera, a dane mogą trafić do dostawcy na warunkach biznesowych. Przed wyborem przepuść przez nie ten sam test, który pokazuję niżej - koszt testu na 1 000 fragmentów to ułamki centa.

Ile to kosztuje przy dwóch skalach

Założenie: fragmenty po ok. 300 tokenów, a pytania po ok. 20 tokenów.

Najważniejszy wniosek: samo liczenie embeddingów przez API jest tanie. Prawdziwe koszty są gdzie indziej:

• Pamięć bazy wektorowej. 10 mln wektorów o wymiarze 3072 (text-embedding-3-large) to ok. 123 GB, o wymiarze 512 (PolDense-68M) ok. 20 GB. To różnica w rachunku za bazę co miesiąc. Więcej o kosztach baz w porównaniu baz wektorowych.
• Zmiana modelu. Wektory z różnych modeli są niekompatybilne, więc zmiana modelu oznacza przeliczenie całego indeksu. Przechowuj teksty źródłowe i zaplanuj to z góry - piszę o tym w tekście o vendor lock-in w AI.
• Prywatność. Model lokalny nie wysyła dokumentów nigdzie, co przy danych osobowych upraszcza zgodność z RODO.

Licencje - co wolno w firmie

Jeśli dział prawny woli najprostszą licencję, wybierz e5-large albo bge-m3 - tracisz 1-2 punkty względem PolDense-150M, ale masz MIT.

Jak przetestować modele na własnych danych

Ranking to punkt wyjścia, a nie decyzja. Zbierz 50-200 prawdziwych pytań i dla każdego wskaż fragment, który powinien się znaleźć. Potem uruchom dla 2-3 kandydatów taki skrypt:

from sentence_transformers import SentenceTransformerCANDIDATES = {"OPI-PIB/PolDense-150M": "[query]: ", "BAAI/bge-m3": "",              "intfloat/multilingual-e5-large": "query: "}DOC_PREFIX = {"intfloat/multilingual-e5-large": "passage: "}def evaluate(name, qprefix, docs, questions, correct):    m = SentenceTransformer(name, device="cpu")    D = m.encode([DOC_PREFIX.get(name, "") + d for d in docs], normalize_embeddings=True)    Q = m.encode([qprefix + q for q in questions], normalize_embeddings=True)    top10 = (Q @ D.T).argsort(axis=1)[:, ::-1][:, :10]    hit1 = sum(top[0] == c for top, c in zip(top10, correct)) / len(correct)    hit10 = sum(c in top for top, c in zip(top10, correct)) / len(correct)    return round(100 * hit1, 1), round(100 * hit10, 1)# docs: lista fragmentów, questions: lista pytań, correct: indeks właściwego fragmentu dla każdego pytania# for name, prefix in CANDIDATES.items(): print(name, evaluate(name, prefix, docs, questions, correct))

Dodaj do zestawu pytania bez polskich znaków i z literówkami - tak, jak piszą Twoi użytkownicy. Wynik „właściwy fragment w top 10” mówi, czy RAG ma szansę odpowiedzieć dobrze, bo model językowy dostaje zwykle kilka najlepszych fragmentów, a nie tylko pierwszy.

Najczęstsze błędy

• Brak prefiksu zapytania - w moim teście do 30 punktów straty, bez żadnego komunikatu o błędzie.
• Wybór modelu z angielskiego rankingu. MTEB i rankingi zagraniczne nie mówią, jak model radzi sobie po polsku.
• Usuwanie polskich znaków z dokumentów. Modele uczono na poprawnym tekście, więc tylko pogarszasz wyniki.
• Mieszanie wektorów z dwóch modeli w jednym indeksie. Po zmianie modelu przelicz wszystko od nowa.
• Za długie fragmenty dla modeli z limitem 512 tokenów. e5 i mmlw obcinają dłuższy tekst bez ostrzeżenia, więc koniec dokumentu w ogóle nie trafia do wektora. Dziel teksty na krótsze fragmenty albo wybierz model z dłuższym limitem (bge-m3, PolDense - do 8192 tokenów).

---

Pomagam firmom budować wyszukiwanie i RAG na polskich dokumentach - od wyboru modelu embeddingów i testu na własnych danych po bazę wektorową i wdrożenie. Robię to w ramach budowy aplikacji AI i automatyzacji z AI. Napisz do mnie - zacznę od testu 2-3 modeli na próbce Twoich pytań.

Warto przeczytać:

• Bazy wektorowe - pgvector, Pinecone, Qdrant czy Weaviate? Jak wybrać do RAG i pamięci AI
• Zaawansowany RAG - chunking, wyszukiwanie hybrydowe i reranking
• Jak zbudować wewnętrzną bazę wiedzy firmy z AI (RAG w praktyce)
• Pamięć agenta AI - Mem0, Zep, Letta czy LangMem?