PDF in strukturierte Daten umwandeln und Tabellen extrahieren (Dokumenten-Parsing für RAG)

Die Qualität jedes RAG-Assistenten, jeder Unternehmenssuche und jeder Analyse-Pipeline wird durch die Qualität des Dokumenten-Parsings begrenzt: Eine zu Textsuppe plattgedrückte Tabelle oder eine zweispaltige Seite in falscher Reihenfolge führt zu selbstsicher falschen Antworten. Moderne Layoutmodelle und kompakte Bild-Sprach-Modelle wandeln PDFs, Scans und Office-Dateien in strukturiertes Markdown/JSON mit Tabellen, Formeln, Lesereihenfolge und Quellkoordinaten um – lokal auf einer einzelnen GPU oder per API für wenige Dollar pro 1.000 Seiten.

Problem & Nutzen

• Heute: PDF ist ein Druckformat, kein Datenformat. Kopieren und Einfügen oder klassische Textextraktion verliert Struktur (Spalten, Tabellen, Kopf-/Fußzeilen); Scans brauchen OCR; Tabellenkalkulationen und Folien werden plattgedrückt. Unternehmen halten Wissen in Handbüchern, Berichten, Datenblättern, Ausschreibungen und Verträgen vor, die Such- und RAG-Werkzeuge nicht zuverlässig nutzen können.
• KI-Nutzen: Layoutbewusstes Parsing erhält Überschriften, Tabellen und Lesereihenfolge, ermöglicht Quellenangaben bis auf Seite und Begrenzungsrahmen und macht Archive in großem Maßstab maschinenlesbar. Benchmark-Forschung zu RAG ergab, dass OCR-/Parsing-Rauschen die Antwortqualität von RAG messbar senkt und dass keine der getesteten OCR-Lösungen damals gut genug war, um hochwertige Wissensbasen aufzubauen [6] – ein Motiv für die Welle von Dokumenten-VLMs 2025–26.
• Kosten: Parsing ist heute günstig: Mistral OCR 3 nennt 2 $ pro 1.000 Seiten (1 $ im Batch) [3]; das Projekt olmOCR nennt „weniger als 200 USD pro Million Seiten“ bei Selbstbetrieb (Herstellerangabe, ohne Methodik) [5].
• Abgrenzung: Dieser Anwendungsfall ist die allgemeine Parsing-Schicht. Fachspezifische Feldextraktion mit geschäftlicher Validierung liegt in DOC-001 (Rechnungen), DOC-003 (Formulare), DOC-012 (Jahresabschlüsse), DOC-013 (Zeichnungen). Retrieval und Antworten liegen in KNOW-001/002.

Varianten

• RAG-Aufnahme: parsen → entlang von Überschriften/Tabellen in Abschnitte teilen → einbetten → indizieren; die Abschnitte tragen Seiten- und Rahmen-Metadaten für Quellenangaben (KNOW-002).
• Tabelle-zu-Daten: Finanz- oder technische Tabellen in CSV/SQL/Dataframes extrahieren, auch über Seiten hinweg; Extraktion von Datenblättern und Stücklisten in der Fertigung.
• Wissenschaftliche und technische Dokumente: Formeln nach LaTeX, Diagramm-zu-Tabelle, Abbildungsunterschriften.
• Archivdigitalisierung: Massenumwandlung gescannter Archive für öffentliche Verwaltung und Bibliotheken (Handschrift: DOC-005).
• Normalisierung mehrerer Formate: eine Pipeline für PDF, DOCX, PPTX, XLSX, HTML, E-Mail.
• Private Nutzung: persönliche Scans (Handbücher, Verträge, Steuerunterlagen) in durchsuchbare Notizen umwandeln.

So funktioniert es

1. ingest (file, email, DMS, SharePoint)
2. triage (born-digital? scan? password? language? page count)
3. layout analysis (regions: text, title, table, figure, formula, header/footer; reading order)
4. recognition (text layer or OCR; table structure; formula
5. LaTeX; chart
6. table; figure caption)
7. assembly (Markdown/HTML/JSON, merge cross-page tables, drop headers/footers)
8. quality gate (confidence, table-sum checks, sample review, fallback to stronger parser)
9. chunking with heading/table-header context + metadata (page, bbox, doc id, ACL)
10. embedding / index / structured store (DOC
11. KNOW-001/002, analytics)

• Drei technische Familien: (1) Pipeline-Parser mit getrennten Layout-, OCR- und Tabellenmodellen (klassisches Docling, MinerU-Pipeline, Layoutdienste von Azure/AWS/Google); (2) End-to-End-Dokumenten-VLMs, die eine ganze Seite als Markdown/DocTags ausgeben (Granite-Docling, PaddleOCR-VL, olmOCR, Mistral OCR, MinerU2.5); (3) allgemeine Spitzen-VLMs, die mit Seitenbildern angesprochen werden – flexibel, aber teurer und in der Lage, Inhalt umzuformulieren oder zu halluzinieren.
• Mensch-in-der-Schleife (Human-in-the-Loop): stichprobenbasierte Prüfung je Dokumentklasse, Prüfwarteschlange für Seiten mit niedriger Konfidenz und numerische Prüfungen extrahierter Tabellen (Zeilen-/Spaltensummen, Einheiten), bevor Daten ins Reporting gelangen.

Datenaufbereitung

Dieser Anwendungsfall ist selbst ein Schritt der Datenaufbereitung, braucht aber aufbereitete Eingaben. Quelldokumente liegen auf Dateiablagen, in DMS-/ERP-Anhängen, Mailarchiven und auf Papier. Typische Lücken: Scans ohne Textebene, gedrehte oder kontrastarme Seiten, passwortgeschützte PDFs, Duplikate und alte Fassungen, gemischte Sprachen sowie komplexe Tabellen oder Formulare. Zugriffsrechte gehen verloren, wenn Dateien in eine Parsing-Warteschlange kopiert werden.

Schritte: (1) Formate und Mengen inventarisieren, siehe PREP-001; (2) restliches Papier mit 300 dpi scannen, siehe PREP-006; (3) Altformate und Mailarchive umwandeln, siehe PREP-007; (4) deduplizieren und nur gültige Fassungen behalten; (5) Quellpfad, Eigentümer, Datum und Berechtigungen als Metadaten übernehmen, siehe PREP-010; (6) eine Stichprobe von 100 Seiten ziehen, mit zwei Engines parsen und Tabellen von Hand gegen ein Referenzset (Gold Set) vergleichen, siehe PREP-018. Werkzeuge: Docling, PaddleOCR oder Mistral OCR, eine Warteschlange wie Celery oder n8n und Paperless-ngx als Ablage. Planen Sie 20-30 % des Aufwands für die Aufbereitung und 30 % für laufende Qualitätsprüfungen der Ausgabe ein.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg C — Docling oder Ähnliches läuft auf einem HW2-Rechner (oder auf der CPU bei digital erzeugten PDFs), hält vertrauliche Dokumente im Haus, und derselbe Parser speist viele weitere Anwendungsfälle (Baukasten-Effekt).
• Großunternehmen: Weg C — hohe Seitenmengen machen API-Kosten je Seite spürbar, und ein gemeinsamer interner Parsing-Dienst vermeidet doppelte Pipelines.
• Entwickler: Weg C — offene Parser sind skriptbar, testbar und versionierbar; Weg-B-APIs nur für Sonderlayouts nutzen.
• Öffentliche Hand: Weg C — Dokumente enthalten oft Bürgerdaten, und Vergaberegeln begünstigen souveränen Betrieb; Weg B auf einer deutschen/EU-Souveränitäts-Cloud ist die Rückfalloption.

Weg A — Kaufen (Standardsoftware)

• Parsing-as-a-Service / Plattformen: LlamaParse (LlamaIndex; agentische OCR-Stufen, 130+ Formate, regionaler Betrieb und EU-Datenschutzseiten dokumentiert) [4], Unstructured-Plattform (partitionieren, extrahieren, anreichern, in Abschnitte teilen, einbetten; 65+ Dateitypen, 35+ Konnektoren) [7], Reducto, Mistral Document AI (FR, EU-Anbieter).
• IDP-Anbieter (EU gekennzeichnet): ABBYY, Hypatos (DE), Klippa (NL), Mindee (FR), Rossum (CZ), DocuWare und d.velop DMS-Suiten (DE) — stark, wo Parsing mit Klassifikation und Workflow gekoppelt ist.
• In RAG-Produkten eingebaut: Microsoft 365 Copilot/Azure AI Search, Google Vertex AI Search, AWS Bedrock Knowledge Bases und in der EU gehostete Enterprise-Search-Produkte bringen eigene Parser mit.
• A wählen, wenn: Parsing kein Differenzierungsmerkmal ist, Dokumente das Unternehmen verlassen dürfen und das Volumen moderat ist.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Layout-/OCR-Dienste: Azure AI Document Intelligence Layoutmodell (Markdown-Ausgabe, Tabellen mit Verbund, Auswahlmarkierungen, Erkennung handschriftähnlicher Schrift, bis zu 2.000 Seiten je PDF/TIFF) in EU-Regionen [2]; Google Document AI Layout Parser (hierarchiebewusst, RAG-taugliche Abschnitte mit übergeordneten Überschriften und Tabellenköpfen; von Gemini erzeugte Abbildungs-/Tabellenbeschreibungen; Online-Limit 15 Seiten, Batch bis 500) [8]; AWS Textract Tabellen/Layout (Zellen, verbundene Zellen, Spaltenköpfe, Tabellentitel/-fußzeilen) in Frankfurt [9].
• Dokumenten-VLM-APIs: Mistral OCR 3 (mistral-ocr-2512, Markdown mit HTML-Tabellen inkl. colspan/rowspan, 2 $/1.000 Seiten; vom Hersteller berichtete Gewinnquote von 74 % gegenüber OCR 2 im eigenen internen Benchmark) [3].
• Multimodale Spitzenmodelle (Claude, Gemini, GPT) mit Seitenbildern und JSON-Schema für Sonderlayouts und für die Interpretation von Diagrammen/Abbildungen; EU-Regionen und Zero-Retention-Bedingungen nutzen.
• Orchestrierung: n8n / Power Automate / Airflow; Originaldatei + geparstes JSON + Seitenbilder für das Prüfprotokoll aufbewahren.
• B wählen, wenn: Sie schnell Qualität brauchen, gemischte Dokumenttypen haben und keine On-Premises-Vorgabe besteht.

Weg C — Selbst betreiben (Open Source)

• Docling (Projekt von IBM Research, MIT): PDF, DOCX, PPTX, XLSX, HTML, Bilder, Audio; verlustfreies DoclingDocument-JSON, Export als Markdown/HTML; lokal/Air-Gap; docling-serve-API, MCP-Server, Integrationen für LangChain/LlamaIndex/Haystack; Granite-Docling-258M (Apache 2.0, Sept. 2025) als kompaktes VLM — Englisch stark, Japanisch/Arabisch/Chinesisch experimentell [1][10].
• PaddleOCR-VL-1.6 (0,9B, Apache 2.0, Mai 2026): 100+ Sprachen, Stempel, seitenübergreifendes Zusammenführen von Tabellen, 96,3 auf OmniDocBench v1.6 (selbst berichtet) [11].
• MinerU (OpenDataLab; eigene Lizenz auf Basis von Apache 2.0 mit Zusatzbedingungen — vor kommerzieller Nutzung prüfen), olmOCR 0.4 (AI2, Apache 2.0; 82,4 auf olmOCR-Bench) [5], Marker (Code Apache 2.0, Modellgewichte unter einer modifizierten OpenRAIL-M-Lizenz, die die kommerzielle Nutzung oberhalb einer Umsatzschwelle einschränkt) [12], die Open-Source-Bibliothek Unstructured (Apache 2.0) [13].
• Bereitstellung: vLLM / SGLang / llama.cpp; PDF-Rendering mit pdfium; Warteschlange (Celery/Temporal) für Stapel.
• Hardware: HW2 (eine GPU mit 24–32 GB) bewältigt Dokumenten-VLMs unter 1B mit grob mehreren Seiten pro Sekunde (der veröffentlichte Durchsatz von Marker liegt je nach Modus bei 2,9–7,4 Seiten/s je GPU, andere Systeme niedriger [12]); nur CPU (HW1) funktioniert für digital erzeugte PDFs mit Pipeline-Parsern. HW3 für VLMs ab 7B.
• C wählen, wenn: vertrauliche Dokumente (Gesundheit, Recht, Personal, rüstungsnah), sehr hohe Mengen oder Souveränitätsanforderungen vorliegen. Betriebsaufwand: mäßig (GPU-Server, Modell-Updates, Regressionstests).

Weg D — Eigenes Training

Selten nötig. Lohnt sich für ungewöhnliche Schriften, Stempel/Siegel, fachspezifische Tabellenformate (z. B. alte technische Listen, historische Hauptbücher) oder um die Kosten bei sehr hohen Mengen zu senken. Beginnen Sie mit dem Feintuning eines kleinen Dokumenten-VLM (PaddleOCR-VL, Granite-Docling, Klasse Qwen-VL) auf einigen tausend Paaren aus Seite und Markdown, vorbefüllt mit Ausgaben eines starken Parsers und von Menschen korrigiert. Evaluieren Sie an einem zurückgehaltenen Set eigener Dokumente; verlassen Sie sich nicht allein auf öffentliche Bestenlisten.

Stand der Technik (2026)

• End-to-End-Dokumenten-VLMs dominieren die öffentlichen Bestenlisten: Auf OmniDocBench (CVPR 2025; 1.651 Seiten, 10 Dokumenttypen, 5 Layouttypen, 5 Sprachen; Bestenliste v1.6) liegen die besten End-to-End-Werte in den mittleren 90ern (z. B. PaddleOCR-VL-1.6 96,34, MinerU2.5-Pro 95,75 laut Projektseite) [14]. Modelle unter 1B messen sich inzwischen mit weit größeren; die Datensatzlizenz erlaubt nur Forschung.
• olmOCR-Bench (1.400 PDFs, 7.000+ Testfälle) zeigt eine Bewertung im Stil von Unit-Tests: olmOCR 0.4 82,4, PaddleOCR-VL 80,0, Chandra 83,1; Pipeline-Werkzeuge wie Docling (50,3 im von Marker berichteten Lauf) und die MinerU-Pipeline (72,7) liegen dort hinter den VLMs – die Zahlen hängen von Benchmark und Version ab, testen Sie also selbst [5][12].
• Trends 2025–26: kompakte VLMs (0,3–1B) mit strukturierten Tags (DocTags, OTSL-Tabellen), seitenübergreifendes Zusammenführen von Tabellen, Diagramm-zu-Tabelle, Formel-zu-LaTeX, Parser-Stufen („schnell“ per Textebene gegenüber „agentisch“ per VLM), hybride Konzepte, die die OCR-Verankerung behalten, um Halluzinationen zu begrenzen (die erklärte Begründung von Google) [8], und Standardausgaben (Markdown + JSON mit Begrenzungsrahmen), die MCP-basierte Agenten speisen.
• Grenzen & Fehlerbilder: mehrseitige und verschachtelte Tabellen, verbundene Kopfzeilen, gedrehte oder schiefe Scans, Kleingedrucktes und Stempel, Handschrift, gemischte Sprachen, gescannte Formulare mit Kontrollkästchen; VLM-basierte Parser können unbemerkt Zeilen auslassen oder erfinden; Lesereihenfolge bei komplexen mehrspaltigen Layouts; Bestenlisten sind überwiegend englisch/chinesisch; Herstellerzahlen sind selbst berichtet. Gegenmaßnahmen: numerische Prüfungen, Quellenangaben per Begrenzungsrahmen, Vergleich zweier Parser bei kritischen Dokumenten und Regressionssets.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: ocr-docparse + vlm bedienen DOC-001 (Rechnungen), DOC-003 (Formulare), DOC-005 (Handschrift), DOC-008 (Posteingang), DOC-012 (Aufbereitung von Jahresabschlüssen), DOC-013 (Zeichnungen); ein GPU-Parsing-Dienst (HW2/HW3) kann alle unterstützen.
• Nachgelagert: KNOW-001/002/004 (Suche, RAG, Assistenten für technische Dokumentation) verarbeiten die Abschnitte; Text-Embeddings, Reranker und Vektordatenbank werden mit ihnen geteilt.
• Vorgelagert/angrenzend: DOC-018 (vor dem Indizieren oder vor dem Senden an externe APIs anonymisieren), DOC-008 (zuerst klassifizieren und weiterleiten).
• Gemeinsame Bausteine: Dokumentenablage mit Seitenbildern und Begrenzungsrahmen, Parse-Cache mit Dateihash als Schlüssel, Weitergabe der Zugriffsrechte (ACL) an Abschnitte, Evaluierungsset aus 100–300 eigenen Seiten, Workflow-Engine (n8n).

Aufwand, Kosten & Kennzahlen

• Weg A: Tage–Wochen; Preise je Seite oder je Credit im SaaS-Modell.
• Weg B: 2–6 Wochen für eine Aufnahme-Pipeline mit Caching, Wiederholungen, Qualitätsprüfungen; API-Kosten grob 1–15 $ pro 1.000 Seiten je nach Dienst und Funktionen (aktuelle Preislisten prüfen).
• Weg C: 1–3 Monate inkl. Bereitstellung, Evaluierung und Monitoring; ein GPU-Server, geringe Grenzkosten.
• Weg D: 2–4 Monate mit Annotationsaufwand.
• Kennzahlen: Genauigkeit auf Tabellenzellenebene (TEDS-artig oder eigenes Zellen-F1), Lesereihenfolgefehler je Seite, Textabstand (Edit-Distanz) auf Referenzseiten, Anteil der zur Prüfung geleiteten Seiten, Trefferquote beim Retrieval / Antwortkorrektheit des nachgelagerten RAG vor und nach dem Parserwechsel, Kosten und Latenz je Seite, Durchsatz in Seiten/Stunde.

Menschen & Veränderung

Einbinden: die Geschäftsführung für Entscheidung und Budget, die IT für die GPU-Maschine und die Warteschlange, die IT-Sicherheit für den Datenfluss und die Datenverantwortlichen jeder Quelle (Finanzen, Personal, Konstruktion), weil sie wissen, welche Dokumente sensibel sind. Die Abteilungsleitung des ersten nutzenden Anwendungsfalls (z. B. eines Wissensassistenten) fungiert als Prozessverantwortliche.

Betriebsrat: In der Regel keine Mitbestimmung nach §87 Abs. 1 Nr. 6 BetrVG, da das Parsen von Dokumenten kein Verhalten überwacht; nach §90 Abs. 1 Nr. 3 unterrichten, wenn es Teil einer breiteren KI-Einführung ist. Datenschutz: Personalakten, Verträge und Kundenpost enthalten personenbezogene Daten; den/die Datenschutzbeauftragte(n) einbinden, Zweck und Rechtsgrundlage prüfen und mit jedem API-Anbieter einen AVV schließen, siehe GUIDE-005. Eine DSFA durchführen, wenn Personal- oder Gesundheitsunterlagen betroffen sind.

KI-Kompetenz: die wenigen Bedienenden zu Fehlerarten schulen (verbundene Zellen, Lesereihenfolge). Pilot: eine Dokumentklasse, zwei Prüfende, 5 % der Ausgabe stichprobenartig kontrollieren. Bedenken: „Wer sieht meine Dokumente?“ – Quellberechtigungen erhalten und Zugriffe protokollieren. Menschen prüfen Tabellen, aus denen Zahlen entstehen. Siehe GUIDE-003 und GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko für die Parsing-Schicht selbst (keine Anwendung nach Anhang III); die KI-Kompetenz (Art. 4) gilt. Die Risikoklasse wird von der nachgelagerten Nutzung geerbt: Das Parsen von Lebensläufen, Kreditakten oder Krankenakten für Entscheidungen zieht das System in Pflichten nach Anhang III (die Anwendbarkeit für Hochrisiko wurde mit dem Omnibus 2026 auf den 2. Dez. 2027 verschoben) [15]. Erzeugte Zusammenfassungen/Abbildungsbeschreibungen, die öffentlich veröffentlicht werden, können eine Kennzeichnung nach Art. 50 erfordern (Transparenzregeln gelten ab Aug. 2026) [15].
• DSGVO: Dokumente enthalten oft personenbezogene Daten (Verträge, Personal, Gesundheit); das Senden an Cloud-APIs erfordert einen AVV, eine EU-Region, Bedingungen ohne Training/mit Zero-Retention und bei Anbietern außerhalb der EU einen Übermittlungsmechanismus. Selbstbetrieb (Weg C) beseitigt die Übermittlungsfrage. Anonymisierung erwägen (DOC-018).
• Sicherheit: PDFs können versteckten Text oder Prompt Injections enthalten, die nachgelagerte LLMs erreichen; geparsten Inhalt als nicht vertrauenswürdige Eingabe behandeln, Dateien prüfen, Rendering in einer Sandbox ausführen.
• Aufbewahrungsrecht: Ist das Original ein steuerlich relevanter Beleg (GoBD), das Original unverändert aufbewahren; die geparste Kopie ist ein Derivat.
• Lizenzen: Lizenzen der Modellgewichte prüfen (Marker-Gewichte, MinerU-Lizenz, nur für Forschung zulässige Bedingungen des OmniDocBench-Datensatzes) [12][14].
• Qualitätsrisiko: Stille Fehler in Tabellen pflanzen sich in Berichte fort; Quellenangaben auf Seite/Begrenzungsrahmen und Validierungsprüfungen beibehalten.

Erste Schritte

1. Ein Referenzset aufbauen: 100–200 Seiten eigener Dokumente (schwierigste Tabellen, Scans, Mehrspaltiges) mit erwartetem Markdown/CSV für wichtige Tabellen.
2. 3–4 Kandidaten (z. B. Docling, PaddleOCR-VL, Mistral OCR, Layout von Azure/Google) laufen lassen und Zellgenauigkeit, Lesereihenfolge, Kosten und Latenz vergleichen; auf die Fehlschläge schauen, nicht nur auf Durchschnitte.
3. Einen primären Parser plus einen Rückfall für schwierige Seiten wählen; numerische/strukturelle Qualitätsprüfungen ergänzen.
4. Entlang der Dokumentstruktur in Abschnitte teilen (Überschriften, ganze Tabellen mit Kopfkontext) und Seiten-/Rahmen-Metadaten speichern; an den RAG-/Such-Stack anbinden (KNOW-002).
5. Nach Dateihash cachen, das Referenzset bei jedem Parser-/Modell-Upgrade erneut laufen lassen, Kennzahlen monatlich verfolgen.

Quellen

1. Docling project (IBM Research, MIT) — https://github.com/docling-project/docling
2. Microsoft — Azure AI Document Intelligence layout model — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout
3. Mistral AI — Mistral OCR 3 — https://mistral.ai/news/mistral-ocr-3
4. LlamaIndex — LlamaParse documentation — https://developers.llamaindex.ai/python/framework/llama_cloud/llama_parse/
5. AI2 — olmOCR repository (v0.4.0, olmOCR-Bench) — https://github.com/allenai/olmocr
6. Zhang et al. — OCR Hinders RAG: Evaluating the Cascading Impact of OCR on RAG (OHRBench) — https://arxiv.org/abs/2412.02592
7. Unstructured — platform documentation — https://docs.unstructured.io/welcome
8. Google Cloud — Document AI Layout Parser and chunking — https://docs.cloud.google.com/document-ai/docs/layout-parse-chunk
9. AWS — Amazon Textract tables — https://docs.aws.amazon.com/textract/latest/dg/how-it-works-tables.html
10. IBM — Granite-Docling-258M model card — https://huggingface.co/ibm-granite/granite-docling-258M
11. PaddleOCR repository (PaddleOCR-VL-1.6) — https://github.com/PaddlePaddle/PaddleOCR
12. datalab-to — Marker (licence, olmocr-bench comparison) — https://github.com/datalab-to/marker
13. Unstructured open-source library — https://github.com/Unstructured-IO/unstructured
14. OmniDocBench (CVPR 2025) — https://github.com/opendatalab/OmniDocBench
15. European Commission — AI Act regulatory framework and application dates — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai