PaddleOCR: das OCR-Modell, das den page

#Zuerst die Erkennung: Was das verändert

PaddleOCR ist eine freie OCR-Toolbox unter der Apache-2.0-Lizenz, die eine Seite nicht Zeile für Zeile liest: Sie ermittelt zuerst, wo sich der Text befindet, liest dann jeden Bereich und kann anschließend die Struktur der Seite und ihrer Tabellen rekonstruieren. Das macht sie robust bei Rechnungen, Formularen, schief eingescannten Seiten und mehrsprachigen Dokumenten, bei denen eine OCR-Engine wie Tesseract mit großer Sicherheit unsinnige Ergebnisse liefert. Das Projekt umfasst zwei Familien: eine modulare Pipeline (PP-OCRv6 für die Texterkennung, PP-StructureV3 für die Struktur) und PaddleOCR-VL, ein Vision-Modell mit etwa 0,9 Milliarden Parametern, das eine Seite in einem einzigen Durchlauf in Markdown umwandelt und laut seinem Herausgeber 96,33 % auf OmniDocBench v1.6 erreicht. Der Preis dafür ist eine aufwendigere Installation mit PaddlePaddle und Modellgewichten sowie dokumentierte GPU-Voraussetzungen für die VL-Variante. Für große Mengen sauberen Textes bleibt eine schlanke OCR-Engine die einfachere Lösung.

Eine klassische Engine geht davon aus, dass eine Seite aus Textzeilen besteht, die wie in einem Buch angeordnet sind. Bei realen Dokumenten ist das anders: Eine Rechnung enthält umrahmte Bereiche, ein Formular hat Felder, eine Präsentation hat Text über Bildern, ein Scan liegt schief vor und ein technischer Plan enthält schräge Beschriftungen.

PaddleOCR teilt das Problem in zwei Schritte auf. Ein Detektionsmodell findet Textbereiche unabhängig davon, wo sie liegen, und gibt ihre Positionen zurück; ein Erkennungsmodell liest jeden Bereich. Ein schräg stehender Text, eine Beschriftung am Rand und eine Zahl in einer Zelle werden zu drei Bereichen unter vielen. Dadurch kommt PaddleOCR auch mit Dokumenten zurecht, bei denen ein zeilenweise arbeitendes Lesesystem Fehler macht, ohne sie erkennen zu lassen.

#Die Schritte der Pipeline

Nicht alle Schritte sind erforderlich. Zum Lesen einiger Etiketten genügen Detektion und Texterkennung; die Aufnahme von Finanzberichten für eine Dokumentenrecherche rechtfertigt die vollständige Verarbeitungskette. PP-OCRv6, die 2026 veröffentlichte Generation von Texterkennungsmodellen, deckt allein 50 Sprachen in einem einheitlichen Modell ab (Chinesisch, Englisch, Japanisch und 46 Sprachen mit lateinischem Alphabet), ohne dass zwischen den Sprachen das Modell gewechselt werden muss.

#PaddleOCR-VL: OCR wird zum Vision-Modell

Seit Oktober 2025 veröffentlicht das Projekt eine zweite Familie unter demselben Namen: PaddleOCR-VL, ein kompaktes Vision-Language-Modell, das die gesamte fünfstufige Pipeline durch einen einzigen Durchlauf ersetzt. Die Ende Mai 2026 erschienene Version 1.6 hat etwa 0,9 Milliarden Parameter und kombiniert einen visuellen Encoder mit dynamischer Auflösung mit einem kleinen Sprachmodell. Auf OmniDocBench v1.6, dem Referenzbenchmark für die Umwandlung von Dokumenten in Markdown oder JSON, erreicht sie einen Score von 96,33 %, ein Niveau, das das Projekt selbst als neuen Stand der Technik bezeichnet.

Was auffällt, ist nicht nur der Score, sondern auch die Größe des Modells, das ihn erzielt. Ein von InsiderLLM veröffentlichter Leitfaden fasst die Lage in einem Satz zusammen: Ein Modell mit 900 Millionen Parametern übertrifft ein Modell mit 72 Milliarden Parametern und GPT-4o bei der OCR von Dokumenten. Derselbe Artikel beziffert den Speicherbedarf des Allround-Konkurrenten — Qwen2.5-VL-72B benötigt bei Q4-Quantisierung mindestens 48 GB VRAM —, während PaddleOCR-VL, ins GGUF-Format konvertiert und in Q4_K_M quantisiert, ungefähr ein bis eineinhalb Gigabyte belegt, einschließlich der Gewichte des Sprachmodells und des visuellen Projektors. Dieser GGUF-Ansatz ist noch neu: Die Unterstützung für PaddleOCR-VL wurde im Februar 2026 (Version b8110) in llama.cpp integriert, und die verfügbaren GGUF-Dateien stammen aus der Community, nicht vom PaddleOCR-Team.

Die Komponente, die den OmniDocBench-Score erzielt, steht nicht allein: Neben PaddleOCR-VL pflegt das Projekt PP-StructureV3, eine Pipeline zur Konvertierung komplexer PDFs in Markdown oder JSON mit den präzisen Koordinaten jeder Tabellenzelle und jedes Textblocks. Beide Komponenten verfolgen dasselbe Ziel – ein reales Dokument sauber zu konvertieren –, gehen dabei aber zwei verschiedene Wege: ein einziges Modell bei PaddleOCR-VL und eine Kette spezialisierter Komponenten bei PP-StructureV3. Die jeweilige Engine unterstützt Multi-GPU- und Multi-Prozess-Inferenz nativ. Das ist entscheidend, sobald ein Korpus mit mehreren Zehntausend Seiten in angemessener Zeit verarbeitet werden muss.

#PaddleOCR oder Tesseract

Eine gut konzipierte Pipeline nutzt beide: einfache Seiten für die ressourcenschonende Engine, komplexe Seiten für die ressourcenintensive Engine. Diese Zuordnung kostet nichts und spart bei einem großen Korpus Stunden. Die Angabe zur Neigung ist kein nebensächliches Detail: Koncile, ein Softwareanbieter für Rechnungsextraktion, hat in eigenen Tests gemessen, dass die Erkennungsrate von Tesseract von 100 % bei einer geraden Rechnung auf 31 % sank, sobald der Scan um nur 3 bis 5 Grad geneigt war – genau der Fall, für den die Orientierungsklassifikation von PaddleOCR ausgelegt ist.

• Tesseract: die schlanke OCR-Engine und wann sie ausreicht
• Docling: Strukturierte Dokumente konvertieren
• Rechnungsdaten extrahieren: von Anfang bis Ende
• Ein Bild mit einem lokalen Vision-Modell analysieren

#Anwendungsfälle: Wann auf PaddleOCR wechseln

Rechnungsstellung und Buchhaltung

Ein Rechnungsscan ist selten vollkommen gerade ausgerichtet; die Tabellenstruktur (Menge, Stückpreis, MwSt.) muss lesbar bleiben, damit die Beträge ihre Bedeutung behalten, statt als Zeile isolierter Zahlen zu enden.

Mehrsprachige Verwaltungsakten

Formulare, Ausweisdokumente, Briefe in verschiedenen Schriftsystemen: Die breite Sprachabdeckung von PaddleOCR erspart es, für jedes Land oder Alphabet eine andere Engine einzurichten.

Lange Berichte für ein RAG

Ein Bericht von mehreren Dutzend Seiten mit Überschriften, Zwischenüberschriften und Tabellen sollte unter Erhalt seiner Struktur konvertiert werden: Eine Aufteilung entlang der Abschnitte ist besser als eine Aufteilung nach Zeichenanzahl.

Ungeordnete gescannte Archivbestände

Kisten voller Papierdokumente, unsorgfältig gescannt und beliebig ausgerichtet: Die Klassifizierung der Ausrichtung beseitigt den größten Teil dieses Durcheinanders schon vor dem Lesen.

Hohes Volumen und sauberer Text

Umgekehrt ist bei großen Mengen von Kassenbelegen oder Auszügen, die bereits gut im Bild erfasst sind, oft weiterhin eine schlankere Engine die bessere Wahl — siehe den Vergleich mit Tesseract weiter oben.

#Installieren und eine erste Extraktion starten

Die Installation erfolgt über pip, mit einer Besonderheit: Seit der Versionsreihe 3.x reicht das Paket paddleocr allein nicht aus. Die Dokumentation verlangt, zuerst die gewählte Inferenz-Engine (standardmäßig PaddlePaddle) und anschließend das Paket paddleocr zu installieren. Die Gewichte der Modelle für die Detektion, die Erkennung und gegebenenfalls das Seitenlayout werden beim ersten Start jeder verwendeten Pipeline heruntergeladen.

1. 01
   Bibliothek installieren

   Zuerst PaddlePaddle gemäß der offiziellen Installationsseite installieren (je nach Rechner die CPU- oder GPU-Variante), anschließend python -m pip install paddleocr ausführen. Das Basispaket unterstützt Python 3.8 oder höher; die optionalen Zusatzkomponenten für die Dokumentanalyse (paddleocr[doc-parser]) erfordern Python 3.9 oder höher.
2. 02
   Erste Extraktion starten

   Der Befehl paddleocr ocr nimmt ein Bild als Eingabe (Option -i) und schreibt die Ergebnisse in den durch --save_path angegebenen Ordner. Um eine Seite mit PaddleOCR-VL in Markdown umzuwandeln, lautet der Befehl paddleocr doc_parser, mit denselben Optionen -i und --save_path.
3. 03
   Nützliche Schritte aktivieren

   Die Optionen use_doc_orientation_classify, use_doc_unwarping und use_textline_orientation aktivieren die Korrektur schief ausgerichteter Seiten oder Textzeilen. Bei sauberen Scans beschleunigt es die Verarbeitung, diese Optionen auf False zu setzen; die offizielle Dokumentation empfiehlt außerdem, unnötige Funktionen zu deaktivieren, wenn die Inferenz zu langsam ist.

python -m pip install paddleocr
paddleocr ocr -i ./facture.jpg --use_doc_orientation_classify True --use_textline_orientation True --save_path ./output

#Was es verbraucht

Das Projekt veröffentlicht keinen allgemeingültigen Durchsatz pro Seite: Er hängt von der Dokumentdichte, den aktivierten Verarbeitungsschritten und der Hardware ab. Die Dokumentation empfiehlt, unnötige Funktionen zu deaktivieren oder bei langsamer Inferenz leichtere Modelle zu wählen. Messen Sie anhand von etwa zwanzig Ihrer Seiten, bevor Sie die Ergebnisse auf ein Korpus hochrechnen. Für PaddleOCR-VL nennt die offizielle Dokumentation die Anforderungen an NVIDIA-GPUs (PaddlePaddle: Compute Capability 7.0 oder höher und CUDA 11.8 oder höher; vLLM: 8.0 oder höher und CUDA 12.6 oder höher) und sieht auch eine Möglichkeit für den Betrieb auf x64-Prozessoren vor. Die Gewichte werden einmal heruntergeladen, danach läuft alles lokal: keine API, keine Kosten pro Seite.

#Das entscheidende Argument: keine erfundenen Inhalte

PaddleOCR liest Pixel. Es kann ein Zeichen falsch lesen, und eine ersetzte Ziffer fällt nicht immer auf. Ein allgemeines Bildverarbeitungsmodell, das ein Dokument transkribieren soll, kann einen formal korrekten, plausiblen Wert erzeugen, der auf der Seite gar nicht vorkommt – und nichts in der Ausgabe weist darauf hin. Bei PaddleOCR-VL ist besondere Vorsicht geboten: Da es den Text erzeugt, statt ihn Bereich für Bereich zu lesen, gehört es zur selben Risikokategorie wie allgemeine Bildverarbeitungsmodelle, auch wenn es für die Transkription trainiert wurde. Kein System ist vor einem Fehler bei einem mehrdeutigen Zeichen gefeit.

Bei der Dokumentenprüfung, in der Buchhaltung oder bei allem, was auditierbar sein muss, sollte dieser Unterschied die Wahl bestimmen: eine spezialisierte OCR-Engine für die Zahlen, auf die Sie sich stützen werden, und ein allgemeines Bildverständnismodell, wenn das Dokument erklärt statt transkribiert werden soll. Bei Dokumenten, bei denen viel auf dem Spiel steht, bleibt es eine berechtigte dritte Option, beide zu verwenden und die Ergebnisse zu vergleichen.

In der Praxis muss man zur Überprüfung nicht alles erneut lesen. Eine Stichprobe von einigen Dutzend Dokumenten pro Stapel, die manuell mit der Ausgabe der OCR-Engine verglichen wird, genügt, um eine systematische Abweichung zu erkennen – ein falsch abgegrenztes Feld, eine falsch erkannte Sprache oder eine regelmäßig falsch segmentierte Tabelle –, bevor diese Abweichung Tausende automatisch verarbeiteter Seiten beeinträchtigt.

• Quelle: offizielles PaddleOCR-Repository auf GitHub
• Quelle: Modellbeschreibung PaddleOCR-VL-1.6
• Quelle: unabhängiger Vergleich zu lokal betriebenem PaddleOCR-VL

#FAQ