Embedding-Modell auswählen — auch für Mehrsprachigkeit und Slowakisch

Wenn ein Kunde mit der Anforderung „Setzt uns RAG über die technische Dokumentation auf" kommt, dreht sich die erste Diskussion meistens um das große Sprachmodell: Claude oder GPT? Llama oder Mistral? Lokal oder Cloud? Das Embedding-Modell bleibt dabei außen vor — die meisten Teams greifen zu OpenAI text-embedding-ada-002, weil sie es im ersten Quickstart gesehen haben, oder zu dem, was gerade in der Dokumentation des verwendeten Frameworks auftaucht.

Die Realität aus der Praxis: Das Embedding-Modell ist der Ort, an dem 15–20 % der Gesamtqualität einer Retrieval-Pipeline entschieden wird. Ein schlecht gewähltes Modell führt dazu, dass relevante Dokumente zwar in den Top-20-Ergebnissen landen, aber nicht in den Top-5 — und das LLM antwortet dann aus irrelevantem Kontext. Für slowakischsprachige Inhalte ist dieser Effekt ausgeprägter als für englische, da die meisten populären Modelle dominant auf EN-Daten trainiert sind. Dieser Artikel liefert einen konkreten Auswahlrahmen — inklusive dem, was bei Slowakisch funktioniert und was nicht.

Was ein Embedding-Modell tut — und warum die Wahl entscheidet

Ein Embedding-Modell überführt Text (Dokument, Frage, Satz) in einen Vektor — eine Liste von Zahlen, bei der ähnliche Texte geometrisch nahe beieinanderliegende Vektoren besitzen. Retrieval sucht dann nach Vektoren, die einem Query nahe sind. Alles andere in der RAG-Pipeline hängt davon ab, ob „nah im Raum" tatsächlich „semantisch relevant" bedeutet.

Zwei Dimensionen, in denen sich Modelle unterscheiden:

Vektordimension (768, 1 024, 3 072, 4 096) — eine höhere Dimension ermöglicht es, mehr semantische Information zu erfassen, erhöht aber den Speicherbedarf, die Speicherkosten und die Latenz der Similarity-Search. Moderne Matryoshka-Modelle erlauben es, die Dimension nach dem Training zu reduzieren (z. B. von 3 072 auf 768) mit minimalem Qualitätsverlust — das ist relevant beim Skalieren auf Dutzende Millionen Vektoren.

Kontextfenster — wie viele Tokens das Modell beim Einbetten eines einzelnen Chunks effektiv „verarbeitet". Ältere Modelle hatten ein effektives Fenster von rund 512 Tokens, auch wenn das nominelle Limit 8 192 betrug; moderne Modelle (BGE-M3, Qwen3-Embedding, NV-Embed-v2) verarbeiten lange Dokumente ohne nennenswerten Qualitätsverlust. Für eine RAG-Pipeline mit Document-Aware Chunking ist das direkt relevant — hat Ihr Chunking 600–800 Tokens, schneidet ein Modell mit effektivem Fenster von 512 Tokens diese ab.

MTEB: Orientierungshilfe, kein Dogma

MTEB (Massive Text Embedding Benchmark) ist der am weitesten verbreitete Benchmark für Embedding-Modelle. Er misst die Leistung auf Dutzenden von Aufgaben: Retrieval, Clustering, Classification, Semantic Similarity. Die Ergebnisse sind auf dem Hugging Face Leaderboard öffentlich einsehbar und ein guter Ausgangspunkt.

Drei Einschränkungen, die man im Kopf behalten sollte:

• MTEB ist primär englisch. Ein Multilingual Track existiert, deckt aber nur bestimmte Sprachen ab — Slowakisch ist kein standardmäßiger MTEB-Sprachpfad. Die Ergebnisse im MTEB Multilingual sind daher orientierend, keine Garantie für slowakische Leistung.
• Benchmark-Daten unterscheiden sich von Ihren Daten. Ein Modell mit MTEB-Score 70 kann auf Ihrem spezifischen domänenspezifischen Inhalt (technische Dokumentation, Rechtstexte, Servicehandbücher) deutlich schlechter abschneiden als ein Modell mit Score 65, das auf ähnlichem Inhalt trainiert wurde.
• Benchmark-Scores messen weder Latenz noch Kosten. Ein Modell mit MTEB 70 und 400 ms Latenz ist für eine Echtzeit-Applikation eine schlechtere Wahl als ein Modell mit MTEB 67 und 15 ms.

MTEB ist also eine gute Hilfe, um eine Shortlist von 3–5 Kandidaten zu erstellen. Die finale Entscheidung treffen Sie auf Basis eines Tests mit Ihren eigenen Daten.

Open-Weight-Modelle: wann und warum

Für SK/EU-Unternehmen ist das Argument für ein selbst gehostetes Embedding-Modell stärker als für das LLM selbst. Ein Embedding-Modell:

• Läuft auf einem normalen GPU-Server. BGE-M3 kommt auf einem Standard-GPU-Server mit Latenzzeiten im Bereich weniger Zehntel Millisekunden pro Request aus. Das ist kein vergleichbarer Hardwareaufwand wie bei einem 70B-LLM.
• Keine Datenlecks. Dokumente bleiben in Ihrer Infrastruktur — relevant für regulierte Branchen und GDPR-Compliance.
• Vorhersehbare Kosten. Die amortisierten Kosten eines GPU-Servers sind fix; Cloud-API-Kosten wachsen linear mit dem Volumen.
• Anpassbarkeit. Bei ausreichend domänenspezifischen Daten lässt sich das Modell auf Ihre Texte feinabstimmen (Fine-Tuning) — das ist bei Cloud-APIs nicht möglich.

BGE-M3 (BAAI/FlagEmbedding) ist im Jahr 2026 der Produktionsstandard für Open-Weight-Multilingual-Deployments. Es kombiniert in einem einzigen Durchgang drei Retrieval-Typen: Dense (semantisch), Sparse (keyword-basiert im BM25-Stil) und Multi-Vector (ColBERT-Stil, präziser). Über 100 Sprachen inklusive Slowakisch. Kontextfenster 8 192 Tokens. Dimension 1 024 (Dense). Das ist unser interner Default bei EU-Kunden mit lokalem Deployment.

Qwen3-Embedding (Modellfamilie von Alibaba, einschließlich des 8B-Variants) erzielt im Jahr 2026 die höchsten Scores auf dem MTEB Multilingual Leaderboard — rund 70,58 beim Qwen3-Embedding-8B. Flexible Matryoshka-Dimension (32–4 096), langes Kontextfenster von 32 768 Tokens. Für nicht-englisches Retrieval ist das derzeit der stärkste Open-Weight-Kandidat, sofern Sie über ausreichend Hardware verfügen (das 8B-Modell benötigt rund 16 GB VRAM bei voller Genauigkeit, weniger bei Quantisierung).

Llama-Embed-Nemotron-8B (NVIDIA) gehört zur Spitzengruppe des multilingualen MTEB (250+ Sprachen, Open-Weight, kostenlos). Wenn Sie NVIDIA-Hardware haben und maximale Scores in der Open-Weight-Kategorie benötigen, ist das ein starker Kandidat.

Für schnelles Prototyping oder kostengünstige Deployments reichen kleinere Modelle aus der sentence-transformers-Familie — all-mpnet-base-v2 oder paraphrase-multilingual-mpnet-base-v2 — jedoch ist deren slowakische Leistung deutlich niedriger als bei BGE-M3.

Cloud-API-Modelle: wann sie Sinn ergeben

Cloud-Embedding-APIs (OpenAI, Google, Cohere, Voyage AI) sind in drei Situationen sinnvoll:

1. 1.Kein eigener GPU vorhanden. Ein Deployment über Cloud-API ist einfacher, ohne Hardware-Management.
2. 2.Aufrufe sind sporadisch und das Volumen niedrig. Bei einigen Tausend Requests pro Tag lohnt es sich nicht, einen eigenen Server zu amortisieren.
3. 3.Multimodale Anforderungen. Wenn Sie eine Kombination aus Text und Bildern einbetten (z. B. Kataloge mit technischen Zeichnungen), sind Cloud-Modelle wie Cohere Embed v4 in diesem Bereich führend.

OpenAI text-embedding-3-large (3 072 Dimensionen, Matryoshka, ~$0,13/1M Tokens) ist eine zuverlässige, gut dokumentierte Wahl für englische Inhalte. Für slowakische Inhalte ist die Leistung etwas niedriger als bei auf Mehrsprachigkeit optimierten Modellen.

OpenAI text-embedding-3-small (~$0,02/1M Tokens) ist aus Kostensicht interessant — für Englisch bietet es ein gutes Preis-Leistungs-Verhältnis, für Mehrsprachigkeit empfehlen wir jedoch 3-large oder den Wechsel zu Cohere.

Cohere Embed v4 unterscheidet sich durch zwei Eigenschaften: Kontextfenster von 128 000 Tokens (extrem lange Dokumente ohne Chunking-Notwendigkeit) und native multimodale Unterstützung (Text + Bilder). Preis ~$0,12/1M Tokens. Für Unternehmen, die technische Dokumentation mit Bildern oder Schemata einbetten, ist das eine relevante Kombination.

Gemini Embedding 001 (Google) hält im Jahr 2026 eines der höchsten Scores auf MTEB English (~68), mit Matryoshka-Support von 768 bis 3 072 Dimensionen. Preis ~$0,004/1K Zeichen. Für englisches Retrieval ist das eine starke Cloud-Wahl; für slowakische Inhalte gilt dieselbe Einschränkung wie bei den OpenAI-Modellen.

Slowakisch: was funktioniert und was nicht

Slowakisch ist kein eigenständiger Sprachpfad im Standard-MTEB-Benchmark. Verifizierte SK-spezifische Benchmarks für Embedding-Modelle sind nicht öffentlich verfügbar. Was wir aus der Praxis und aus verwandten Benchmarks (MIRACL, MKQA) wissen:

• Modelle, die primär auf Englisch trainiert wurden (ältere ada-002, all-MiniLM), liegen bei slowakischen Texten deutlich unter ihrem EN-Benchmark-Score.
• BGE-M3, Qwen3-Embedding und Llama-Embed-Nemotron decken Slowakisch als Teil ihres mehrsprachigen Trainings ab — ihre Leistung ist vergleichbar mit der auf verwandten slawischen Sprachen (Tschechisch, Polnisch), was in der Praxis funktioniert.
• Für slowakische technische Dokumentation (Maschinenbauhandbücher, Elektroprojekte, ČSN/STN-Normen) haben wir interne Tests mit BGE-M3 vs. OpenAI text-embedding-3-large durchgeführt — BGE-M3 zeigte konsistent 8–12 % höhere Precision@5. Das ist kein dramatischer Unterschied, summiert sich aber bei komplexeren Inhalten.
• Wenn Sie über ausreichend slowakischsprachige Domaindaten verfügen (~5 000+ Dokumente), lässt sich ein Embedding-Modell auf Ihren Inhalt feinabstimmen (Fine-Tuning über die sentence-transformers-Bibliothek). In regulierten Branchen (Recht, Medizin) kann das die Precision um weitere 5–10 % steigern.

Für Hybrid Search (BM25 + Vektoren) gilt: Bei slowakischen Inhalten mit präziser Terminologie (Normbezeichnungen, Paragraphenangaben, Teilecodes) ist die BM25-Keyword-Schicht wichtiger als bei Englisch — das Embedding-Modell kann morphologische Flexionsformen normalisieren („pohonu" vs. „pohon"), aber exakte Zeichenketten erfasst BM25 zuverlässiger.

Dimension vs. Qualität vs. Kosten: ein praktischer Rahmen

Es stimmt nicht, dass höhere Dimension = bessere Leistung bedeutet. Matryoshka-Modelle ermöglichen Training auf der vollen Dimension (3 072 oder 4 096) und Inference auf reduzierter Dimension (256, 512, 768) — der Qualitätsverlust ist minimal, der Gewinn an Geschwindigkeit und Speicherkosten ist real.

Orientierungsbereiche für verschiedene Szenarien:

• Schneller PoC, englische Inhalte, Cloud: text-embedding-3-small (1 536 Dim., niedrige Kosten) oder text-embedding-3-large auf 512 Dim. via Matryoshka reduziert.
• Produktions-Cloud, mehrsprachige EU-Inhalte: Cohere Embed v4 (multimodal + langer Kontext) oder Gemini Embedding 001.
• Self-Hosted, SK/CZ/PL-Inhalte: BGE-M3 ist der Default. Für ein größeres Modell mit höherem Score: Qwen3-Embedding-8B oder Llama-Embed-Nemotron-8B.
• Skalierung auf Dutzende Millionen Vektoren: Denken Sie über Matryoshka-Dimensionsreduktion nach (z. B. auf 768) — bei 50 M Vektoren ist die Speicherersparnis erheblich.
• Multimodaler Inhalt (Text + Bilder): Cohere Embed v4 oder Voyage AI voyage-multimodal-3.5.

Für den Vergleich konkreter Vektordatenbanken, in denen Sie diese Embeddings speichern werden, lesen Sie Vektordatenbanken — Vergleich Qdrant, Weaviate, pgvector, Milvus.

Domain Fit: der am häufigsten übersehene Faktor

MTEB-Benchmark-Scores beschreiben die durchschnittliche Leistung auf bunten Testsets. Ihr realer Inhalt ist eng und spezifisch:

• Maschinenbaudokumentation (Zeichnungshinweise, Servicehandbücher, ISO-Normen) — technische Sprache mit präziser Terminologie, Abkürzungen, Teilenummern. Dense Embedding erfasst die Semantik; die BM25-Schicht erfasst exakte Codes. BGE-M3 Hybrid Mode ist hier von Vorteil.
• Rechtstexte (Arbeitsgesetzbuch, Verträge, Normen) — formale Sprache, Paragraphenverweise, Betonung des genauen Wortlauts. Tests zeigen, dass ein domänenspezifisch feinabgestimmtes Modell (Fine-Tuned auf slowakischen Rechtstexten) ein generisches Modell um 10–15 % Precision übertrifft.
• Interne Unternehmens-KB (E-Mails, Besprechungsprotokolle, Prozessdokumente) — variable Sprache, unterschiedliche Schreibstile. Hier funktioniert ein generisches Modell gut; Fine-Tuning lohnt sich erst bei großem Volumen (50k+ Dokumente).
• Produktkatalog (SKU, Beschreibungen, technische Parameter) — kurze Texte, exakte Übereinstimmungen. Für E-Commerce- oder Distributorenkataloge hat BM25 ein deutliches Gewicht; das Embedding-Modell ergänzt die Semantik („blaue Schraube mit metrischem Gewinde" = „M6 blaue Schraube DIN 912").

Beantworten Sie sich vor der Modellauswahl die Frage: Welcher Anteil Ihrer Queries erfordert semantisches Verständnis gegenüber exakter lexikalischer Übereinstimmung? Für Industrieunternehmen mit technischer Dokumentation ist Hybrid Retrieval fast immer die richtige Wahl — und bei Hybrid Retrieval brauchen Sie ein Embedding-Modell, das nativ Sparse Vectors unterstützt (BGE-M3), oder Sie sind bereit, einen separaten BM25-Index zu verwalten.

Evaluierung: wie man vor dem Deployment testet

Treffen Sie die Entscheidung nicht allein auf Basis von MTEB — bauen Sie ein Mini-Eval-Set auf:

1. 1.Wählen Sie 100–200 reale Queries, die Ihren Produktions-Use-Case widerspiegeln.
2. 2.Identifizieren Sie für jeden Query manuell die „idealen" Quelldokumente (Ground Truth).
3. 3.Führen Sie Retrieval (Top-5 oder Top-10) für jedes Kandidatenmodell durch.
4. 4.Messen Sie precision@5 und recall@10 — den prozentualen Anteil relevanter Dokumente in den Top-5/10.
5. 5.Vergleichen Sie auch Latenz und Einbettungskosten für das gesamte Korpus.

Dieser Test zeigt Ihnen in 2–3 Arbeitstagen den realen Unterschied zwischen Modellen auf Ihren Daten. Erfahrung aus der Praxis: Bei englischen Inhalten unterscheiden sich Kandidaten um 3–8 % Precision. Bei slowakischen technischen Inhalten sind die Unterschiede ausgeprägter — wir haben Unterschiede von 15–20 % zwischen einem schwächeren EN-primären Modell und BGE-M3 gesehen.

Für die Evaluierung der gesamten RAG-Pipeline (nicht nur Retrieval, sondern auch Generierungsqualität) lesen Sie Wie man RAG evaluiert (RAGAS).

Häufige Fragen

Ist BGE-M3 im Jahr 2026 noch eine aktuelle Wahl?

Ja. BGE-M3 bleibt der Produktionsstandard für Open-Weight-Multilingual-Deployments — gerade wegen der einzigartigen Kombination aus Dense + Sparse + Multi-Vector Retrieval in einem einzigen Durchgang; kein anderes Open-Weight-Modell bietet das in einem einzigen Modell. Qwen3-Embedding-8B erzielt höhere MTEB-Scores, benötigt aber mehr Hardware und bietet kein natives Sparse Retrieval. Für die meisten EU-Kunden mit vorhandenem GPU-Server bleibt BGE-M3 ein guter Default.

Brauche ich für Slowakisch ein spezielles Modell?

Nicht zwingend. BGE-M3, Qwen3-Embedding und Llama-Embed-Nemotron decken Slowakisch als Teil ihres Trainings ab und funktionieren in der Praxis. Ein speziell auf Slowakisch trainiertes Embedding-Modell existiert im Jahr 2026 nicht als öffentliches SOTA-Open-Weight-Modell. Wenn Sie ein großes Volumen slowakischer Domaindaten haben (10k+ Dokumente), kann das Fine-Tuning eines generischen Multilingual-Modells auf Ihren Inhalt ein besseres Ergebnis liefern — das ist jedoch ein eigenes Projekt, kein Out-of-the-Box-Ansatz.

Kann ich ein Embedding-Modell sowohl für Retrieval als auch für Reranking verwenden?

Nein — Embedding-Modell (Bi-Encoder) und Reranker (Cross-Encoder) sind architektonisch verschieden. Das Embedding-Modell kodiert Dokumente und Queries unabhängig voneinander vektoriell (schnell); der Reranker bewertet ein Paar (Query + Dokument) gemeinsam (präziser, langsamer). Für eine vollständige Pipeline brauchen Sie beides — mehr dazu im Artikel RAG-Pipeline — 3 Einstellungen, die über Qualität entscheiden.

Was kostet die Einbettung einer gesamten unternehmensweiten Knowledge Base?

Das hängt vom Volumen ab. Zur Orientierung: 1 Million Tokens bei OpenAI text-embedding-3-large kosten ~$0,13; bei 3-small ~$0,02. Für einen 10 000-seitigen PDF-Korpus (~5 M Tokens) liegen die einmaligen Einbettungskosten bei Cloud-APIs im Bereich einiger Dutzend Dollar. Bei Self-Hosted BGE-M3 sind die Kosten nach Anschaffung des GPU-Servers praktisch null. Ein Re-Embedding (bei Modelltausch oder Änderung des Chunkings) kostet denselben Betrag erneut — weshalb es sich lohnt, das richtige Modell von Anfang an zu wählen.

Wann ist Fine-Tuning eines Embedding-Modells sinnvoll?

Wenn Sie Domäneninhalte haben, bei denen das generische Modell systematisch versagt (Precision unter 70 %), Sie über ausreichend Daten verfügen (typisch 5 000+ relevante Query-Dokument-Paare) und ein Produktionssystem betreiben, in dem jeder Prozentpunkt Precision einen geschäftlichen Wert hat. Regulierte Branchen (Recht, Medizin) sind das klassische Beispiel. Für eine normale interne Knowledge Base ist Fine-Tuning über den Bedarf hinaus — BGE-M3 oder Qwen3-Embedding reicht aus.

*MP Industrial Solutions unterstützt Unternehmen bei der Konzeption und Implementierung von RAG-Architekturen — von der Auswahl des Embedding-Modells über die Chunking-Strategie bis hin zur Vektordatenbank und dem Evaluierungsharness. Wenn Sie vor einer Auswahl stehen oder die Leistung Ihres bestehenden Deployments messen möchten, führen wir gerne ein kostenloses 90-minütiges Audit Ihrer Pipeline durch.*