Bei RAG (Retrieval-Augmented Generation) konzentrieren sich die meisten Debugging-Versuche 2026 auf Prompts des Modells und System Instructions. Der Kunde ändert den Prompt 12-mal, sitzt 4 Tage daran und die Präzision der Antworten verbessert sich von 67 % auf 70 %. Inzwischen würden drei Einstellungen in der Retrieval-Schicht — Chunking, Embedding Model, Reranking — bei einem halben Tag Arbeit die Präzision auf 84 % schieben. Dieser Artikel handelt von diesen drei Einstellungen.
Warum Retrieval entscheidet, nicht das LLM
Grundlegende Asymmetrie der RAG-Architektur: Wenn Retrieval die **richtigen Dokumentationsfragmente** zurückgibt, gibt auch ein durchschnittliches 7B-Modell eine qualitative Antwort. Wenn Retrieval irrelevante oder unvollständige Fragmente zurückgibt, rettet auch Claude Opus 4.6 die Antwort nicht — das Modell hat einfach keine wahren Fakten im Kontext. „Garbage in, Garbage out" ist in RAG buchstäblich ein physikalisches Gesetz.
Konkretes Beispiel: juristisches RAG über slowakische Gesetzgebung, 12 000 Dokumente, 8 M Tokens. Mit Default-Chunking (500 Tokens Fixed Size) und OpenAI text-embedding-ada-002 erreichten wir Precision@5 = 0,61, Recall@10 = 0,72. Nach drei Einstellungen (Document-Aware Chunking, Embedding Upgrade auf BGE-M3, Cohere Rerank 3) — Precision@5 = 0,84, Recall@10 = 0,93. **Keine Änderung des LLM, keine Änderung des Prompts.**
Einstellung 1: Chunk Size + Chunking Strategy
Häufigste Konfiguration in PoC-Projekten: `RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)` aus dem LangChain-Default. Funktioniert in 60 % der Use-Cases. Für den Rest ist es schlecht.
**Zwei Entscheidungsdimensionen:**
A) Chunk-Größe (Tokens)
- **128–256 Tokens** — hohe Präzision, Retrieval findet genau den Absatz, der antwortet. Risiko: Kontext um den Absatz fehlt, das Modell sieht nicht den gesamten Gedankenfluss. Geeignet für FAQ, Code-Snippets, strukturierte Daten.
- **256–512 Tokens** — häufigster Kompromiss. Absatz mit umgebendem Kontext. Default-Wahl für die meisten B2B-Knowledge-Base-Deployments.
- **512–1024 Tokens** — breiterer Kontext, das Modell bekommt mehr Zusammenhänge, aber die Retrieval-Präzision sinkt (Embedding eines 1 024-Token-Chunks „verdünnt" das Hauptthema). Geeignet für längere narrative Dokumente (juristische Entscheidungen, Forschungspapiere, technische Handbücher).
- **> 1 024 Tokens** — selten korrekt. Embedding-Modelle haben effektive Länge ~512 Tokens — die meiste Information jenseits dieser Schwelle „löst sich" in einem Vektor auf. Es gibt eine Ausnahme: Long-Context-Embedding-Modelle (Voyage-3-large, BGE-M3 im Full-Modus, NV-Embed-v2) schaffen effektiv bis zu 8 192 Tokens.
B) Splitting-Strategie (Fixed vs. Semantic vs. Document-Aware)
- **Fixed-Size Chunking** — einfach, deterministisch, aber bricht Absätze, Sätze, sogar Wörter an der Grenze. Kontextverlust bei ~15 % der Chunks, was sich in 8–12 % Verschlechterung von Precision@5 niederschlägt.
- **Semantic Chunking** — mittels Embeddings werden Grenzen sinnvoller Segmente erkannt (z. B. `semantic_chunker` in LlamaIndex). Bessere Kontexterhaltung, aber Chunks haben Variable Size — bei Inference muss mit Streuung 200–800 Tokens gerechnet werden. Verbesserung Precision@5 um 5–8 %.
- **Document-Aware Chunking** — nutzt die Struktur des Dokuments (Markdown Headings, HTML `<section>`, PDF Sections über Docling oder Unstructured.io). Chunks entsprechen logischen Einheiten des Autors. **Beste Wahl für 80 % der B2B-Use-Cases**, Verbesserung Precision@5 um 12–18 % gegenüber Fixed-Size.
Praktische Konfiguration für juristisches RAG: Docling-parsed PDF → Split nach `<heading>` in serieller Reihenfolge → falls Heading Section > 800 Tokens, Sub-Split nach Absätzen (`\n\n`) → Metadata pro Chunk: `{doc_id, section, page, jurisdiction, paragraph_number}`. 10–20 % Overlap zwischen benachbarten Chunks für Kontinuität.
**Konkreter Benchmark:** 12 000 juristische Dokumente, Fixed 500-Token vs. Document-Aware Chunking. - Fixed: 38 400 Chunks, avg 487 Tokens, Precision@5 = 0,61 - Document-Aware: 24 200 Chunks, avg 612 Tokens, Precision@5 = 0,73
Einstellung 2: Embedding-Modell
Am meisten unterschätzte Entscheidung. Der Kunde wählt OpenAI `text-embedding-ada-002` aus 2022, weil „es im LangChain Quickstart ist", und verliert 15–20 % Präzision, die er mit einem modernen Modell gewinnen würde.
Top-Wahlmöglichkeiten 2026 — Cost/Quality/Latency Tradeoff
**OpenAI text-embedding-3-large** - Dimension: 3 072 (reduzierbar via Matryoshka Representation auf 256/512/1 024) - MTEB Score: ~64,6 - Preis: 0,13 USD / M Tokens - Multilingual: gut, aber nicht das Beste für DE/CZ — in Tests mit deutschen juristischen Texten Precision@5 = 0,77 - Latenz: ~80 ms pro Request (API) - **Wann:** All-in Cloud Setup, englisch + übliche EU-Sprachmischung
**Cohere embed-multilingual-v3.0** - Dimension: 1 024 - MTEB Score: ~63,8 (Multilingual Benchmark höher) - Preis: 0,10 USD / M Tokens - Multilingual: hervorragend für 100+ Sprachen, besonders stark für ost- und mitteleuropäische Sprachen (DE, SK, CZ, HU, RO) - Latenz: ~60 ms pro Request - **Wann:** Multilingual Knowledge Base, EU Compliance (Cohere hat EU Region Endpoint)
**sentence-transformers/all-mpnet-base-v2** - Dimension: 768 - MTEB Score: ~57,8 - Preis: self-hosted (CPU/GPU) - Multilingual: schwach (primär EN) - Latenz: ~10 ms auf CPU, ~3 ms auf GPU - **Wann:** Budget Setup, EN-only, Offline
**BGE-M3 (BAAI/bge-m3)** - Dimension: 1 024 (Dense), plus Sparse + ColBERT-style Multivector - MTEB Score: ~66,1 (Multilingual Benchmark) - Preis: self-hosted - Multilingual: hervorragend für 100+ Sprachen inklusive DE - Latenz: ~15 ms auf RTX 4090 - **Wann:** SOTA-Wahl für Multilingual + Self-Hosted. **Unsere Default 2026 für EU-Kunden.**
**Voyage AI voyage-3-large** - Dimension: 1 024 - MTEB Score: ~68,2 (einer der höchsten 2026) - Preis: 0,18 USD / M Tokens - Multilingual: hervorragend - **Wann:** Premium Cloud, wo jeder 1 % Präzision zählt
**Konkreter Benchmark:** gleicher juristischer Corpus (8 M Tokens), Document-Aware Chunking, kein Reranker. - OpenAI text-embedding-3-large: Precision@5 = 0,77, Latenz 80 ms - Cohere embed-multilingual-v3: Precision@5 = 0,79, Latenz 60 ms - BGE-M3 (self-hosted): Precision@5 = 0,81, Latenz 15 ms - Voyage-3-large: Precision@5 = 0,82, Latenz 95 ms
Für deutschen juristischen Content ist der Unterschied zwischen `text-embedding-ada-002` (0,61) und BGE-M3 (0,81) **20 Prozentpunkte Präzision** — einfachste Änderung mit höchstem Impact.
Einstellung 3: Reranker
Am meisten unterschätzte Pipeline-Komponente. Architektur: Retrieval liefert Top-K Kandidaten (typisch K = 20–50) über Embedding Similarity, der **Reranker** scort sie neu mit einem Cross-Encoder-Modell (langsamer, aber präziser) und wählt Top-N (typisch N = 5) für den LLM-Kontext aus.
Warum es funktioniert: Bi-Encoder-Embedding (schnelles Retrieval) ist „lossy" — komprimiert das Dokument in einen Vektor. Cross-Encoder-Reranker (langsamer) sieht Dokument + Query zusammen und bewertet ihre Relevanz pro Token. Bei Top-20 Reranking fügt es 50–200 ms Latenz hinzu, aber Precision@5 wächst typisch um 12–18 %.
Top-Wahlmöglichkeiten 2026
**Cohere Rerank 3** - Preis: 2,00 USD / 1 000 Search Units (1 Unit = 1 Query + bis zu 100 Documents) - Multilingual: hervorragend - Latenz: ~100–150 ms pro Query (Top-20 Rerank) - API: einfach, EU Endpoint verfügbar - **Wann:** Cloud Setup, Multilingual Content, Premium-Qualität
**BAAI/bge-reranker-v2-m3 (BGE Reranker v2 M3)** - Preis: self-hosted - Multilingual: hervorragend (gleiches Training wie BGE-M3) - Latenz: ~80–120 ms auf RTX 4090 für Top-20 - **Wann:** Self-Hosted Setup, SOTA Open-Source-Wahl für Multilingual
**cross-encoder/ms-marco-MiniLM-L-6-v2** - Preis: self-hosted, kleines Modell (66 M Parameter) - Multilingual: schwach (EN-trained) - Latenz: ~30 ms auf GPU - **Wann:** Budget Setup, EN-only
**Kein Reranker (Baseline)** - Preis: Null - **Wann:** PoC, geringes Volumen, Latenz unter 200 ms ist Anforderung
Konkreter Benchmark — Hinzufügen des Rerankers zur bestehenden Pipeline
Juristisches RAG, BGE-M3 Retrieval, Top-20 → Top-5: - Ohne Reranker: Precision@5 = 0,81, Latenz 250 ms - Cohere Rerank 3: Precision@5 = 0,88, Latenz 380 ms - BGE-Reranker-v2-m3 (self-hosted): Precision@5 = 0,89, Latenz 340 ms
**Reranker erhöht Precision um 7–8 % zum Preis von 130–150 ms.** Für regulierte Knowledge Bases (Recht, Medizin, Finanzen) ist das immer lohnenswert. Für Low-Stake-Chatbots (FAQ) kann der Reranker überflüssig sein — abhängig von den Kosten einer falschen Antwort.
Hybrid Retrieval — wenn es um Keywords und Semantik geht
Bei Inhalt, bei dem **Keywords einen eigenen Wert haben** (Gesetzesnummern, Paragraphen, GUIDs, Normziffern, exakte Produktnamen), kann überwiegender Dense Embedding Retrieval scheitern. Embedding fängt semantische Ähnlichkeit ein, aber ein wörtlicher Match auf „§ 271 Abs. 2" kann in der semantischen Norm verloren gehen.
**Lösung: Hybrid Retrieval** = parallel BM25 (Sparse, Keyword-Based) + Dense Embedding Retrieval, Ergebnisse werden zusammengeführt (typisch `reciprocal_rank_fusion`).
Stack 2026: Qdrant 1.10+ mit native Sparse Vectors + Dense Vectors, oder OpenSearch mit pgvector Layer, oder Weaviate Hybrid Search API. Konfiguration: Alpha-Parameter bestimmt die Gewichtung (0 = reines BM25, 1 = reines Dense, Default 0,5).
**Benchmark Hybrid Retrieval für juristischen Corpus:** - BM25 only: Precision@5 = 0,68 (hervorragend für „§ 271", schwach für „was gilt bei Kündigung aus gesundheitlichen Gründen") - Dense (BGE-M3) only: Precision@5 = 0,81 - Hybrid (alpha=0.5): Precision@5 = 0,87
Für juristischen / medizinischen / technischen Normcontent ist Hybrid signifikant besser. Für konversationellen FAQ-Content reduziert sich der Unterschied auf 1–2 %.
Praktischer Entscheidungsrahmen
1. **Welcher Inhaltstyp?** Konversationelles FAQ / Blogposts → Dense Embedding reicht. Strukturiertes Dokument mit Sections / Absätzen → Document-Aware Chunking ist Pflicht. 2. **Welche Sprache?** EN-only → MTEB Top Performer (Voyage, BGE-M3, OpenAI). Multilingual EU-Sprachen → BGE-M3, Cohere multilingual-v3. 3. **Welches Budget?** Cloud-only → OpenAI 3-large + Cohere Rerank 3. Self-hosted → BGE-M3 + BGE-Reranker-v2-m3. 4. **Welche Latenz tolerieren Sie?** < 200 ms → ohne Reranker oder kleiner Cross-Encoder. 200–500 ms → Full Pipeline mit Reranker. 5. **Sind Keywords kritisch?** Ja → Hybrid BM25 + Dense. Nein → reines Dense. 6. **Welches Anfragevolumen?** Bei > 100 RPS amortisiert sich Self-Hosted-Stack in 4–8 Monaten.
Praktische Iteration
RAG-Tuning ist kein „einmal einstellen, vergessen" Projekt. Iterations-Stack, der sich bewährt hat:
1. **Eval Set:** 200+ realistische Anfragen + handannotierte „ideale" Quelldokumente. Ohne dies lässt sich Verbesserung nicht messen. 2. **Baseline:** zuerst einfache Pipeline (Fixed Chunking + ein Embedding Model + kein Reranker). Score = Baseline. 3. **Ändern Sie schrittweise einen Parameter:** Chunking → Embedding → Reranker → Hybrid. Nach jeder Änderung Precision@5, Recall@10, Latency messen. 4. **Stoppen Sie, wenn Marginal Cost > Marginal Benefit.** Typisch erfordert Precision@5 über 0,90 disproportional viel Aufwand — Fine-tuned Embedding oder Custom Reranker, der sich beim Use Case mit toleranter Qualität nicht lohnt.
In juristischem RAG für 12 000 Dokumente haben wir in 4 Wochen Arbeit Precision@5 von 67 % auf 88 % gebracht. Die nächsten 4 Wochen würden wir wahrscheinlich auf 90 % bringen. Der Kunde entschied sich zu stoppen — 88 % waren operativ ausreichend, und weitere 5 Wochen GPU + Engineer Time amortisierten sich nicht.
---
*Wir machen RAG-Architektur + Tuning für B2B Knowledge Bases mit 1k–10M Dokumenten. Wenn Sie eine bestehende Pipeline haben und Precision@5 unter 75 % festhängt, gehen wir in einem 90-minütigen Audit konkret drei Einstellungen für Ihren Content durch und geben Ihnen eine numerische Baseline für die Tuning-Roadmap.*