OCR am Scheideweg: Zwei Wege, ein hundertseitiges Dokument in einem Durchlauf zu lesen
Du bist Data Engineer in einer Unternehmensberatung. Auf deinem Tisch liegt ein 200-seitiger gescannter Branchenreport — gespickt mit Tabellen, Diagrammen, mehrspaltigem Layout und dutzenden Seiten handschriftlicher Anmerkungen. Die Aufgabe ist klar: Diesen Report in strukturierte Daten umwandeln und in die Analyse-Pipeline einspeisen.
Was hättest du vor ein paar Jahren getan? Ein Skript geschrieben, das PDF in 200 Bilder zerlegt, jedes Bild einzeln durch eine OCR-Engine gejagt und dann 200 Textfragmente wieder zusammengeklebt — wobei du mit hoher Wahrscheinlichkeit die Spaltenüberschriften seitenübergreifender Tabellen verloren, die Lesereihenfolge bei mehrspaltigem Layout durcheinandergebracht und Sätze an den Seitengrenzen abgeschnitten hättest.
Am 23. Juni 2026 erschienen zwei Beiträge gleichzeitig auf der Hacker-News-Startseite: Baidus Open-Source-Projekt Unlimited OCR (428 Punkte) und Mistrals OCR 4 (420 Punkte). Zwei Ereignisse am selben Tag, die auf dasselbe Signal hindeuten: Die Ära der OCR für Langdokumente ist angebrochen. Aber wie sie anbricht — darauf geben die beiden völlig unterschiedliche Antworten.
Ein altes Problem: Warum ist Langdokument-OCR so schwer?
OCR an sich ist kein neues Problem. Tesseract gibt es seit vierzig Jahren, und die Dokumenterkennungs-APIs der Cloud-Anbieter sind seit vielen Jahren im Einsatz. Doch an Langdokumenten scheitern all diese Lösungen an derselben Wand: der KV-Cache-Explosion.
Die Grundidee von OCR mit großen Sprachmodellen: Das Dokumentbild wird in eine Sequenz visueller Tokens kodiert, und das LLM „liest” Token für Token den Text heraus. Für jedes generierte Token muss das Modell auf die Zustände aller vorherigen Tokens zurückgreifen — gespeichert im sogenannten KV-Cache. Je länger das Dokument, desto mehr generierte Inhalte, und der KV-Cache wächst linear O(N), bis der Videospeicher kollabiert.
Die Standardantwort der Industrie auf dieses Problem ist das eingangs erwähnte „Zerschneiden und Zusammenkleben” — das Langdokument wird in Einzelseiten zerlegt, Seite für Seite verarbeitet, mit einem externen Scheduler als Klebstoff. Der HN-Nutzer robotswantdata bringt es in der Unlimited-OCR-Diskussion präzise auf den Punkt: „Entwickler sind gezwungen, dreckigen Code zu schreiben, der PDFs in Einzelseiten zerhackt, sie einzeln verarbeitet und den Text wieder zusammenklebt (janky code that chops PDFs into individual pages, processes them one by one, and glues the text back together).”
Es funktioniert, aber es ist kein echtes Langdokument-Verständnis. Seitenübergreifender Kontext geht verloren, Tabellen werden zerstückelt, die Lesereihenfolge gerät durcheinander — das sind die Kosten der „Engineering-Patches”.
Der Baidu-Weg: Den KV-Cache mit R-SWA auf eine Konstante drücken
Die Kerninnovation von Baidus Unlimited OCR heißt Reference Sliding Window Attention (R-SWA) — ein Aufmerksamkeitsmechanismus, der den KV-Cache von O(N) auf O(1) reduziert.
Keine Formeln, sondern Intuition.
Stell dir vor, du schreibst ein Buch ab. Du siehst auf die Vorlage (Reference) und schreibst gleichzeitig den Text (Generation). Du musst nicht jedes Mal, wenn du ein Wort schreibst, alles bisher Geschriebene erneut lesen — du brauchst nur gelegentlich einen Blick auf die letzten paar Zeilen, um sicherzustellen, dass du nicht in der Zeile verrutscht bist. Die Vorlage bleibt dir stets vor Augen, sie verschwimmt nicht, sie verschwindet nicht.
Genau das tut R-SWA. Es teilt den Aufmerksamkeitspfad in zwei Wege:
- Global-Reference-Pfad: Jedes generierte Token beachtet stets alle visuellen Tokens (das Dokumentbild) und den Prompt — die Vorlage bleibt immer scharf, seitenübergreifender Kontext geht nicht verloren.
- Local-Generation-Pfad: Jedes generierte Token beachtet nur die letzten 128 bereits generierten Tokens — das Kurzzeitgedächtnis braucht nur ein gleitendes Fenster, alte Token-Zustände können gefahrlos vergessen werden.
Der entscheidende Entwurf: Visuelle Tokens nehmen nicht an der „Zustandsaktualisierung” teil. Sie werden nur gelesen, nicht verändert. Damit wird ein klassischer Schwachpunkt der Sliding-Window-Attention umgangen: dass visuelle Merkmale mit der Zustandsaktualisierung allmählich „verschwimmen” und die Erkennungsgenauigkeit sinkt.
Das Ergebnis: Der KV-Cache bleibt während des gesamten Dekodierungsprozesses konstant. Eine 40-seitige PDF wird dem Modell vorgelegt, einmalige Inferenz, alles gelesen — kein Zerschneiden, kein externer Scheduler, kein „dreckiger Code zum Zusammenkleben von Seitenzahlen”.
Technisch im Detail: Unlimited OCR nutzt DeepSeek OCR als Baseline, behält dessen DeepEncoder mit 16-facher Kompressionsrate bei, ersetzt aber alle Aufmerksamkeitsschichten im Decoder-LLM durch R-SWA. Das Modell hat 3B Parameter, aktiviert bei der Inferenz nur 500M (MoE-Architektur) und erreicht im OmniDocBench v1.5 einen Gesamtscore von 93 % — 6 Prozentpunkte über der DeepSeek-OCR-Baseline.
Das Paper liegt auf arXiv, der Code auf GitHub (MIT-Lizenz), die Modellgewichte auf HuggingFace und ModelScope. Der klassische akademische Weg: Paper veröffentlichen, Code open-sourcen, Gewichte freigeben, die Community erweitern lassen.
Der Mistral-Weg: Dokument-Intelligenz durch produktreife Lösungen definieren
Mistral veröffentlichte am selben Tag OCR 4, ein Jahr nach dem letzten OCR-Produktupdate.
Das Verkaufsargument von OCR 4 ist die vollständige Engineering-Delivery. Es hebt OCR von „Text extrahieren” auf „Dokumentstruktur verstehen”: Die Ausgabe ist nicht nur Text, sondern umfasst Bounding Boxes (Position jedes Textblocks auf der Seite), Blockklassifikation (Überschrift, Tabelle, Formel, Unterschriftenbereich mit Klassifikationslabel) und Inline Confidence Scores (Konfidenzwerte pro Zeichen oder Wort).
Unterstützt werden 170 Sprachen und 10 Sprachfamilien. Self-Hosting-Deployment in einem einzelnen Container. 85,20 Punkte im OlmOCRBench, durchschnittliche Gewinnrate von 72 % in menschlichen Präferenztests.
Aus Mistrals Positionierung heraus betrachtet, ist OCR 4 eine „Ingestion-Komponente” seiner Document-Intelligence-Pipeline — im Zusammenspiel mit dem Search Toolkit für Unternehmenssuche, RAG und domänenspezifische Retrieval. Bounding Boxes ermöglichen das Hervorheben von Suchergebnissen im Originaldokument; Konfidenzwerte steuern den menschlichen Überprüfungs-Workflow; die strukturierte Blockausgabe macht nachgelagerte Datenpipelines zuverlässiger.
Closed Source, kommerzielle API, volumenbasierte Abrechnung — der klassische Weg eines Produktunternehmens.
Der HN-Kommentarbereich driftet ab: Sind handschriftliche Adressen das wahre OCR-Wunder?
Im HN-Kommentarbereich zu Mistral OCR 4 vollzog sich eine bemerkenswerte Wendung. Der Kommentar mit den meisten Upvotes stammt von ericyd:
„Ich hielt den US-Postdienst immer für ein technisches Wunder. Sie können Milliarden von Sendungen erkennen und zustellen, obwohl Adressen extrem uneinheitlich geschrieben sind — ein und dieselbe Adresse kann in mehreren verschiedenen Formen auftauchen …”
Daraufhin erzählt idoubtit eine noch extremere Geschichte: Sein Vater erhielt in den 70ern einen Brief aus Algerien, auf dem Umschlag nur drei Wörter — sein Name, der Stadtname „Créteil” und „France”. Ohne Internet, ohne zentrale Datenbank hat das Postsystem den Brief zugestellt.
Aus meiner Sicht liegt eine subtile Spannung zwischen diesen Geschichten und der Veröffentlichung von Mistral OCR 4. Sie erinnern die Praktiker daran: Das ultimative Ziel von OCR sind die extrem unstandardisierten, extrem kontextabhängigen Erkennungsaufgaben der realen Welt. Die Zustellung handschriftlicher Adressen könnte die früheste Form von „Langdokument-OCR” sein — nur dass das „Dokument” ein Briefumschlag ist und das „Modell” das kollektive Gedächtnis der Postboten über ihr Viertel.
Zwei Wege, eine Gabelung: Dimensionen der Wahl
Aus meiner Sicht repräsentieren Baidus Unlimited OCR und Mistrals OCR 4 zwei unterschiedliche Lieferphilosophien auf derselben Strecke.
Wer den Baidu-Weg wählt, bekommt: ein lesbares Paper, eine modifizierbare Codebasis, einen universellen Aufmerksamkeitsmechanismus, der auf andere Aufgaben übertragbar ist (das Paper nennt ASR und Übersetzung). Der Preis: selbst deployen, selbst die Parameter tunen, selbst die Engineering-Probleme lösen. Geeignet für Teams mit Engineering-Kapazität, akademische Forschung oder Szenarien, die eigenes Finetuning erfordern.
Wer den Mistral-Weg wählt, bekommt: einen API-Endpunkt, strukturierte JSON-Ausgabe, eine sofort einsatzbereite Document-Intelligence-Pipeline. Der Preis: keine Einsicht in die Modellgewichte, keine Änderung der internen Logik, Abrechnung pro Token. Geeignet für Enterprise-Deployment, schnelle Integration, Produktionsszenarien, die Bounding Boxes und Konfidenzwerte benötigen.
Die beiden schließen sich nicht gegenseitig aus. Dieselbe Dokumentenpipeline eines Unternehmens könnte beide Ansätze gleichzeitig nutzen: Unlimited OCRs Ansatz zur Optimierung der Langdokument-Verarbeitungseffizienz und OCR 4s strukturierte Ausgabe für nachgelagerte Lokalisierung und Retrieval.
Der wahre Wendepunkt: Von „lesbar” zu „in einem Durchlauf lesbar”
Ganz gleich, welchen Weg man wählt — der 23. Juni 2026 verdient es, erinnert zu werden. Nicht weil zwei Produkte gleichzeitig auf der HN-Startseite auftauchten — das ist nur die Oberfläche. Sondern weil die OCR-Domäne offiziell eine Linie überschritten hat: von „gerade noch brauchbar” zu „Zero-Shot-Langdokument-Parsing”.
Vor einem Jahr war die Vorstellung, ein Modell 40 Seiten gescanntes Dokument in einem Durchlauf lesen zu lassen, noch Fantasie. Heute ist sie der gemeinsame Ausgangspunkt zweier unterschiedlicher technischer Ansätze. R-SWA hat bewiesen, dass mathematische Innovation im Aufmerksamkeitsmechanismus neue Möglichkeitsräume öffnen kann; OCR 4 hat bewiesen, dass strukturierte Ausgabe mit solidem Engineering OCR in echte Produktionspipelines integrieren kann.
Für den Ingenieur mit dem 200-seitigen Bericht lautet die Antwort nicht mehr: „Schreib eine For-Schleife zum Zerschneiden und Zusammenkleben.” Ob er die Open-Source-R-SWA-Lösung nimmt oder die Mistral-API aufruft — das ist eine andere Geschichte.