Wie RAG-Pipelines wirklich funktionieren: Chunking, Embeddings und Reranking

Retrieval-Augmented Generation klingt einfach: Dokumente einlesen, in Vektoren umwandeln, bei Anfragen die relevantesten Abschnitte finden, dem Sprachmodell mitgeben. In der Praxis scheitern die meisten Implementierungen an drei unterschätzten Problemen: falsches Chunking, schlechte Embeddings und fehlendes Reranking.

Chunking: Die unterschätzte Grundlage

Die meisten Teams verwenden feste Chunk-Größen: 512 Token, 1024 Token. Das funktioniert für homogene Dokumente, scheitert aber an der Realität: Produkthandbücher haben andere Strukturen als Support-Artikel. API-Dokumentationen sind anders aufgebaut als FAQs. Feste Chunk-Größen reißen semantische Einheiten auseinander — eine Antwort wird über zwei Chunks verteilt, das Retrieval findet nur die Hälfte.

Die bessere Strategie ist kontextabhängiges Chunking: Dokumententyp erkennen, natürliche Grenzen respektieren (Absätze, Überschriften, Code-Blöcke), Überlappungen zwischen Chunks für Kontextkontinuität. Das kostet mehr Vorverarbeitung, zahlt sich aber bei der Retrieval-Qualität massiv aus.

Embeddings: Nicht alle Vektoren sind gleich

Der Markt für Embedding-Modelle ist unübersichtlich: OpenAI, Cohere, Voyage, BGE, E5 — jedes Modell hat eigene Stärken. Der entscheidende Faktor ist nicht der MTEB-Benchmark-Score, sondern die semantische Dichte in der Zielsprache. Deutsche Texte brauchen Embeddings, die deutsche Komposita und Satzstrukturen verstehen. Ein englisches Modell, das "Kundenservice" und "Service für Kunden" nicht als äquivalent erkennt, produziert schon bei einfachen Anfragen Lücken.

Praktisch bedeutet das: Embedding-Qualität regelmäßig mit domain-spezifischen Test-Queries evaluieren, nicht nur generischen Benchmarks vertrauen. Retrieval-Recall auf echten Kundenfragen messen, nicht auf synthetischen Datasets.

Reranking: Der unterschätzte Qualitätshebel

Die meisten RAG-Systeme nehmen die Top-k Ergebnisse aus der Vektorähnlichkeitssuche und geben sie direkt ans Sprachmodell. Das Problem: Vektorähnlichkeit misst semantische Nähe, nicht Relevanz. Zwei Texte können semantisch nah sein (beide handeln von Retouren) aber für die konkrete Anfrage ("Wie lange dauert meine Rückerstattung?") völlig unterschiedlich relevant sein.

Reranking fügt einen zweiten Bewertungsschritt ein: Ein spezialisiertes Modell (Cross-Encoder) vergleicht die Anfrage direkt mit jedem Kandidaten-Chunk und bewertet die tatsächliche Relevanz. Das ist rechenintensiver als reine Vektorsuche, aber die Qualitätsverbesserung ist signifikant — besonders bei komplexen oder mehrdeutigen Anfragen.

Ein System entsteht erst durch die Integration

Chunking, Embeddings und Reranking sind keine unabhängigen Optimierungsprobleme. Besseres Chunking verändert, welche Embeddings produziert werden. Bessere Embeddings verschieben, welche Chunks ins Reranking kommen. Und Reranking kompensiert Schwächen in beiden vorgelagerten Schritten.

Teams, die ihre RAG-Pipeline ernsthaft verbessern wollen, sollten nicht einen Parameter isoliert optimieren. Sie sollten die gesamte Kette als System betrachten — und dort ansetzen, wo der größte Qualitätsverlust entsteht. Das findet man nicht im Benchmark-Report. Das findet man, indem man echte Kundenanfragen durch die Pipeline schickt und nachmisst, wo die Antwortqualität einbricht.