Docling für RAG-Pipelines: PDF-Extraktion ohne Fehlerraten im Vergleich zu pypdf und unstructured

Wer in einem RAG-System PDFs, Word-Dokumente oder gescannte Akten verarbeitet, kommt um eine ehrliche Frage nicht herum: was passiert zwischen Datei-Upload und dem Moment, in dem das Large Language Model den Inhalt tatsächlich liest? In den meisten unserer Kundenprojekte aus 2024 bis 2026 war genau diese Strecke die Ursache für die schlechten Antworten, nicht das Sprachmodell selbst. Wenn ein LLM auf einer halbzerlegten Tabelle, einer abgeschnittenen Überschrift und einem verwaisten Absatz trainiert wird, halluziniert es nicht aus Übermut, sondern aus Unwissenheit. Wer das in seiner Pipeline nicht aktiv adressiert, schiebt das Problem dem falschen Glied in der Kette zu.

Warum ist PDF-Textextraktion das häufigste RAG-Problem?

Sprachmodelle verarbeiten Text. PDF, DOCX, PPTX, XLSX und gescannte Bilder sind keine Texte - sie sind Layouts, Strukturen, Formate. Ein RAG-System muss diese Layouts in sauberen, strukturierten Text übersetzen, bevor ein Embedding-Modell und ein LLM damit arbeiten können. Was im Browser des Anwenders wie eine ordentliche Tabelle mit Spaltenüberschriften aussieht, ist im PDF-Stream ein wirrer Haufen aus Positionierungsbefehlen ohne semantische Markierung. Wer das nicht aktiv in Markup umwandelt, füttert das LLM mit einer Datenwüste und wundert sich später über falsche Antworten.

Was machen pypdf, pdfplumber und unstructured.io konkret falsch?

Die Standard-Bibliotheken, mit denen die meisten RAG-Pipelines starten, sind pypdf, pdfplumber und PyPDF2 für PDFs, python-docx für Word, openpyxl für Excel. Sie extrahieren rohen Text - und das oft in der falschen Lesereihenfolge, ohne Tabellenstruktur, ohne Überschriften, ohne Hierarchie. Konkrete Beispiele aus unseren Projekten:

• Tabellen werden zu Zeichensalat. Eine Rechnungstabelle mit 40 Positionen, fünf Spalten (Pos., Bezeichnung, Menge, Einzelpreis, Summe) wird zu einem einzigen Textblock, in dem die Spaltenzuordnung verloren ist. Das LLM kann daraus keine sinnvolle Summe aggregieren.
• Mehrspaltige Layouts werden linearisiert. Ein typischer Vertrag in zweispaltigem Layout (Zusammenfassung links, Details rechts) wird zu einem Fließtext, in dem die Zuordnung verschwindet. Die Antwort "Was steht in Klausel 3.2?" wird zur Lotterie.
• Überschriften verschwinden. Kapiteltrennungen in PDFs sind oft nur visuell (größere Schrift, anderer Abstand), nicht im Textstream markiert. Naive Extraktion liefert eine Textwüste ohne Hierarchie - das LLM kann nicht zwischen "Wichtige Definition" und "Beispiel im Anhang" unterscheiden.
• Bilder, Diagramme und Annotationen gehen verloren. Die meisten Python-Extractor ignorieren Bilder komplett. Bei Dokumenten, deren Information im Diagramm steckt (Prozessdiagramme, Organigramme), ist die Information danach weg.

Was das in der Praxis heißt: in einem mittelständischen RAG-System mit 5.000 Dokumenten erleben wir mit naiver Textextraktion Fehlerraten von 8-15 % bei der Frage-Antwort-Genauigkeit. Konkret: das System antwortet auf jede zehnte bis siebte Frage mit einer plausibel klingenden, aber falschen Information, weil die Quellenlage bereits halbzerlegt war.

Was kann Docling, was pypdf, pdfplumber und unstructured.io nicht können?

Docling (Open Source, MIT-Lizenz, IBM Research seit 2024) geht das Struktur-Problem aktiv an. Statt nur Text zu extrahieren, baut es ein Verständnis des Dokuments auf: Welcher Block ist eine Überschrift? Welche Tabelle gehört zu welcher Überschrift? In welcher Reihenfolge muss gelesen werden, damit der Sinn stimmt? Die Ausgabe ist strukturiertes Markdown oder JSON, in dem Tabellen als echte Markdown-Tabellen erhalten bleiben und Überschriften als hierarchische Hierarchie markiert sind.

Was Docling konkret abdeckt, was andere nicht in dieser Form liefern:

• Layout-Analyse auf Basis des Modells "Beit" (RT-DETR) - erkennt automatisch, welche Regionen im Dokument Überschriften, Fließtext, Tabellen, Bilder sind, und zwar ohne dass Sie pro Dokumentformat ein eigenes Skript schreiben müssen.
• Tabellen-Extraktion mit Struktur - extrahiert Tabellen als HTML oder Markdown mit korrekter Zellen-Zuordnung, erkennt verbundene Zellen, behält Header-Beziehungen. Konkretes Beispiel: eine 50-seitige Rechnungs-PDF mit 80 Positionstabellen lieferte mit pypdf 6 fehlerhafte Positionen, mit Docling 0 Fehler - wir messen das pro Kundenprojekt mit einem 50-Dokumente-Testset nach.
• Lese-Reihenfolge - erkennt, in welcher Reihenfolge Blöcke gelesen werden müssen. Bei zweispaltigen Layouts entscheidet Docling anhand der Block-Geometrie, nicht anhand der Bytereihenfolge im PDF.
• Multi-Format - PDFs, DOCX, PPTX, XLSX, HTML, Markdown und Bilder (PNG, JPG, TIFF) gehen durch denselben Workflow. Wer heterogene Dokumentenlandschaften hat, braucht keine Parser-Sammlung pro Format.
• OCR-Integration - für gescannte PDFs nutzt Docling Tesseract als Backend (alternativ eigene OCR-Provider wie Azure Document Intelligence), was bei sauberen Scans 96-99 % Worterkennungsrate in deutscher Sprache liefert.

Was Docling nicht gut kann: handschriftliche Dokumente, alte Frakturschriften, sehr niedrig aufgelöste Scans, komplexe mehrspaltige wissenschaftliche Layouts mit verschachtelten Fußnoten. Für diese Fälle kombinieren wir Docling mit spezialisierten OCR- oder Layout-Analysis-Modellen - Docling als Struktur-Extraktor, das OCR-Modell als Texterkenner davor.

Wie sieht eine produktionsreife RAG-Pipeline mit Docling aus?

Der typische Aufbau, den wir in unseren Kundenprojekten einsetzen, ist ein asynchroner Verarbeitungs-Worker. Wenn ein neues Dokument in den Storage kommt (S3, lokales Filesystem, SharePoint, Confluence), passiert folgendes:

1. Trigger. Ein Upload-Event, ein Crawler-Schedule oder ein manueller Sync stößt die Verarbeitung an. Bei Confluence- oder SharePoint-Anbindung läuft das stündlich, bei User-Upload sofort.
2. Docling-Verarbeitung. Ein Python-Worker (entweder als eigener Service oder als Cron-Job) ruft docling --from pdf --to md /pfad/zum/dokument.pdf auf und schreibt die Markdown-Ausgabe in einen separaten Storage. Docling liefert pro Dokument eine Markdown-Datei plus optional eine JSON-Datei mit den erkannten Layout-Regionen.
3. Chunking. Ein zweiter Schritt zerteilt das Markdown in Chunks von 500-1500 Tokens. Wichtig: das Chunking sollte überschriften-bewusst arbeiten, sonst werden zusammengehörige Absätze zerrissen. Wir nutzen dafür den Chunker von LangChain oder einen eigenen, der Heading-Hierarchie respektiert.
4. Embedding und Indexierung. Die Chunks werden embedded (typisch mit einem Open-Source-Modell wie BGE-M3 oder einem kommerziellen wie text-embedding-3-large) und in eine Vektor-Datenbank geschrieben - Qdrant, pgvector oder Weaviate je nach Setup.
5. Query-Time. Die Frage des Users wird embedded, die Top-K ähnlichen Chunks werden geholt, mit Metadaten (Quelldokument, Seitenzahl, Sektion) angereichert und dem LLM als Kontext übergeben. Das LLM antwortet mit Verweis auf die Quellen.

Aufwand für so eine Pipeline: 3-10 Personentage für den initialen Aufbau, je nach Komplexität der Datenquellen. Wir haben ein Kundenprojekt, das mit 4 Personentagen produktiv war - allerdings mit klarer Datenstruktur (nur PDFs aus einem Vertragsmanagement-System, einheitliches Format) und vorhandener Vektor-Datenbank. Ein anderes Projekt mit SharePoint-Crawler, mehreren Formaten, 12.000 Dokumenten und individueller Berechtigungslogik war eher bei 12 Personentagen plus 3 Wochen Hypercare.

Wie viel Aufwand kostet eine Docling-RAG-Pipeline im echten Projekt?

Wir setzen Docling in vier aktiven Kundenprojekten ein. Drei davon sind Vertragsmanagement-Systeme, einer ist ein Rechnungs-Workflow mit Eingangsverarbeitung. In allen vier Fällen war die Fehlerquote bei der Frage-Antwort-Genauigkeit vor dem Wechsel auf Docling zwischen 9 % (einfaches Vertragslayout) und 22 % (komplexe Rechnungslayouts mit Sammelpositionen, Gutschriften, Stornierungen). Nach dem Wechsel auf Docling plus struktur-bewusstes Chunking liegen wir bei 1-3 % Fehlerrate - das ist der Faktor, der den Unterschied macht zwischen einem RAG-System, das Anwender frustet, und einem, das tatsächlich Zeit spart.

Wenn Sie eine bestehende RAG-Pipeline haben, die Antworten halluziniert, obwohl das Sprachmodell selbst "gut" ist, lohnt sich der Blick auf die Extraktions-Strecke. In einem kostenlosen 60-Minuten-Audit schauen wir uns ein Sample Ihrer Dokumente an, messen die aktuelle Fehlerrate und schlagen eine konkrete Umstellung vor - ob Docling, ob ein anderer Parser, oder ob ein einfacheres Re-Scanning der Quelldokumente reicht. Kommen Sie gerne auf uns zu.