olmOCR ist AI2s Open-Source-Toolkit zur Linearisierung von Dokumenten. Es rendert jede PDF-Seite als Bild und lässt das dokumentenspezifisch trainierte Vision-Language-Modell olmOCR-2 Fließtext, Tabellen und LaTeX-Formeln in natürlicher Lesereihenfolge rekonstruieren. Anschließend prüft die Pipeline YAML-Metadaten, wiederholt fehlerhafte oder gedrehte Seiten und schreibt Markdown sowie Dolma-JSONL. Auch PNG und JPEG werden akzeptiert; typische Einsatzfelder sind Korpuserstellung, historische Scans, Suche und RAG-Vorbereitung.
Das ist mehr als klassische Zeichenerkennung. Konventionelle OCR konzentriert sich häufig auf Zeichen und Koordinaten; olmOCR entscheidet zusätzlich über Spaltenreihenfolge, unterdrückt wiederkehrende Kopf- und Fußzeilen und übersetzt visuelle Tabellen in Textstruktur. Das Ergebnis ist für Sprachmodelle gut lesbar, bleibt aber generierter Text. Eine flüssige Passage kann eine Zahl, eine Verneinung, eine Formelvariable oder die Zuordnung einer Tabellenzelle falsch wiedergeben. Originalseite, Seitenbild und Prüfentscheidung müssen deshalb erhalten bleiben.
Was mit einer Dokumentseite geschieht
| Phase | Aktuelles Verhalten | Fehlergrenze |
|---|---|---|
| Eingabe | PDF, PNG und JPEG aus lokalem Speicher oder einem Workspace | Verschlüsselte, defekte, übergroße oder unzulässig beschaffte Dateien brauchen eigene Sperren |
| Rendering | Jede PDF-Seite wird als begrenztes PNG gerendert; eine Rotation kann erneut versucht werden | Kleinschrift, Unschärfe, Kompression, Beschädigung und extreme Seitenverhältnisse vernichten Evidenz |
| Rekonstruktion | olmOCR-2 erzeugt aus dem Seitenbild natürlich geordneten Text und Struktur | Das VLM kann Inhalte auslassen, ersetzen, normalisieren oder plausibel erfinden |
| Validierung/Retry | Pipeline prüft Abschlussgrund, Kontextgrenze, YAML-Parse und Rotationssignal | Ein valides Schema ist kein Beweis für sachliche Richtigkeit |
| Export | Seitentext wird mit Page-Spans zu Dolma zusammengeführt; optional folgt Markdown | Seitenübergreifende Tabellen, Fußnoten, Überschriften und fehlende Seiten benötigen Dokumentprüfung |
Die aktuelle Architektur verarbeitet Seiten weitgehend unabhängig. Das vereinfacht Parallelisierung, Wiederholungen und das Fortsetzen großer Jobs. Sie löst aber keine Semantik über Seitengrenzen hinweg. Steht ein Tabellenkopf auf der vorherigen Seite oder setzt sich eine Fußnote später fort, können beide Einzelergebnisse plausibel und die Kombination trotzdem falsch sein. Seiten-ID, Original-Hash, Fehlerliste und Manifest gehören daher zum Ergebnis.
Das Projekt wird weiterhin gepflegt. Zum Prüfdatum war v0.4.27 vom 12. März 2026 die neueste sichtbare stabile GitHub-Version. Frühere Releases enthielten unter anderem Korrekturen für lange Warteschlangen, automatische Rotation und Halluzinationen auf leeren Dokumenten. Aktive Wartung ist positiv, zeigt aber zugleich, warum Produktion eine getestete Version pinnen sollte, statt ungeprüft dem main-Branch zu folgen.
Anchoring: die wichtige Grenze zwischen früherem und aktuellem Verfahren
Das Repository enthält weiterhin anchor.py. Dieses Modul kann begrenzten nativen PDF-Text über pdftotext, PDFium oder pypdf extrahieren. Frühere Ansätze gaben einem VLM diesen unvollkommenen Text zusammen mit dem gerenderten Bild als Zeichenhilfe. Die CLI listet noch --target_anchor_text_len, kennzeichnet die Option jedoch ausdrücklich als für neue Modelle ungenutzt. Die aktuelle main-Pipeline baut für olmOCR-2 einen No-Anchoring-Prompt; pdftotext erscheint vor allem als Fallback, wenn Modellverarbeitung scheitert.
Die pauschale Aussage „olmOCR verwendet PDF-Anker“ ist deshalb versionsblind. Anchoring ist eine erhaltene Technik und Teil der Projektgeschichte, aber nicht die Evidenzquelle jeder heutigen Inferenz. Bei born-digital PDFs lohnt sich eine unabhängige native Textextraktion dennoch: Übereinstimmung ist noch kein Beweis, Abweichung aber ein guter Review-Trigger für Encoding, Reihenfolge, Auslassung oder Halluzination. Ein reiner Bildscan besitzt unter Umständen überhaupt keinen brauchbaren Textanker.
Modell, Daten, Benchmark und Lizenz
| Komponente | Verifizierter Umfang | Saubere Interpretation |
|---|---|---|
| Ursprünglicher Trainingsmix | Die erste Arbeit nennt 260.000 Seiten aus mehr als 100.000 gecrawlten PDFs, darunter Grafiken, Handschrift und schlechte Scans | Vielfalt beweist keine gleichmäßige Qualität für alle Sprachen, Archive oder Formulare |
| olmOCR-2 | 7B-Klasse, von Qwen2.5-VL-7B-Instruct abgeleitet; SFT plus Reinforcement Learning mit verifizierbaren Unit-Test-Rewards | Die Arbeit verortet die größten Verbesserungen bei Mathematik, Tabellen und Mehrspaltenlayout im englischen Benchmark |
| olmOCR-Bench | Rund 1.400 einseitige PDFs und mehr als 7.000 maschinenprüfbare Fakten zu Formeln, Tabellen, alten Scans, Headern, Spalten und Kleinschrift | Wichtige schwierige Fälle, aber nicht die Verteilung eigener Dokumente |
| Präzision | Die Model Card empfiehlt FP8 für praktische Inferenz und BF16 für weiteres Fine-Tuning | Ein Präzisionslabel garantiert weder Qualität noch Durchsatz oder VRAM-Bedarf |
| Lizenz | Toolkit und veröffentlichte olmOCR-2-Gewichte sind Apache-2.0; die Model Card verweist zusätzlich auf AI2 Responsible Use Guidelines | Rechte am Quelldokument, Abhängigkeiten, Basismodell-Hinweise und Zweck getrennt prüfen |
Die öffentliche Rangliste darf nicht als universelle Genauigkeit verkauft werden. olmOCR-Bench ist englisch, seitenbezogen und verwendet normalisierte Faktentests. Diese Methode entdeckt wichtige Fehler, die eine reine Edit-Distance kaum gewichtet, etwa ein vertauschtes Formelzeichen. Sie belegt jedoch nicht die Qualität für deutsche Verträge, Rechnungen, Frakturschrift oder medizinische Akten. Deshalb nennt diese Seite weder erfundene WER-Werte noch einen angeblich allgemeingültigen Prozentsatz.
Die ursprüngliche Arbeit veröffentlichte ein Skalierungs- und Kostenexperiment für ihren damaligen 2025er Stack. Das ist ein historischer, kontextgebundener Wert und kein heutiger Festpreis. GPU, Bildgröße, Retry-Rate, Modellversion und Providerpreise ändern sich. Für eine Beschaffung zählt der datierte Preis pro akzeptierter Seite einschließlich Fehlläufen, Übertragung, Speicherung und menschlicher Kontrolle.
Installation, lokale Stapel und Remote-Inferenz
python -m venv .venv
source .venv/bin/activate
pip install "olmocr[gpu]"
olmocr ./workspace --markdown --pdfs ./samples/report.pdf
olmocr ./workspace --markdown --workers 2 \
--max_page_retries 3 --pdfs ./incoming/*.pdf
pip install olmocr
olmocr ./workspace --server https://inference.example/v1 \
--api_key "$OLMOCR_API_KEY" \
--model allenai/olmOCR-2-7B-1025-FP8 \
--max_concurrent_requests 8 --markdown --pdfs ./incoming/*.pdfDie aktuellen Paketmetadaten verlangen Python 3.11 oder neuer. Das GPU-Extra pinnt eine konkrete Kombination aus Torch, Transformers und vLLM. Der offizielle README beschreibt das 7B-Klassenmodell als GPU-pflichtig. Dass generische Transformers Gewichte theoretisch in Arbeitsspeicher laden können, rechtfertigt kein Leistungsversprechen für einen unterstützten CPU-only-Produktionspfad. CUDA-Treiber, GPU, Container und Lockfile müssen gemeinsam getestet werden.
Lokale GPU-Inferenz kann Seiten nach dem kontrollierten Download der Gewichte in der genehmigten Umgebung halten. Ein OpenAI-kompatibler Remote-Server erhält dagegen gerenderte Seiten, nicht bloß Vektoren. TLS, Identität, Region, Request-Logs, Aufbewahrung, DPA, Modellalias und Parallelitätsgrenzen sind zu prüfen; API-Schlüssel gehören in einen Secret Manager. Das öffentliche Demo eignet sich nur für offene oder synthetische Beispiele, bis aktuelle Datenschutzbedingungen freigegeben sind.
| Bereitstellung | Geeignet für | Kontrollen | Hauptrisiko |
|---|---|---|---|
| Lokale Einzel-GPU | Vertraulicher Pilot, mittlere Queue | Version pinnen, Worker/VRAM begrenzen, Workspace verschlüsseln | CUDA-Kompatibilität und Single Point of Failure |
| Internes Multi-GPU | Große kontrollierte Stapel | Fortsetzbarer Workspace, Parallelkonfiguration, Seitenmanifest | Mehr Durchsatz vervielfacht auch stille Fehler |
| Eigener Remote-Server | Geteilte Inferenz im zugelassenen Netz | TLS, Service-Identität, Quoten, keine Body-Logs | Zentralisierte Exposition sensibler Dokumente |
| Drittanbieter-API | Schnelle Evaluation ohne eigene GPU | DPA, Region, Retention, Preis und Modellversion | Datenabfluss, variable Kosten und wechselnde Aliasse |
| AI2-Demo | Qualitativer Test mit öffentlichen Seiten | Keine vertraulichen Daten | Kein Ersatz für geprüfte Produktion oder SLA |
Ein ausführbarer Evaluations- und Abnahmeprozess
- Nach Fehlermodus sampeln. Digitale PDFs, Fotos, Schräglage, alte Scans, Kleinschrift, Spalten, Formeln, Tabellen, Handschrift, Sprachmischung, leere Seiten und Maximalgrößen aufnehmen.
- Seitenfakten definieren. Namen, Daten, Summen, Negationen, Zellbeziehungen, Formeln, Pflichtsätze, unerwünschte Kopf-/Fußzeilen und Reihenfolgen markieren.
- Mindestens zwei unabhängige Pfade ausführen. olmOCR mit nativer PDF-Extraktion, Tesseract oder einem anderen Parser vergleichen und Abweichungen zur Prüfung routen.
- Auslassung und Erfindung getrennt zählen. Ein falsches Minuszeichen oder ein erfundener Satz hat geringe Zeichendistanz, aber hohe fachliche Wirkung.
- Betrieb messen. Seitenlatenz, Retries, Fehlschläge, Peak-VRAM, Token und Kosten pro akzeptierter Seite erfassen.
- Manifest einfrieren. Input-Hash, Release, Checkpoint, Präzision, Runtime, Rendergröße, Retry-Parameter und Reviewentscheidung speichern.
- Klein beginnen. Erst nach Abnahme eines kleinen Batches skalieren; bei steigender Retry-Rate, fehlenden Seiten oder auffällig kurzem Output stoppen.
- Hochrisikofelder manuell verifizieren. Finanzzahlen, Pflichten, medizinische Angaben, Identität und Formeln niemals allein automatisch veröffentlichen.
git clone https://github.com/allenai/olmocr.git
cd olmocr
pip install -e ".[bench]"
playwright install chromium
huggingface-cli download --repo-type dataset allenai/olmOCR-bench \
--local-dir ./olmOCR-bench
python -m olmocr.bench.convert olmocr_pipeline --dir ./olmOCR-bench/bench_data
python -m olmocr.bench.benchmark --dir ./olmOCR-bench/bench_dataolmOCR-Bench ist ein gutes Regressionstor nach Upgrades. Die Tests prüfen unter anderem Vorhandensein und Abwesenheit von Text, natürliche Reihenfolge, Tabellenbeziehungen und renderbare Mathematik als binäre Fakten. Für den offiziellen Lauf werden die Bench-Abhängigkeiten und Playwright Chromium installiert. Der aktuelle README bestimmt den unterstützten Runner; danach werden die konvertierten Seiten bewertet.
Zusätzlich braucht jedes Team ein privates Holdout. Seiten, die zum Prompt- oder Parameter-Tuning dienten, dürfen nicht anschließend als unabhängiger Endtest ausgegeben werden. Fehler sollten nach Fakten, Struktur, Lesereihenfolge, Sprache, Scanqualität und Betrieb klassifiziert werden. Bei RAG ist zu testen, ob Chunks zur richtigen Seite zurückführen; bei Datenextraktion zählt der JSON- oder Zellenwert, nicht nur hübsches Markdown.
Tabellen, Formeln, Scans, Sprachen, Datenschutz und Halluzinationen
Tabellen und Formeln sind explizite Stärken von olmOCR-2, aber syntaktisch gültiges Markdown oder LaTeX ist keine semantische Garantie. Summen, Zeilen-/Spaltenzuordnung, verbundene Zellen, Hoch-/Tiefstellungen, Dezimaltrennzeichen, Minuszeichen, Einheiten und Variablen müssen gegen die Seite geprüft werden. Eine sauber aussehende Tabelle kann einen Wert still normalisiert haben.
Schlechte Scans besitzen eine Evidenzgrenze. Hochskalierung stellt verlorene Tinte nicht wieder her. Ein VLM kann aus sprachlichem Kontext ein glaubwürdiges Wort ergänzen; genau diese Flüssigkeit macht unmarkierte Unsicherheit riskant. Unlesbare Stellen sollten als unsicher erhalten bleiben. Leere, fast leere, duplizierte und beschädigte Seiten sowie anweisungsähnlicher Text im Dokument gehören in den Test.
Der offizielle Benchmark ist englisch. Multilinguale Verarbeitung ist möglich, doch veröffentlichte Evidenz belegt keine einheitliche Qualität für deutsche Fraktur, vertikale Schrift, RTL, seltene Zeichen oder gemischte Alphabete. Für jede Zielsprache und Layoutklasse ist ein eigener Test mit muttersprachlicher Kontrolle erforderlich. Aus einem englischen Leaderboard darf keine deutsche Genauigkeit abgeleitet werden.
„Lokal“ ist eine Architekturbehauptung, die Modellcache, S3-Workspace, Logs, Crash-Dumps, Backups und Monitoring einschließt. Aufbewahrung minimieren, Original und Ergebnis verschlüsseln, Rollenrechte setzen, Logs redigieren und Löschdatum festlegen. Ein Remote-Endpunkt erhält die vollständige Seitenevidenz und ist entsprechend der Dokumentensensibilität zu behandeln.
Ein parsbares YAML, ein normaler finish_reason oder ein erfolgreicher Retry beweisen nur technische Form. Längenanomalien, verbotene Phrasen, Seitenabdeckung, Cross-Engine-Differenzen und Regeln für kritische Felder können Probleme vorsortieren. Bei rechtlichen, medizinischen, finanziellen oder wissenschaftlichen Entscheidungen bleibt menschlicher Abgleich erforderlich.
Vergleich mit Marker, Docling, Tesseract und Cloud Document AI
| Option | Wann wählen | Ausgabestärke | Abwägung |
|---|---|---|---|
| olmOCR | Natürlich geordneter Text für LLM/RAG mit Formeln, Tabellen und schwierigem Layout | Sauberes Markdown/Text plus Dolma | GPU/VLM-Betrieb, generatives Fehlerrisiko, wenig Positionsstruktur |
| Marker | Viele Dateiformate, Bilder, strukturiertes JSON oder CPU/MPS-/Hybridmodi | Markdown, JSON, HTML, Chunks und Blöcke | Modi verhalten sich verschieden; Gewichts- und Code-Lizenz getrennt prüfen |
| Docling | Breites Dokumentframework und einheitliche strukturierte Repräsentation | Lossless JSON, Markdown/HTML, viele Integrationen | Größerer konfigurierbarer Stack; Qualität hängt von Pipeline/OCR/VLM ab |
| Tesseract | Deterministische Zeichen-OCR, Koordinaten, TSV/hOCR und viele Sprachpakete | Text und Positionsformate | Layout, Tabellen, Formeln und Lesereihenfolge brauchen Zusatzkomponenten |
| Cloud Document AI | Managed OCR, Formulare/KV, Klassifikation, Splitting und SLA | Strukturierte Document-Objekte und spezialisierte Prozessoren | Nutzungsgebühr, Datenprüfung, Vendor-Schema und Lock-in |
Redaktionelles Urteil: olmOCR ist am treffendsten ein Seitenrekonstrukteur für Sprachmodell-Workflows, kein pixelgenaues Archivtranskript. Wenn Koordinaten, deterministische Provenienz, Formularfelder oder Klassifikation zwingend sind, ist ein strukturierter Parser/OCR- oder Cloud-Prozessor die bessere Primärquelle; olmOCR kann als zweite Sicht dienen.
Eine robuste Produktion verwendet oft einen Router statt eines Universalmodells: saubere Digital-PDFs gehen durch native Extraktion, visuell schwierige Seiten zum VLM, kritische Felder und Konflikte zwischen beiden Pfaden zum Menschen. Das kontrolliert zugleich Rechenkosten und Halluzinationsrisiko.
Häufige Fragen
Ist olmOCR nur Tesseract plus Sprachmodell?
Nein. Tesseract erkennt Zeichenzeilen und kann Koordinaten liefern. olmOCR generiert aus der gesamten Seite natürlich geordneten Text, Tabellen und Formeln. Das erweitert Layoutverständnis, erzeugt aber ein anderes Fehlerrisiko.
Nutzt das aktuelle olmOCR-2 PDF-Ankertext?
Der neue Modellpfad auf main verwendet einen No-Anchoring-Prompt; die CLI nennt die Anchor-Länge für neue Modelle ungenutzt. Anchor-Code und pdftotext-Fallback bleiben erhalten und sind für unabhängige Kontrolle nützlich.
Kann olmOCR ohne Cloud laufen?
Ja, nach kontrolliertem Download auf einem kompatiblen lokalen NVIDIA-GPU/vLLM-System. Cache, Logs, Workspace und Backups gehören zur Prüfung. Der Remote-Server-Modus überträgt Seiteninhalte.
Erhält man Bounding Boxes?
Die primäre Ausgabe ist linearer Text mit Page-Spans, kein Wort-Koordinatengraph. Für Positionsprovenienz sind Tesseract, Marker JSON, Docling oder ein Document-AI-Dienst geeigneter.
Sind Tabellen und Formeln zuverlässig?
Sie sind ein Schwerpunkt, aber nicht garantiert. Summen, Zellbeziehungen, Vorzeichen, Variablen, Einheiten und verbundene Zellen müssen am Original geprüft werden.
Welche Sprachen werden unterstützt?
Das Modell kann mehrsprachige Seiten verarbeiten, aber der offizielle Benchmark ist englisch. Jede Zielsprache, Schriftart und Leserichtung braucht eine eigene Evaluation.
Wie viel VRAM ist nötig?
AI2 beschreibt ein 7B-Klassen-GPU-Modell und empfiehlt FP8 für praktische Inferenz, nennt aber keinen universellen Wert für alle Laufzeiten, Bildgrößen und Parallelitäten. Auf Zielhardware messen.
Darf ich vertrauliche Dateien in das Demo laden?
Nicht ohne aktuelle Freigabe von Datenschutz, Retention und Bedingungen. Bis dahin ausschließlich öffentliche oder synthetische Seiten verwenden; vertrauliche Daten lokal oder vertraglich abgesichert verarbeiten.
Geprüfte Quellen
- AI2 olmOCR repository and README
- Official release history
- olmOCR original paper
- olmOCR 2 paper: unit-test rewards
- olmOCR-2 model card and license
- olmOCR-Bench design and runner
- Official training guide
- Current page pipeline implementation
- Anchor-text implementation
- Python and GPU dependency metadata
- Apache-2.0 project license
- Marker official repository
- Docling official repository
- Tesseract official repository
- Google Cloud Document AI overview
Unabhängige technische Prüfung: 2026-08-20. Sichtbar neueste stabile Version: v0.4.27. Modellaliasse, Abhängigkeiten, API-Preise und Demo-Regeln ändern sich; vor Produktion gepinnte Quellen und privaten Testsatz erneut prüfen.
