RAG-Pipeline — 3 Einstellungen, die über Qualität entscheiden

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. 1.Welcher Inhaltstyp? Konversationelles FAQ / Blogposts → Dense Embedding reicht. Strukturiertes Dokument mit Sections / Absätzen → Document-Aware Chunking ist Pflicht.
2. 2.Welche Sprache? EN-only → MTEB Top Performer (Voyage, BGE-M3, OpenAI). Multilingual EU-Sprachen → BGE-M3, Cohere multilingual-v3.
3. 3.Welches Budget? Cloud-only → OpenAI 3-large + Cohere Rerank 3. Self-hosted → BGE-M3 + BGE-Reranker-v2-m3.
4. 4.Welche Latenz tolerieren Sie? < 200 ms → ohne Reranker oder kleiner Cross-Encoder. 200–500 ms → Full Pipeline mit Reranker.
5. 5.Sind Keywords kritisch? Ja → Hybrid BM25 + Dense. Nein → reines Dense.
6. 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. 1.Eval Set: 200+ realistische Anfragen + handannotierte „ideale" Quelldokumente. Ohne dies lässt sich Verbesserung nicht messen.
2. 2.Baseline: zuerst einfache Pipeline (Fixed Chunking + ein Embedding Model + kein Reranker). Score = Baseline.
3. 3.Ändern Sie schrittweise einen Parameter: Chunking → Embedding → Reranker → Hybrid. Nach jeder Änderung Precision@5, Recall@10, Latency messen.
4. 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.*