RAG PDF: pdf-inspector oder OCR? Entscheidung 2026

RAG PDF sollte nicht pauschal mit OCR verarbeitet werden: pdf-inspector eignet sich als Prüf- und Extraktionseinstieg, während OCR nur für Scan-Seiten oder eine unbrauchbare Textebene zugeschaltet wird. Für einen kleinen Prototyp genügt eine vereinfachte Kette; bei regelmäßiger Aufnahme oder hohem Durchsatz ist ein stufenweises Routing die belastbarere Architektur.

Dieser Beitrag richtet sich an Entwickler und Architekten, die eine RAG-Aufnahmepipeline von Grund auf planen, an Teams mit langsamer oder instabiler OCR-Verarbeitung sowie an Verantwortliche, die für Regressionstests eine reproduzierbare Rechenumgebung vorbereiten müssen.

Zuletzt aktualisiert am 10.08.2026; technische Angaben wurden anhand des aktuellen Projekt-README, der Änderungsaktivität und der offiziellen Dokumentationen der verwendeten Parser- und OCR-Komponenten geprüft.

Die Entscheidung beginnt mit der Textqualität

Bei PDF-Dateien ist „Text vorhanden“ kein ausreichendes Qualitätskriterium. Ein Dokument kann eine versteckte Textebene besitzen, deren Zeichen zwar extrahierbar sind, deren Reihenfolge aber für eine RAG-Pipeline kaum brauchbar ist. Typische Fälle sind falsch angeordnete Spalten, getrennte Wörter, wiederholte Kopfzeilen oder Tabellen, die als unverbundene Einzelzeichen erscheinen.

Für die Weiterverarbeitung müssen mindestens fünf Eigenschaften getrennt bewertet werden:

1. Zeichenabdeckung: Fehlen relevante Wörter, Sonderzeichen, Fußnoten oder Seiteninhalte?
2. Lesereihenfolge: Wird eine zweispaltige Seite von oben nach unten und anschließend spaltenweise gelesen?
3. Absatzgrenze: Bleiben Überschriften, Absätze und Listen voneinander unterscheidbar?
4. Struktur: Werden Tabellen, Bildunterschriften, Formeln und Seitenwechsel nachvollziehbar erhalten?
5. Rückverfolgbarkeit: Kann eine Antwort später auf Dokument, Seite und Textabschnitt zurückgeführt werden?

pdf-inspector wird im offiziellen Projekt-README als Bibliothek für PDF-Klassifizierung und Textextraktion beschrieben. Die Ausgabe kann unter anderem zwischen text_based, scanned, image_based und mixed unterscheiden. Das ist für eine RAG-Pipeline wichtig, weil die Klassifizierung eine Routing-Entscheidung ermöglicht. Sie ist jedoch nicht automatisch ein Beweis dafür, dass jede Tabelle oder jedes komplexe Layout bereits RAG-tauglich strukturiert wurde.

Die Dokumentation eines etablierten PDF-Parsers weist ausdrücklich darauf hin, dass einfache Textextraktion keine automatische Verschönerung vornimmt. Unerwartete Zeilenumbrüche und eine nicht natürliche Lesereihenfolge sind deshalb möglich. Die Hinweise zur Textextraktion und Lesereihenfolge sollten vor der Wahl des Chunking-Verfahrens gelesen werden.

Muss eine RAG-PDF-Pipeline vor der Verarbeitung immer OCR ausführen? Nein. Bei einer sauberen nativen Textebene ist OCR ein zusätzlicher Verarbeitungsschritt, der eine bereits brauchbare Textquelle ersetzen oder verschlechtern kann. Zuerst sollte die vorhandene Ebene geprüft werden; OCR folgt nur bei fehlendem, unvollständigem oder nicht vertrauenswürdigem Text.

Was die drei Verarbeitungswege tatsächlich leisten

Die drei Ansätze werden häufig als konkurrierende Werkzeuge betrachtet, obwohl sie unterschiedliche Aufgaben erfüllen.

1. Native Extraktion mit pdf-inspector

Dieser Weg liest die im PDF gespeicherten Textobjekte, klassifiziert den Dokumenttyp und kann eine Markdown-orientierte Ausgabe erzeugen. Er eignet sich besonders für digital erzeugte Berichte, Rechnungen, Forschungsunterlagen und Verträge, sofern die Textobjekte bereits sinnvoll angeordnet sind.

Die offizielle Projektseite nennt für ihre eigene Benchmark einen Durchsatz von unter 200 Millisekunden bei textbasierten PDFs sowie einen Anteil von ungefähr 54 % der untersuchten PDFs, die keine OCR benötigen. Diese Angaben sind als Projektaussagen beziehungsweise Benchmarkwerte zu lesen, nicht als allgemeingültige Leistungsversprechen. Die Benchmark wurde laut README am 31.07.2026 auf einem Apple M4 Pro mit festgelegten Versionen, einem einzelnen Prozess und einem bestimmten Korpus aktualisiert. Die vollständige Benchmarkbeschreibung des Projekts nennt außerdem Werte für Lesereihenfolge, Tabellen und Überschriften.

2. Direkte OCR-Verarbeitung

OCR rendert Seiten als Bilder oder verarbeitet vorhandene Bildinhalte und erkennt daraus Zeichen. Das ist für reine Scans unverzichtbar, kann aber bei digital erzeugten PDFs unnötig sein. Eine OCR-Komponente kann zwar eine durchsuchbare Textebene hinzufügen, sie entscheidet aber nicht automatisch, ob eine erkannte Tabelle fachlich korrekt aufgebaut ist.

Die offizielle OCR-Dokumentation beschreibt OCR vor allem als Methode, um gescannten PDFs eine durchsuchbare Textebene hinzuzufügen. Daraus folgt eine klare Architekturgrenze: OCR liefert erkannte Zeichen; die anschließende Dokumentstrukturierung, Seitenspeicherung und Chunk-Aufteilung bleiben Aufgaben der RAG-Pipeline.

3. Gemischtes Routing

Die Hybridroute prüft zuerst das Dokument oder einzelne Seiten, extrahiert native Inhalte, wenn diese ausreichend gut sind, und ruft OCR nur für problematische Seiten auf. Gerade bei gemischten PDFs mit zehn Textseiten und einzelnen gescannten Anlagen verhindert diese Methode, dass der komplette Bestand unnötig gerendert und erkannt wird.

Für RAG PDF ist die Hybridroute meist die beste Produktionsbasis, weil sie die Entscheidung nicht auf Dateiebene erzwingt. Eine Datei kann auf Seite 1 bis 20 digital erzeugten Text enthalten und auf Seite 21 ein eingescanntes Formular. Ein Dokument-Flag allein reicht dann nicht; das Routing muss gegebenenfalls seitenweise erfolgen.

Die relevanten Metriken für die Architekturentscheidung

Die folgende Bewertung ist keine allgemeine Qualitätsgarantie, sondern ein technischer Entscheidungsrahmen für typische RAG-Aufnahmepipelines. Die Punktzahl bezieht sich auf die Eignung für den jeweiligen Einsatz, nicht auf eine universelle Produktbewertung.

Die Qualitätsstufe sollte nicht aus einer einzigen Zeichenanzahl abgeleitet werden. Ein Parser kann viele Zeichen liefern und trotzdem eine schlechte Grundlage für Retrieval erzeugen, wenn Überschrift und Absatz vermischt werden. Umgekehrt kann eine kurze Seite mit einer korrekten Tabelle für die spätere Antwortqualität wichtiger sein als eine lange Textseite.

Für die Abnahme empfiehlt sich deshalb ein gemeinsames Protokoll aus Rohtext, Markdown, Seitenkennung, erkannter Dokumentklasse, OCR-Status und Fehlergrund. Ein Beispiel für eine Mindeststruktur lautet:

{
  "document_id": "beispiel-001",
  "page": 7,
  "route": "native_extraction",
  "pdf_type": "mixed",
  "text_chars": 1840,
  "has_heading": true,
  "table_status": "manual_review",
  "source_reference": "seite-7"
}

Die Zahl im Beispiel ist keine Leistungsangabe, sondern nur ein Schema. In der produktiven Pipeline müssen die Werte aus dem jeweiligen Dokument stammen.

PDF Parsing braucht eine klare Grenze zwischen Erkennen und Verstehen

Kann pdf-inspector OCR vollständig ersetzen? Nur für den Teil der Aufgaben, den eine native Extraktion abdeckt. pdf-inspector kann erkennen, ob ein Dokument oder eine Seite textbasiert, gescannt, bildbasiert oder gemischt ist, und daraus Text extrahieren. Eine fehlende OCR-Schicht wird dadurch nicht erzeugt. Bei einem Scan bleibt ein OCR-Schritt erforderlich.

Diese Abgrenzung verhindert einen häufigen Architekturfehler: Die Klassifizierung wird mit vollständigem Dokumentverständnis verwechselt. Ein Tool kann einen Scan korrekt als Scan melden, ohne die Handschrift, die Formularlogik, die Tabellenbeziehungen oder die Bedeutung einer mathematischen Formel zuverlässig zu interpretieren.

Bei mehrspaltigen Dokumenten sollten zusätzlich Positionsinformationen und Lesereihenfolge geprüft werden. Für native Extraktion bieten etablierte Bibliotheken Funktionen für einfachen Text, Blocksortierung, Layoutmodus und Markdown-Ausgabe. Die aktuelle Dokumentation zur PDF-Textextraktion zeigt außerdem, dass bildbasierte Seiten über einen OCR-Textbereich nachverarbeitet werden können.

Bei Tabellen ist ein separater Test sinnvoll. Eine RAG-Anwendung kann zwar den Tabelleninhalt als Text aufnehmen, aber Spaltenbeziehungen verlieren. Das führt zu Antworten, in denen ein Wert aus Spalte B dem falschen Produkt aus Spalte A zugeordnet wird. Für kritische Tabellen sollte daher neben dem Fließtext ein strukturiertes Format wie CSV, JSON oder eine geprüfte Markdown-Tabelle gespeichert werden.

Formeln und technische Zeichnungen benötigen ebenfalls eine eigene Behandlung. OCR kann Zeichen wie „O“, „0“, „l“ und „1“ verwechseln; bei Formeln kommen hoch- und tiefgestellte Zeichen hinzu. Solche Seiten sollten nicht automatisch als fehlerfrei markiert werden, nur weil der OCR-Prozess ohne Fehlermeldung beendet wurde.

Geschwindigkeit und Durchsatz bestimmen das Routing

Eine feste Aussage wie „OCR ist immer zehnmal langsamer“ wäre ohne Korpus, Seitenformat, Sprache, Bildauflösung, Prozessor und Parallelisierungsmodell nicht belastbar. Die Verarbeitung setzt sich aus mehreren Abschnitten zusammen:

• PDF öffnen und Metadaten lesen,
• Dokument oder Seiten klassifizieren,
• native Textobjekte extrahieren,
• Seiten bei Bedarf rendern,
• OCR ausführen,
• Layout und Tabellen normalisieren,
• Text in Chunks zerlegen,
• Embeddings berechnen,
• Vektordaten und Quellenmetadaten speichern.

Der entscheidende Vergleich ist deshalb nicht „Tool A gegen Tool B“, sondern Kosten einer unnötigen OCR-Stufe gegen Kosten einer verpassten OCR-Stufe. Eine unnötige OCR-Stufe erhöht Wartezeit, CPU-Auslastung, temporären Speicherbedarf und Fehlerfläche. Eine verpasste OCR-Stufe erzeugt scheinbar leere Dokumente, schlechte Treffer und schwer erklärbare Lücken im Wissensbestand.

Für einen kleinen Prototyp mit wenigen, bekannten Dateien kann direkte OCR akzeptabel sein, weil die einfache Implementierung zunächst wichtiger ist als die maximale Effizienz. Für eine wiederkehrende Aufnahme sollte dagegen jede Route messbar sein. Geeignete Kennzahlen sind:

• Anteil der Dokumente und Seiten je Route,
• mittlere und p95-Verarbeitungszeit pro Seite,
• OCR-Fehlerquote,
• Anteil leerer oder ungewöhnlich kurzer Ausgaben,
• Seitenreferenz- und Chunk-Vollständigkeit,
• manuelle Korrekturquote,
• Wiederholbarkeit nach einem Versionswechsel.

Die Benchmark des pdf-inspector-Projekts ist nützlich, weil sie eine konkrete Umgebung, einen Korpus und feste Versionen nennt. Sie ersetzt jedoch keinen eigenen Test mit den Dokumenten, die tatsächlich in das RAG-System gelangen sollen.

Rechenressourcen und Kosten werden häufig falsch verteilt

Die Kosten einer PDF-Aufnahme entstehen nicht nur durch OCR. Für eine belastbare Schätzung sollte das Team die folgenden Komponenten separat erfassen:

Gesamtkosten =
Dokumentmenge × durchschnittliche Seitenzahl
× Verarbeitungszeit je Seite
× Miet- oder Betriebskosten je Zeiteinheit
+ Speicher
+ Embedding-Verarbeitung
+ Wiederholungen und Fehlversuche

Diese Formel enthält bewusst keine vorgegebenen Geldbeträge. Die tatsächlichen Werte hängen von Umgebung, Auslastung, Vertragsmodell, Laufzeit und Parallelisierung ab. Für einen einmaligen Batch kann eine zeitweise gemietete Umgebung wirtschaftlicher sein als dauerhaft reservierte Hardware. Für tägliche oder kontinuierliche Aufnahme kann eine fest betriebene Umgebung mit planbarer Auslastung einfacher zu überwachen sein.

Die Ressourcenprofile unterscheiden sich:

• Klassifizierung und native Extraktion: überwiegend CPU- und Speicherlast; lokale Ausführung ist oft ausreichend.
• Rendering: zusätzliche temporäre Dateien und Speicherbandbreite; parallele Jobs können den Datenträger stärker belasten als erwartet.
• OCR: rechenintensiver und abhängig von Sprache, Bildqualität und Auflösung; Spitzenlasten müssen begrenzt werden.
• Embedding: abhängig vom gewählten Modell und der Batchgröße; die Extraktion ist nicht automatisch der teuerste Schritt.
• Speicherung: Originaldatei, normalisierte Ausgabe, Seitenbilder, OCR-Ergebnis, Chunks und Diagnosedaten können parallel anfallen.

Bei vertraulichen Dokumenten muss außerdem feststehen, ob Seitenbilder oder OCR-Zwischendateien nach der Verarbeitung gelöscht werden. Die Datenschutzinformationen von Zilmac sollten in die interne Prüfung einbezogen werden, wenn für Regressionstests eine gemietete Mac-Umgebung eingesetzt wird.

Die passende Architektur nach Datenmenge

Kleiner Prototyp:
Für einen ersten Versuch genügt pdf-inspector als Einstieg, gefolgt von manueller Prüfung der problematischen Dokumente. Eine einfache Rückfallregel lautet: Wenn die Klassifizierung scanned, image_based oder mixed meldet, wird die Datei oder die betroffene Seite an OCR übergeben. Vor dem Embedding sollten mindestens zehn repräsentative Dokumente kontrolliert werden, darunter ein mehrspaltiger Bericht, eine Tabelle, ein Scan und ein gemischtes Dokument.

Periodischer Batch:
Bei wöchentlichen oder monatlichen Importen sollte die Route dauerhaft protokolliert werden. Bereits verarbeitete Dokumente benötigen einen stabilen Fingerabdruck, damit eine Versionsänderung nicht unbemerkt den gesamten Bestand neu verarbeitet. Für einen Batch ist außerdem ein getrenntes Fehlerverzeichnis sinnvoll: fehlerhafte Dateien dürfen nicht still aus dem Import verschwinden.

Kontinuierliche Produktionsaufnahme:
Für laufende Zuflüsse ist die Hybridroute die bessere Wahl. Klassifizierung, native Extraktion und OCR werden als getrennte Stufen mit eigenen Zeitüberschreitungen betrieben. Jede Stufe muss einen reproduzierbaren Status liefern. Ein Dokument mit erfolgreicher Klassifizierung, aber fehlgeschlagener OCR darf nicht als vollständig verarbeitet gelten.

Fünf Schritte bis zur belastbaren RAG-Aufnahme

Erster Schritt: Ein repräsentatives Testkorpus definieren

Das Korpus sollte nicht nur aus gut lesbaren Text-PDFs bestehen. Es benötigt native PDFs, Scans, gemischte Dateien, mehrspaltige Seiten, Tabellen, Formeln, gedrehte Seiten und Dokumente mit fehlerhafter oder versteckter Textebene. Die Auswahl muss die späteren Produktionsdaten abbilden.

Zweiter Schritt: Rohzustand vor dem Parsing erfassen

Für jede Datei werden Dateifingerabdruck, Seitenzahl, Dateigröße, Passwortstatus, Dokumenttyp und vorhandene Textebene protokolliert. Eine Datei mit sehr kurzer extrahierter Ausgabe darf nicht automatisch als leer gelten, bevor die Seiten visuell geprüft wurden.

Dritter Schritt: Drei Routen mit identischem Korpus ausführen

Dasselbe Korpus wird nacheinander über native Extraktion, direkte OCR und Hybridrouting verarbeitet. Dabei dürfen Chunk-Größe, Embedding-Modell und Suchtest nicht gleichzeitig verändert werden. Sonst bleibt unklar, ob eine Qualitätsänderung aus der PDF-Aufnahme oder aus dem RAG-System stammt.

Vierter Schritt: Retrieval statt nur Rohtext prüfen

Die Abnahme muss echte Suchfragen enthalten. Für jede Frage wird kontrolliert, ob der richtige Abschnitt gefunden, die Seitenreferenz bewahrt und die Tabellenzuordnung korrekt wiedergegeben wird. Ein Textvergleich allein erkennt nicht zuverlässig, ob ein Chunk für Retrieval sinnvoll geschnitten wurde.

Fünfter Schritt: Rückfall, Versionierung und Regression festschreiben

Die Pipeline benötigt definierte Zustände für „native erfolgreich“, „OCR erforderlich“, „manuelle Prüfung“ und „nicht verarbeitet“. Parser-, OCR- und Betriebssystemversionen werden fixiert. Nach jeder Aktualisierung werden dieselben Testdateien erneut verarbeitet und die Kennzahlen mit dem vorherigen Lauf verglichen.

Die folgende Prüfliste kann direkt als Abnahmegrundlage verwendet werden:

• [ ] Das Testkorpus enthält native, gescannte und gemischte PDFs.
• [ ] Jede Datei erhält eine stabile Dokument-ID und eine Seitenreferenz.
• [ ] Die Route pro Dokument und Seite wird protokolliert.
• [ ] Leere, ungewöhnlich kurze und stark abweichende Ausgaben werden markiert.
• [ ] Überschriften und Absatzgrenzen werden stichprobenartig geprüft.
• [ ] Tabellen werden separat auf Spalten- und Zeilenbeziehungen getestet.
• [ ] OCR wird nur bei definierten Auslösern gestartet.
• [ ] Fehlgeschlagene Seiten erhalten einen reproduzierbaren Rückfallstatus.
• [ ] Parser- und OCR-Versionen sind für Regressionstests festgelegt.
• [ ] Datenschutzregeln für Originale, Seitenbilder und temporäre Dateien sind dokumentiert.
• [ ] Ein Suchtest prüft Inhalt, Seitenreferenz und Antwortgrundlage gemeinsam.
• [ ] Die Pipeline kann denselben Testlauf mit identischem Ergebnis wiederholen.

Die klare Empfehlung für die Auswahl

Für native Text-PDFs ist pdf-inspector der sinnvollere Einstieg als direkte OCR, weil die Pipeline zuerst klassifizieren und native Inhalte ohne unnötigen Bildschritt übernehmen kann. Für reine Scans ist OCR kein optionales Qualitätsfeature, sondern die notwendige Texterkennung. Für gemischte Dokumente ist die seitenweise Hybridroute die belastbarste Lösung.

Die entscheidende Kennzahl lautet nicht, wie viele Dateien ein Tool verarbeitet, sondern wie viele verwertbare, auffindbare und zurückverfolgbare Textabschnitte nach der Aufnahme übrig bleiben. Ein schneller Import mit falscher Lesereihenfolge verschiebt die Kosten nur in die spätere Fehlersuche.

Eine direkte OCR-Pipeline bleibt trotzdem sinnvoll, wenn das Eingangskorpus fast ausschließlich aus Scans besteht, die Layoutanforderungen gering sind und die OCR-Qualität bereits mit einem repräsentativen Korpus nachgewiesen wurde. Sie ist dagegen keine gute Standardroute für heterogene Dokumentbestände, bei denen native Textobjekte, Tabellen und Seitenreferenzen erhalten bleiben sollen.

Für die Auswahl einer geeigneten Cloud-Mac-Umgebung sollte der Verantwortliche die erwartete Seitenmenge, den Batch-Zeitraum, den maximalen Parallelismus und die benötigten Testwiederholungen zusammentragen. Eine zeitweise gemietete Mac-Umgebung kann für Regressionen und Spitzenlasten sinnvoll sein; bei dauerhaft hoher Auslastung oder speziellen physischen Schnittstellen kann eigener Betrieb die bessere Wahl sein.

Wer derzeit eine ungeteilte OCR-Kette auf einem einzelnen Arbeitsplatz oder einer dauerhaft laufenden Standardumgebung betreibt, trägt meist drei Nachteile: native PDFs werden unnötig gerendert, Fehlversuche blockieren den gesamten Ablauf und die Reproduzierbarkeit leidet, wenn lokale Bibliotheken oder Versionen wechseln. Für zeitlich begrenzte Tests, Batchläufe und die Vorbereitung einer stabilen RAG-Pipeline ist es deshalb oft sinnvoller, die benötigte Mac-Rechenumgebung über Zilmac gezielt für den jeweiligen Prüfzeitraum zu mieten, statt die Produktionsentscheidung auf einer zufälligen lokalen Konfiguration aufzubauen.