PDF-Parsing für RAG: Layout-Pipelines, OCR und Vision-Modelle im Vergleich

Wer ein schwaches RAG-System debuggt, fängt meist beim Embedding-Modell, der Chunk-Größe oder dem Prompt an. Bei PDFs liegt das Problem oft davor: Der Parser hat ein zweispaltiges Datenblatt in verschachtelte Halbsätze verwandelt, eine Preistabelle zu einer Zahlenkette plattgedrückt und die Fußzeile in jeden Chunk kopiert. Kein Reranker repariert Text, der schon vor dem Embedding falsch war.

Dieser Artikel vergleicht die drei Familien von PDF-Parsern im Jahr 2026, Textlayer-Extraktion, Layout-Pipelines wie Docling, Marker und MinerU sowie Vision-Modelle für ganze Seiten, anhand der Zahlen, die die Projekte selbst veröffentlichen. Danach geht es um Tabellen, strukturbewusstes Chunking, den direkten Versand an ein Modell, Lizenzen und einen kleinen Test an eigenen Dokumenten, bevor man sich festlegt.

Warum entscheidet das PDF-Parsing über die RAG-Qualität?

Ein PDF speichert Glyphen an Koordinaten, keine Absätze. Alles, was eine RAG-Pipeline braucht, Lesereihenfolge, welcher Text eine Überschrift ist, wo eine Tabellenzelle beginnt, muss rekonstruiert werden. Jeder Fehler landet direkt im Index:

• Lesereihenfolge: Mehrspaltige Layouts, Randspalten und Bildunterschriften werden zeilenweise vermischt, ein Chunk enthält dann zwei unzusammenhängende Sätze.
• Tabellen: Ohne Strukturrekonstruktion wird eine Tabelle zu einer Folge von Werten ohne Spaltennamen, und das Modell rät, welche Zahl zu welchem Produkt gehört.
• Wiederkehrende Elemente: Kopfzeilen, Fußzeilen und Seitenzahlen stehen auf jeder Seite und ziehen irrelevante Chunks in die Top-Ergebnisse.
• Scans und kaputte Textlayer: Gescannte Seiten haben gar keinen Text, und manche exportierte PDFs tragen einen fehlerhaften Textlayer, der am Bildschirm gut aussieht, aber als Zeichensalat extrahiert wird.

Deshalb bewerte ich Retrieval und Generierung getrennt, wie in RAG evaluieren beschrieben. Scheitert das Retrieval bei PDFs, zuerst den geparsten Text der betroffenen Seite öffnen, bevor man irgendetwas anderes anfasst.

Welche drei Familien von PDF-Parsern gibt es?

Parser unterscheiden sich vor allem darin, was sie lesen: den eingebetteten Textlayer, ein gerendertes Bild der Seite oder beides.

Die Grenzen verschwimmen. Docling (MIT-Lizenz) lässt standardmäßig Layout- und Tabellenstrukturmodelle über den Textlayer laufen, kann aber auf eine VLM-Pipeline mit dem 258M-Parameter-Modell GraniteDocling umschalten. Marker leitet Layout, OCR und Tabellenerkennung inzwischen über sein lokal betriebenes surya-VLM, liest digitalen Text aber weiterhin direkt aus dem PDF. MinerU bietet ein Pipeline- und ein VLM-Backend. In der Praxis lautet die Frage weniger welches Tool als welcher Modus für welche Seiten.

Was sagen die Benchmarks wirklich?

Der derzeit nützlichste gemeinsame Maßstab ist olmOCR-bench vom Allen Institute for AI, eingeführt mit dem olmOCR-Paper: rund 1.400 PDFs mit Tausenden Pass/Fail-Unit-Tests für Formeln, Tabellen, Lesereihenfolge, Kopf- und Fußzeilen und alte Scans. Unit-Tests passen besser zu RAG als Editierdistanz, weil sie Fakten prüfen, auf die es ankommt, etwa ob eine Tabellenzelle neben der richtigen Kopfzeile steht.

Die Tabelle ist mit Vorsicht zu lesen: Datalab entwickelt Marker und hat alle drei auf eigener Hardware gemessen, Docling lief in seiner Standard-Pipeline, und MinerUs VLM-Backend, das laut Datalab selbst besser abschneidet, fehlt. Datalab führt sein eigenes Dokument-VLM Chandra auf demselben Benchmark mit 85,8. Zwei Dinge gelten trotzdem. Bei digitalen PDFs liegen die beiden führenden Pipelines fast gleichauf, also können Geschwindigkeit und Lizenz entscheiden. Und Vision-Modelle für ganze Seiten gewinnen bei schwierigen Seiten, deshalb lohnt sich das Routing pro Seite.

Wie extrahiert und chunkt man Tabellen?

Tabellen tragen in technischen und kaufmännischen Dokumenten genau die Fakten, nach denen Nutzer am häufigsten fragen: Maße, Toleranzen, Preise, Lieferzeiten. Man sollte sie als eigene Objekte behandeln:

1. Struktur im Output behalten. Tabellen als HTML- oder Markdown-Tabellen exportieren, nicht als Text. Marker gibt Tabellen als HTML-Blöcke aus, Docling exportiert Markdown, HTML und verlustfreies JSON.
2. Eine Tabelle, ein Chunk, zusammen mit Beschriftung und nächster Überschrift, damit der Chunk sagt, worum es geht.
3. Lange Tabellen nach Zeilen teilen und die Kopfzeile in jedem Teil wiederholen; eine Zeile ohne Spaltennamen ist Rauschen.
4. Seitenübergreifende Tabellen zusammenführen. Das ist eine bekannte Schwachstelle; Markers optionaler Modus --use_llm nutzt ein LLM, um Tabellen über Seiten hinweg zusammenzuführen und zu formatieren, gegen Aufpreis.
5. Gibt es die Daten anderswo, diese nutzen. Eine Preisliste aus dem ERP gehört in eine Datenbank, die der Agent abfragen kann, nicht in ein PDF, das man zurückparst.

Wie chunkt man geparste Dokumente?

Hat der Parser die Überschriften rekonstruiert, entlang dieser chunken, statt alle N Tokens zu schneiden. Ein Abschnitt unter einer Überschrift ist meist ein Thema, und der Überschriftenpfad (Dokumenttitel, Kapitel, Abschnitt) ergibt ein kurzes, günstiges Kontextpräfix für jeden Chunk. Chunk-Größen, hybride Suche und Reranking behandle ich in Eine produktive RAG-Pipeline, Schritt für Schritt.

Anthropics Contextual Retrieval geht einen Schritt weiter: Ein LLM schreibt vor dem Embedding für jeden Chunk einen kurzen Kontextsatz aus dem ganzen Dokument. Mit Prompt-Caching schätzte Anthropic die einmaligen Kosten auf 1,02 Dollar pro Million Dokument-Tokens. Am besten wirkt es auf sauberem Parsing, denn der Kontextsatz ist nur so gut wie der Dokumenttext, den das Modell liest.

# Illustrative: chunk a parsed Markdown document by headings, keep tables whole
import re

def chunks(md: str, doc_title: str, max_chars: int = 3000):
    path, buf = [doc_title], []
    for block in re.split(r"\n(?=#{1,3} )|\n\n", md):
        if m := re.match(r"(#{1,3}) (.+)", block):
            yield from flush(path, buf); buf = []
            level = len(m.group(1)); path = path[:level] + [m.group(2)]
        elif block.lstrip().startswith(("|", "<table")):
            yield from flush(path, buf); buf = []
            yield {"context": " > ".join(path), "text": block, "kind": "table"}
        else:
            buf.append(block)
            if sum(map(len, buf)) > max_chars:
                yield from flush(path, buf); buf = []
    yield from flush(path, buf)

def flush(path, buf):
    if buf:
        yield {"context": " > ".join(path), "text": "\n\n".join(buf), "kind": "text"}

Wann schickt man das PDF direkt an das Modell?

Frontier-Modelle lesen PDFs nativ. Claudes PDF-Unterstützung akzeptiert Anfragen bis 32 MB und 600 Seiten (100 Seiten, wenn das Kontextfenster der Anfrage unter einer Million Tokens liegt) und verarbeitet jede Seite als Bild. Lädt ein Nutzer einen Vertrag in einen Chat, ist das die einfachste und oft beste Option.

Für einen Korpus kippt die Rechnung. Jede Anfrage würde das erneute Lesen der Seiten bezahlen, man kann keine Seiten ranken, die man nicht embedded hat, und Zitate brauchen stabile Seiten- und Chunk-IDs. Die olmOCR-Autoren beziffern die Konvertierung von einer Million Seiten mit GPT-4o auf über 6.240 Dollar, gegenüber 176 Dollar mit ihrem offenen 7B-Modell auf eigenen GPUs. Einmal parsen, indexieren und dem Modell nur die gefundenen Chunks schicken.

Welche Lizenz- und Datenschutzfragen zählen?

Vor dem Go-live eines Kundenprojekts die Lizenz der Gewichte prüfen, nicht nur die des Codes; besonders die Marker-Bedingungen hängen von der Unternehmensgröße ab. Alle drei laufen lokal, was zählt, wenn die Dokumente personenbezogene Daten enthalten, etwa Rechnungen, Personalakten oder Support-Tickets. Nutzt man doch einen gehosteten Parser oder eine LLM-API, gelten die Fragen aus DSGVO und LLM-Datenresidenz unverändert.

Wie testet man einen Parser an eigenen Dokumenten?

Die Idee von olmOCR-bench übernehmen und Unit-Tests für eigene Seiten schreiben. 30 bis 50 Seiten wählen, die den Korpus abbilden, auch die hässlichen: einen gescannten Lieferschein, ein zweispaltiges Datenblatt, eine seitenübergreifende Tabelle. Für jede Seite ein paar Prüfungen schreiben, die ein korrektes Ergebnis bestehen muss, und jeden Kandidaten dagegen laufen lassen.

# Illustrative page checks, scored per parser
CHECKS = [
  {"page": "datasheet-p2", "present": "Operating temperature -20 to 60 °C"},
  {"page": "datasheet-p2", "order": ["Dimensions", "Weight", "Material"]},
  {"page": "pricelist-p1", "cell": {"row": "ART-10001", "col": "Unit price", "value": "12.40"}},
  {"page": "delivery-note-scan", "present": "Lieferschein Nr. 48211"},
  {"page": "manual-p7", "absent": "Page 7 of 112"},   # footer must not leak into text
]

Jeden Parser nach Bestehensquote, Seiten pro Sekunde auf der eigenen Hardware und Kosten bewerten. Dann die Retrieval-Evaluation auf dem Output des Gewinners laufen lassen, denn der Parser, der die Prüfungen gewinnt, gewinnt meist, aber nicht immer, auch das Retrieval.

Was ändert sich bei B2B-Datenblättern und Handbüchern?

Industriedokumente stecken voller Artikelnummern, Einheiten und Tabellen, genau dort tun Textlayer-Fehler weh: ein verlorener Bindestrich in ART-10001, ein Gradzeichen als Fragezeichen, eine fehlende Einheitenspalte. Exakte Kennungen mit einem Keyword-Index neben den Vektoren auffindbar halten, wie in semantischer Produktsuche für B2B-Shops beschrieben, und Prüfungen für Artikelnummern in den Parser-Testsatz aufnehmen.

Viele Datenblätter existieren auch als strukturierte Daten in einem PIM. Wo das so ist, die PIM-Attribute indexieren und das PDF als Quelle verlinken, statt das PDF zurückzuentwickeln, das das PIM erzeugt hat. Hat man nur PDFs, ist eine Layout-Pipeline mit selektiver OCR der vernünftige Standard, ein Vision-Modell für ganze Seiten bleibt für die Seiten reserviert, an denen sie scheitert.

Quellen

1. Docling: README, features and license (GitHub)
2. Auer et al.: Docling: An Efficient Open-Source Toolkit for AI-driven Document Conversion (2025)
3. Datalab: Marker README, olmOCR-bench results and license (GitHub)
4. OpenDataLab: MinerU README and license (GitHub)
5. Poznanski et al.: olmOCR: Unlocking Trillions of Tokens in PDFs with Vision Language Models (2025)
6. Claude Platform Docs: PDF support
7. Anthropic: Introducing Contextual Retrieval (Sep 2024)