PDF-Parser für RAG: wo offene Werkzeuge reichen und wo nicht

TL;DR

Bei digital erzeugten PDF mit einfachem Layout liefern offene Parser Ergebnisse auf Augenhöhe mit dem Azure-Dienst — bei einem Bruchteil der Kosten. Bei gescannten Seiten, mehrspaltigen Layouts und verbundenen Tabellenzellen kippt das Bild deutlich. Die Frage ist nicht welcher Parser, sondern wie viel Prozent Ihres Bestands zur zweiten Gruppe gehört.

Warum das über die RAG-Qualität entscheidet

Ein Beispiel, das die Sache greifbar macht. In einer Wartungsanleitung steht eine Tabelle:

Ein guter Parser gibt daraus eine Struktur zurück, in der klar ist, dass 85 Nm zur Lagerschraube gehört. Ein schlechter gibt zurück:

Bauteil Intervall Drehmoment Lagerschraube M12 500 h 85 Nm Dichtring 2000 h

Aus diesem Text kann kein Modell zuverlässig ableiten, welches Drehmoment für welches Bauteil gilt. Die Antwort wird plausibel klingen und falsch sein — der schlechteste aller Zustände.

Wir haben deshalb die Regel, bei jeder RAG-Einführung zuerst zwanzig repräsentative Dokumente durch die Kandidaten zu schicken und die Ergebnisse anzuschauen. Nicht Benchmarks lesen. Anschauen.

Die Kandidaten

Azure Document Intelligence ist der verwaltete Dienst mit vortrainierten Modellen für Layout, Rechnungen, Belege und Ausweise, dazu die Möglichkeit eigener Modelle. Das Layout-Modell gibt Tabellen mit Zeilen- und Spaltenzugehörigkeit zurück, erkennt Überschriftenhierarchien und markiert Textblöcke nach Rolle.

Docling ist ein offenes Werkzeug, das aus PDF eine strukturierte Darstellung erzeugt, inklusive Tabellenerkennung über ein eigenes Modell. Es hat sich in den letzten Jahren zum ernsthaftesten offenen Gegenspieler entwickelt.

Unstructured deckt die größte Bandbreite an Dateiformaten ab und ist deshalb attraktiv, wenn Ihr Bestand aus allem besteht — PDF, Word, PowerPoint, Mails, HTML. Bei komplexen Tabellen ist es schwächer als Docling.

PyMuPDF ist kein Layout-Analysator, sondern ein schneller Textextrakor. Für digital erzeugte PDF ohne Tabellen ist es unschlagbar effizient und wird zu Unrecht übersehen.

Was in der Praxis passiert

Aus Projekten, in denen wir alle vier auf denselben Bestand losgelassen haben, ein Muster nach Dokumenttyp:

Digital erzeugte PDF, einspaltig, wenig Tabellen — etwa Richtlinien, Protokolle, Verträge. Alle vier funktionieren. PyMuPDF ist um Größenordnungen schneller und kostet nichts. Hier den Azure-Dienst zu nutzen, ist Geldverbrennung.

Digital erzeugt, mit Tabellen — Stücklisten, Prüfpläne, Preislisten. Docling und Azure liefern brauchbare Strukturen, Unstructured verliert bei verbundenen Zellen, PyMuPDF gibt Fließtext zurück. Der Abstand zwischen Docling und Azure ist hier kleiner, als der Preisunterschied vermuten lässt.

Gescannte Seiten — alte Konstruktionsunterlagen, unterschriebene Prüfprotokolle, eingegangene Post. Hier zieht Azure davon. Die Texterkennung ist robuster gegenüber schiefen Scans, schlechter Qualität und handschriftlichen Ergänzungen. Offene Werkzeuge mit Tesseract dahinter liefern bei gutem Scan brauchbare, bei mittelmäßigem Scan unbrauchbare Ergebnisse.

Mehrspaltige Layouts — Datenblätter, Fachartikel. Azure erkennt die Lesereihenfolge zuverlässiger. Offene Parser mischen die Spalten in einer Weise, die den Text semantisch zerstört.

Die Rechnung

Für 30.000 Dokumente mit durchschnittlich 12 Seiten, also 360.000 Seiten:

Azure Document Intelligence wird pro 1.000 Seiten abgerechnet, das Layout-Modell liegt spürbar über dem reinen Lesemodell. Für einen einmaligen Erstdurchlauf dieser Größe landen Sie im mittleren vierstelligen Eurobereich. Prüfen Sie die aktuellen Preise für Ihre Region — sie ändern sich, und die Differenz zwischen Lese- und Layout-Modell ist erheblich.

Docling oder PyMuPDF kosten Rechenzeit. Auf einem Server mit acht Kernen verarbeitet Docling grob 1 bis 3 Seiten pro Sekunde, je nach Komplexität und ob Tabellenerkennung aktiv ist. 360.000 Seiten sind damit zwei bis vier Tage Rechenzeit — einmalig, im Hintergrund, für die Stromkosten.

Der Abstand ist also erheblich. Und trotzdem ist die reine Kostenrechnung der falsche Maßstab, wenn 30 Prozent Ihres Bestands aus Scans besteht: Ein unbrauchbar geparstes Dokument kostet Sie mehr als seine Verarbeitung.

Der Weg, den wir empfehlen

Nicht ein Parser, sondern eine Weiche.

import fitz  # PyMuPDF

def parser_waehlen(pfad: str) -> str:
    """Entscheidet anhand des Dokuments, welcher Parser passt."""
    doc = fitz.open(pfad)
    seiten = min(len(doc), 5)              # Stichprobe reicht
    text_laenge = sum(len(doc[i].get_text()) for i in range(seiten))

    if text_laenge < 100 * seiten:
        return "azure"                     # praktisch kein Text: Scan
    if any(doc[i].find_tables().tables for i in range(seiten)):
        return "docling"                   # Tabellen vorhanden
    return "pymupdf"                       # einfacher Fließtext

Diese dreißig Zeilen sparen in einem gemischten Bestand regelmäßig 70 bis 90 Prozent der Parsing-Kosten, weil der teure Dienst nur die Dokumente sieht, die ihn wirklich brauchen. Und sie verbessern gleichzeitig das Ergebnis, weil jeder Dokumenttyp den passenden Weg nimmt.

Der Schwellenwert von 100 Zeichen pro Seite ist ein Ausgangswert. Prüfen Sie ihn an Ihrem Bestand — bei Dokumenten mit vielen Zeichnungen und wenig Text greift er zu früh.

Wo diese Weiche in der Gesamtverarbeitung sitzt, steht im Beitrag zur Ingestion-Pipeline.

Was Sie bei Scans zusätzlich brauchen

Ein Punkt, der bei on-premise-Anforderungen wichtig wird: Wenn die Dokumente das Haus nicht verlassen dürfen, fällt der Azure-Dienst aus, und Sie brauchen einen offenen Weg für Scans.

Praktikabel ist eine Kombination aus einem Modell zur Layout-Erkennung und einer Texterkennung, beides lokal betrieben. Das Ergebnis liegt unter dem des verwalteten Dienstes, ist aber für gut gescannte Seiten brauchbar. Rechnen Sie mit spürbarem Aufwand für Vorverarbeitung: Schieflagen korrigieren, Kontrast anheben, leere Seiten aussortieren. Diese drei Schritte bringen bei mittelmäßigen Scans mehr als der Wechsel der Texterkennung.

Wo das mit Bilddaten in der Fertigung zusammenläuft, behandelt der Beitrag zur lokalen Dokumentenanalyse.

Häufig gestellte Fragen

Welcher PDF-Parser eignet sich am besten für RAG?

Es gibt keinen einzelnen. Für digital erzeugte Dokumente ohne Tabellen ist ein schneller Textextraktor wie PyMuPDF ausreichend und kostenlos, für Tabellen liefert Docling gute Strukturen, für gescannte oder mehrspaltige Dokumente ist ein verwalteter Dienst wie Azure Document Intelligence deutlich robuster. Praktikabel ist eine Weiche, die pro Dokument entscheidet.

Wie erkenne ich, ob ein PDF gescannt oder digital erzeugt ist?

Über die Menge des extrahierbaren Texts. Ein digital erzeugtes PDF liefert bei der Textextraktion mehrere hundert bis tausend Zeichen pro Seite, ein Scan nahezu keine — der Inhalt liegt dort als Bild vor. Eine Stichprobe über die ersten Seiten genügt für die Entscheidung.

Was kostet Azure Document Intelligence für 30.000 Dokumente?

Bei durchschnittlich 12 Seiten je Dokument reden wir über 360.000 Seiten. Die Abrechnung erfolgt je 1.000 Seiten, wobei das Layout-Modell deutlich über dem reinen Lesemodell liegt. Für einen einmaligen Erstdurchlauf dieser Größe sollten Sie einen mittleren vierstelligen Betrag einplanen und die aktuellen Preise für Ihre Region prüfen, bevor Sie kalkulieren.

Warum sind Tabellen für RAG so kritisch?

Weil ihr Informationsgehalt in der Zuordnung liegt. Wird eine Tabelle als Fließtext extrahiert, geht die Verbindung zwischen Zeile, Spalte und Wert verloren — das Modell sieht Zahlen ohne Bezug und erzeugt daraus plausible, aber falsche Antworten. Bei technischen Dokumenten mit Intervallen, Grenzwerten und Drehmomenten ist das der häufigste Grund für falsche Auskünfte.

Gibt es eine brauchbare Texterkennung, die vollständig im Haus läuft?

Ja, mit Einschränkungen. Eine Kombination aus lokaler Layout-Erkennung und offener Texterkennung liefert bei gut gescannten Seiten brauchbare Ergebnisse. Bei schiefen, kontrastarmen oder handschriftlich ergänzten Vorlagen bleibt der Abstand zu verwalteten Diensten deutlich. Investieren Sie in dem Fall zuerst in die Bildvorverarbeitung — Schieflagenkorrektur und Kontrastanhebung bringen mehr als der Wechsel der Erkennungssoftware.

Der nächste Schritt

Nehmen Sie zwanzig Dokumente, die für Ihren Bestand repräsentativ sind — inklusive der hässlichen Scans — und schicken Sie sie durch zwei Kandidaten. Schauen Sie sich das Ergebnis an, statt Genauigkeitswerte zu vergleichen. Nach einer Stunde wissen Sie, ob Sie einen bezahlten Dienst brauchen. Bei der Auswertung schauen wir gern mit.