Chunking für RAG: Dokumente richtig für die KI-Suche zerteilen

Ein Sprachmodell liest nie Ihr ganzes Dokument. Es liest Häppchen. Diese Häppchen heißen Chunks, und wie Sie ein Dokument in Chunks zerlegen, entscheidet darüber, ob Ihre KI-Suche den passenden Absatz findet oder einen halben Satz aus dem falschen Kapitel.

Viele Teams stecken Wochen in die Auswahl des Embedding-Modells und der Vektordatenbank. Das Zerteilen der Dokumente erledigen sie nebenbei mit drei Zeilen Code. Dabei liegt genau hier oft der Grund, warum eine RAG-Anwendung schwache Antworten liefert. Dieser Beitrag zeigt, welche Verfahren es gibt, wo ihre Grenzen liegen und wie Sie für Ihre Daten das richtige finden.

Warum der Chunk die wichtigste Einheit ist

Beim Aufbau einer RAG-Pipeline zerlegen Sie jedes Dokument in kleinere Abschnitte. Jeder Abschnitt wird einzeln eingebettet und in der Vektordatenbank abgelegt. Stellt ein Nutzer eine Frage, sucht das System die am besten passenden Chunks und legt sie dem Sprachmodell als Kontext vor. Das Modell antwortet also ausschließlich auf Basis dessen, was in diesen Häppchen steht.

Daraus folgt eine unbequeme Wahrheit. Zerschneiden Sie einen Gedanken mitten im Satz, bekommt das Modell nur die Hälfte. Packen Sie dagegen fünf Themen in einen einzigen Chunk, verwässert die Bedeutung und die Suche greift unscharf. Der Chunk ist die kleinste Einheit, die Ihre Anwendung je zu Gesicht bekommt – und damit die Stellschraube, an der am meisten hängt.

Die gute Nachricht: Sie können hier viel gewinnen, ohne ein einziges Modell auszutauschen. Besseres Chunking kostet kein zusätzliches GPU-Budget. Es braucht nur ein Verständnis dafür, wie Ihre Dokumente aufgebaut sind.

Der naive Weg und sein Preis

Die meisten Bibliotheken schlagen denselben Standard vor: feste Länge. Sie schneiden den Text alle 500 oder 1000 Zeichen durch, egal was dort gerade steht. Das ist schnell eingebaut und funktioniert bei glattem Fließtext erstaunlich oft. Der Haken zeigt sich, sobald Ihre Dokumente Struktur haben.

Ein Schnitt nach fester Zeichenzahl trennt eine Tabelle von ihrer Überschrift. Er reißt eine Aufzählung auseinander. Er kappt eine Vertragsklausel in der Mitte, sodass die Bedingung im einen Chunk steht und die Rechtsfolge im nächsten. Die Suche findet dann einen Fetzen, dem der entscheidende Kontext fehlt, und das Modell rät sich den Rest zusammen.

Besonders tückisch wird es bei technischen Unterlagen, Rechnungen oder Formularen. Dort trägt die Position einer Zahl ihre ganze Bedeutung. Wird sie vom Kopf ihrer Spalte getrennt, ist sie wertlos. Feste Länge ist deshalb ein guter Startpunkt für einen Prototyp, aber selten die Antwort für den Produktivbetrieb.

Der Struktur des Dokuments folgen

Der nächste Schritt ist naheliegend: Zerteilen Sie dort, wo das Dokument selbst Grenzen zieht. Ein rekursiver Splitter versucht zuerst, an Absätzen zu trennen. Reicht das nicht, geht er auf Sätze herunter, dann auf einzelne Wörter. So bleibt zusammen, was inhaltlich zusammengehört, und ein Chunk endet am Absatzende statt mitten im Wort.

Noch mehr holen Sie heraus, wenn Sie die Auszeichnung des Dokuments auswerten. Markdown kennt Überschriften, HTML kennt Abschnitte, PDFs tragen oft eine erkennbare Gliederung. Schneiden Sie entlang dieser Hierarchie, entstehen Chunks, die je einem Thema entsprechen. Ein Kapitel, ein Unterpunkt, eine Klausel – jeweils als eigene Einheit.

Der Aufwand lohnt sich dort, wo Ihre Dokumente sauber strukturiert sind: Handbücher, Richtlinien, Wissensdatenbanken. Je klarer die Vorlage gegliedert ist, desto besser folgt ihr der Splitter. Bei chaotisch gescannten Altbeständen stößt das Verfahren an Grenzen, weil die Struktur schlicht fehlt.

Nach Bedeutung statt nach Form trennen

Manchmal verrät die Form nichts über den Inhalt. Ein Transkript aus einer Besprechung läuft als Textwüste ohne Überschriften. Hier hilft semantisches Chunking. Das Verfahren bettet Satz für Satz ein und misst, wie stark sich zwei benachbarte Sätze bedeutungsmäßig ähneln. Fällt diese Ähnlichkeit ab, liegt dort vermutlich ein Themenwechsel – und genau da setzt der Schnitt.

Das Ergebnis sind Chunks, die inhaltlich in sich geschlossen sind, auch wenn das Dokument äußerlich keine Gliederung bietet. Wechselt das Gespräch vom Budget zum Zeitplan, erkennt das Verfahren den Übergang und trennt dort. Jeder Abschnitt behandelt dann genau ein Thema.

Der Preis ist Rechenzeit. Semantisches Chunking bettet den Text schon beim Zerteilen ein, nicht erst beim Indexieren. Bei großen Beständen kann das ins Gewicht fallen. Für wertvolle, unstrukturierte Quellen zahlt sich der Mehraufwand oft trotzdem aus, weil die Trefferqualität spürbar steigt.

Overlap, Metadaten und der Elternkontext

Egal welches Verfahren Sie wählen, drei Kniffe verbessern fast jedes Ergebnis. Sie kosten wenig und verhindern typische Fehler an den Rändern der Chunks.

• Überlappung: Lassen Sie benachbarte Chunks einige Sätze teilen. So geht ein Gedanke, der genau auf der Schnittkante liegt, keiner Seite verloren.
• Metadaten: Hängen Sie jedem Chunk Herkunft, Kapitel, Datum und Dokumenttyp an. Damit filtern Sie die Suche vor und können dem Nutzer am Ende die Quelle nennen.
• Elternkontext: Suchen Sie mit kleinen, präzisen Chunks, geben Sie dem Modell aber den größeren Abschnitt ringsum. Kleine Einheiten treffen genauer, der weitere Kontext macht die Antwort vollständig.

Gerade der letzte Punkt, oft Parent-Document-Retrieval genannt, löst einen echten Zielkonflikt. Kleine Chunks finden die richtige Stelle, liefern dem Modell aber zu wenig Umfeld. Große Chunks geben Kontext, verwässern aber die Suche. Trennen Sie beides: suchen fein, antworten breit.

Late Chunking: erst einbetten, dann trennen

Ein neuerer Ansatz dreht die übliche Reihenfolge um. Statt den Text zuerst zu zerschneiden und jeden Schnipsel isoliert einzubetten, schickt Late Chunking das ganze Dokument durch das Embedding-Modell. Erst danach teilt es die entstandenen Vektoren in Chunks auf. Jeder Abschnitt trägt so die Information des gesamten Dokuments in sich.

Der Vorteil zeigt sich bei Bezügen über Satzgrenzen hinweg. Steht in Absatz drei nur das Pronomen „das Unternehmen“ und der Name fiel in Absatz eins, weiß ein klassisch isolierter Chunk nichts von diesem Namen. Beim Late Chunking ist die Verbindung bereits im Vektor verankert, weil das Modell den ganzen Text auf einmal gesehen hat.

Voraussetzung ist ein Embedding-Modell mit ausreichend langem Kontextfenster. Moderne, frei verfügbare Modelle bringen das mit. Das Verfahren ist jung, aber es passt gut zu einem selbst gehosteten Aufbau, bei dem Sie ohnehin die volle Kontrolle über die Pipeline haben.

Wie Sie die passende Strategie finden

Die eine richtige Chunking-Methode gibt es nicht. Was passt, hängt an Ihren Dokumenten und an der Art der Fragen. Ein Handbuch mit klarer Gliederung verlangt ein anderes Vorgehen als ein Stapel formloser Protokolle. Beginnen Sie deshalb nicht mit der Technik, sondern mit einem Blick auf Ihre Daten.

Danach hilft nur Messen. Legen Sie einen kleinen Satz echter Fragen samt erwarteter Belegstellen an. Testen Sie zwei, drei Chunking-Varianten gegeneinander und prüfen Sie, welche die richtigen Absätze nach oben bringt. Dieser Aufwand von einem Tag erspart Ihnen später Wochen des Rätselns, warum die Antworten nicht stimmen.

Behandeln Sie Chunking als das, was es ist: eine eigene Entscheidung mit großer Wirkung, nicht als Fußnote im Setup. Wer hier sauber arbeitet, holt aus demselben Modell und derselben Datenbank deutlich bessere Antworten heraus – ohne einen Cent mehr für Hardware.

Sie möchten eine RAG-Lösung aufbauen, die auf Ihre Dokumente und Ihre Infrastruktur zugeschnitten ist? Wir begleiten Unternehmen beim Entwurf und Betrieb selbst gehosteter KI-Systeme – von der Dokumentenaufbereitung bis zur produktiven Suche. Sprechen Sie mit uns auf ai-designers.de.

Bilder: AI-Designed