Dokument-KI: Scans und PDFs für RAG maschinenlesbar machen
Bevor ein Sprachmodell über deine Dokumente Auskunft geben kann, muss aus dem Bild-PDF oder Scan zuerst sauberer, strukturierter Text werden – der Ingest-Schritt jeder RAG-Pipeline. Hier entscheidet sich mehr, als man denkt: Eine still eingefügte falsche Zahl vergiftet die ganze Wissensbasis. Dieser Artikel sortiert die Dokument-KI-Landschaft 2026: spezialisierte OCR-Modelle gegen Frontier-VLMs, strukturierte Ausgabe statt Rohtext, API gegen Self-Hosting – und den Sonderfall historischer und handgeschriebener Schriften, an dem die Allzweck-Modelle scheitern.
5 Min. Lesezeit
6 Abschnitte
10 Quellen
Das Problem: vom Scan zum zitierfähigen Text
Ein eingescanntes Buch, ein abfotografiertes Formular, ein PDF ohne Textebene – für ein Sprachmodell ist das zunächst nur ein Pixelraster. Damit es im Rahmen einer RAGRetrieval-Augmented Generation: dem Modell werden zur Anfrage passende Textstellen aus einer eigenen Wissensquelle beigelegt, damit es daraus antwortet statt nur aus dem Training. Reduziert Halluzinationen und hält Wissen aktuell.Mehr im Wissen →-Pipeline darüber Auskunft geben kann, muss der Inhalt erst maschinenlesbar werden: in Text, möglichst mit erhaltener Struktur (Tabellen, Überschriften, Lesereihenfolge) und mit einem Anker zurück zur Quellseite, damit Antworten zitierfähig bleiben.
Genau das ist die Aufgabe von OCR (Optical Character Recognition) – und sie hat sich 2026 stark gewandelt. Klassisches OCR lieferte rohen Fließtext, den man danach mühsam nachbereiten musste. Moderne Dokument-KI gibt eine strukturierte Repräsentation zurück und ist damit direkt als Vorstufe für Retrieval und Agenten gedacht. Der OCR-Schritt ist nicht mehr eine lästige Vorverarbeitung, sondern die Stelle, an der über die Qualität der gesamten Wissensbasis entschieden wird.
MerksatzOCR ist der Ingest-Schritt jeder RAG-Pipeline: Was hier falsch oder unstrukturiert ankommt, lässt sich später nicht mehr reparieren.
Spezialisierte OCR vs. Frontier-VLM – und die Zahlenfalle
Naheliegend wäre, einfach das stärkste multimodalEin Modell ist multimodal, wenn es mehr als nur Text verarbeitet – etwa Bilder, Audio oder Video als Eingabe versteht (manche erzeugen sie auch als Ausgabe).Mehr im Wissen → Sprachmodell die Seite „lesen“ zu lassen. Auf reinen OCR-Benchmarks gewinnen aber die spezialisierten Modelle: Auf OmniDocBench liegen dedizierte Systeme wie GLM-OCR (94,62) und PaddleOCR-VL vor allen Frontier-Modellen, während Gemini 3.1 Pro (90,33) und Claude Opus 4.6 (87,1) darunter rangieren (Werte aus Sekundär-Aggregatoren, also als Richtung zu lesen, nicht als Goldstandard).
Wichtiger als der Punktestand ist der Grund. Frontier-VLMs sind bei dichten Seiten halluzinationsanfällig – sie erfinden, vertauschen oder lassen Werte aus –, und ihre Bounding-Boxes (Positionsangaben „wo steht was“) sind unzuverlässig: Studien 2026 messen für Claude, GPT und Grok auf Koordinaten eine Zeichenfehlerrate über 0,5; die Boxen sehen plausibel aus, treffen aber nicht die echte Textposition. Für eine Faktenbasis ist das die gefährlichste Fehlerart: In einer Zahlentabelle ist eine still eingefügte, plausible falsche Ziffer Gift, weil sie durch jede oberflächliche Plausibilitätsprüfung schlüpft.
Spezialisierte OCR-Modelle sind dagegen auf wortgetreue Transkription trainiert, nicht auf „verstehen und neu formulieren“ – genau die Eigenschaft, die man beim Ingest will. Die in der Praxis empfohlene Pipeline ist deshalb hybrid: Das OCR-Modell transkribiert die Seite faithful in strukturierten Text, das Sprachmodell destilliert auf diesem Text. So liefert das Modell, das gut liest, die Zahlen, und das Modell, das gut versteht, die Auswertung – statt eines, das beim Lesen rät.
OmniDocBench (Aggregator)
GLM-OCR 94,62 · Gemini 3.1 Pro 90,33 · Opus 4.6 87,1
MerksatzNimm fürs reine Lesen das spezialisierte OCR-Modell, fürs Verstehen das Sprachmodell – ein Frontier-VLM, das beim Transkribieren halluziniert, vergiftet die Daten unbemerkt.
Der eigentliche Sprung moderner Dokument-KI ist nicht bessere Zeichenerkennung, sondern die strukturierte Ausgabe. Statt eines Fließtext-Bandes liefern aktuelle Modelle eine Repräsentation mit Bounding-Boxes (wo steht was), einer Block-Klassifikation (Titel, Tabelle, Formel, Signatur …) und Konfidenzwerten pro Seite und Wort – oft direkt als Markdown oder HTML mit erhaltener Tabellenstruktur.
Für eine Structured OutputFähigkeit eines Modells, die Antwort in einem festen, maschinenlesbaren Format (z. B. JSON nach Schema) zu liefern – wichtig, wenn Programme die Ausgabe weiterverarbeiten.Mehr im Wissen → heißt das praktisch: Tabellen bleiben Tabellen, mehrspaltige Seiten werden in der richtigen Lesereihenfolge serialisiert, und jeder Textblock trägt einen Positionsanker für zitierfähige Antworten. Genau das spart die fehleranfällige Nachbereitung, die rohen OCR-Text sonst erst RAG-tauglich machen muss. Der Mistral-OCR-4-Release vom Juni 2026 hat diese Idee – „Dokument-Verstehen statt bloßer Texterkennung“ – als Verkaufsargument in den Vordergrund gestellt; die Fähigkeit selbst ist aber Stand der Technik über mehrere Anbieter hinweg, nicht ein Alleinstellungsmerkmal.
MerksatzDer Mehrwert 2026 ist nicht „mehr Text richtig erkannt“, sondern Tabellen, Lesereihenfolge und Positionsanker als maschinenlesbare Struktur – das, was RAG ohne Nacharbeit verwerten kann.
API oder selbst hosten: Mistral OCR 4 gegen offene Modelle
Bei der Bezugsweise spaltet sich das Feld. Mistral OCR 4 ist als API günstig (4 $ pro 1 000 Seiten, 2 $ über die Batch-API) und bietet einen selbst gehosteten Einzel-Container für regulierte Branchen – allerdings ist dieser Container nicht open-weightModell, dessen trainierte Gewichte öffentlich herunterladbar sind, sodass man es selbst (lokal oder auf eigener Hardware) betreiben kann. Nicht zwingend vollständig quelloffen – die Lizenz bestimmt die erlaubte Nutzung.Mehr im Wissen →, sondern an ein Enterprise-Agreement gebunden. Wer Dokumente aus Compliance-Gründen ohnehin im eigenen Netz halten muss, kommt an den frei ladbaren Modellen kaum vorbei.
Unter den offenen Modellen lohnt der genaue Blick, denn der Benchmark-Spitzenreiter ist nicht für jeden Fall die beste Wahl. Auf dem unabhängig reproduzierten OlmOCRBench führen Infinity-Parser2-Pro (87,6) und Chandra-2 (85,9) – aber Infinity-Parser2 unterstützt primär Englisch und Chinesisch und bricht bei anderen Sprachen ein, und olmOCR-2 (8B, 82,3) ist englisch-only. Für mehrsprachige, tabellenlastige Dokumente ist Chandra-2 (90-Sprachen-Benchmark, gezielt auf Tabellen/Layout trainiert) meist der bessere Fit; als leichte Alternative laufen dots.ocr (3B, ~79) und DeepSeek-OCR-2 (3B, ~75) schon in wenig Speicher.
Hardware-seitig sind diese Modelle bescheiden: 3B-Modelle laufen in ~8–10 GB VRAM, ein 8–9B-VLM wie Chandra-2 passt mit QuantisierungVerfahren, das die Gewichte eines Modells mit weniger Bits speichert (z. B. 4 statt 16). Das senkt Speicher- und Hardwarebedarf deutlich, kostet aber etwas Genauigkeit – wichtig fürs lokale Betreiben.Mehr im Wissen → bequem in 16 GB – eine Consumer-GPU der 16-GB-Klasse genügt also für eine lokale, strukturierte OCR-Pipeline. Das ist der Punkt, an dem Self-HostingEin (meist open-weight) Modell auf eigener Hardware oder in der eigenen Cloud betreiben, statt die API eines Anbieters zu nutzen. Bringt Datenhoheit und Kostenkontrolle, erfordert aber eigene Infrastruktur.Mehr im Wissen → sich lohnt: ein dauerhafter, lokal bleibender Volltext-/Markdown-Layer über den eigenen Korpus, ohne urheberrechtlich geschütztes Material in eine Cloud-API zu geben.
Mistral OCR 4 (API / Batch)
4 $ / 2 $ pro 1 000 Seiten · Self-Host-Container nur Enterprise (kein open-weight)
MerksatzMistrals Self-Host-Container ist Enterprise-gated; für „lokal und mehrsprachig“ ist ein offenes Modell wie Chandra-2 auf einer 16-GB-GPU der pragmatische Weg.
Sonderfall: handgeschriebene und historische Schriften
Eine harte Grenze ziehen alle bisher genannten Modelle bei historischer Handschrift. Altdeutsche Kurrent- und Sütterlin-Schriften verbinden Buchstaben über lange durchgezogene Striche, haben uneindeutige Wortabstände und Schnörkel, die als Buchstabenteile fehlgedeutet werden. Allzweck-OCR und LLM-Vision – auch die spezialisierten Dokument-Modelle – liegen darauf unter 50 % Genauigkeit; sie sind schlicht nicht auf diese Schriften trainiert.
Dafür braucht es spezialisierte HTR (Handwritten Text Recognition). Transkribus erreicht mit dedizierten Kurrent-/Sütterlin-Modellen auf sauberen Vorlagen 95–99 % Zeichengenauigkeit (bei schwierigen Händen eher 70–85 %) und erlaubt, ein eigenes Modell schon ab rund 50 transkribierten Seiten auf eine konkrete Handschrift nachzutrainieren. Das Standard-Transkribus ist allerdings cloud-basiert – für lokal bleibende Daten ist der offene Stack eScriptorium mit der Kraken- (oder PyLaia-) Engine die Wahl: self-hostbar, offline, GPU-beschleunigt, mit öffentlichen Modellen für deutsche Schriften des 17.–20. Jahrhunderts.
Sauber gedruckte Fraktur (altdeutscher Blockdruck, keine Handschrift) ist ein einfacherer, separater Fall: Hier genügen Fraktur-spezialisierte OCR-Modelle wie Tesseract mit dem `frak2021`-Modell oder die Fraktur-Modelle in Transkribus/ABBYY, die mit den typischen Ligaturen (langes ſ, ch-/tz-Verbünde) umgehen können.
MerksatzFür handgeschriebenes Altdeutsch (Kurrent/Sütterlin) führt kein Weg an spezialisierter HTR vorbei – lokal über eScriptorium + Kraken; gedruckte Fraktur ist der einfachere Fall.
Die Wahl folgt dem Material, nicht dem Benchmark-Sieger. Für moderne, gedruckte Dokumente (die häufigsten Bild-PDFs) ist ein spezialisiertes OCR-Modell richtig – mehrsprachig und tabellenlastig Chandra-2, schlank und schnell dots.ocr; als günstige strukturbewusste API mit Self-Host-Option Mistral OCR 4. Reiner, sauberer Fließtext lässt sich auch direkt von einem Frontier-VLM lesen, weil es sich bei Prosa selbst korrigiert – aber sobald Zahlen, Tabellen oder Formeln dicht werden, gehört die Transkription an ein dediziertes OCR-Modell.
Über allem steht die Aufgabentrennung: Transkription und Verständnis sind zwei verschiedene Jobs. Lass das OCR-/HTR-Modell faithful in strukturierten Text überführen und ein starkes Sprachmodell darauf die eigentliche Auswertung, Zusammenfassung und Verschlagwortung machen. Und behandle alle Benchmark-Zahlen in diesem schnelllebigen Feld als Richtung, nicht als Urteil – viele Spitzenwerte stammen aus Anbieter-eigenen Studien und sind auf unabhängigen, reproduzierten Leaderboards zu prüfen.
Moderner Druck
Chandra-2 / dots.ocr / Mistral OCR 4
Reiner Fließtext
Frontier-VLM direkt okay – nicht bei Zahlen/Tabellen
Kurrent/Sütterlin · Fraktur-Druck
eScriptorium+Kraken · Tesseract frak2021
MerksatzSuch das Werkzeug nach dem Material aus, trenne Transkription von Verständnis – und lies Anbieter-Benchmarks als Richtung, nicht als Beweis.