Porównanie modeli embeddingowych 2026: text-embedding-3, Cohere, BGE-M3, Voyage & Jina

Model embeddingowy zamienia tekst na wektory liczbowe, dzięki którym podobieństwo semantyczne staje się mierzalne. Te wektory są podstawą każdego systemu RAG. Rzetelne porównanie modeli embeddingowych ocenia kandydatów pod kątem liczby wymiarów, długości kontekstu, benchmarków MTEB/MMTEB, wielojęzyczności, kosztów, możliwości self-hostingu i licencji. Dla tekstów w innych językach niż angielski obowiązuje zasada: pozycja w angielskim MTEB to nie pozycja na przykład dla niemieckiego. Miarodajne są MMTEB, MIRACL i MTEB-DE.

• Najlepszy niemiecki (własnościowy): Cohere Embed v4, lider wielojęzyczny, dostępny przez API, przez Azure lub jako Private Deployment we własnym VPC albo on-premises (stan na 2026 rok).
• Standard open source dla wielojęzycznego RAG: BGE-M3 (MIT), SOTA w MIRACL, łączy dense, sparse i multi-vector w jednym modelu.
• Najwyższy wynik MMTEB wśród otwartych modeli w porównaniu: Qwen3-Embedding-8B (Apache 2.0), ale wymaga znacznie większej mocy GPU niż BGE-M3.
• Otwarte wagi z zastrzeżeniem licencyjnym: Jina v3/v4, opracowane w Berlinie i od października 2025 część Elastic. v4 jest multimodalny i przetwarza także dokumenty wizualne. Wagi są wolne tylko do użytku niekomercyjnego. Komercyjnie korzystasz z Jina przez API albo z osobną licencją.

Dlaczego angielski ranking MTEB wprowadza w błąd

MTEB v1 jest zdominowany przez zadania w języku angielskim. Właściwe punkty odniesienia dla zastosowań wielojęzycznych to MMTEB (Massive Multilingual Text Embedding Benchmark z ponad 500 zadaniami i ponad 250 językami), MIRACL (wyszukiwanie jednojęzyczne w 18 językach) oraz niemieckie podzbiory, takie jak MTEB-DE, GermanQuAD-Retrieval i MIRACL-de. Te benchmarki regularnie przetasowują ranking: modele, które błyszczą po angielsku, po niemiecku często tracą 5-15 punktów nDCG@10, zwłaszcza przy złożeniach, języku specjalistycznym, terminologii prawniczej i medycznej oraz wyszukiwaniu długich wyrazów silnie zależnym od tokenizacji.

W niemieckojęzycznych korpusach B2B dochodzi jeszcze jedna trudność: nazwy własne, kody produktów, numery paragrafów, kody ICD, numery materiałów SAP, numery IBAN i sygnatury akt to dokładnie te tokeny, z którymi czyste modele dense retrieval radzą sobie słabo. Dlatego wybór modelu to zawsze decyzja o jakości języka niemieckiego, a nie o globalnym rankingu.

Porównanie najważniejszych modeli embeddingowych 2026

Poniższa tabela zestawia najważniejsze kryteria wyboru. Wyniki benchmarków, o ile nie podano linku, pochodzą z wewnętrznej bazy badawczej (stan na 2026 rok). Dane licencyjne modeli open weight pochodzą z kart modeli w Hugging Face (stan na październik 2026).

Własnościowe API: OpenAI, Cohere, Voyage

OpenAI text-embedding-3-large przy 3072 wymiarach i kontekście 8192 tokenów osiąga solidne wyniki po angielsku, ale w specjalistycznych zadaniach po niemiecku wyraźnie ustępuje Cohere i BGE. Pozostaje dostępny wyłącznie przez API (także przez Azure OpenAI w europejskich regionach, takich jak Sweden Central czy Switzerland North), więc jurysdykcja USA nadal obowiązuje. Cohere Embed v4 to własnościowy lider wielojęzyczny z najlepszymi wynikami dla niemieckiego, kontekstem do 128k i przycinaniem Matryoshka od 256 do 1536 wymiarów. Suwerennie uruchomisz go jako Private Deployment we własnym VPC albo on-premises. Voyage (od lutego 2025 w MongoDB) specjalizuje się w angielskim, finansach, prawie i kodzie; dla wyszukiwania w języku niemieckim nie jest punktem odniesienia.

Modele z otwartymi wagami: BGE-M3, Jina, Qwen3

BGE-M3 (BAAI, MIT) to standard open source dla wielojęzycznego RAG w Europie: 1024 wymiary, kontekst 8192 tokenów, SOTA w MIRACL i, co wyjątkowe, embeddingi dense, sparse i multi-vector w jednym modelu. Jina v3 i v4 powstały w Berlinie, ale Jina AI należy od października 2025 do Elastic. Przy kontekście 32k v4 przetwarza dodatkowo dokumenty bogate wizualnie (tabele, wykresy, diagramy) i osiąga ViDoRe 90,17 w trybie multi-vector. Uwaga na licencje: jina-embeddings-v3 jest objęty licencją CC BY-NC 4.0, a jina-embeddings-v4 licencją Qwen Research License. Obie pozwalają na self-hosting tylko w celach niekomercyjnych. Komercyjnie korzystasz z nich przez API albo z osobną licencją. Z tego samego powodu NV-Embed-v2 (NVIDIA, CC-BY-NC) odpada przy komercyjnych wdrożeniach w Europie. Swobodnie można natomiast używać jina-embeddings-v2-base-de (Apache 2.0), który przy 322 MB jest pragmatycznym dwujęzycznym wyborem dla stacków MŚP bez GPU, oraz Qwen3-Embedding (Apache 2.0).

Przykład z praktyki: koszty pamięci i Matryoshka

Konkretny przykład obliczeń dla 10 mln wektorów o 1024 wymiarach z indeksem HNSW:

• float32 (punkt odniesienia): surowe wektory 40 GB, plus 50-100% narzutu HNSW -> efektywny working set 60-80 GB.
• halfvec (float16): ok. 30-40 GB przy pomijalnej utracie recall.
• Scalar Quantization (SQ8): ok. 10-20 GB przy utracie recall wynoszącej tylko 1-3%.
• Binary + Rescore: ok. 5-10 GB, ale tylko z rescoringiem pełnych wektorów dla top-N, w przeciwnym razie utrata recall wynosi 30-60%.

Do tego dochodzi Matryoshka: text-embedding-3-large z 3072 wymiarami jest przewymiarowany dla większości przypadków korporacyjnego RAG. Przycięcie do 1024 lub 512 wymiarów kosztuje tylko ok. 1-3% jakości wyszukiwania, ale daje 3-6x mniej pamięci i niższe opóźnienia ANN. Nie wymaga to dodatkowego trenowania. To samo dotyczy Cohere Embed v4, mxbai-2d i Voyage 4. Przy nowych wdrożeniach zalecenie brzmi: wybierz model obsługujący Matryoshka i zapisuj wektory w 512-1024 wymiarach. BGE-M3 nie był trenowany metodą Matryoshka, ale ze stałymi 1024 wymiarami i tak mieści się w tym zakresie.

Nie zapominaj o rerankerze

Wybór modelu to dopiero połowa sukcesu. Reranker typu cross-encoder po pierwszym etapie wyszukiwania to najskuteczniejszy pojedynczy krok w pipelinie: zwykle podnosi recall@5 o 5-15 punktów procentowych. Według badania Anthropic dotyczącego Contextual Retrieval kontekstualizowane embeddingi w połączeniu z kontekstualizowanym BM25 obniżają odsetek błędów w wyszukiwaniu top-20 o 49%, a z dodatkowym rerankerem o 67%, za każdym razem w porównaniu ze standardowymi embeddingami. Suwerennymi rerankerami, które możesz hostować samodzielnie, są BGE Reranker v2-m3 (Apache 2.0) i mxbai-rerank-large-v2 (Apache 2.0). Jina Reranker v2 i v3 są objęte licencją CC BY-NC 4.0 i do zastosowań komercyjnych wymagają osobnej licencji. Własnościową alternatywą jest Cohere Rerank, dostępny przez API lub jako Private Deployment we własnym VPC albo on-premises.

Rekomendacja dla Europy i zastosowań wielojęzycznych

Konkretna kolejność dla korporacyjnego RAG w języku niemieckim (stan na 2026 rok) uwzględnia jakość, zapotrzebowanie na zasoby i licencję: 1. Cohere Embed v4 (najlepszy niemiecki, własnościowy, suwerenny tylko jako Private Deployment), 2. BGE-M3 (standard open source dla wielojęzycznego RAG, MIT, w pełni suwerenny, znacznie oszczędniejszy w eksploatacji), 3. Qwen3-Embedding-8B (Apache 2.0, najwyższy wynik MMTEB ~70,58 wśród otwartych modeli w tym porównaniu, ale wymaga znacznie większej mocy GPU), 4. Jina v3/v4 (opracowane w Berlinie, od 10/2025 część Elastic, v4 multimodalny, komercyjnie tylko przez API lub z licencją), 5. BGE-multilingual-gemma2 (jeszcze cięższy, ale mocny w kilku splitach). OpenAI text-embedding-3-large w zadaniach po niemiecku plasuje się wyraźnie niżej.

Najbardziej suwerenny stack: BGE-M3 lub Qwen3-Embedding, hostowany samodzielnie na jednym GPU L4/A10G, uzupełniony o BGE Reranker v2-m3. Wszystkie trzy modele są objęte licencją MIT lub Apache 2.0, a wszystkie warstwy działają w suwerennych chmurach z regionu DACH (STACKIT, IONOS, OTC, Hetzner). Cohere Embed v4 dochodzi tam, gdzie nieco lepsza jakość dla niemieckiego uzasadnia komercyjne zobowiązanie. Dla pełnej kontroli nad danymi Cohere oferuje Embed także jako Private Deployment we własnym VPC albo on-premises. Ważne dla zgodności z przepisami: embeddingi z danych osobowych z dużym prawdopodobieństwem same są uznawane za dane osobowe (zob. opinię EROD 28/2024). Dlatego przy regulowanych obciążeniach najmniej ryzykownym wyborem są modele, które można hostować samodzielnie. Jeśli zewnętrzny dostawca oblicza lub przechowuje embeddingi za Ciebie, także w chmurze w UE, potrzebujesz umowy powierzenia przetwarzania danych zgodnie z art. 28 RODO. Amerykańskie API nie jest wykluczone, ale wymaga dodatkowo podstawy transferu zgodnie z art. 44 i nast. RODO. Jeśli dostawca ma certyfikację w ramach EU-US Data Privacy Framework, wystarczy decyzja stwierdzająca odpowiedni stopień ochrony. Przy standardowych klauzulach umownych musisz dodatkowo sprawdzić, czy prawo w kraju docelowym nie podważa ochrony (ocena skutków transferu).

Dla agencji i decydentów B2B

Wybór modelu embeddingowego w równym stopniu decyduje o jakości wyszukiwania, kosztach pamięci i zgodności Twojego systemu RAG z RODO. Kto buduje dla rynków europejskich, powinien wybierać nie według angielskiego rankingu MTEB, lecz według potwierdzonej jakości w danym języku i suwerenności. Jako agencja z Wiednia Blck Alpaca projektuje i wdraża suwerenne, wielojęzyczne stacki RAG i agentów AI oraz towarzyszy Ci od wyboru modelu przez self-hosting aż po integrację rerankera. Odezwij się, jeśli chcesz zbudować zgodne z RODO środowisko embeddingów dla treści w języku niemieckim albo zoptymalizować istniejący system pod kątem jakości wyszukiwania po niemiecku.