Was ist die beste Chunk-Größe für RAG?

Es gibt keinen universell besten Wert. Zu kleine Abschnitte verlieren Kontext, zu große verwässern die Relevanz und füllen das Kontextfenster unnötig. In der Praxis bewährt sich, Dokumente an natürlichen Grenzen wie Absätzen oder Abschnitten zu teilen und benachbarte Chunks leicht überlappen zu lassen, damit zusammenhängende Aussagen nicht zerrissen werden. Die passende Größe hängt von Dokumentart und Anwendungsfall ab und sollte mit einer Evaluation überprüft werden.

Was bedeutet Top-K beim Retrieval?

Top-K bezeichnet die Anzahl der Textabschnitte, die das System pro Anfrage aus dem Vektor-Store abruft — etwa die fünf oder zehn ähnlichsten Stellen. Ein höheres K liefert mehr Kontext, erhöht aber das Risiko, irrelevante Passagen mitzuschleppen, und füllt das Kontextfenster. Ein niedriges K ist fokussierter, kann aber relevante Stellen übersehen. Der passende Wert wird über Evaluation justiert, oft in Kombination mit einem Re-Ranking-Schritt.

Warum brauche ich Re-Ranking, wenn das Retrieval schon die ähnlichsten Stellen liefert?

Die Vektorsuche findet schnell viele inhaltlich ähnliche Kandidaten, ordnet sie aber nur grob nach Vektorähnlichkeit. Ein Re-Ranking-Schritt bewertet diese Kandidaten anschließend genauer auf ihre tatsächliche Relevanz zur Frage und sortiert sie neu. So landen die wirklich passenden Stellen vorn, bevor sie an das Sprachmodell gehen — das verbessert die Antwortqualität spürbar.

Wissen · Aktualisiert: 4. Juni 2026

RAG-Architektur im Detail

Ein RAG-System ist mehr als ein Modell mit angeschlossener Suche. Dieser Beitrag öffnet die vier Stufen — vom Chunking über Embeddings und Vektor-Store bis zu Retrieval, Generierung und Evaluation — und zeigt, worauf es in der Praxis ankommt.

Von Slava Spitsyn · AI Builder · Redaktionelle Grundsätze (englisch)

Ein RAG-System lässt sich auf vier Stufen herunterbrechen: Dokumente aufbereiten und einbetten, in einem Vektor-Store ablegen, zur Anfrage die relevanten Stellen abrufen und daraus eine Antwort mit Quellen erzeugen. Klingt geradlinig — und ist es im Prinzip auch. Die Qualität entsteht jedoch in den Details jeder Stufe: in der Chunking-Strategie, der Wahl der Embeddings, der Abstimmung des Retrievals und der Kontrolle der Generierung.

Dieser Beitrag vertieft die Architektur, die der Leitfaden RAG für Unternehmenswissen im Überblick skizziert. Er bleibt technisch korrekt, aber zugänglich.

Stufe 1: Chunking — Dokumente sinnvoll teilen

Bevor ein Dokument durchsuchbar wird, muss es in handhabbare Abschnitte zerlegt werden — das sogenannte Chunking. Diese Stufe wird oft unterschätzt, prägt aber die spätere Antwortqualität stärker als fast jede andere.

Die Kunst liegt in der richtigen Granularität:

Zu kleine Chunks verlieren Kontext. Ein einzelner Satz ohne Umgebung lässt sich schlecht sinnvoll abrufen.
Zu große Chunks verwässern die Relevanz und füllen später das Kontextfenster mit Ballast.

Bewährt hat sich, an natürlichen Grenzen zu teilen — Absätze, Abschnitte, Überschriften — statt stur nach Zeichenzahl zu schneiden. Eine leichte Überlappung benachbarter Chunks sorgt dafür, dass zusammenhängende Aussagen nicht an einer Schnittkante zerrissen werden. Welche Größe passt, hängt von der Dokumentart ab und sollte über eine Evaluation überprüft werden.

Stufe 2: Embeddings — Bedeutung in Vektoren

Jeder Chunk wird in einen Embedding-Vektor übersetzt — eine numerische Repräsentation seiner inhaltlichen Bedeutung. Inhaltlich ähnliche Abschnitte liegen in diesem Vektorraum nahe beieinander, auch wenn sie unterschiedliche Worte verwenden. Genau das macht die spätere semantische Suche möglich: Es zählt die Bedeutung, nicht der exakte Wortlaut.

Die Wahl des Embedding-Modells hat Folgen. Ein verbreiteter, pragmatischer Standard ist OpenAIs text-embedding-3-small. Wo strengere Datenschutzanforderungen gelten, lassen sich EU-gehostete oder lokal betriebene Embedding-Modelle einsetzen. Wichtig ist Konsistenz: Dokumente und Anfragen müssen mit demselben Modell eingebettet werden, damit ihre Vektoren vergleichbar sind.

Stufe 3: Vektor-Store — speichern und durchsuchen

Die Embeddings landen in einem Vektor-Store, einer Datenbank, die auf Ähnlichkeitssuche im Vektorraum spezialisiert ist. Häufig ist dafür kein eigenes Spezialsystem nötig: Mit pgvector lässt sich eine bestehende PostgreSQL-Datenbank um Vektorsuche erweitern. Das hält die Architektur schlank — Ihre Inhalte liegen in einer vertrauten, betreibbaren Datenbank statt in einem zusätzlichen Dienst.

Damit die Suche auch bei großen Beständen schnell bleibt, nutzen Vektor-Stores Indexverfahren, die nicht jeden Vektor einzeln vergleichen, sondern näherungsweise die ähnlichsten Kandidaten finden. Für die meisten Unternehmensanwendungen ist diese Näherung in Geschwindigkeit und Qualität ein guter Kompromiss.

Stufe 4: Retrieval, Re-Ranking und Generierung

Stellt ein Nutzer eine Frage, wird auch diese eingebettet und mit dem Vektor-Store abgeglichen. Drei Schritte führen zur Antwort:

Retrieval (Top-K). Das System holt die K ähnlichsten Abschnitte — etwa die fünf oder zehn besten Treffer. Ein höheres K liefert mehr Kontext, schleppt aber leichter Irrelevantes mit; ein niedriges K ist fokussierter, übersieht aber eventuell passende Stellen. Der richtige Wert wird über Evaluation justiert.
Re-Ranking. Die Vektorsuche ordnet Kandidaten nur grob nach Ähnlichkeit. Ein optionaler Re-Ranking-Schritt bewertet die Treffer anschließend genauer auf ihre tatsächliche Relevanz zur Frage und sortiert sie neu. So landen die wirklich passenden Stellen vorn, bevor sie ans Modell gehen — ein oft unterschätzter Hebel für die Antwortqualität.
Generierung mit Quellen. Die ausgewählten Stellen gehen zusammen mit der Frage an das Sprachmodell, das daraus eine zusammenhängende Antwort formuliert. Ein gut gebautes System weist dabei die Quellen aus, aus denen die Antwort stammt — das macht sie überprüfbar.

Evaluation und Halluzinations-Kontrolle

Ein RAG-System ist nie „fertig“, sobald es Antworten liefert — entscheidend ist, wie gut diese Antworten sind. Deshalb gehört Evaluation fest zur Architektur. Geprüft wird typischerweise zweierlei:

Retrieval-Qualität: Liefert die Suche tatsächlich die relevanten Stellen? Fehlt ein passendes Dokument im Ergebnis, kann auch das beste Modell nicht korrekt antworten.
Antwort-Qualität: Stützt sich die Antwort erkennbar auf den abgerufenen Kontext — oder erfindet das Modell etwas dazu?

RAG senkt das Risiko von Halluzinationen deutlich, weil das Modell auf konkretem Kontext arbeitet und Quellen ausweisen kann. Es beseitigt sie nicht: Fehlen relevante Dokumente oder ruft das System die falschen Stellen ab, bleiben falsche Antworten möglich. Eine kontinuierliche Evaluation macht solche Schwächen sichtbar und justierbar — etwa über Chunk-Größe, K-Wert oder Re-Ranking.

Wie es weitergeht

Die Architektur entscheidet auch darüber, ob ein RAG-System mit RAG allein auskommt oder ob ein bestimmtes Verhalten zusätzlich Fine-Tuning verlangt. Und sie bestimmt, wie weit sich der Betrieb in die eigene Infrastruktur verlagern lässt — bis hin zum vollständig lokalen Aufbau, den der Beitrag RAG on-premise betreiben behandelt.

Fazit

Hinter dem schlanken Vier-Stufen-Bild eines RAG-Systems steckt an jeder Stufe handwerkliche Substanz: durchdachtes Chunking, konsistente Embeddings, ein betreibbarer Vektor-Store, ein abgestimmtes Retrieval mit Re-Ranking und eine quellenbasierte Generierung — zusammengehalten durch eine ehrliche Evaluation. Wer diese Stufen versteht, baut RAG-Systeme, die nicht nur antworten, sondern verlässlich und nachvollziehbar antworten.