Chunking: Texte für RAG sinnvoll in Abschnitte zerlegen

Beispiel aus der Praxis

In der Wissensbasis mit RAG und MCP-Server ist Chunking der zweite Schritt des Ingest-Workflows. Ein Dokument-Loader liest die Dateien aus einem Ordner, ein Text-Splitter zerlegt sie in Abschnitte, danach entstehen mehrsprachige Embeddings, und Text und Vektoren landen in PostgreSQL mit Vektor-Erweiterung.

Agenten sehen von diesem Schritt nichts. Sie rufen über einen MCP-Server nur die Suche auf und bekommen die passenden Abschnitte zurück. Gerade deshalb ist das Chunking eine zentrale Stellschraube: Was beim Zerlegen auseinandergerissen wird, kann später keine Suche mehr zusammenfügen.

Weil Ingest und Retrieval getrennte Workflows sind, lässt sich die Chunking-Strategie ändern und der Bestand neu einlesen, ohne einen angebundenen Agenten anzufassen. Die Änderung wirkt zentral für alle Clients.

Warum braucht RAG Chunking?

Ein RAG-System sucht zu einer Frage passende Textstellen und gibt sie einem Sprachmodell als Kontext. Ganze Dokumente eignen sich dafür schlecht, aus zwei Gründen.

Erstens haben auch Embedding-Modelle eine Obergrenze an Tokens, die sie in einen Vektor übersetzen. Pinecone weist darauf hin, dass überzählige Tokens sonst abgeschnitten werden können und wichtiger Inhalt damit gar nicht im Vektor ankommt (Pinecone, Chunking Strategies). Zweitens wird ein Vektor umso unschärfer, je mehr Themen ein Text enthält. Ein Handbuch mit fünfzig Kapiteln als ein Vektor passt zu jeder Frage ein bisschen und zu keiner richtig.

Die Ähnlichkeit wird bei der semantischen Suche deshalb auf Ebene der Chunks berechnet (Pinecone, Chunking Strategies). Pinecone nennt eine einfache Faustregel: Ein Abschnitt, der für einen Menschen ohne den umgebenden Text Sinn ergibt, ergibt auch für das Sprachmodell Sinn.

Welche Chunking-Strategien gibt es?

Pinecone bezeichnet Chunking nach fester Größe als häufigsten und einfachsten Ansatz und empfiehlt, dort zu beginnen und erst bei Bedarf zu verfeinern (Pinecone, Chunking Strategies). LangChain empfiehlt für die meisten Fälle den RecursiveCharacterTextSplitter als Ausgangspunkt (LangChain Docs, Text splitters). Er versucht zuerst, ganze Absätze zu erhalten, und weicht nur bei Bedarf auf Sätze und Wörter aus; die Standard-Trennzeichen sind Leerzeile, Zeilenumbruch, Leerzeichen und zuletzt einzelne Zeichen (Pinecone, Chunking Strategies).

Semantisches Chunking geht auf ein Notebook von Greg Kamradt zurück. Der Text wird in Sätze zerlegt, jeweils mit den Nachbarsätzen eingebettet, und wo die Distanz zwischen benachbarten Gruppen springt, entsteht eine neue Grenze (Pinecone, Chunking Strategies).

Was ist Überlappung beim Chunking?

Überlappung (Chunk Overlap) bedeutet, dass das Ende eines Chunks am Anfang des nächsten noch einmal vorkommt. Ein Gedanke, der an der Schnittkante beginnt, steht dann vollständig in mindestens einem der beiden Abschnitte.

Wie groß die Überlappung ausfällt, ist eine Abwägung. Mehr Überlappung bedeutet mehr gespeicherten Text, mehr Embeddings und doppelte Inhalte in den Treffern. OpenAI nutzt für seine Dateisuche standardmäßig 800 Tokens pro Chunk und 400 Tokens Überlappung; die Überlappung darf höchstens die Hälfte der Chunk-Größe betragen (OpenAI API Reference, Vector Stores, Stand: Oktober 2026). Andere Werkzeuge haben andere Voreinstellungen, deshalb lohnt der Blick in die Dokumentation des jeweiligen Text-Splitters.

Wie groß sollte ein Chunk sein?

Eine allgemeingültige Größe gibt es nicht. Kleine Chunks treffen eine Frage präziser, verlieren aber den Zusammenhang. Große Chunks behalten mehr Kontext, enthalten aber auch mehr Text, der nicht zur Frage passt, und verbrauchen mehr Platz im Kontextfenster des Sprachmodells.

Pinecone schlägt vor, eine Spanne von Größen zu testen, etwa kleinere Chunks mit 128 oder 256 Tokens und größere mit 512 oder 1.024 Tokens, und die Ergebnisse mit repräsentativen Fragen zu vergleichen (Pinecone, Chunking Strategies). Entscheidend sind dabei die Art der Dokumente und das verwendete Embedding-Modell. Kurze FAQ-Einträge oder Produktdatenblätter müssen oft gar nicht zerlegt werden.

Was hat Chunking mit Contextual Retrieval zu tun?

Jede Chunking-Strategie hat dasselbe Grundproblem: Ein Abschnitt verliert seinen Bezug zum Gesamtdokument. Ein Satz wie „Die Frist beträgt drei Monate“ sagt ohne Dokumenttitel nicht, um welchen Vertrag es geht.

Contextual Retrieval setzt nach dem Chunking an. Ein Sprachmodell schreibt für jeden Chunk einen kurzen Kontext aus dem Gesamtdokument und stellt ihn voran, bevor Embeddings und Stichwortindex entstehen (Anthropic, 2024). Chunking bestimmt also, wo geschnitten wird; Contextual Retrieval repariert, was beim Schneiden an Zusammenhang verloren geht. Wie sich beides in eine Unternehmensarchitektur einfügt, zeigt der Artikel Company Brain aufbauen.

Was bedeutet Chunking für Inhalte, die in KI-Suchen erscheinen sollen?

Viele KI-Suchen und Antwortmaschinen arbeiten intern mit Retrieval. Wie einzelne Anbieter Webseiten zerlegen, legen sie meist nicht offen. Die Faustregel aus dem Chunking lässt sich trotzdem auf das eigene Schreiben übertragen: Absätze, die ohne den Rest der Seite verständlich sind, lassen sich auch als einzelne Abschnitte sinnvoll verwenden.

Praktisch heißt das: eine klare Gliederung mit Überschriften, die die Frage des Absatzes nennen, Begriffe im Absatz ausschreiben statt mit „dies“ auf vorherige Abschnitte zu verweisen, und Zahlen mit Quelle im selben Satz. Google selbst nennt für seine KI-Funktionen keine besonderen Optimierungen, sondern die üblichen SEO-Grundlagen, darunter wichtige Inhalte in Textform bereitzustellen (Google Search Central, AI features). Mehr dazu steht unter Generative Engine Optimization und KI-Sichtbarkeit.

Welche Fehler passieren beim Chunking?

Der häufigste Fehler ist eine einzige Strategie für alle Dokumenttypen. Verträge, Tabellen, Code und FAQ-Seiten haben verschiedene Strukturen und brauchen oft verschiedene Splitter.

Ein zweiter Fehler betrifft Tabellen und Listen. Werden sie zeilenweise zerschnitten, landen Spaltenüberschriften und Werte in verschiedenen Chunks, und kein Abschnitt ist für sich verständlich.

Ein dritter Fehler ist, die Chunk-Größe nach Gefühl festzulegen und nie zu prüfen. Feste Testfragen mit bekannten richtigen Abschnitten zeigen, ob eine Änderung die Suche verbessert oder verschlechtert, bevor sie produktiv geht.