Agentic Chunking: Nicht jeder Dokumentenschnitt braucht ein LLM

Ein RAG-System scheitert nicht erst beim Prompt. Häufig verliert es entscheidende Informationen schon dann, wenn technische Dokumentation in Suchabschnitte zerlegt wird. Tabellen werden getrennt, Revisionen verwechselt oder ein Satz wird ohne die zugehörige Überschrift indexiert. Eine semantisch ähnliche Textstelle ist noch keine gültige Antwort.

Agentic Chunking verspricht, solche Grenzen intelligenter zu bestimmen: Ein Sprachmodell oder ein mehrstufiger Workflow analysiert Inhalt und Struktur, bevor Chunks für die Suche erzeugt werden. Das kann helfen, wenn Dokumente uneinheitlich aufgebaut sind. Es ist aber keine Garantie für bessere Retrieval-Ergebnisse.

Wir behandeln Chunking deshalb als überprüfbare Architekturentscheidung. Die Frage lautet nicht, ob ein Modell einen plausiblen Split erzeugt. Die Frage lautet, ob dadurch reale Suchanfragen zuverlässiger beantwortet werden – bei vertretbarem Indexierungsaufwand, belastbarer Datenherkunft und kontrollierbaren Betriebskosten.

Die Grundlagen von Retrieval, Kontextaufbereitung und Antwortgenerierung beschreiben wir in unserem Beitrag RAG-System entwickeln.

„Agentic Chunking“ ist kein einheitlich standardisierter Algorithmus. Der Begriff beschreibt unterschiedliche Implementierungen: Manche lassen ein LLM Themenwechsel und Abschnittsgrenzen bestimmen. Andere verwenden mehrere Schritte, um Kapitel zu klassifizieren, Abschnitte zu verknüpfen oder Chunks mit zusätzlichem Kontext zu versehen.

Das müssen wir auseinanderhalten. Ein LLM, das Trennstellen vorschlägt, ist nicht automatisch ein autonomer Agent. Eine kontextuelle Zusammenfassung vor dem Embedding ist wiederum nicht dasselbe wie eine neue Chunk-Grenze. Und ein Parent-Child-Retriever ist eine Retrieval-Strategie, keine LLM-basierte Segmentierung.

Für Architekturentscheidungen beschreiben wir deshalb den konkreten Verarbeitungsschritt: Welche Eingaben erhält das Modell? Was darf es verändern? Welche Grenzen müssen eingehalten werden? Wie erkennen wir Fehler und spielen den ursprünglichen Text wieder aus?

Fixed-Size Chunking trennt Text nach Tokens oder Zeichen mit optionalem Overlap. Das ist schnell, günstig und reproduzierbar. Es eignet sich als messbare Baseline, kann aber Überschriften, Tabellen und Anweisungen ungünstig aufteilen.

Structure-Aware Chunking folgt der Dokumentstruktur: Kapitel, Überschriften, Absätze, Listen, Tabellen und Codeblöcke. Für gut strukturierte technische Dokumentation ist das häufig der beste Ausgangspunkt. Der Parser muss dabei Lesereihenfolge und Hierarchie korrekt erkennen.

Semantic Chunking verwendet beispielsweise Embedding-Ähnlichkeiten benachbarter Sätze, um inhaltliche Übergänge zu erkennen. Dafür wird nicht zwingend ein generatives LLM eingesetzt. Verfahren wie der SemanticSplitterNodeParser von LlamaIndex arbeiten mit Ähnlichkeitswerten und Schwellwerten.

LLM-basiertes oder Agentic Chunking lässt ein Modell die Struktur interpretieren oder Grenzen vorschlagen. Das kann anspruchsvolle Dokumente besser erschließen, erzeugt aber zusätzliche Modellaufrufe, mögliche Fehlentscheidungen und Anforderungen an Validierung sowie Reproduzierbarkeit.

Hierarchical Chunking speichert kleine Suchabschnitte und größere Parent-Abschnitte mit Beziehungen zueinander. Bei der Suche lassen sich präzise Treffer finden und bei Bedarf der umgebende Kontext laden. Diese Methode kann völlig ohne agentische Segmentierung funktionieren.

Eine praktische Einordnung der Parser- und Hierarchieverfahren findet sich in der LlamaIndex-Dokumentation zu Node Parsers.

Ein vereinfachtes Beispiel aus der Instandhaltung: In der Dokumentation einer Antriebseinheit stehen die Überschrift „Baureihe M-400, Revision 5“, eine Tabelle mit Anzugsmomenten und darunter der Hinweis „Diese Werte gelten nicht bei der Hochtemperatur-Ausführung; siehe Abschnitt 7.3“. Das ist ein illustratives Szenario, kein reales Projektergebnis.

Ein Split nach 500 Tokens kann den Tabellenabschnitt vom Gültigkeitshinweis trennen. Eine semantische Suche findet dann womöglich genau das gesuchte Anzugsmoment, nicht aber die Einschränkung. Gibt der Assistent nur den isolierten Wert zurück, klingt die Antwort sicher und ist für eine konkrete Maschinenkonfiguration möglicherweise falsch.

Structure-Aware Chunking kann Überschrift, Tabellenzeilen, Einheiten und Hinweise als gemeinsame logische Einheit behandeln. Eine hierarchische Retrieval-Strategie kann beim Treffer die umgebende Parent-Section ergänzen. LLM-basierte Segmentierung lohnt sich erst, wenn solche deterministischen Verfahren die Struktur nicht zuverlässig rekonstruieren.

Die verbindliche Freigabe eines Dokumentstands kommt weiterhin aus den entsprechenden Fach- oder Quellsystemen. Ein Modell darf sie nicht allein aus sprachlicher Plausibilität bestimmen.

Die Qualität einer Chunking-Pipeline beginnt bei der Extraktion. Bei PDF-Dateien können Tabellen, mehrspaltige Seiten, Kopfzeilen, Fußnoten und Querverweise falsch gelesen werden. Bei gescannten Dokumenten kommen OCR-Fehler hinzu. LLM-basiertes Chunking auf fehlerhaft extrahiertem Text repariert solche Probleme nicht automatisch.

Wir erfassen zuerst die Dokumenthierarchie und erhalten – soweit die Quelle es zulässt – Titel, Kapitelpfad, Tabellen, Listen, Code, Seitenbezüge und die Position einer Textstelle im Ursprungsdokument. Anschließend führen wir Normalisierung und gegebenenfalls fachliche Klassifikation durch.

Erst auf dieser Grundlage wählen wir zwischen strukturbasiertem, semantischem und modellgestütztem Chunking. Bei Tabellen mit Einheiten, technischen Parametern oder Revisionen sind explizite Regeln häufig wichtiger als eine besonders elegante semantische Segmentierung.

Die Pipeline soll Daten lesbarer und abrufbarer machen, ohne Quelleninformationen, Reihenfolge oder fachliche Einschränkungen unbemerkt zu verändern.

Wenn ein LLM Grenzen vorschlägt, sollte es nicht gleichzeitig verbindliche Fakten neu formulieren. Eine robuste Implementierung lässt das Modell beispielsweise auf vorhandene Abschnitte oder Zeichen-Offsets verweisen. Den finalen Chunk-Text erzeugt anschließend ein deterministischer Prozess aus dem Originaldokument.

Wir validieren das Ergebnis: Sind alle vorgeschlagenen Positionen gültig und sortiert? Bleiben Überschriften mit dem richtigen Inhalt verbunden? Gibt es unerlaubte Lücken oder Überschneidungen? Werden definierte Mindest- und Maximalgrößen sowie unveränderliche Tabellenbereiche eingehalten? Ist die Zuordnung zu Quelle und Revision vollständig?

Ungültige Vorschläge führen nicht zu stillen Korrekturen durch dasselbe Modell. Die Pipeline protokolliert den Fehler und verwendet eine festgelegte Fallback-Strategie, etwa den strukturbasierten Split. Die Modell- und Prompt-Version, das Ergebnis und die Kosten werden für spätere Vergleiche erfasst.

Eine solche Validierung garantiert noch keine fachlich richtige Segmentierung. Sie verhindert aber, dass ein generatives System unbemerkt Inhalte verändert oder beschädigte Chunks in den Index schreibt.

Ein Chunk benötigt mehr als Text und Embedding. Für Unternehmensdokumente speichern wir mindestens einen stabilen Quell-Identifier, Dokumentversion, Abschnittspfad, Position im Original, Aktualisierungszeitpunkt und die für den Zugriff relevanten Metadaten.

Je nach Fachbereich kommen Produkt-ID, Anlagenkonfiguration, Gültigkeitsdatum, Standort oder Klassifizierung hinzu. Der Index muss außerdem Löschungen, zurückgezogene Freigaben und Berechtigungsänderungen nachvollziehen. Die Zugriffskontrolle muss bereits vor der Übergabe an das Sprachmodell greifen.

Die Metadaten sind kein optionales Zusatzfeld. Ohne sie lässt sich ein ähnlicher Text womöglich finden, aber nicht sicher entscheiden, ob er für die konkrete Anfrage gültig und zugänglich ist. Für technische Dokumente sind eindeutige Beziehungen zwischen Produkt, Variante und Dokument häufig wichtiger als die gewählte Chunking-Methode.

Warum das bei Unternehmensdaten über reine Dokumentensuche hinausgeht, analysieren wir im Beitrag Die KI findet das Dokument. Aber kennt sie den Kontext?.

Eine weitere Option besteht darin, kurze Kontextinformationen an einen bereits erzeugten Chunk anzufügen: aus welchem Dokument er stammt, welche Kapitelüberschrift gilt und auf welche Produktvariante er sich bezieht. Das verbessert potenziell die Auffindbarkeit, ohne die ursprüngliche Quelle zu ändern.

Anthropic beschreibt diesen Ansatz als Contextual Retrieval und kombiniert kontextualisierte Informationen unter anderem mit Embedding-Suche und BM25. Die Methode ist nicht identisch mit Agentic Chunking: Sie verändert primär die Repräsentation für Suche und Retrieval, nicht zwingend die Chunk-Grenzen.

Solcher Kontext darf fachlich verbindliche Angaben nicht frei dazuerfinden. Wir unterscheiden deshalb strikt zwischen extrahierten Metadaten, verifizierten Daten aus Quellsystemen und generierten Erläuterungen. Generierte Zusatztexte bleiben als solche gekennzeichnet und werden gegen eine Evaluationsbasis getestet.

Die technische Methode und die zugehörigen Evaluationen erklärt Anthropic unter Introducing Contextual Retrieval.

Für lange Richtlinien, Spezifikationen und Handbücher ist es oft sinnvoll, kleine Abschnitte für die Suche zu indexieren, bei einem Treffer aber zusätzlich den übergeordneten Abschnitt zu laden. So lassen sich präzise Treffer mit ihrer fachlichen Umgebung verbinden.

Ein Beispiel: Die Suche trifft eine einzelne Tabellenzeile zur Komponententemperatur. Der Parent-Abschnitt enthält Anwendungsgrenzen, Einheiten und Revision. Für die Modellantwort wird nicht das gesamte Handbuch benötigt, wohl aber der Abschnitt, der den Einzelwert verständlich macht.

Hierarchische Verfahren erzeugen zusätzliche Index- und Verwaltungsaufgaben. Sie sind trotzdem oft leichter zu prüfen als frei durch ein LLM erzeugte Wissenseinheiten. Bevor wir auf Agentic Chunking wechseln, testen wir deshalb Structure-Aware Chunking und Parent-Child-Retrieval als einfache, nachvollziehbare Baselines.

LlamaIndex dokumentiert dazu einen Hierarchical Node Parser mit Parent-Child-Beziehungen.

Ein pauschales Limit von 500 oder 1.000 Tokens ist kein Architekturprinzip. Kleine Chunks können präzise Treffer begünstigen, verlieren jedoch schneller zusammengehörige Aussagen. Große Chunks erhalten mehr Kontext, erhöhen aber potenziell Latenz, Indexkosten und den Modell-Input.

Auch Overlap ist kein kostenloser Qualitätsgewinn. Zu viel Überlappung vervielfacht ähnliche Treffer und kann die Diversität des abgerufenen Kontexts verschlechtern. Besser ist es, strukturierte Kapitelbeziehungen zu behalten und bei Bedarf gezielt angrenzende Abschnitte zu ergänzen.

Ein NVIDIA-Vergleich verschiedener Chunking-Ansätze zeigte, dass die beste Segmentierung zwischen Datensätzen und Fragetypen variiert. Daraus folgt gerade keine universelle Empfehlung für eine bestimmte Chunk-Größe oder eine generative Methode.

Die Untersuchung und ihre Grenzen beschreibt NVIDIA unter Finding the Best Chunking Strategy for Accurate AI Responses.

Wir vergleichen mindestens drei Varianten auf denselben Dokumenten und Fragen: einen deterministischen Baseline-Split, eine Structure-Aware- oder hierarchische Variante und eine LLM-gestützte Variante. Alle Kandidaten nutzen nach Möglichkeit dieselben Embeddings, denselben Retriever und dieselben Filter. Nur so lässt sich der Einfluss der Segmentierung sinnvoll beurteilen.

Ein Testset umfasst echte oder fachlich geprüfte Fragen mit erwarteten Quellenstellen. Besonders wichtig sind negative Fälle: falsche Revisionen, ähnliche Produktnummern, Tabellen mit Bedingungen, Querverweise, mehrdeutige Bezeichnungen und Dokumente, die ausdrücklich keine Antwort enthalten.

Wir messen Retrieval Recall@k, Precision@k oder MRR für die gefundenen Quellen, zusätzlich die fachliche Antwortkorrektheit und den tatsächlichen Quellenbezug. Dazu gehören Chunk-Anzahl, Indexgröße, Extraktionsfehler, Indexierungsdauer, Token-Verbrauch, Antwortlatenz und Kosten pro erfolgreich gelöster Aufgabe.

Der Vergleich muss auch Wiederholbarkeit prüfen: Liefert dasselbe Modell bei erneuter Verarbeitung dieselben Grenzen? Was passiert nach einem Modell- oder Prompt-Update? Und ändern sich bereits gültige Ergebnisse, wenn nur ein einzelnes Quellendokument aktualisiert wurde?

Eine begutachtete Studie in NAACL Findings 2025 fand bei Semantic Chunking keine konsistenten Verbesserungen, die den zusätzlichen Rechenaufwand generell rechtfertigen. Das untersucht nicht jede denkbare Agentic-Chunking-Variante, ist aber ein klarer Grund, Mehrwert zu messen statt anzunehmen.

Chunking ist häufig eine einmalige Indexierungsentscheidung pro Dokumentversion, aber kein folgenloser Preprocessing-Schritt. Jede Änderung an Parser, Prompt, Modell oder Metadaten-Schema kann neue Chunk-Grenzen und dadurch andere Suchtreffer erzeugen.

Wir versionieren daher Extraktions- und Chunking-Strategie, pflegen stabile Source-IDs und dokumentieren die Zuordnung zwischen Originaldokument, abgeleitetem Chunk und Suchindex. Aktualisieren oder löschen Quellsysteme Inhalte, müssen die betroffenen Indexeinträge konsistent nachgezogen werden.

Im Betrieb überwachen wir fehlgeschlagene Ingestion-Jobs, Index-Aktualität, Chunk-Verteilung, Retrieval-Qualität, Antwortzeit und Kosten. Traces verbinden Anfrage, Filter, Treffer, Modellaufruf und Antwort. So lässt sich feststellen, ob eine schlechte Antwort beim Quelltext, bei der Segmentierung, beim Retrieval oder bei der Generierung entstanden ist.

Wie wir Evaluation, Tracing und Monitoring über die gesamte KI-Anwendung betrachten, erläutern wir unter KI-Agenten in Produktion: Observability.

Wir beginnen mit einem deterministischen Parser und einer einfachen, messbaren Baseline. Bei sauber strukturierten Markdown-Dateien, API-Dokumentationen oder Richtlinien mit klaren Überschriften ist Structure-Aware Chunking meist der erste Kandidat. Die zusätzliche Komplexität eines LLMs muss dafür erst einen nachweisbaren Nutzen liefern.

Wir prüfen LLM-gestützte Verfahren besonders bei heterogenen Dokumentbeständen, schwer erkennbaren Themenübergängen oder inhaltlichen Zusammenhängen, die strukturelle Regeln wiederholt falsch schneiden. Auch dann gelten feste Grenzen: Quellen erhalten, Offsets validieren, Regeln für Tabellen und Revisionen durchsetzen, Fallback definieren und Evals ausführen.

Wenn die eigentliche Frage veraltete Stammdaten, widersprüchliche Dokumente oder Beziehungen zwischen ERP, PLM und SharePoint betrifft, ist Chunking nicht der Haupthebel. Dann brauchen wir Data Engineering, eindeutige Identifikatoren, fachliche Modelle und gegebenenfalls strukturierte Abfragen oder einen Knowledge Graph.

Solche Daten- und Retrieval-Architekturen entwickeln wir im Data Engineering und im übergreifenden Data & AI Engineering.

Ein guter Chunk ist kein Selbstzweck. Er ist eine Komponente einer Anwendung, die relevante Informationen verlässlich bereitstellt. In einem Serviceprozess muss das Ergebnis zur richtigen Maschine, zur gültigen Revision und zur konkreten Aufgabe passen – nicht nur sprachlich ähnlich sein.

Mit Valanor AI verbinden wir Unternehmens-, Maschinen- und Sensordaten mit Analytics, Machine Learning und KI. Wir entwickeln die Datenbasis, die passende Retrieval- oder Modelllogik und den Übergang zu nachvollziehbaren Empfehlungen und Aufgaben in bestehenden Systemen.

Wir entscheiden anhand von Fehlerkosten, fachlicher Relevanz und gemessener Qualität, wo LLMs sinnvoll sind. Ein zusätzlicher Modellaufruf ist nur dann gut, wenn das Gesamtsystem dadurch nachweislich besser arbeitet.