RAG optimieren: Chunk Size, Overlap und Datenqualität richtig einstellen

Du hast eine RAG-Pipeline am Laufen – aber die Antworten sind manchmal unvollständig, manchmal irrelevant. Das Modell scheint den Kontext nicht richtig zu nutzen. Die häufigste Ursache: falsche Chunk-Größen, unüberlegtes Overlap und schlechte Eingabedaten. Dieser Artikel erklärt die wichtigsten Stellschrauben und zeigt, welche Werte 2026 als Best Practice gelten.

Warum Chunk-Größe so entscheidend ist

Chunking ist die einzeln wirksamste Design-Entscheidung in einem RAG-System. Sie bestimmt direkt, was das Modell zu sehen bekommt – und damit die Antwortqualität. Schlechtes Chunking kaskadiert durch die gesamte Pipeline: Irrelevante Chunks führen zu schlechten Antworten, egal wie gut das LLM ist.

Zu kleine Chunks verlieren Kontext. Im FloTorch-2026-Benchmark produzierten semantische Chunks mit durchschnittlich 43 Tokens nur 54% Genauigkeit bei zusammengesetzten Fragen – weil jeder Chunk allein zu wenig Aussagekraft hatte.

Zu große Chunks verwässern das Retrieval. Bei über ~2.500 Tokens wurde 2026 ein "Context Cliff" identifiziert: Die Antwortqualität fällt ab, weil das Modell im riesigen Kontext-Block das Relevante nicht mehr priorisieren kann.

Der Sweet Spot: 256–512 Tokens für die meisten Anwendungsfälle.

Benchmark-Empfehlungen für 2026

Der größte Real-Dokument-Test 2026 hat klare Ergebnisse:

Methode	Chunk-Größe	Overlap	Genauigkeit
Recursive Character Split	512 Tokens	50–100	69%
Semantic Chunking	~43 Tokens	—	54%
Fixed-Size, kein Overlap	512 Tokens	0	61%
Große Chunks	1.024 Tokens	15%	83%*

*FinanceBench-Experiment mit stark strukturierten Finanzdokumenten – Ausnahme, nicht Regel.

Empfehlung als Startpunkt: RecursiveCharacterTextSplitter mit 512 Tokens und 50–100 Tokens Overlap. Das funktioniert gut, braucht keine teuren Model-Calls und übertrifft in Benchmarks komplexere Alternativen.

Chunk-Größe nach Dokumenttyp optimieren

Kein universeller Wert passt für alle Dokumentarten:

from langchain.text_splitter import RecursiveCharacterTextSplitter

# Standard: Artikel, Wikis, Handbücher
standard_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=64
)

# Kurze FAQ-Einträge, Support-Tickets
kurz_splitter = RecursiveCharacterTextSplitter(
    chunk_size=256,
    chunk_overlap=32
)

# Lange technische Dokumente, Verträge
lang_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1024,
    chunk_overlap=128
)

Dokumenttyp	Empfohlene Chunk-Größe	Overlap
FAQs / kurze Einträge	128–256 Tokens	20–30
Artikel, Wikis, Handbücher	512 Tokens	50–100
Verträge, technische Specs	768–1024 Tokens	100–150
Code-Dateien	Pro Funktion/Klasse	0
Tabellenzeilen	1 Zeile + Header	—

Overlap-Strategien: Wann hilft er, wann nicht?

Overlap bedeutet, dass sich benachbarte Chunks am Rand überlappen. Wenn ein Satz genau auf der Chunk-Grenze liegt, fällt er ohne Overlap aus dem Kontext – mit Overlap ist er in beiden Chunks enthalten.

Faustregel: 10–20% des Chunk-Size als Overlap. Bei 512 Tokens also 50–100 Tokens.

Wichtig: Eine Studie 2026 mit SPLADE (Sparse Retrieval) zeigte, dass Overlap dort keinen messbaren Nutzen bringt. Bei dichtem, semantischem Retrieval (wie OpenAI Embeddings) ist er hingegen wertvoll. Es lohnt sich, beide Varianten zu testen.

Das richtige Embedding-Modell wählen

Die Chunk-Größe beeinflusst auch die Wahl des Embedding-Modells:

Modell	Max Tokens	Kosten/1M	Empfehlung
text-embedding-3-small	8.191	$0,02	Standard, bestes Preis-Leistung
text-embedding-3-large	8.191	$0,13	Wenn Qualität kritisch ist
text-embedding-ada-002	8.191	$0,10	Legacy, nicht mehr empfohlen

text-embedding-3-small ist 2026 der klare Standard: günstig genug für nächtliche Re-Indexierungen ganzer Dokumentenkorpora, und in Retrieval-Benchmarks kaum schlechter als das teure Large-Modell.

RAG-Qualität evaluieren

Ohne Messung keine Optimierung. Die wichtigsten Metriken:

# RAGAS – das Standard-Framework für RAG-Evaluation
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

results = evaluate(
    dataset=test_set,  # Fragen + erwartete Antworten
    metrics=[
        faithfulness,       # Ist die Antwort durch den Kontext belegt?
        answer_relevancy,   # Beantwortet die Antwort die Frage?
        context_precision   # Sind die gefundenen Chunks relevant?
    ]
)
print(results)

Die drei entscheidenden Metriken:

• Faithfulness – Erfindet das Modell Fakten, die nicht im Kontext stehen? (Halluzination)
• Answer Relevancy – Beantwortet die Antwort die gestellte Frage?
• Context Precision – Sind die abgerufenen Chunks wirklich relevant für die Frage?

Ein schlechter Context-Precision-Score zeigt, dass das Chunking oder das Retrieval (k-Wert, Similarity-Threshold) angepasst werden muss.

Praktischer Optimierungs-Workflow

1. Startpunkt: 512 Tokens, 64 Overlap, k=4, text-embedding-3-small
2. Testset erstellen: 20–50 repräsentative Fragen mit erwarteten Antworten
3. RAGAS evaluieren: Baseline-Score messen
4. Chunk-Größe variieren: 256 und 1024 testen, RAGAS vergleichen
5. k-Wert anpassen: Mehr Chunks (k=6) = mehr Kontext, aber mehr Rauschen
6. Dokumenttyp-spezifisch chunken: PDF vs. FAQ vs. Code separat behandeln

Zusammenfassung

Die wichtigste Erkenntnis aus 2026-Benchmarks: Recursive Character Splitting mit 512 Tokens und 50–100 Tokens Overlap ist ein starker, bewährter Ausgangspunkt – besser als komplexe semantische Methoden für die meisten Anwendungsfälle. Messe mit RAGAS, variiere Chunk-Größe und k-Wert systematisch, und passe die Strategie an deinen Dokumenttyp an. Qualität entsteht durch Messen und Iterieren, nicht durch einmaliges Raten.

---

Quellen:

• RAG Chunking Strategies: The 2026 Benchmark Guide – premai.io
• Best Chunking Strategies for RAG in 2026 – Firecrawl
• Chunking Strategies for RAG – Weaviate Blog
• RAG in Production 2026 – abhs.in