RAG Chunking: Strategien für Unternehmensdaten

Chunking ist eine messbare Retrieval-Hypothese. Eine fixe Chunk-Größe ist kein Architekturziel. Die richtige Strategie ist diejenige, die für reale Fragen die relevante Evidenz zuverlässig auffindbar macht, ohne Kontextgrenzen und Dokumentstruktur unnötig zu zerstören.

Ein Retriever durchsucht nicht abstrakt ein Dokument, sondern die Einheiten, die beim Indexieren entstanden sind. Wird eine Bedingung von der zugehörigen Anweisung getrennt oder eine Tabelle in unzuordenbare Textreste zerlegt, helfen bessere Embeddings, Reranker oder Modelle nur begrenzt.

Für den Gesamtzusammenhang siehe RAG-System entwickeln & richtig aufbauen. Die Qualität der Ingestion vor dem Chunking behandelt RAG-Datenquellen anbinden.

Warum fixe Token-Grenzen oft am Dokument vorbeigehen

Ein Token-Limit weiß nicht, ob es gerade einen Warnhinweis, eine Tabellenzeile oder die Voraussetzung eines Konfigurationsschritts trennt. Kleine Einheiten können sehr präzise gefunden werden, verlieren aber ihren Begründungszusammenhang. Große Einheiten halten Kontext zusammen, nehmen aber leicht mehrere Themen auf und schleppen irrelevanten Text mit.

Die beste Chunk-Größe existiert deshalb nicht unabhängig vom Query-Set und der erwarteten Evidenz.

Das Szenario: ein Service-Handbuch, keine Demo-Passage

Als Referenz dient eine 40–60-seitige technische Betriebsanleitung für eine Produktfamilie. Sie enthält Kapitel und Unterkapitel, Konfigurationsschritte, Troubleshooting, Querverweise, Warnhinweise, Tabellen sowie Produktcodes und Ersatzteilnummern.

Die späteren Nutzerfragen sind konkret:

• „Welches Drehmoment gilt für Bauteil X?“
• „Welche Voraussetzung muss vor Schritt 4 erfüllt sein?“
• „Was bedeutet Fehlercode E217?“
• „Welche Warnung gilt nur für Modell B?“
• „Welche Ersatzteilnummer gehört zu Baugruppe Y?“

Entscheidend ist nicht, ob jeder Chunk formal gleich groß ist. Drehmoment und Bauteil, Voraussetzung und Schritt, Fehlercode und Bedeutung oder Warnung und Modellbezug müssen gemeinsam als belastbare Evidenz verfügbar sein.

Drei Strategien gegen dieselben Fragen

Fixed-size: die technische Baseline

Fixed-size teilt extrahierten Text bei einem festen Zeichen- oder Token-Limit. Das ist einfach, reproduzierbar und als Baseline sinnvoll. Im Handbuch kann die Grenze aber mitten durch Folgendes laufen:

• einen Warnhinweis für Modell B und den zugehörigen Arbeitsschritt,
• eine Tabellenzeile mit Baugruppe und Ersatzteilnummer,
• Schritt 4 und die unmittelbar davor stehende Voraussetzung.

Es entstehen oft kleine, gut indexierbare Einheiten mit unvollständiger Evidenz. Overlap kann die Grenze abfedern, aber nicht sinnvoll ersetzen.

Structure-aware: die Dokumentgrenzen ernst nehmen

Structure-aware Chunking folgt vor allem den Grenzen, die das Handbuch bereits trägt: H1/H2/H3, Abschnitt, Liste, Tabelle und semantisch zusammengehörender Block. Ein Chunk kann etwa aus Überschrift, Konfigurationsschritten und zugehörigem Warnhinweis bestehen.

Das erhält den Abschnittspfad für Aussagen wie „gilt nur für Modell B“ und verhindert, dass Schritt 4 ohne seine Voraussetzung indexiert wird. Die Einheiten werden unterschiedlich groß. Sehr lange Abschnitte brauchen eine kontrollierte Unterteilung – möglichst an weiteren logischen Grenzen statt blind mitten im Inhalt.

Parent/Child: präzise finden, vollständig beantworten

Parent/Child trennt Retrieval- und Antwortkontext bewusst. Kleine Child-Einheiten werden für die Suche indexiert; nach einem Treffer wird der größere Parent-Abschnitt als Kontext für die Antwort geladen.

Retrieval Unit und Context Unit müssen nicht identisch sein.

Im Handbuch kann ein Child exakt „E217“ oder „Baugruppe Y“ treffen. Der Parent liefert dann Fehlerbeschreibung, Ursache, betroffene Modelle, Warnung und nächsten Prüfschritt beziehungsweise die vollständige Ersatzteiltabelle. Das reduziert Fremdkontext beim Retrieval, kann im Antwortkontext aber mehr Material als nötig laden. Der Parent muss deshalb eine fachlich sinnvolle Grenze bleiben, etwa ein Troubleshooting-Unterabschnitt statt das ganze Kapitel.

Vergleich: welche Evidenz kommt bei den fünf Fragen an?

Die Tabelle ist keine allgemeine Rangliste. Sie beschreibt eine Hypothese für dieses Handbuch. Bei einem Korpus aus kurzen, homogenen Notizen könnte dieselbe Bewertung anders ausfallen.

Sonderfälle: Struktur ist Evidenz

Tabellen dürfen nicht blind mitten in einer Zeile gesplittet werden. Bei einer Ersatzteiltabelle müssen Tabellenkopf, Baugruppe, Produktcode und Ersatzteilnummer so erhalten bleiben, dass die Zuordnung eindeutig bleibt. Ist die Extraktion bereits kaputt, ist das zuerst ein Parsing- und Normalisierungsproblem, nicht ein Chunk-Größenproblem.

Listen und Konfigurationsschritte sollten möglichst als logische Einheit bleiben: Die Voraussetzung vor Schritt 4 gehört nicht in einen anderen Retrieval-Kontext als Schritt 4. Warnhinweise dürfen nicht vom zugehörigen Abschnitt getrennt werden – insbesondere nicht vom Modell, der Konfiguration oder dem Arbeitsschritt, für den sie gelten. Überschriften, Code- und Produktkennungen gehören in die indexierbare Repräsentation; sie tragen oft den entscheidenden Fachbezug.

Overlap: Kompensation, nicht Default

Overlap kopiert einen Randbereich in den nächsten Chunk. Er kann bei Fixed-size die Chance erhöhen, dass eine Grenze zwischen Warnung und Schritt oder zwischen Tabellenkopf und Zeile weniger schadet.

Er ersetzt aber keine sinnvolle Grenze: Duplikate vergrößern den Index, erzeugen nahezu identische Treffer und können redundanten Antwortkontext liefern. Overlap ist sinnvoll, wenn die Evaluation zeigt, dass relevante Evidenz an unvermeidbaren Grenzen verloren geht – nicht als Standardantwort auf schlecht erhaltene Dokumentstruktur.

Chunking als Evaluationsexperiment

Für dieses Handbuch wird jede der drei Varianten mit denselben Fragen aus einem Golden Dataset getestet. Pro Frage sollte die erwartete Evidenz feststehen, etwa die konkrete Tabellenzeile, der Warnhinweis mit Modellbezug oder die Schritte 1–4.

• Recall@k: Taucht die erwartete Evidenz unter den ersten k Retrieval-Ergebnissen auf?
• Evidence Coverage: Deckt der Retrieval-Kontext alle für die Antwort nötigen Teile ab?
• Context Precision: Wie viel irrelevanter Kontext wird zusätzlich geladen?
• Answer Correctness: Kann das System die Frage mit dieser Evidenz richtig beantworten?

Diese Metriken zeigen, ob eine Grenze Evidenz verloren hat, ob der Parent zu groß gewählt ist oder ob die Suchschicht den passenden Child nicht findet. Aufbau, Ground Truth und Regressionen beschreibt der bestehende Artikel RAG Evaluation: Metriken, Golden Dataset & Regression Tests.

Chunking und Hybrid Search gemeinsam prüfen

Bei exakten Produktcodes, Teilenummern und Fehlercodes wie E217 kann Hybrid Search die lexikalische Suche mit semantischem Retrieval kombinieren. Das verbessert die Chance, den richtigen Kandidaten zu finden. Es repariert jedoch keine getrennte Tabellenzeile und keinen abgelösten Warnhinweis. Chunk-Grenzen und Ranking müssen deshalb getrennt getestet werden.

Entscheidungsregel für Production

Bei strukturierten Unternehmensdokumenten würde ich nicht mit blindem 500-Token-Chunking starten. Ich würde zuerst die Dokumentstruktur erhalten und dann gegen reale Fragen testen, ob kleinere Retrieval-Einheiten oder Parent/Child-Retrieval die Evidenz zuverlässiger treffen.

Fixed-size bleibt eine nützliche Vergleichsbasis. Structure-aware ist für dieses Handbuch der naheliegende erste Produktionskandidat. Parent/Child ist gerechtfertigt, wenn Tests zeigen, dass präzise Treffer regelmäßig mehr Abschnittskontext für korrekte Antworten benötigen. Die beste Chunk-Größe hängt vom Query-Set und der erwarteten Evidenz ab.