Embedding-Modelle für Deutsch 2026: BGE-M3, Qwen3-Embedding und E5 im Vergleich

Sie wollen ein RAG-System auf deutschen Dokumenten aufbauen? WZ-IT misst Embedding-Modelle mit Referenzfragen auf Ihrem Bestand und betreibt Retrieval, Reranker und Sprachmodell auf eigener Hardware, siehe RAG Proof of Value und interner KI-Assistent im KI-Hub. Termin vereinbaren

Das Embedding-Modell entscheidet in einem RAG-System, welche Textstellen überhaupt beim Sprachmodell ankommen. Findet die Suche den passenden Absatz nicht, kann auch das größte Sprachmodell die Frage nicht belegt beantworten. Trotzdem wird das Embedding-Modell oft nach dem ersten Tutorial gewählt und danach nicht mehr hinterfragt.

Für deutsche Dokumente ist die Auswahl 2026 breiter als noch vor zwei Jahren: BGE-M3, die Qwen3-Embedding-Familie, multilingual-e5, EmbeddingGemma, Granite Embedding R2 und mehrere Jina-Generationen stehen als offene Gewichte bereit, Mistral Embed als europäische API. Die Unterschiede liegen weniger in einer Benchmark-Zahl als in Lizenz, Kontextlänge, Vektordimension, Speicherbedarf und darin, welche Inferenz-Server das Modell vollständig unterstützen. Dieser Beitrag stellt die Modelle nach diesen Kriterien gegenüber. Stand September 2026.

Inhaltsverzeichnis

1. Was das Embedding-Modell in einem RAG-System entscheidet
2. Die Modelle im Überblick
3. Lizenzen: nicht jedes offene Modell ist kommerziell nutzbar
4. Was Benchmarks über deutsche Texte aussagen
5. Kontextlänge, Dimensionen und Speicherbedarf
6. VRAM und Hardware
7. Betrieb mit TEI, vLLM und Ollama
8. Welches Modell für welchen Einsatz
9. Modellwechsel bedeutet Neuindexierung
10. Unser Vorgehen bei WZ-IT
11. Weiterführende Guides

Was das Embedding-Modell in einem RAG-System entscheidet

Ein Embedding-Modell übersetzt Text in einen Vektor, eine Liste von Zahlen. Texte mit ähnlicher Bedeutung liegen im Vektorraum nahe beieinander. Bei der Indexierung wird jeder Abschnitt (Chunk) eines Dokuments eingebettet und in einer Vektordatenbank wie Qdrant oder PostgreSQL mit pgvector gespeichert. Bei einer Frage wird die Frage mit demselben Modell eingebettet, und die Datenbank liefert die nächstgelegenen Chunks. Die Grundlagen beschreibt der Wissensartikel Was ist RAG?.

Aus diesem Ablauf ergeben sich die Anforderungen an das Modell:

Das Embedding-Modell ist dabei nur ein Baustein. Die Aufteilung der Dokumente (Chunking) und die Kombination mit einer Stichwortsuche und einem Reranker (Hybrid Search und Reranking) beeinflussen die Trefferqualität ebenso stark.

Die Modelle im Überblick

Die Tabelle enthält die Modelle, die für deutschsprachige RAG-Systeme 2026 regelmäßig in Frage kommen. Angaben aus den jeweiligen Model Cards auf Hugging Face, Parameterzahlen aus den Modelldateien.

Werte in Klammern: Die Modelle unterstützen Matryoshka Representation Learning (MRL). Die Vektoren lassen sich auf eine kleinere Dimension kürzen, mit geringem Qualitätsverlust und deutlich kleinerem Index.

Einige Besonderheiten, die im Betrieb eine Rolle spielen:

• BGE-M3 erzeugt aus einem Modell drei Darstellungen: einen dichten Vektor, Sparse-Gewichte je Token (ähnlich BM25) und Multi-Vektoren im ColBERT-Stil (Model Card). Damit ist eine hybride Suche ohne zweites Modell möglich.
• Qwen3-Embedding erwartet auf der Anfrageseite eine Instruktion (Instruct: ... Query: ...), die Dokumente werden ohne Instruktion eingebettet. Ohne Instruktion sinkt die Retrieval-Leistung laut Qwen um etwa 1 bis 5 Prozent. Die Instruktion sollte auch bei deutschen Texten auf Englisch formuliert sein, weil die Trainingsinstruktionen überwiegend englisch waren (Model Card).
• multilingual-e5 verlangt die Präfixe query: und passage:, die Instruct-Variante eine Instruktion auf der Anfrageseite. Eingaben werden auf 512 Token gekürzt (Model Card).
• jina-embeddings-v2-base-de ist zweisprachig für Deutsch und Englisch trainiert, ausdrücklich auch für gemischte Eingaben (Model Card).
• Jina AI gehört seit Oktober 2025 zu Elastic (Elastic, Ankündigung). Die Modelle bleiben auf Hugging Face verfügbar und werden zusätzlich über den Elastic Inference Service angeboten.

Lizenzen: nicht jedes offene Modell ist kommerziell nutzbar

Offene Gewichte bedeuten nicht automatisch freie Nutzung im Unternehmen. Das betrifft vor allem die Jina-Modelle, die in vielen Vergleichen weit oben stehen.

Die Model Card von jina-embeddings-v3 formuliert es ausdrücklich: Wer das Modell außerhalb von AWS und Azure oder on-premises im Unternehmen einsetzt, nutzt es unter CC BY-NC 4.0, für kommerzielle Nutzung ist eine Anfrage beim Vertrieb nötig (Model Card, Abschnitt License). Bei jina-embeddings-v4 stand zunächst CC BY-NC 4.0, die korrekte Lizenz ist laut Model Card die Qwen Research License, weil das Modell auf Qwen2.5-VL-3B aufbaut (Model Card).

Für ein produktives RAG-System im Unternehmen bleiben ohne Zusatzvertrag damit BGE-M3, Qwen3-Embedding, multilingual-e5, Granite Embedding R2, jina-embeddings-v2-base-de und, unter den Gemma-Bedingungen, EmbeddingGemma.

Was Benchmarks über deutsche Texte aussagen

Der Massive Text Embedding Benchmark (MTEB) ist die übliche Referenz. Für die Auswahl deutscher Modelle ist er nur bedingt aussagekräftig, weil die bekannten Ranglisten über viele Sprachen und Aufgaben mitteln.

Mehrsprachiger Gesamtwert. Die Model Card von Qwen3-Embedding veröffentlicht die Mittelwerte im mehrsprachigen MTEB (MMTEB) über alle Aufgaben, Stand der Vergleichswerte 24. Mai 2025 (Model Card). Für jina-embeddings-v5-text-small nennt Jina 67,7 (Model Card).

Dieser Mittelwert enthält Klassifikation, Clustering, Bitext-Mining und weitere Aufgaben, die für RAG keine Rolle spielen.

Deutsches Retrieval. Aussagekräftiger für RAG ist das Retrieval auf deutschen Texten. MTEB enthält dafür den Benchmark MTEB(deu, v1) mit den Retrieval-Aufgaben GermanQuAD, GermanDPR, XMarket und GerDaLIR (MTEB-Benchmarkdefinition). Für die aktuellen Modelle liegen dort nicht durchgängig Ergebnisse vor. Eine Aufgabe, für die es für fast alle Kandidaten Werte gibt, ist der deutsche Teil von MIRACL (Retrieval auf der deutschen Wikipedia, Variante mit Hard Negatives). Die folgenden Werte stammen aus dem öffentlichen MTEB-Ergebnisrepository, Stand September 2026.

Drei Beobachtungen aus beiden Tabellen:

1. Größer ist nicht automatisch besser. Im deutschen Retrieval liegt das 4B-Modell vor dem 8B-Modell, obwohl das 8B-Modell im Gesamtwert führt.
2. Gesamtwerte können täuschen. multilingual-e5-large-instruct liegt im MMTEB-Mittel vor BGE-M3, im deutschen Retrieval aber deutlich dahinter.
3. Wikipedia ist nicht Ihr Bestand. Erlasse, Verträge, Handbücher, Wartungsprotokolle und gescannte PDFs verhalten sich anders als Lexikonartikel. MTEB führt inzwischen mit RTEB(deu, beta) einen deutschen Retrieval-Benchmark mit Rechts-, Gesundheits- und Geschäftsdaten, der teils auf nicht öffentlichen Datensätzen beruht (Benchmarkdefinition).

Die Benchmarks eignen sich, um die Kandidatenliste auf drei oder vier Modelle zu verkleinern. Die Entscheidung trifft ein Testset mit echten Fragen und den zugehörigen Fundstellen aus dem eigenen Bestand. Wie ein solches Testset aufgebaut und ausgewertet wird, beschreibt der Wissensartikel RAG-Qualität messen.

Kontextlänge, Dimensionen und Speicherbedarf

Kontextlänge. Die maximale Eingabelänge begrenzt die Chunk-Größe. multilingual-e5 schneidet nach 512 Token ab, der Rest eines längeren Abschnitts fließt nicht in den Vektor ein. BGE-M3 und jina-embeddings-v2-base-de verarbeiten 8.192 Token, Qwen3-Embedding, Granite Embedding R2 und jina-embeddings-v5 bis zu 32.768 Token. Eine lange Eingabelänge heißt nicht, dass lange Chunks besser suchen: Ein Vektor für zehn Seiten bildet deren Inhalt nur grob ab. Sie erlaubt aber, Abschnitte nach der Dokumentstruktur zu schneiden, statt nach einer festen Tokenzahl.

Dimension und Indexgröße. In pgvector belegt ein Vektor 4 × Dimension + 8 Byte, der Typ vector lässt sich bis 2.000 Dimensionen mit einem Index versehen, halfvec bis 4.000 (pgvector README). Für eine Million Chunks ergibt das ohne Indexstrukturen:

Die Qwen3-Modelle mit 2.560 und 4.096 Dimensionen lassen sich über MRL auf 1.024 Dimensionen kürzen. Ob der Qualitätsverlust dabei akzeptabel ist, gehört ins Testset. Qdrant hat diese Indexgrenze nicht, dort wirken sich große Dimensionen auf Arbeitsspeicher und Suchlatenz aus. Die Unterschiede der beiden Datenbanken beschreibt Qdrant vs. pgvector.

VRAM und Hardware

Embedding-Modelle sind klein im Vergleich zu Sprachmodellen. In FP16 oder BF16 belegen die Gewichte etwa zwei Byte pro Parameter:

Dazu kommt Speicher für die Verarbeitung, der mit Batchgröße und Eingabelänge wächst. Bei 8.192 oder 32.768 Token pro Eingabe ist dieser Anteil nicht vernachlässigbar.

Für die Hardwareplanung heißt das:

• Modelle bis rund 600 Mio. Parameter laufen auch auf der CPU. Für Suchanfragen im laufenden Betrieb reicht das oft. Die Erstindexierung eines großen Bestands dauert auf der CPU jedoch um ein Vielfaches länger als auf einer GPU.
• Embedding-Modell, Reranker und Sprachmodell teilen sich den Grafikspeicher, wenn sie auf derselben Maschine laufen. Auf einer GPU mit 24 GB, etwa der NVIDIA RTX PRO 4000 Blackwell, bleibt neben einem Qwen3-Embedding-8B (ca. 15 GB) wenig Platz für ein Sprachmodell. Mit BGE-M3 oder Qwen3-Embedding-0.6B bleibt der größte Teil frei.
• Die Erstindexierung ist die Lastspitze. Danach werden nur neue und geänderte Dokumente eingebettet und die Anfragen der Nutzer, jeweils wenige Dutzend Token.

Wie sich VRAM für das gesamte System aus Sprachmodell, KV-Cache, Embedding und Reranker zusammensetzt, beschreibt GPU und VRAM dimensionieren.

Betrieb mit TEI, vLLM und Ollama

Drei Inferenz-Server kommen für Embedding-Modelle üblicherweise in Frage. Alle drei stellen eine HTTP-Schnittstelle bereit, vLLM und TEI zusätzlich im OpenAI-kompatiblen Format.

Quellen: TEI, unterstützte Modelle, vLLM, Embedding-Modelle, vLLM, BGE-M3, Ollama-Bibliothek, Ollama Embed-API. Stand September 2026.

Worauf es im Betrieb ankommt:

• Sparse-Vektoren von BGE-M3. vLLM liefert sie, wenn das Modell mit überschriebener Architektur gestartet wird, weil die config.json das Modell sonst als einfaches XLM-RoBERTa lädt:

vllm serve BAAI/bge-m3 \
  --runner pooling \
  --hf-overrides '{"architectures": ["BgeM3EmbeddingModel"]}' \
  --pooler-config.task token_classify

Mit --pooler-config.task embed liefert dieselbe Instanz dichte Vektoren. In TEI ist die Sparse-Unterstützung für BGE-M3 als Pull Request eingereicht, aber noch nicht übernommen.

• Blackwell-GPUs in TEI. Für GPUs der Blackwell-Generation mit Compute Capability 12.0, zu denen die RTX PRO 4000 und 6000 Blackwell gehören, führt TEI ein eigenes Image, das als experimentell gekennzeichnet ist (TEI-Dokumentation).
• Präfixe und Instruktionen müssen in der Anwendung gesetzt werden, nicht im Server. Ein Pipeline-Baustein, der bei E5 query: vergisst oder bei Qwen3 die Instruktion weglässt, verschlechtert die Suche ohne Fehlermeldung.
• Custom Code. jina-embeddings-v2 und v3 laden eigenen Modellcode (trust_remote_code). Das ist im Betrieb eine zusätzliche Code-Abhängigkeit, die bei Updates mitgeprüft werden muss.

Ollama eignet sich für Prototypen und den Einzelplatz. Für produktive Systeme mit vielen gleichzeitigen Anfragen und einer Erstindexierung großer Bestände sind TEI oder vLLM die belastbareren Wege. Den Vergleich der Inferenz-Server für Sprachmodelle enthält der Beitrag vLLM, Ollama und llama.cpp im Vergleich, die Einrichtung übernehmen wir als vLLM-Betrieb oder mit Ollama.

Welches Modell für welchen Einsatz

Die Tabelle ist ein Ausgangspunkt für die Kandidatenliste, keine Rangliste. Die Auswahl bestätigt oder widerlegt erst das Testset.

Für die API-Variante gilt: Bei der Indexierung wird der gesamte Dokumentbestand an den Anbieter übertragen, im Betrieb jede Suchanfrage. Welche europäischen Anbieter welche Embedding-Modelle anbieten, vergleicht der Beitrag Europäische LLM-APIs im Vergleich. Embedding und Reranker brauchen wenig Rechenleistung und lassen sich auch dann lokal betreiben, wenn das Sprachmodell über eine API läuft.

Modellwechsel bedeutet Neuindexierung

Vektoren verschiedener Modelle sind nicht vergleichbar. Ein Wechsel des Embedding-Modells bedeutet, den gesamten Bestand neu einzubetten. Das gilt auch für einen Wechsel der Dimension per MRL, der Präfixe oder der Instruktion.

Praktische Folgen:

1. Modell, Revision, Dimension und Instruktion dokumentieren. Auf Hugging Face ändern sich auch bestehende Modelle, zum Beispiel wurde bei jina-embeddings-v3 ein Fehler in der Matryoshka-Kürzung nachträglich korrigiert (Model Card). Eine feste Revision im Deployment verhindert, dass sich Vektoren unbemerkt ändern.
2. Neuen Index parallel aufbauen. Der alte Index bleibt aktiv, bis der neue vollständig ist und im Testset mindestens gleich gut abschneidet.
3. Testset erneut ausführen. Recall und Ranking-Metriken vor und nach dem Wechsel vergleichen, nicht nur Stichproben.
4. Berechtigungen mitführen. Der neue Index muss dieselben Zugriffsinformationen je Chunk tragen wie der alte, siehe RAG mit Berechtigungen.

Unser Vorgehen bei WZ-IT

Wir wählen das Embedding-Modell nicht nach Rangliste, sondern mit Messungen auf Ihrem Bestand.

1. Bestand und Fragen erfassen. Dokumenttypen, Sprachen, Länge, gescannte Anteile und typische Fragen der Fachbereiche.
2. Kandidaten eingrenzen. Nach Lizenz, Kontextlänge, Dimension und Hardware bleiben meist drei bis vier Modelle.
3. Mit Referenzfragen messen. Im RAG Proof of Value arbeiten wir mit 40 bis 60 Referenzfragen einschließlich Quellen- und Nichtwissenstests, mit Baseline-Messung und zwei Optimierungszyklen.
4. Betrieb einrichten. Embedding-Modell und Reranker laufen mit TEI oder vLLM auf dem AI Cube in Ihrem Netzwerk oder auf einem Managed GPU-Server von WZ-IT mit NVIDIA RTX PRO 4000 Blackwell (24 GB) oder RTX PRO 6000 Blackwell (96 GB).
5. Dokumentieren und übergeben. Modellrevision, Dimension, Instruktionen und Testset werden festgehalten, damit ein späterer Modellwechsel messbar bleibt.

Support, Beratung und Implementierung durch WZ-IT. Den Aufbau als produktiven Assistenten mit Rechten und Quellenangaben beschreibt die Seite interner KI-Assistent.

Weiterführende Guides

• Hybrid Search und Reranking, Stichwortsuche, dichte Vektoren und Cross-Encoder kombinieren.
• Chunking für deutsche Dokumente, Abschnittsgrößen, Struktur und Metadaten.
• RAG-Qualität messen, Testset, Retrieval- und Antwortmetriken.
• Europäische LLM-APIs im Vergleich, Anbieter mit Embedding- und Reranker-Modellen in der EU.
• RAG-Wissensdatenbank in der Verwaltung, Aufbau für Behörden mit eigenem Betrieb.
• KI-Lösungen von WZ-IT, der Hub mit allen KI-Leistungen.

Welches Embedding-Modell passt zu Ihren Dokumenten? Wir messen die Kandidaten mit Referenzfragen aus Ihrem Bestand und betreiben das gewählte Modell auf Ihrer Hardware oder einem Managed GPU-Server von WZ-IT. Termin vereinbaren

Quellen

• BAAI, BGE-M3 Model Card
• Qwen, Qwen3-Embedding-8B Model Card
• Qwen, Qwen3-Embedding-0.6B Model Card
• Qwen, Qwen3-Embedding-4B Model Card
• intfloat, multilingual-e5-large Model Card
• intfloat, multilingual-e5-large-instruct Model Card
• Google, EmbeddingGemma Model Card
• Google, Gemma Terms of Use
• IBM, Granite Embedding 311M Multilingual R2 Model Card
• Jina AI, jina-embeddings-v2-base-de Model Card
• Jina AI, jina-embeddings-v3 Model Card
• Jina AI, jina-embeddings-v4 Model Card
• Jina AI, jina-embeddings-v5-text-small Model Card
• Elastic, Jina AI wird Teil von Elastic
• Mistral AI, Mistral Embed Model Card
• Mistral AI, Text Embeddings
• MTEB, Benchmarkdefinitionen
• MTEB, RTEB-Benchmarkdefinitionen
• MTEB, Ergebnisrepository
• MTEB Leaderboard
• pgvector README
• Hugging Face, Text Embeddings Inference: unterstützte Modelle und Hardware
• Text Embeddings Inference, Pull Request zu BGE-M3 Sparse
• vLLM, unterstützte Embedding-Modelle
• vLLM, Pooling-Modelle: BGE-M3
• Ollama, Qwen3-Embedding in der Modellbibliothek
• Ollama, Embed-API