Chunking, Parsing und die verlorenen Zusammenhänge

Retrieval-Systeme arbeiten selten direkt mit vollständigen Dokumenten. Sie zerlegen Inhalte in kleinere Einheiten, erzeugen Repräsentationen und suchen später nach passenden Segmenten. Das klingt wie eine technische Routine: Text extrahieren, nach einer festen Zeichenzahl schneiden, Embeddings bilden, fertig. Genau hier entstehen jedoch viele Fehler, die später fälschlich dem Sprachmodell zugeschrieben werden.

Wenn eine Tabellenzeile ohne Spaltenüberschrift, eine Ausnahme ohne zugehörige Regel oder eine Bildunterschrift ohne Abbildung abgerufen wird, ist der Treffer semantisch beschädigt. Er kann ähnliche Wörter enthalten und trotzdem nicht mehr dieselbe Aussage tragen. Chunking ist deshalb keine bloße Speicheroptimierung. Es entscheidet, welche Wissenseinheiten das System überhaupt sehen, vergleichen und belegen kann.

Parsing kommt vor Chunking

Eine PDF-Datei ist zunächst eine Anordnung von Zeichen und grafischen Elementen auf Seiten. Ihre visuelle Ordnung entspricht nicht automatisch einer maschinenlesbaren Lesereihenfolge. Mehrspaltige Texte, Kopf- und Fußzeilen, Seitenzahlen, Fußnoten, Textkästen, Tabellen und eingescannte Seiten können bei einfacher Extraktion durcheinandergeraten.

Parsing rekonstruiert aus diesem Layout eine Dokumentstruktur. Es erkennt Überschriftenebenen, Absätze, Listen, Tabellen, Abbildungen, Bildunterschriften, Fußnoten und Seitenbezüge. Bei Scans kommt Texterkennung hinzu. Erst nach dieser Rekonstruktion ist sinnvoll bestimmbar, was zusammengehört.

Ein Parser kann ebenfalls irren: Er wiederholt Fußzeilen, verschachtelt zwei Spalten, löst Bindestriche falsch auf oder verwandelt eine Tabelle in unverbundene Wörter. Deshalb sollte er strukturierte Elemente mit Typ, Position, Lesereihenfolge und Konfidenz ausgeben, nicht nur Fließtext. Docling beschreibt ein solches Vorgehen mit Layoutanalyse und Tabellenerkennung. Das konkrete Werkzeug ist austauschbar; das Architekturprinzip ist es nicht.

Dokumente besitzen mehrere Ordnungen zugleich

Ein Dokument hat eine lineare Reihenfolge, eine hierarchische Gliederung und zusätzliche Referenzbeziehungen. Ein Absatz steht nach einem anderen, gehört unter eine Überschrift und verweist möglicherweise auf eine Tabelle drei Seiten später. Reiner Fließtext bewahrt nur die lineare Ordnung.

Für zuverlässiges Retrieval braucht ein Segment zusätzlich seinen Pfad: Dokument → Kapitel → Abschnitt → Element. Dazu kommen Nachbarn, Querverweise und die Version des Ursprungsdokuments. „Es gelten folgende Ausnahmen" ist ohne Überschrift und Vorgänger bedeutungslos. Mit dem Pfad Sicherheitsrichtlinie → Zugriffssteuerung → Externe Konten → Ausnahmen wird der Geltungsbereich sichtbar.

Feste Fenster sind eine Baseline, keine Strategie

Die einfachste Segmentierung schneidet nach einer festen Zahl von Tokens oder Zeichen. Sie ist schnell und reproduzierbar, respektiert aber keine Satz-, Absatz- oder Abschnittsgrenzen. Die Schnittkante kann genau zwischen Regel und Bedingung liegen.

Kleine Chunks erhöhen die thematische Präzision, verlieren aber Definitionen, Einschränkungen und Begründungen. Große Chunks bewahren mehr Zusammenhang, enthalten jedoch mehrere Themen, verbrauchen Kontextbudget und verdünnen die relevante Passage. Es gibt keine universell richtige Größe. Glossareintrag, Vertragsklausel, Tabellenzeile und Methodenkapitel benötigen unterschiedliche Segmentierungsprofile.

Overlap wiederholt einen Teil des vorherigen Segments im nächsten. Das hilft bei kurzen Gedankengängen, erzeugt aber Duplikate und stellt keine Struktur wieder her. Eine Tabellenzeile erhält durch hundert wiederholte Tokens nicht automatisch ihre Spaltenüberschrift. Eine Fußnote bleibt ohne Referenzanker unklar. Overlap ist eine lokale Sicherheitsmarge, kein Ersatz für explizite Beziehungen.

Tabellen sind kleine Datenmodelle

Die Bedeutung einer Tabellenzelle entsteht aus Zeilen- und Spaltenkopf, Einheit, Gruppierung und häufig einer Fußnote. Ein Segment „12 | 18 | 24" sagt nicht, ob Monate, Prozentwerte oder Stückzahlen gemeint sind. Ein brauchbares Tabellensegment enthält Titel, relevante Überschriften, Einheit, Zeilenbezeichnung, Werte, Fußnoten und Quellenposition.

Große Tabellen können in Zeilengruppen geteilt werden, doch jedes Child verweist auf ein Parent-Objekt der vollständigen Tabelle. Für Trendfragen kann eine strukturierte Datenrepräsentation geeigneter sein als reiner Text. Ähnlich bleiben Bildunterschrift, Figure-ID und erklärender Absatz miteinander verknüpft, auch wenn sie getrennt gespeichert werden.

Querverweise erzeugen unsichtbare Abhängigkeiten

„Wie oben beschrieben", „diese Werte" oder „sie gilt nicht für …" sind Verweise. Ein Segment kann grammatisch vollständig erscheinen und trotzdem seinen Bezug verloren haben. Ein Context Packet kann deshalb einen kleinen Primärchunk, den Abschnittspfad, eine kurze Parent-Zusammenfassung und gezielt aufgelöste Referenzen enthalten.

Parent-Child-Modelle trennen Such- und Antwortgranularität. Kleine Children sind gut auffindbar; bei einem Treffer wird kontrolliert der größere Parent oder eine definierte Nachbarschaft nachgeladen. Das ist häufig robuster, als alle Chunks von Beginn an groß zu machen.

Semantische und hierarchische Verfahren

Semantisches Chunking setzt Grenzen dort, wo sich das Thema erkennbar ändert. Es kann bei Fließtext besser funktionieren als starre Fenster, erkennt formale Beziehungen aber nicht immer. Eine robuste Strategie kombiniert harte Strukturgrenzen mit weichen semantischen Signalen.

Late Chunking verarbeitet zunächst einen größeren Zusammenhang und bildet erst danach Repräsentationen für Teilbereiche. Dadurch können Chunk-Embeddings Informationen aus dem Umfeld tragen. Das ist ein relevanter Ansatz, aber keine universelle Reparatur: Falsche Lesereihenfolge, zerstörte Tabellenstruktur oder fehlende Versionen bleiben falsch.

RAPTOR organisiert rekursive Zusammenfassungen in einer Baumstruktur und ermöglicht Retrieval auf mehreren Abstraktionsebenen. Detailsegmente und übergeordnete Synthesen dürfen gemeinsam indexiert werden, bleiben aber unterschiedliche Evidenztypen. Eine Zusammenfassung ist keine Primärquelle; finale Aussagen sollten auf die zugrunde liegenden Passagen zurückführen.

Auch ein großes Kontextfenster beseitigt das Problem nicht. Untersuchungen zum „Lost in the Middle"-Effekt zeigen, dass relevante Information je nach Position in langen Eingaben schlechter genutzt werden kann. Mehr Kontext ist nicht automatisch besserer Kontext. Auswahl, Reihenfolge und Hervorhebung bleiben Engineering-Aufgaben.

Extraktion ist nicht Verständnis

Der erste Verarbeitungsschritt macht Inhalte technisch zugänglich. Bei digitalen PDFs kann Text extrahiert werden; bei Scans ist optische Zeichenerkennung nötig. Tabellen, Spalten, Fußnoten, Überschriften und Lesereihenfolgen müssen erhalten oder rekonstruiert werden. Ein plausibler Textstrom beweist nicht, dass die Dokumentstruktur korrekt erfasst wurde.

Qualität beginnt deshalb mit prüfbaren Extraktionsmerkmalen: Seitenbezug, erkannter Dokumenttyp, Sprache, OCR-Konfidenz, Tabellenanzahl und Warnungen für unlesbare Bereiche. Bei kritischen Quellen sollte der extrahierte Text auf die visuelle Originalseite zurückverweisen. So lässt sich ein Fehler von der späteren Antwort bis zum Scan zurückverfolgen.

Ein nützlicher Grundsatz lautet: Das Original bleibt unverändert, die Extraktion wird versioniert und jede weitere Ableitung erhält eine eigene Kennung. Eine korrigierte OCR-Fassung überschreibt nicht stillschweigend die vorherige. Sie verweist auf Quelle, Verarbeitungsprozess und Zeitpunkt.

Segmentierung bestimmt, was auffindbar bleibt

Für semantisches Retrieval werden lange Dokumente meist in kleinere Einheiten zerlegt. Zu große Segmente enthalten viel Nebeninhalt; zu kleine Segmente verlieren Definitionen, Einschränkungen oder Begründungen. Eine universell richtige Segmentgröße gibt es nicht. Sie hängt von Dokumenttyp, Fragen, Sprache, Einbettungsmodell und verfügbarem Kontextfenster ab.

Besser als blindes Schneiden nach Zeichenzahl ist eine strukturorientierte Strategie: Überschrift, Absatz, Tabellenzeile, Entscheidung oder Sprecherwechsel bilden natürliche Grenzen. Überlappung kann Kontext erhalten, erzeugt aber Duplikate und darf nicht dazu führen, dass dieselbe Aussage mehrfach als unabhängige Evidenz erscheint.

Jedes Segment braucht eine Rückbindung an das Dokument:

chunk_id: decision-2026-014#section-03
source_id: decision-2026-014
source_version: 2.1
page_or_timecode: "04:12-05:08"
section: "Entscheidung und Begründung"
status: approved
valid_from: 2026-06-01
access_class: internal

Diese Felder sind keine Dekoration. Sie ermöglichen Filter, Zitation, Zugriffskontrolle und Fehleranalyse. Ein Textsegment ohne stabile Herkunft ist für eine belastbare Antwort nur eingeschränkt brauchbar.

Beziehungen tragen mehr als Ordnernamen

Ordner bilden gewöhnlich einen Ablageort ab. Projektwissen ist mehrdimensional. Ein Dokument kann gleichzeitig zu einem Kunden, einer Entscheidung, einem Arbeitspaket, einer Risikoannahme und einer offenen Frage gehören. Beziehungen machen sichtbar, was ein Dateipfad nicht ausdrücken kann.

Eine minimale Wissensstruktur benötigt noch keinen Wissensgraphen. Markdown-Dateien mit maschinenlesbarem Kopfbereich, stabile Kennungen, interne Links und ein gepflegter Index reichen für kleine Bestände oft aus. Wichtig ist, dass Beziehungstypen unterschieden werden: „begründet", „widerspricht", „ersetzt", „gilt für", „entstand aus" und „benötigt Freigabe" haben unterschiedliche Bedeutung.

Bei größeren Beständen können Graphstrukturen und Vektorsuche kombiniert werden. Vektoren unterstützen Ähnlichkeit, Graphbeziehungen unterstützen explizite Verknüpfungen. Keines von beiden entscheidet automatisch, ob eine Quelle gültig ist. Status und Berechtigungen müssen als verbindliche Filter vor dem Retrieval wirken, nicht erst als Hinweis im Prompt.

Qualität wird auf mehreren Ebenen gemessen

Eine End-to-End-Bewertung allein sagt zu wenig. Die Pipeline braucht getrennte Prüfungen. Extraktionstests prüfen Lesereihenfolge, Tabellen und Zeichenfehler. Metadatentests prüfen Pflichtfelder, erlaubte Werte und Referenzen. Retrievaltests fragen, ob relevante Quellen unter den ersten Treffern erscheinen und ob gesperrte Inhalte ausgeschlossen bleiben. Antworttests prüfen Evidenztreue, Vollständigkeit, Unsicherheitsangabe und Zitationskorrektheit.

Ein gutes Testset besteht aus realen Aufgaben, schwierigen Negativfällen und bekannten Widersprüchen. Es enthält auch Fragen, die das System nicht beantworten darf. „Keine hinreichende Evidenz" ist ein korrektes Ergebnis, wenn der Wissensraum keine belastbare Grundlage bietet.

Wissen braucht einen Lebenszyklus

Projektwissen verändert sich. Entscheidungen werden revidiert, Quellen veralten, Rollen wechseln und Schutzklassen ändern sich. Deshalb braucht jede Wissensbasis den Zyklus: aufnehmen, extrahieren, klassifizieren, verbinden, prüfen, freigeben, verwenden, aktualisieren und archivieren.

KI kann Metadaten vorschlagen, Entitäten erkennen, ähnliche Inhalte gruppieren, Widersprüche markieren und Zusammenfassungen erzeugen. Diese Vorschläge dürfen nicht mit Freigabe verwechselt werden. Menschen sichern fachliche Bedeutung, Verbindlichkeit und Ausnahmen; Automatisierung macht die Erschließung skalierbar und wiederholbar.

Der entscheidende Architekturgedanke lautet: Das Ziel ist nicht die größte Sammlung und nicht die höchste Zahl an Verknüpfungen. Das Ziel ist, dass ein Mensch oder Agent für eine konkrete Aufgabe den kleinsten verlässlichen, zulässigen und nachvollziehbaren Kontext erhält.

Methode: PARSE → STRUCTURE → SEGMENT → LINK → RETRIEVE → REASSEMBLE → TEST

PARSE rekonstruiert Lesereihenfolge und Elemente. STRUCTURE bildet Hierarchie und Typen. SEGMENT erzeugt zweckgebundene Einheiten. LINK erhält Parent, Nachbarn und Querverweise. RETRIEVE sucht kleine Kandidaten. REASSEMBLE ergänzt kontrolliert den notwendigen Zusammenhang. TEST prüft Grenzfälle, Quellenbindung und Versionen.

Die Regel lautet: so klein wie für präzises Retrieval nötig, so reich an Beziehungen wie für korrekte Interpretation erforderlich.

Übung: Erstelle eine Chunk Integrity Map

1. Wähle drei Seiten mit Überschrift, Tabelle oder Querverweis.

2. Markiere Lesereihenfolge und Elementtypen.

3. Ziehe Chunk-Grenzen und begründe sie.

4. Notiere Parent, Nachbarn, Referenzen und Metadaten.

5. Formuliere eine Tabellen- und eine Ausnahmefrage.

6. Prüfe, ob der Treffer kontrolliert erweitert werden muss.

7. Dokumentiere je einen Parsing-, Boundary- und Reassembly-Fehler.

Reflexion: Welche Information verliert ohne Überschrift oder Nachbarabsatz ihren Sinn? Welche Beziehung sollte explizit gespeichert werden, statt auf Überlappung zu vertrauen?

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Optimale Chunking-Verfahren sind korpus-, modell- und aufgabenabhängig. Die Ansätze sind Architekturbausteine, keine universellen Leistungsgarantien. Redaktionell geprüft am 17. Juli 2026.