Lost in Parsing

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Warum die Qualität eines RAG-Systems schon beim Einlesen der Dokumente entschieden wird, und welche zwei Stufen dabei den Unterschied machen.

🎚️ Soundcheck

In Ausgabe #001 dieses Newsletter habe ich schon ein Anti-Pattern genannt: „Wir laden einfach alle PDFs hoch.“ Seitdem ging es um Retrieval, Wissensgraphen, Evaluation und zuletzt in #011 um hybride Suche und Reranking. Alle diese Verfahren haben allerdings eine gemeinsame Voraussetzung, über die irgendwie ziemlich selten gesprochen wird: Sie können natürlich nur finden, was beim Einlesen tatsächlich noch vorhanden ist.

Genau dort, in der Ingestion, gehen in der Praxis erstaunlich viele Antworten verloren, und zwar still & heimlich. Hier gibt's kein Fehler, kein Log-Eintrag oder ähnliches, das System läuft einfach weiter. Nur die eine Tabelle aus dem einen Vertrag ist beim Parsing zu einer zusammenhangslosen Wortkette geworden, und der Satz mit der entscheidenden Ausnahme wurde beim Chunking von seinem restlichen, aber dennoch relevanten Bezug getrennt. Diese Ausgabe behandelt die zwei Stufen, an denen das passieren kann: das Parsing, also die Umwandlung des Dokuments in strukturierten Text, und das Chunking, also die Aufteilung in abrufbare Einheiten.

🎤 Main Set: Das Parsing

Wenn einfache Textextraktion nicht klappt

Die meisten Dokumente in einem Unternehmens-Sharepoint sind meist alles andere als „sauber“ aufgebaut. Sie haben Tabellen, ein mehrspaltiges Layout, Kopf- und Fußzeilen auf jeder Seite, und ein durchaus großer Teil liegt als Scan vor, nicht als einfach zu verarbeitenden Text. Eine einfache Textextraktion aus dem PDF liest die Zeichen in der Reihenfolge aus, in der sie in der Datei stehen, und die entspricht bei solchen Dokumenten oft nicht unbedingt der Lesereihenfolge.

Das konkrete Ergebnis: Eine Preistabelle mit den Spalten Wartungsstufe, Reaktionszeit und Monatspreis wird zu einer flachen Zeichenfolge, in der Zellen zusammenlaufen und die Zuordnung von Wert zu Spalte verloren geht. Auf die Frage „Was kostet Wartungsstufe 2?“ findet das System dann zwar ein Textstück mit allen richtigen Zahlen, kann die passende aber nicht mehr zuordnen. Bei zweispaltigem Layout werden Sätze aus der linken und rechten Spalte ineinander verschränkt, und bei Scans kommt ohne OCR schlicht gar kein Text raus.

Was strukturerhaltende Parser anders machen

Die Antwort darauf sind Parser, die eine Seite nicht als Zeichenstrom, sondern als Bild mit Layout verarbeiten und daraus Struktur rekonstruieren: Überschriften als Überschriften, Tabellen als Tabellen mit Zeilen und Spalten, Absätze in korrekter Lesereihenfolge. Das bekannteste quell-offene Werkzeug dafür ist Docling von IBM, inzwischen unter dem Dach der Linux Foundation, mit einem kompakten Modell (Granite-Docling), das eine Seite in einem Durchlauf verarbeitet. Kommerzielle Dienste wie LlamaParse arbeiten nach demselben Prinzip.

Der Preis ist natürlich Rechenzeit, denn ein solcher Parser braucht pro Seite ein Vielfaches einer reinen Textextraktion. Die Entscheidung ist deshalb keine grundsätzliche, sondern eine nach Dokumenttyp: Für saubere, einspaltige Textdokumente reicht die einfache Extraktion, für bestimmte Verträge, Handbücher, Berichte mit Tabellen und Scans ist der strukturerhaltende Parser der Unterschied zwischen einer beantwortbaren und einer unbeantwortbaren Frage.

🥁 Track 2: Das Chunking

Probleme mit den Chunk-Grenzen

Nach dem Parsing wird der Text in Abschnitte zerlegt, weil ein Retriever nicht ganze Dokumente, sondern Abschnitte vergleicht. Der einfachste Ansatz schneidet nach einer festen Anzahl Zeichen oder Token. Genau an diesen Schnitten entsteht das nächste Problem: Ein Abschnitt beginnt mit „Diese Frist gilt nicht bei Verträgen mit Laufzeit unter zwölf Monaten“, und welche Frist gemeint ist, stand im vorherigen Abschnitt. Der Abschnitt ist für sich genommen nicht mehr verständlich, und ein Embedding, das nur diesen Abschnitt sieht, kann die Frage nach der Frist nicht mit ihm verbinden.

Ein erster Schritt ist ohnehin, entlang der Struktur zu schneiden, die das Parsing geliefert hat: an Überschriften, nicht mitten im Absatz, und eine Tabelle bleibt als Ganzes ein einziger Chunk. Das löst das Bezugsproblem aber nicht vollständig, weil auch Abschnitte innerhalb eines Kapitels aufeinander verweisen.

Was ist also die Lösung?

Für das Problem haben sich zwei Verfahren etabliert, die auf unterschiedlichem Weg dasselbe erreichen: Jeder Chunk trägt den Kontext seines Dokuments mit sich.

Contextual Retrieval (von Anthropic) lässt ein Sprachmodell für jeden Chunk ein bis zwei Sätze Einordnung schreiben, etwa „Dieser Abschnitt regelt die Kündigungsfrist im Wartungsvertrag mit Kunde X“, und stellt sie dem Chunk vor dem Einbetten voran. Der Mehraufwand ist hier entsprechend ein Modellaufruf pro Chunk, einmalig bei der Ingestion. Nach Anthropics eigener Messung sank die Zahl der Fälle, in denen der richtige Abschnitt nicht unter den besten zwanzig Treffern war, in Kombination mit Reranking um bis zu 67 Prozent.

Late Chunking (von Jina) kommt ohne Sprachmodell aus. Das Embedding-Modell verarbeitet zunächst das ganze Dokument auf Token-Ebene, und erst danach werden die Chunk-Grenzen gezogen und die Vektoren pro Abschnitt zusammengefasst. Jeder Chunk-Vektor enthält dadurch tatsächlich Information aus dem gesamten Dokument, der Bezug auf die Frist aus dem vorherigen Abschnitt (bezogen auf das Vertrags-Beispiel oben) ist also im Vektor bereits enthalten. Das ist günstiger als Contextual Retrieval, setzt aber ein Embedding-Modell voraus, das lange Eingaben verarbeiten kann.

Eine Vergleichsstudie auf arXiv (Reconstructing Context, 2504.19754) liefert dazu einen Befund, der die Prioritäten zurechtrückt: Sobald Late Chunking im Einsatz ist, unterscheiden sich einfache Fixed-Window-Chunks und aufwendiges semantisches Chunking kaum noch in der Ergebnisqualität. Anders gesagt, der Aufwand gehört eher in die Erhaltung des Kontexts als in die Feinjustierung der Schnittstellen.

🎯 Encore: Der eine Gedanke für Entscheider

Die Dokument-Ingestion ist die Stufe, deren Recall niemand so wirklich auf dem Schirm hat & misst. Warum? Weil sie vor allem liegt, was üblicherweise evaluiert wird. Ein Dokument, dessen Tabelle beim Parsing zerfallen ist, taucht in keiner Retrieval-Metrik als Fehler auf, es fehlt einfach. Jeder spätere Schritt, von hybrider Suche bis Reranking, arbeitet nur mit dem, was diese erste Stufe durchgelassen hat.

Die Prüffrage für Entscheider: Haben wir unsere zwanzig strukturell „schlimmsten“ Dokumente, mit Tabellen, Scans und Mehrspaltenlayout, einmal durch den Parser geschickt und das Ergebnis tatsächlich angesehen, und ist eine Tabelle danach noch eine Tabelle?

💿 B-Side

Anti-Pattern: Alle Dokumenttypen mit derselben einfachen Textextraktion einlesen und anschließend in feste Token-Chunks schneiden, weil das halt der Standard des Frameworks ist. Für den sauberen Textbericht funktioniert das, für den Vertrag mit der Preistabelle entsteht ein Index, der die wichtigen Antworten womöglich gar nicht enthält, und die Suche danach ist von vornherein aussichtslos.

Praxis: Ein kleines Testset aus den „hässlichsten“ eigenen Dokumenten anlegen, das Parsing-Ergebnis für jedes davon sichten, und den Retrieval-Recall aus #004 getrennt nach Dokumenttyp messen. Dort, wo er einbricht, liegt das Problem übrigens fast immer vor dem Retriever.

---

Das war Rag'n'Roll #013. Die nächste Ausgabe fragt, ob ein zweiter Agent überhaupt nötig ist: was drei aktuelle Studien zu Single- und Multi-Agent-Systemen zeigen, und woran man vor dem Bauen erkennt, welches Muster zur Aufgabe passt.

Weiterleiten erwünscht🤘