Open-Source-Embedding-Models-Benchmark für RAG

NVIDIA Llama-Embed-Nemotron-8B führt bei der Genauigkeit. Bei den Kosten läuft Googles EmbeddingGemma-300m etwa 4x günstiger als Nemotron, bei einem kleinen Verlust an Genauigkeit.

Ergebnisse des Open-Source-Embedding-Models-Benchmarks

Erläuterung der Metriken

nDCG@3: Normalisierter diskontierter kumulativer Gewinn bei Cutoff 3. Bei einem relevanten Dokument pro Anfrage beträgt er 1 / log2(Rang + 1), wenn das Gold-Dokument in den Top 3 landet, andernfalls 0. Rang 1 erzielt 1.000, Rang 2 erzielt 0.631 und Rang 3 erzielt 0.500. Wir verwenden nDCG@3 als primäre Metrik, da Produktions-RAG-Pipelines die Top-3-bis-5-Chunks an das LLM liefern und der Primacy Bias dazu führt, dass Rang 1 überproportional wichtig ist.

nDCG@10: Dieselbe Formel mit Cutoff 10.

Recall@10: Anteil der Anfragen, bei denen das Gold-Dokument in den Top 10 erscheint.

MRR@10: Mittlerer reziproker Rang bei Cutoff 10. Gold auf Rang 1 erzielt 1.000, Rang 2 erzielt 0.500 und Rang 10 erzielt 0.100. Ähnliches Ziel wie nDCG@3, aber mit einer steileren Rangstrafe.

Top-1-Treffer: Anteil der Anfragen, bei denen das gold-relevante Dokument das einzige Top-Ergebnis ist. Die strengste Metrik und diejenige, die einem Lookup-Workflow ohne LLM am nächsten kommt.

nDCG@3-Ergebnisse nach Domäne

Das AVG-Ranking verdeckt Domänenumkehrungen. Harrier gewinnt CUAD, landet aber bei TechQA auf Platz sieben. SFR-2 belegt bei TechQA den zweiten Platz, bei CUAD jedoch nur den vierten. KaLM-12B ist bei MedRAG Fünfter und bei TechQA Neunter. nDCG@3 pro Domäne:

BM25 ist auf MedRAG konkurrenzfähig (0.7862, schlägt PubMedBERT und das mehrsprachige Granite) und schwach auf CUAD (0.5844, wo 11 von 14 dichten Models es übertreffen). Juristische Verträge enthalten eine dichte Entitätssprache, die lexikalische Übereinstimmungen belohnt. Bei medizinischen Abstracts übertreffen die besten dichten Models (Nemotron 0.9629, SFR-2 0.9620, jina-v5 0.9523) BM25 um 0.17 bis 0.18 absolute nDCG@3-Punkte.

Bootstrap-95 %-Konfidenzintervalle pro (Model, Domäne)-Zelle, einschließlich eines Vier-Wege-Gleichstands bei MedRAG an der Spitze und einer Harrier-Nemotron-Überschneidung bei CUAD, die das Punktschätz-Ranking einebnet, werden im Abschnitt zur Benchmark-Methodik berichtet.

Kosten pro Million Tokens

Die selbst gehosteten Kosten sind GPU-amortisiert: der Stundensatz geteilt durch die pro Stunde verarbeiteten Tokens. Der verwendete Pod war ein RunPod-Community-Cloud-H100 80GB SXM5 zu 2.99 $/Std. Die Wall-Clock-Zeit pro Model über den 551-Query-, 3-Korpus-Lauf (insgesamt ~46.2M Tokens) ergibt die folgenden Schätzungen für $/1M Tokens:

Die Formel:

GPU $/Std. = 2.99 $ (der RunPod-Community-H100-80GB-SXM5-Satz des verwendeten Pods). wall_seconds = gesamte Wall-Clock-Zeit jedes Models über den 551-Query-, 3-Korpus-Lauf. total_tokens ≈ 46.22M (Summe aus 3 Korpora + 551 Queries, Zeichenzahl ÷ 4 Heuristik).

Rechenbeispiel Nemotron-8B: (2.99 $ / 3600) × (1247.8 × 1.000.000 / 46.220.000) = 0.0224 $ pro 1M Tokens.

Fünf Models führen ihre Kostenstufe an (keine andere Zeile kostet weniger und erzielt gleichzeitig eine höhere Punktzahl): Granite-278m-multilingual am unteren Ende der Kostenleiter, gefolgt von Granite-small-r2, EmbeddingGemma-300m, jina-v5-text-small und Nemotron-8B am oberen Ende der Qualitätsleiter. Die Endpunkte spannen 13x bei den Kosten (0.0017 $/M bis 0.0224 $/M) und 0.23 nDCG@3 absolut (0.6952 bis 0.9249).

Domänenspezialisten vs. Generalisten

PubMedBERT, fine-tuned auf PubMed-Titel-Abstract-Paaren, ist offensichtlich das „richtige Werkzeug“ für die medizinische RAG-Retrieval auf PubMed. Es erzielt nDCG@3 = 0.7084 bei MedRAG, was unter der BM25-Lexikal-Baseline (0.7862) im selben Korpus liegt. Moderne Open-Source-Generalisten übertreffen es in seiner Trainingsdaten-Domäne um 0.22 bis 0.25 absolute Punkte:

Der Grund für das schlechtere Abschneiden des Spezialisten sind Alter und Rezept. PubMedBERT ist ein 110M-Parameter-BERT von 2022 mit symmetrischem Mean-Pooling und ohne Instruction-Prefix. Die Generalisten von 2024 bis 2026 basieren auf größeren Backbones, asymmetrischen Query- und Document-Prefixes sowie instruction-tuned Retrieval-Zielen. Der Architektur-Unterschied wiegt stärker als der Domänen-Match: Ein vier Jahre alter Fine-Tune kann selbst auf dem Trainingskorpus des Fine-Tunes nicht mit einem instruction-tuned Retriever der aktuellen Generation mithalten.

Die Regel für Käufer lautet, einen Domänenspezialisten vor dem Einsatz auf repräsentativen Queries gegen einen modernen Generalisten zu testen. Die Annahme „Der Spezialist gewinnt in seiner Domäne“ ist für Open-Source-Embedding-Models im Jahr 2026 nicht mehr sicher.

Erkenntnisse aus dem Open-Source-Embedding-Benchmark

Nemotron-8Bs TechQA-Vorsprung ist statistisch vom zweiten Platz getrennt

Nemotron-8B AVG nDCG@3 = 0.9249. Pro Domäne landet es bei 0.8602 auf CUAD, 0.9515 auf TechQA und 0.9629 auf MedRAG. Das TechQA-Ergebnis (0.9515 [0.923, 0.977]) überschneidet sich nicht mit dem zweitplatzierten SFR-Embedding-2_R (0.9109 [0.869, 0.949]). Die Bootstrap-CIs sind klar getrennt. Die 8B-Llama-3.1-Basis, instruction-tuned für Retrieval mit einem query-seitigen Instruct: …\nQuery: …-Prefix und einem symmetrischen document-seitigen Prefix, sorgt für einen absoluten nDCG@3-Vorsprung von 0.04 gegenüber der nächsten Zeile bei Workloads mit langen Dokumenten.

Die beiden Domänen, in denen Nemotron eindeutig gewinnt (TechQA, MedRAG), sind die Langdokument-Korpora, in denen die Instruction-Prefix-Asymmetrie am wichtigsten ist. CUAD ist die einzige Domäne, in der es nicht führt: Microsofts Harrier-oss-v1-0.6b (0.8720) übertrifft Nemotron (0.8602) bei juristischen Verträgen, obwohl es 13x kleiner ist, wobei sich die CIs jedoch überschneiden und der Vorsprung bei dieser Stichprobengröße statistisch nicht getrennt ist.

Ein 0.6B-Microsoft-Harrier-Model übertrifft jedes offene Model unter 7B Parametern

Microsoft Harrier-oss-v1-0.6b (veröffentlicht 2026-04 mit einer Qwen3-0.6B-Basis und einer MIT-Lizenz) landet bei AVG nDCG@3 = 0.8911, insgesamt Platz vier. Es übertrifft das 12B-Tencent-KaLM-Gemma3 (0.8057, Tencent-Community-Lizenz), das 7B-Salesforce-SFR-Embedding-2_R auf CUAD (0.8421 gegenüber Harrier 0.8720) sowie Googles EmbeddingGemma-300m (0.8706). Bei einem Vergleich mit gleicher Architektur liegt Harrier-0.6b (0.8911) um 0.074 nDCG@3 über Qwen3-Embedding-0.6B (0.8168), das auf derselben Qwen3-0.6B-Basis aufbaut. Der Trainingskorpus und das Instruction-Rezept verursachten den Unterschied, nicht die Parameterzahl.

Für Käufer ist Harrier die bestplatzierte Open-Source-Zeile, die mit einer Lizenz ausgeliefert wird, die ohne Einschränkungen für die kommerzielle Nutzung geeignet ist. SFR-2 (CC-BY-NC), Nemotron (NSCL-v1) und jina-v5 (CC-BY-NC) übertreffen es auf der AVG-Leiter, aber alle drei sind nur für Forschung oder nicht-kommerziell.

Ein medizinischer Spezialisten-Embedder verliert gegen BM25

NeuMLs PubMedBERT-base-embeddings wurde auf PubMed-Titel-Abstract-Paaren fine-tuned. Es ist offensichtlich das „richtige Werkzeug“ für einen medizinischen RAG-Benchmark auf PubMed. Es erzielt nDCG@3 = 0.7084 auf MedRAG, was absolut 0.078 unter der BM25-Lexikal-Baseline (0.7862) im selben Korpus liegt. Die besten Open-Source-Generalisten auf MedRAG liegen weit über beiden: Nemotron-8B 0.9629, SFR-Embedding-2_R 0.9620, Harrier-oss 0.9605, jina-v5 0.9523, KaLM-Gemma3-12B 0.9453.

Dies ist die Umkehrung, die ändern sollte, wie ein Käufer einen Domänenspezialisten auswählt. PubMedBERT ist ein 110M-Parameter-BERT von 2022 mit symmetrischem Mean-Pooling und ohne Instruction-Prefix. Das Generalistenfeld von 2024 bis 2026 basiert auf größeren Backbones, asymmetrischen Query- und Document-Prefixes sowie instruction-tuned Retrieval-Zielen. Bei MedRAG-Queries, die bereits medizinisches Vokabular enthalten, ist der lexikalische Match von BM25 von Natur aus stark, und die Spezialisierung von PubMedBERT fügt dem nichts hinzu.

Die praktische Schlussfolgerung lautet, einen Spezialisten-Embedder nicht allein nach dem Namen auszuwählen. Benchmarken Sie ihn vor der Entscheidung mit Ihren eigenen Queries.

Snowflake Arctic schwankt um 0.32 nDCG@3 zwischen den Domänen

Snowflakes snowflake-arctic-embed-l-v2.0 (568M, Apache-2.0, bge-m3-retromae-Derivat, mehrsprachig) erzielt nDCG@3 = 0.5846 bei CUAD-Rechtsverträgen und 0.9053 bei MedRAG-medizinischen Abstracts. Dasselbe Model, dasselbe Rezept, dasselbe Query-Format, mit einer Schwankung von 0.32 Punkten über zwei Domänen. Andere Models im Feld schwanken weniger: SFR-2 reicht von 0.8421 bis 0.9620 (Lücke 0.12), Nemotron von 0.8602 bis 0.9629 (Lücke 0.10), Harrier von 0.8408 bis 0.9605 (Lücke 0.12).

Der Mechanismus ist die Zusammensetzung der Trainingsdaten. Arctic wurde auf BEIR, MIRACL und CLEF abgestimmt; Rechtsverträge sind nicht vertreten. Für einen vertikalen Retrieval-Workload sind Domänen-Trainingsdaten wichtiger als Parameterzahl oder Kontextlänge.

So funktioniert Open-Source-Embedding-Inference

Open-Source-Embedding-Models laufen in diesem Benchmark in zwei Backends: sentence-transformers (12 Models) und vLLM (4 Models). Die Aufteilung betrifft nicht die Qualität, sondern die Laufzeiteffizienz bei Models ab 8B, wo die Standard-Python-Inference-Schleife von sentence-transformers zu langsam ist, um praktikabel zu sein.

Das Rezept pro Model ist wichtiger als die Wahl des Backends. Moderne Retrieval-Models verwenden asymmetrische Prefixes: Die Query-Seite wird in einen Instruct-artigen Prompt eingefasst (Instruct: Given a question, retrieve passages...\nQuery: <text>), während die Document-Seite schlicht bleibt. Der Pooling-Typ variiert: BERT-abgeleitete Models verwenden CLS-Pooling; LLM-abgeleitete Models (Llama, Mistral, Qwen3, Gemma3-Basis) verwenden Last-Token-Pooling; mehrsprachige Models verwenden häufig Mean-Pooling. Die HuggingFace-Karte jedes Models ist die maßgebliche Quelle dafür, welche Prefix- und Pooling-Kombination korrekt ist.

Backend-Stufe:

• vLLM: Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small
• sentence-transformers: Qwen3-0.6B, EmbeddingGemma-300m, Granite-Trio, SFR-2, Conan-v1, PubMedBERT, GIST, Snowflake Arctic, Microsoft Harrier

Beobachtete asymmetrische Prefix-Muster:

• Instruct + Query/Document: SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
• Built-in encode_query / encode_document: EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
• task / prompt_name (sentence-transformers-Parameter): jina-v5, Snowflake Arctic, Harrier
• Kein Prefix (symmetrisch): Granite-Trio, Conan, PubMedBERT, GIST

Pooling-Typ nach Basisarchitektur:

• CLS-Pooling: Granite r2 Trio, Snowflake Arctic
• Last-Token-Pooling: Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Mean-Pooling: EmbeddingGemma, Granite-multilingual, Conan, PubMedBERT, GIST

Die Verwendung des falschen Rezepts verschlechtert die Retrieval-Qualität stillschweigend, ohne dass es zu einem Absturz kommt. Jeder Benchmark für Open-Source-Embedder sollte eine Sanity-Untergrenze enthalten (Recall@10 unter 0.5 in allen Domänen ist bei jedem Model ein Warnsignal für eine Fehlkonfiguration, nicht für ein Ergebnis).

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Methodik des Open-Source-Embedding-Models-Benchmarks

Drei Retrieval-Domänen wurden evaluiert: CUAD-Rechtsverträge (246 Queries, 509 Verträge), TechQA-Kundensupport-Technotes (151 Queries, 28000 IBM-Technotes), MedRAG-PubMed-Gesundheits-Abstracts (154 Queries, 50000 Abstracts). Insgesamt 551 Queries.

Die Methodik zur Datensatzerstellung wird mit unserem früheren englischen Embedding-Models-Benchmark geteilt: Protocol-A-3-LLM-Konsens-Query-Generierung (rotierender Writer-Pool, fester Scorer, zwei Nicht-Writer-Validatoren pro Versuch), Korpus-Pinning per SHA-256-Hash, domänenspezifische Entity-Banned-Token-Whitelists zur Verhinderung lexikalischer BM25-Abkürzungen, Cohen’s κ-Inter-Rater-Übereinstimmung pro Validatorenpaar, aus dem bereits in jedem Query-JSON vorhandenen Feld bm25_rank_at_target synthetisierte BM25-Baseline-Ränge (Pyserini-äquivalent). Primäre Metrik nDCG@3 (RAG-realistisch, das, was Produktions-RAG-Systeme konsumieren); sekundäre Metriken nDCG@10, Recall@10, Recall@100, MRR@10, Top-1-Treffer.

Open-Source-spezifische Spezifikationen:

• GPU: 1 x NVIDIA H100 80GB SXM5 über RunPod Community Cloud
• Pod-Vorlage: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
• Stack: PyTorch 2.10.0+cu128, vLLM 0.19.1, transformers 5.6.2, sentence-transformers 5.4.1
• Versand pro Model: HF-Model-Card-Hauptpfad. ST für 12 Models, vLLM für Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.
• Chunking pro Model: Zeichenebenen-Trunkierung bei max_seq_length x 4 Zeichen pro Token, anschließend trunkierte der Tokenizer des Models auf seine tatsächliche maximale Sequenzlänge.
• Asymmetrisches Retrieval: Jedes Model, das dies unterstützt, erhält den auf der HF-Karte dokumentierten Query- und Document-Prefix. Bei einigen ist kein Prefix der dokumentierte Standard.
• L2-Normalisierung: einheitlich nach dem Pooling angewendet. Einige Models tun dies intern. Wir renormalisieren, um Konsistenz im gesamten Feld zu gewährleisten.
• Embedding-Cache-Schlüssel: enthält Prefix + Task + Prompt_Name + Max_Seq + Backend, sodass ein Prefix-Wechsel während des Laufs nicht stillschweigend veraltete Embeddings laden kann.
• Statistisches Protokoll: 10K Bootstrap-Resamples pro (Model, Domäne, Metrik)-Zelle, Perzentil-95 %-KI, Seed=2026.

Getestete Models

Sortiert nach AVG nDCG@3-Rang. Backend-Spalte: ST = sentence-transformers, vLLM = vLLM 0.19.

Ergebnisse der Bootstrap-95 %-Konfidenzintervalle

Die obige vollständige Rangliste ist ein einzelner Lauf pro (Model, Domäne)-Zelle. Die Varianz der Model-Initialisierung über Sitzungen hinweg wird nicht gemessen. Um die Varianz auf Anfrageebene innerhalb eines Laufs zu erfassen, resampeln wir den Rangvektor pro Anfrage für jede (Model, Domäne)-Zelle 10.000 Mal mit Zurücklegen (Perzentilmethode, Seed=2026, Stichprobengrößen CUAD n=246, TechQA n=151, MedRAG n=154). Bootstrap-95 %-KI pro Domäne für nDCG@3:

Die KIs verändern tatsächlich, welche Umkehrungen die Daten stützen. Auf CUAD überschneiden sich Harrier (0.8720, [0.836, 0.906]) und Nemotron (0.8602, [0.821, 0.897]), sodass der Harrier-auf-CUAD-Vorsprung bei dieser Stichprobengröße nicht klar getrennt ist. Auf TechQA überschneiden sich Nemotron (0.9515, [0.923, 0.977]) und SFR-2 (0.9109, [0.869, 0.949]) nicht, sodass Nemotrons TechQA-Vorsprung statistisch getrennt ist. Auf MedRAG liegen die Top Vier (Nemotron 0.9629, SFR-2 0.9620, Harrier 0.9605, jina-v5 0.9523) innerhalb der KIs der jeweils anderen und bilden einen statistischen Vier-Wege-Gleichstand. Die PubMedBERT-unter-BM25-Umkehrung auf MedRAG (0.7084 [0.641, 0.772] gegenüber BM25 0.7862) liegt am Rand der Überschneidung. Die zentrale Tendenz stellt den Spezialisten klar unter BM25, aber ein 3-Lauf-Cross-Session-Durchgang ist nötig, um ihn als getrennt statt überlappend aufzulösen.

Einschränkungen

Einzelner Lauf pro (Model, Domäne)-Zelle. Die obige Bootstrap-KI-Tabelle erfasst die Varianz auf Anfrageebene innerhalb eines Laufs (10K Resamples, Perzentilmethode, Seed=2026), aber die Varianz der Model-Initialisierung über Sitzungen hinweg wird nicht gemessen. Ein 3-Lauf-Cross-Midnight-Durchgang ist für v2.1 geplant. Die engeren Gleichstände, die von der KI-Tabelle aufgedeckt wurden (z. B. der Vier-Wege-MedRAG-Gleichstand an der Spitze, die Harrier-Nemotron-CUAD-Überschneidung, die marginale PubMedBERT-gegen-BM25-Umkehrung), würden am stärksten von einem Multi-Run-Durchgang profitieren.

Per-Model-Kontextlängen-Störfaktor. Models mit 512-Token-Kontextfenstern (Granite-278m-multilingual, PubMedBERT, Conan, GIST) sehen nur die ersten ~2K Zeichen jedes Dokuments. Models mit 8K- oder 32K-Kontext (Nemotron, KaLM-12B, jina-v5, Harrier, Granite r2 english) sehen das gesamte Dokument. Dies begünstigt Langkontext-Models bei TechQA (lange Technotes) und MedRAG (lange Abstracts).

Risiko der Kontamination von MedRAG-Trainingsdaten. Mehrere der evaluierten Models wurden auf PubMed-abgeleiteten Daten trainiert (PubMedBERT per Definition, möglicherweise Granite-278m-multilingual, möglicherweise Qwen3-Basis). Ein Teil des MedRAG-nDCG@3-Schubs könnte auf Überlappungen in den Trainingsdaten und nicht auf Retrieval-Qualität zurückzuführen sein.

Conan-v1 ist chinesisch trainiert. Die Aufnahme in rein englische Domänen ist ein lehrreicher Datenpunkt zum Sprach-Mismatch und kein fairer direkter Vergleich der englischen Retrieval-Qualität. Wir erwarten eine Unterperformance gegenüber englisch trainierten Wettbewerbern, und genau das zeigen die Daten.

Weiterführende Informationen

Entdecken Sie weitere RAG-Benchmarks, wie zum Beispiel:

• Top 10 mehrsprachige Embedding-Models für RAG
• Embedding Models: OpenAI vs. Gemini vs. Voyage
• Top-Vektordatenbank für RAG: Qdrant vs. Weaviate vs. Pinecone
• Reranker-Benchmark: Top 8 Models im Vergleich
• Multimodale Embedding-Models: Apple vs. Meta vs. OpenAI

Zitieren Sie diesen Benchmark

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Open-Source-Embedding-Models-Benchmark für RAG}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/open-source-embedding-models}},
  note   = {AIMultiple. Abgerufen am 10. August 2026}
}

Änderungsprotokoll

4 Aktualisierungen

Alle4Allgemein3Methodik1

1. 202625. Apr

   Der Top-K-Benchmark mit 16 Modellen auf Amazon-Rezensionen wurde durch einen Benchmark mit 14 Modellen zu CUAD, TechQA und MedRAG mit nDCG@3 und Kosten ersetzt.

2. 8. Jan

   Lizenz & kommerzielle Nutzung zur Übersicht der Open-Source-Einbettungsmodelle hinzugefügt.

3. 6. Jan

   Der Benchmark wurde um fünf zusätzliche Open-Source-Modelle erweitert.

4. 6. Jan

   Hardware, Batch-Größe und Präzision im Evaluierungs-Setup aktualisiert.

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenwissenschaftler bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten