Test 12 modeli embeddingowych po polsku i po angielsku
Przetestowaliśmy dwanaście lokalnych modeli embeddingowych. Zadanie nie jest trywialne: model musiał znaleźć w pomocy LibreOffice właściwy fragment na podstawie pytania. Dokumentacja liczy 911 stron w obu językach. Zadaliśmy po 500 pytań dla każdego języka, a wyniki porównaliśmy z klasycznym algorytmem BM25. Wszystkie dane publikujemy na GitHubie.
Po co embeddingi w firmowej dokumentacji
Aby zasilić modele LLM firmową wiedzą. Bez modeli embeddingowych, model LLM sam nie potrafi przeszukiwać dokumentów. Często pytając nie pamiętamy dokładnie czego szukamy, dlatego model embeddingowy musi znaleźć wszystkie frazy podobne do wyszukiwanej. Piszemy na przykład, co chcemy osiągnąć: "jak zablokować komórki przed edycją w Excelu". Model embeddingowy zamienia pytanie i fragmenty dokumentów na wektory liczb i szuka tych, które są najbliższe w przestrzeni znaczeń.
Model embeddingowy to kluczowy element każdego systemu RAG, czyli firmowej bazy wiedzy z asystentem AI, którą można pytać o tematy z dokumentacji. Jeśli model embeddingowy poda modelowi LLM złe fragmenty dokumentacji, to nawet Claude Opus pomyli się i odpowie źle. Dlatego przygotowaliśmy benchmark, który sprawdza, jak dobrze radzą sobie lokalnie dostępne modele embeddingowe, i to zarówno w języku angielskim, jak i po polsku. Więcej o samej firmowej bazie wiedzy piszemy w artykule RAG: firmowa baza wiedzy AI.
Jak testowaliśmy
Naszym korpusem testowym jest pomoc programu LibreOffice (help.libreoffice.org/latest): 911 stron dokumentacji w języku angielskim oraz w języku polskim. Strony pocięliśmy na fragmenty (chunki) według nagłówków h1 i h2, do około 1500 znaków. Łącznie otrzymaliśmy 3 101 fragmentów po angielsku i 3 200 po polsku.
- Pytania: zadawaliśmy po 500 pytań dla każdego języka, każde związane z inną stroną dokumentacji i z jednym poprawnym (złotym) fragmentem. Wygenerował je lokalnie model mistral-small3.2:24b, czyli spoza rodzin testowanych modeli embeddingowych. W ten sposób minimalizujemy bias związany z podobieństwem modelu.
- Nasze pytania miały trzy różne style: "goal" (opis celu, ale bez nazwy funkcji czy menu), "keyword" (słowo kluczowe - krótka fraza jak w wyszukiwarce) i "howto" (konkretne pytanie "jak zrobię X").
- Baza wektorowa: Jako bazę wektorową wykorzystaliśmy Qdrant 1.20.0 uruchomiony lokalnie, ze skonfigurowaną osobną kolekcją dla każdego modelu i języka.
- Embeddingi: liczone modelem załadowanym w Ollamie na karcie NVIDIA GeForce RTX 3090. Prefiksy zapytań i dokumentów zgodne z kartą każdego modelu.
- Punkt odniesienia: Jako punkt odniesienia przyjęliśmy wynik algorytmu BM25, czyli klasyczne wyszukiwanie po słowach.
Główna miara to MRR@10: średnia z odwrotności pozycji, na której model umieścił poprawny fragment, liczona do 10. miejsca i podana w procentach. Wynik 100 znaczyłby, że poprawny fragment zawsze jest pierwszy. Dodatkowo podajemy Hit@10, czyli w ilu procentach pytań poprawny fragment trafił do dziesięciu pierwszych wyników.
Testowane modele
Wszystkie testowane modele pochodzą z biblioteki Ollama.
| Model | Parametry | Kwantyzacja | Wymiar | Kontekst (tokeny) |
|---|---|---|---|---|
| qwen3-embedding:8b | 7,6 mld | Q4_K_M | 4096 | 40 960 |
| qwen3-embedding:4b | 4 mld | Q4_K_M | 2560 | 40 960 |
| qwen3-embedding:0.6b | 596 mln | Q8_0 | 1024 | 32 768 |
| embeddinggemma (v1) | 308 mln | BF16 | 768 | 2 048 |
| embeddinggemma-2 (tagi 270m, 440m, 570m, 740m) | 271 mln | Q8_0 | 768 | 262 144 |
| snowflake-arctic-embed2 | 567 mln | F16 | 1024 | 8 192 |
| bge-m3 | 567 mln | F16 | 1024 | 8 192 |
| nomic-embed-text-v2-moe | 475 mln | F16 | 768 | 512 |
| granite-embedding:278m | 277 mln | F16 | 768 | 512 |
| mxbai-embed-large | 334 mln | F16 | 1024 | 512 |
| nomic-embed-text (v1) | 137 mln | F16 | 768 | 2 048 |
| paraphrase-multilingual | 277 mln | F16 | 768 | 512 |
Wyniki
Tabela jest posortowana według MRR@10 po angielsku. Pogrubiono najlepszą wartość w kolumnie. Szybkość to liczba dokumentów (fragmentów) indeksowanych na sekundę na karcie RTX 3090.
| Model | MRR@10 EN | MRR@10 PL | Hit@10 EN | Hit@10 PL | Wymiar | Dok./s |
|---|---|---|---|---|---|---|
| qwen3-embedding:8b | 78,4 | 73,2 | 96,0 | 94,4 | 4096 | 12–17 |
| qwen3-embedding:4b | 74,7 | 70,8 | 95,4 | 93,8 | 2560 | 20–26 |
| embeddinggemma (v1) | 71,2 | 70,8 | 89,8 | 90,0 | 768 | 50–53 |
| snowflake-arctic-embed2 | 71,0 | 71,6 | 90,2 | 90,4 | 1024 | 47 |
| qwen3-embedding:0.6b | 69,6 | 63,6 | 90,4 | 85,8 | 1024 | 41–46 |
| embeddinggemma-2 (każdy tag) | 68,0 | 64,6 | 87,8 | 88,0 | 768 | 41–46 |
| nomic-embed-text-v2-moe | 67,8 | 65,6 | 87,8 | 87,4 | 768 | 61–66 |
| bge-m3 | 65,5 | 68,3 | 86,6 | 88,6 | 1024 | 42–49 |
| granite-embedding:278m | 64,8 | 57,6 | 86,8 | 77,0 | 768 | 66–68 |
| mxbai-embed-large (tylko angielski) | 66,0 | 30,1 | 84,8 | 48,2 | 1024 | 48–50 |
| nomic-embed-text (v1) (tylko angielski) | 62,7 | 39,1 | 83,0 | 57,2 | 768 | 70–74 |
| BM25 (bez stemmingu) (punkt odniesienia) | 62,2 | 54,1 | 83,2 | 78,6 | – | – |
| paraphrase-multilingual | 49,3 | 41,6 | 73,4 | 62,6 | 768 | 78–79 |
Szybkość zależy od sprzętu i ustawień karty, więc traktuj ją jako porównanie modeli między sobą, nie jako wartość bezwzględną.
Gdzie embeddingi wygrywają z BM25
Ogólny wynik ukrywa różnice między stylami pytań. Poniżej MRR@10 w podziale na trzy style, dla wybranych modeli i BM25.
| Model | Angielski | Polski | ||||
|---|---|---|---|---|---|---|
| goal | howto | keyword | goal | howto | keyword | |
| qwen3-embedding:8b | 74,7 | 83,5 | 77,1 | 67,0 | 81,1 | 71,6 |
| qwen3-embedding:4b | 71,5 | 78,7 | 74,0 | 63,8 | 78,7 | 69,9 |
| embeddinggemma (v1) | 61,9 | 74,8 | 76,8 | 60,0 | 77,6 | 74,7 |
| snowflake-arctic-embed2 | 60,5 | 74,2 | 78,2 | 56,8 | 80,0 | 78,0 |
| bge-m3 | 51,6 | 69,3 | 75,5 | 53,0 | 76,6 | 75,3 |
| nomic-embed-text-v2-moe | 51,6 | 73,7 | 78,1 | 49,2 | 75,7 | 72,0 |
| BM25 | 43,4 | 76,1 | 67,1 | 38,4 | 73,2 | 50,9 |
Przewaga qwen3-embedding:8b bierze się głównie z pytań "goal", czyli opisu celu bez nazwy funkcji. BM25 w tym stylu ma tylko 43,4 po angielsku i 38,4 po polsku, za to w stylu "howto" osiąga 76,1 i 73,2, bo takie pytanie często powtarza słowa z wyszukiwanego tekstu.
Co z tego wynika
Największy model wygrywa, choć nie zawsze
qwen3-embedding:8b jest najlepszy w obu językach i w trafieniu do dziesiątki (96,0 i 94,4 procent). W języku polskim jego przewaga nad snowflake-arctic-embed2 wynosi 1,6 punktu MRR i mieści się w granicach błędu: przedział ufności 95 procent to od −1,4 do +4,9. Statystycznie nie ma więc powodu, by dla samego polskiego wybierać znacznie wolniejszy model.
Mały model często wystarcza
embeddinggemma v1 i snowflake-arctic-embed2 dają około 71 punktów MRR w obu językach i indeksują około 50 dokumentów na sekundę. Qwen3 4B jest po angielsku o 3,5 punktu lepszy (74,7 wobec 71,2), ale po polsku nie daje przewagi (70,8 wobec 70,8 i 71,6), a indeksuje ponad dwa razy wolniej.
Modele trenowane głównie na angielskim osiągają słabe wyniki w języku polskim
Choć wydaje się to oczywiste, ten test empirycznie to potwierdził. Model mxbai-embed-large ma po polsku MRR@10 30,1, a nomic-embed-text v1 39,1. Algorytm BM25 daje znacznie lepszy wynik 54,1. Jeśli w bazie wiedzy są polskie dokumenty, model musi być wielojęzyczny. Wśród modeli wielojęzycznych najsłabiej wypadł paraphrase-multilingual: 49,3 po angielsku i 41,6 po polsku.
Nowszy nie znaczy lepszy: embeddinggemma-2
embeddinggemma-2 ma o 3,1 punktu niższy MRR po angielsku i o 6,2 po polsku niż pierwsza wersja. Różnice są wyraźne: przedział ufności 95 procent to od +0,9 do +5,5 na korzyść wersji pierwszej po angielsku i od +3,3 do +8,8 po polsku. Zmiana formatu prefiksu nie pomaga, a brak prefiksów obniża wynik o 2 do 3 punktów. Cztery tagi w Ollamie (270m, 440m, 570m, 740m) zawierają ten sam model tekstowy 271 mln parametrów i dają identyczne wektory. Większe tagi dokładają wyłącznie enkodery obrazu, dźwięku albo obu. Do wyszukiwania w tekście wystarczy 270m.
Który model wybrać
- Najwyższa trafność, mało dokumentów lub ważna jakość: qwen3-embedding:8b. Indeksowanie jest wolne, ale robi się je raz, a potem tylko dla nowych dokumentów i zmian.
- Polski i angielski, dużo dokumentów: snowflake-arctic-embed2 albo embeddinggemma v1. Podobna trafność, kilka razy szybsze indeksowanie, wektory od 768 do 1024 wymiarów.
- Bardzo długie fragmenty: modele z kontekstem 8 192 tokenów i więcej (snowflake-arctic-embed2, bge-m3, rodzina Qwen3). Modele z kontekstem 512 tokenów, jak granite-embedding czy mxbai, obcinają dłuższy tekst.
- Nie wybieraj modeli trenowanych na angielskim korpusie do polskich treści ani paraphrase-multilingual do wyszukiwania w dokumentach.
Ograniczenia testu. Jeden korpus (pomoc LibreOffice, tekst techniczny w formie instrukcji), po 500 pytań na język i jeden przebieg na model. Pytania pisał model językowy, który widział fragment, więc część z nich, zwłaszcza w stylu "howto", powtarza słowa z tekstu. To faworyzuje BM25, więc jego wynik traktuj jako górne oszacowanie. Na umowach, korespondencji czy dokumentach prawnych kolejność modeli może być inna. Test najlepiej powtórzyć na własnych dokumentach.
Embeddingi to tylko pierwszy etap. Wybrany model embeddingowy możesz podłączyć do własnej bazy wiedzy, w której odpowiada lokalny model językowy. Dobór sprzętu pod takie wdrożenie opisujemy w artykule Jaki serwer do lokalnego LLM, a przykład ładowania dokumentów do bazy wiedzy w benchmarku RAG na ThinkStation PGX.
Pytania i odpowiedzi
Jaki model embeddingowy wybrać do wyszukiwania w polskiej dokumentacji?
W naszym teście najwyższą trafność po polsku dał qwen3-embedding:8b (MRR@10 73,2), ale indeksuje 12 do 13 dokumentów na sekundę. Prawie tak samo dobrze po polsku radzi sobie snowflake-arctic-embed2 (71,6), który jest około trzy razy szybszy. Różnica 1,6 punktu między nimi mieści się w granicach błędu statystycznego. Dla polskich treści konieczny jest model wielojęzyczny.
Czy modele trenowane na angielskim nadają się do polskich tekstów?
Zdecydowanie nie. mxbai-embed-large i nomic-embed-text v1 po angielsku wypadają przyzwoicie, ale po polsku mają MRR@10 odpowiednio 30,1 i 39,1, czyli mniej niż BM25 (54,1). Prosty indeks słów kluczowych działa lepiej niż taki embedding.
Czy embeddinggemma-2 jest lepszy od pierwszej wersji?
W tym teście nie. Po angielsku ma MRR@10 68,0 wobec 71,2 u wersji pierwszej, a po polsku 64,6 wobec 70,8. Cztery tagi embeddinggemma-2 w Ollamie (270m, 440m, 570m, 740m) zawierają ten sam model tekstowy i dają identyczne wektory, więc do tekstu wystarczy najmniejszy.
Czy embedding zastępuje wyszukiwanie po słowach kluczowych (BM25)?
Nie zawsze. Gdy pytanie powtarza słowa z dokumentu, BM25 radzi sobie dobrze: w zapytaniach typu "howto" ma 76,1 po angielsku. Embeddingi wygrywają, gdy użytkownik opisuje cel własnymi słowami: w stylu "goal" BM25 ma 43,4, a qwen3-embedding:8b 74,7. W praktyce warto połączyć oba podejścia.
Źródła i dane
Dane z testu:
- Wyniki wszystkich modeli (JSON): MRR, Hit@k i nDCG na poziomie fragmentu i strony, wyniki w podziale na style pytań, szybkość, wymiar wektora i parametry modeli
- Kod benchmarku (GitHub: roxlukas/llm_benchmark): pobieranie korpusu, generowanie pytań i uruchamianie testu
Dane udostępniamy na licencji CC BY 4.0: możesz je wykorzystać, także komercyjnie, jeśli podasz jako źródło AI Transformation z linkiem do raportu.
Korpus: Pomoc LibreOffice, wersja angielska (en-US) i polska.