Kapitel 2 — Intelligentes Document-Parsing

Zweiter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Ein Retrieval-System erbt die Qualität seines Inputs — und die Input-Schicht ist der Ort, an dem die häufigste Ursache enttäuschender RAG-Qualität still wohnt.

Warum dieses Kapitel existiert

Die erste Version einer RAG-Pipeline benutzt fast immer das PDF-zu-Text-Werkzeug, das gerade herumlag. Plausibel aussehender Text kommt heraus, der Index füllt sich, das Modell produziert plausibel aussehende Antworten. Monate später entdeckt das Team, dass Tabellen lautlos zu Fließtext geplättet wurden, mehrspaltige Papiere zeilenweise verschränkt sind, Fußnoten in Absätze eingespleißt wurden und Bildunterschriften vollständig fehlen. Die Decke der Retrieval-Qualität war gesetzt, bevor das Retrieval überhaupt konfiguriert wurde. Dieses Kapitel handelt davon, die Input-Schicht ernst zu nehmen, denn nichts weiter unten kann zurückholen, was der Parser weggeworfen hat.

2.1 Warum das Plätten einer PDF das Wichtige verliert

Eine PDF ist eine Liste von Glyphen mit Koordinaten, gezeichnet auf Seiten mit deklarierter Größe. Die visuelle Struktur, die ein Mensch sieht — Spalten, Tabellen, Bildunterschriften, Seitenleisten — ist nirgendwo semantisch gespeichert. Sie lebt im gerenderten Bild. "Text aus einer PDF extrahieren" ist also schwieriger, als es klingt: Der naive Extraktor liest den Glyphen-Strom in der Reihenfolge, in der die Markierungen geschrieben wurden, was auf einer zweispaltigen Seite die Spalten zeilenweise verschränkt. Was herauskommt, ist grammatisch seltsamer, semantisch gebrochener Text aus echten Wörtern des echten Dokuments — die Sorte Fehler, die in einer Stichprobe schwer zu erkennen ist.

Tabellen sind schlimmer. Die Bedeutung von 1.427 in Zeile 3, Spalte 4 ist der Schnitt aus Q3 2024 und Region Nordost. Für einen naiven Extraktor ist es eine Zahl ohne Beziehung zu beiden Strings, weil die Strings woanders auf der Seite gezeichnet wurden. Die Tabelle löst sich in eine Liste von Zahlen auf, getrennt durch Leerzeichen, und Anfragen nach "Umsatz im Nordosten in Q3" finden nichts — der Chunk, der 1.427 enthält, enthält Nordost nicht nahe genug, um sie im Embedding zu verknüpfen. Formulare haben dasselbe Versagensmuster: Labels und Werte werden als getrennte Strings ausgegeben, und der Index enthält jetzt Werte ohne Feldnamen. OCR auf gescannten Dokumenten ergänzt zeichenweise Fehler genau bei Fachbegriffen und Eigennamen — der Stelle, an der Retrieval am empfindlichsten auf Schreibweise reagiert.

2.2 Layoutbewusstes Parsing: die Signale zurückbringen

Die Antwort ist eine Klasse von Werkzeugen, die das Dokument als zweidimensionales Artefakt behandeln, nicht als Glyphen-Strom. Die Seite wird zum Bild gerendert, ein Layout-Detection-Modell segmentiert sie in Regionen (Absätze, Tabellen, Abbildungen, Kopfzeilen), die Lesereihenfolge wird über Dokument-Layout-Heuristiken rekonstruiert, und Tabellen laufen durch spezialisierte Modelle, die Zeilen- und Spaltenstruktur in HTML, Markdown oder JSON wiederherstellen. Der Output ist kein flacher String mehr — er ist eine strukturierte Repräsentation, die die Hierarchie erhält, Bildunterschriften an ihre Abbildungen bindet und Metadaten freilegt, an denen der nachgelagerte Chunker schneiden kann.

Der Preis ist Rechenzeit — eine bis mehrere Sekunden pro Seite gegenüber Millisekunden bei naiver Extraktion, was bei Millionen-Seiten-Korpora ins Gewicht fällt. Und das Versagensmuster ändert sich: Ein naiver Extraktor, der eine Tabelle zerlegt, liefert zumindest Text. Ein layoutbewusster Parser, der eine Region falsch identifiziert, liefert strukturierten Output, der selbstbewusst falsch sein kann — eine Abbildung, die als Tabelle gelesen wurde, eine Kopfzeile, die als Fließtext erkannt wurde. Das Team muss repräsentative komplexe Seiten stichprobenartig prüfen, bevor es der Pipeline im Großen vertraut.

2.3 Die aktuelle Werkzeuglandschaft

Das Feld hat sich um ein halbes Dutzend Werkzeuge konsolidiert, die man kennen sollte. LlamaParse ist der gehostete Parser von LlamaIndex — stark bei Tabellen und Formularen, die richtige Voreinstellung, wenn du ohnehin im LlamaIndex-Ökosystem arbeitest und Managed Services akzeptabel sind. Docling ist IBMs Open-Source-Parser mit Layout-Bewusstsein und dem TableFormer-Modell für komplexe Tabellenstrukturen, die natürliche Wahl für On-Premises-Deployments, bei denen Daten die eigene Infrastruktur nicht verlassen dürfen. Unstructured optimiert auf Breite — viele Eingabeformate, ein typisiertes Element-Partitionierungsmodell, konsistente Downstream-Schnittstelle — und ist die sicherste erste Wahl für heterogene Enterprise-Korpora. Marker-PDF macht eine Sache sehr gut: PDF zu sauberem Markdown, mit besonderer Aufmerksamkeit für Überschriften, Listen und Code-Blöcke. Firecrawl erledigt das Web-Input-Problem — URL rein, sauberes Markdown raus, Boilerplate entfernt. DeepSeek-OCR, Ende 2025 veröffentlicht, kodiert Seiten in sehr wenige Vision-Tokens für dramatisch geringeren Speicher- und Rechenaufwand und ist der ernsthafte Kandidat, wenn der Durchsatz das Budget dominiert.

Die praktische Bewertung sieht so aus: Nimm fünfzig repräsentative Dokumente, die das Schwierigkeitsspektrum des Korpus abdecken, lass jedes Werkzeug darüberlaufen, vergleiche manuell auf den Dimensionen, die für deinen Korpus zählen — Tabellentreue, mehrspaltige Lesereihenfolge, OCR-Genauigkeit auf Scans, Behandlung von Abbildungen, Durchsatz. Der Gewinner ist selten auf jeder Dimension der beste. Er ist der beste auf den Dimensionen, die für deinen Korpus am meisten zählen, zu einem Preis, den dein Budget tragen kann.

2.4 Die multimodale Alternative

Ein paralleler Pfad verwirft die Rahmung ganz. Wenn ein Vision-Language-Modell eine Seite gut genug lesen kann, um Fragen zu ihr zu beantworten, warum dann überhaupt zu Text konvertieren? Late-Interaction-Multimodal-Retriever wie ColPali und ColQwen2 erweitern die ColBERT-Idee auf Bilder — ein Embedding pro Patch der Seite, gegen Query-Tokens über Max-Similarity-Aggregation bewertet. Der Retriever holt Seiten hoch, deren reiner Textgehalt nicht gepasst hätte, weil die relevante Information in einer Tabelle, einer Abbildung oder einem Layout stand, das die Textextraktion verstümmelt hätte. Das Vision-Language-Modell liest die Seite direkt.

Der Preis ist beträchtlich und verdient eine konkrete Nennung. Ein Standard-Text-Chunk produziert ein Embedding mit ~1.024 Dimensionen — ein paar Kilobyte. Eine ColPali-kodierte Seite produziert rund tausend Patch-Embeddings mit ~128 Dimensionen — ein halbes Megabyte pro Seite. Die Indexgröße für eine Million Seiten wächst von Gigabyte auf Hunderte Gigabyte, das Scoring wird teurer, und die Generierung braucht ein Vision-Language-Modell. Für Korpora, die dicht an Tabellen und Abbildungen sind, ist der Sprung real. Für textlastige Korpora mit knappem Budget ist gut geparstes Text-Retrieval weiter die kosteneffizienteste Voreinstellung. Hybride Konfigurationen — ColPali fürs Retrieval, Text-Konvertierung für die Generierung, oder umgekehrt — werden im kommenden Jahr der Ort sein, an dem produktives multimodales RAG meist landet.

Was Kapitel 2 vorbereitet

Ein sauberer, layoutbewusster Parse ist notwendig für hochwertiges RAG und hinreichend für nichts. Ein geparstes Dokument ist immer noch ein Dokument — es muss in Stücke zerlegt werden, klein genug zum Einbetten und groß genug, um etwas zu bedeuten. Der Chunker, der die strukturellen Hinweise des Parsers ignoriert, wirft weg, was der Parser sich erkämpft hatte. Die zwei Schichten müssen gemeinsam gedacht werden, und Kapitel 3 geht das Chunking-Spektrum und die Frontier-Techniken durch, die es neu geformt haben.

Als Nächstes — Kapitel 3: Fortgeschrittene Chunking-Frameworks. Das Chunking-Spektrum von Fixgröße bis strukturbewusst, der Overlap-Mythos, die Kontextklippe und die Techniken Contextual Retrieval und Late Chunking, die das Kalkül verschoben haben.