Unlimited OCR — Baidus One-Shot-Modell zum Parsen langer Dokumente
(github.com/baidu)- Ein E2E-OCR-Modell auf Basis von DeepSeek OCR, das sämtliche Attention im Decoder ersetzt und Dokumente mit mehreren Dutzend Seiten in einem einzigen Forward Pass transkribiert
- Der Kern ist Reference Sliding Window Attention (R-SWA), die den KV-Cache konstant hält, selbst wenn die Decoding-Länge wächst, und so steigende Speicher- und Rechenkosten verhindert
- Das Verfahren ahmt das Arbeitsgedächtnis (working memory) von Menschen nach, die beim Abschreiben weit entfernte Ausgaben allmählich vergessen und nur auf den benachbarten Kontext Bezug nehmen
- Auf OmniDocBench v1.5 erreicht das Modell 93 % und liegt damit 6 % vor DeepSeek OCR; auf v1.6 erzielt es mit 93,92 % eine end-to-end-SOTA
- R-SWA ist über OCR hinaus ein allgemeiner Parsing-Attention-Mechanismus, der auch für referenzbasierte Langtext-Aufgaben wie ASR und Übersetzung geeignet ist
Hintergrund und Problemdefinition
- Menschen können lange Aufgaben wie die Transkription von Hunderten Seiten oder die Übersetzung mehrstündiger Sprache ohne Effizienzverlust bewältigen, bestehende OCR-Modelle können jedoch nicht einmal 10 Seiten in einem einzelnen Forward Pass parsen
- Aktuelle Modelle arbeiten seitenweise per for-loop und initialisieren den Speicher in jedem Schritt neu
- Dieser Ansatz ist nur ein Engineering-Workaround, der einen konsistenten Langkontext-Prozess in isolierte Kurzzeitaufgaben zerlegt, statt einen Fortschritt in Richtung AGI-orientierter Intelligenz darzustellen
- Nutzt man ein LLM als Decoder, verbessert sich die Leistung durch die Ausnutzung der Vorverteilung von Sprache, doch mit wachsender Ausgabelänge erhöht der akkumulierte KV-Cache den Speicherverbrauch und verlangsamt die Generierung schrittweise
- Menschliches Transkriptionsverhalten entspricht weder standardmäßiger Full Attention noch Linear Attention
- Bereits geschriebener Text wird nicht komplett erneut überflogen; stattdessen wird nur benachbarter Kontext referenziert, um die Richtung beizubehalten
- Visuelle/Referenz-Tokens unterliegen keiner rekursiven Zustandsaktualisierung — bei Aktualisierung würden visuelle Merkmale nach und nach verschwimmen und die Erkennungsgenauigkeit sinken
Reference Sliding Window Attention (R-SWA)
- Jedes Token kann auf alle Referenz-Tokens (visuelle Tokens + Prompt) zugreifen, während die Output-Attention nur auf die letzten n Tokens beschränkt wird (Standardwert 128)
- So kann jedes Token das gesamte Bild wahrnehmen und innerhalb eines kausalen Sliding Windows den OCR-Fortschritt durch Zustandsübergänge selbstständig verfolgen
- Während der Inferenz bleibt der KV-Cache konstant, was den Speicherdruck reduziert und Rechenkosten senkt
- Die Attention wird auf ein zweiteiliges Fenster der Größe m+n beschränkt
- m ist das Prefix-Fenster, das visuelle Tokens und den Prompt umfasst; es bleibt während einer einzelnen Inferenz fest und hängt nur von Seitenzahl und Auflösung ab, nicht von der Decoding-Länge
- n ist das Fenster des Decode-Bereichs, das bei fester Größe kausal mitslidet
-
Verwaltung des KV-Caches
- Die DeepSeek-OCR-Baseline verwendet standardmäßiges MHA, wodurch die Größe des KV-Caches unbegrenzt auf Lm + T anwächst
- R-SWA behält zwar den vollständigen Prefix-Cache Lm bei, speichert von den generierten Tokens aber nur die letzten n; dadurch ergibt sich eine Cache-Größe von Lm + min(n,T) ≤ Lm + n als konstante Obergrenze
- Bei ausreichend großer Ausgabelänge konvergiert das Cache-Verhältnis ρ(T) gegen 0 → lineares Wachstum wird auf eine Konstante reduziert
-
Kernel-Analyse
- Messungen mit dem Flash-Attention-v3-Kernel zeigen: Bei standardmäßigem MHA in DeepSeek OCR steigt die Latenz mit jedem Decoding-Schritt, während Unlimited OCR dank R-SWA eine konstante Laufzeit beibehält
- Bei DeepSeek OCR treten Spikes auf, wenn die Länge des KV-Caches bestimmte Ausrichtungsgrenzen überschreitet und die Datentransfereffizienz stark sinkt; bei R-SWA passiert das nicht
- Auch der GPU-Speicher steigt beim Originalmodell während der Inferenz linear an, während Unlimited OCR konstant bleibt — diese gleichzeitige Stabilität bei Rechenaufwand und Speicher ermöglicht das Parsen langer Dokumente
Modellarchitektur
- Basierend auf DeepSeek OCR werden DeepEncoder und ein MoE-Decoder kombiniert (insgesamt 3B, davon 500M aktive Parameter)
- Das bisherige MHA wird durch R-SWA ersetzt; zum Referenz-KV-Cache m kommt ein Ausgabe-KV-Puffer mit fixer Kapazität n hinzu, um Langdokument-Parsing zu ermöglichen
- Der KV-Cache ist als Queue mit Kapazität m+n implementiert; bei jedem neu generierten Token wird der KV des (m+1)-ten Tokens verdrängt, sodass Kosten und Speicher nicht anwachsen
-
DeepEncoder
- SAM-ViT und CLIP-ViT werden kaskadiert, mit 16-facher Token-Kompression in der Bridge — der vordere Teil verarbeitet Originalbild-Tokens mit Window Attention, Global Attention ist nur für komprimierte Tokens vorgesehen
- Beim Kodieren hochauflösender Bilder bleiben die Aktivierungen niedrig, um GPU-Speicher zu sparen; ein 1024×1024-PDF-Bild wird auf nur 256 Tokens komprimiert
- Es gibt zwei Modi: Base für mehrere Seiten (1024×1024) und Gundam für einzelne Seiten (dynamische Auflösung)
- Visuelle Tokens werden einmal kodiert und bleiben während des gesamten Ablaufs statisch; sie durchlaufen keine Zustandsübergänge zusammen mit der Ausgabe
Trainings-Setup
- Training mit rund 2 Millionen OCR-Datensätzen für Dokumente, Verhältnis Einzelseite zu Mehrseite 9:1
- Einzelseitige PDFs werden mit Paddle OCR annotiert; Ground Truth entsteht durch das Verbinden von Blockkoordinaten und Inhalt, die Koordinaten werden auf den Bereich 0–1000 normalisiert
- Mehrseitige Daten werden durch Verkettung einzelner Seiten synthetisiert; etwa 200.000 Samples (2 bis 50 Seiten) verwenden den Trenner
<page>und werden in Sequenzen von insgesamt 32K Tokens gepackt
- Vom DeepSeek-OCR-Checkpoint aus wird 4.000 Schritte weitertrainiert, mit globaler Batch-Größe 256, maximaler Sequenzlänge 32K und 8×16 A800 GPUs
- Während des Trainings wird der DeepEncoder eingefroren und nur die LLM-Parameter werden trainiert
- Eingesetzt werden der AdamW-Optimierer, ein Cosine-Annealing-Scheduler, eine initiale Lernrate von 1e-4, DeepEP (EP=4) sowie das Framework Megatron-LM
- Für die Inferenz wird die KV-Cache-Verwaltung für R-SWA in der Transformers-Bibliothek implementiert, und die SGLang-Engine erhält Optimierungsunterstützung — beide Frameworks arbeiten mit konstanten TPS und konstantem GPU-Speicher
Evaluationsergebnisse
- Der Hauptbenchmark ist OmniDocBench (v1.5/v1.6), der multidimensionale Parsing-Fähigkeiten wie Text, Formeln, Tabellenstruktur und Lesereihenfolge bewertet
- v1.6 ist die neueste Version und enthält 296 zusätzliche Testbilder gegenüber v1.5; v1.5 bietet Vergleiche mit klassischen Modellen einschließlich DeepSeek OCR
- Für die Bewertung von Langdokument-OCR wurde ein eigener Testsatz erstellt, der Romane, Dokumente und Papers in 2/5/10/20/40+ Seiten unterteilt (je Kategorie mindestens 10 Bücher)
-
Zentrale Leistung
- Mit nur zusätzlichen 2M Trainingsdaten wird end-to-end SOTA erreicht; in v1.5 sinkt die Text-Edit-Distance um 0,035, und Tabellen-TEDS verbessert sich um 5,96 %
- Der Gesamtwert von v1.6 liegt bei 93,92 % und markiert end-to-end SOTA — selbst der vollständige Ersatz der Standard-Attention durch R-SWA mit Breite 128 ist effektiv und verlustfrei
- Mit 0,5B aktiven MoE-Parametern ist die Inferenz hocheffizient; im Base-Modus werden 5580 TPS erreicht (12,7 % schneller als DeepSeek OCR mit 4951 TPS)
-
Analyse der Unterkategorien
- Gegenüber DeepSeek OCR zeigen sich in allen Metriken konsistente Verbesserungen, auf dem Niveau eines „free lunch“
- Gegenüber DeepSeek OCR 2 liegt das Modell bei Text-Edit-Distance und Lesereihenfolge in 7 von 9 Fällen vorne
- Auch bei komplexen Layouts wie PPT, Zeitungen, Magazinen und Notizen gibt es keine Nachteile
-
Langdokument-Parsing
- Mit R-SWA können Dutzende bis Hunderte Seiten in einem einzigen Pass prefilling-seitig verarbeitet und vom Anfang bis zum Ende fortlaufend geparst werden; dank festem KV-Cache bleibt die Ausgabelatenz konstant
- Auch bei gleichzeitiger Eingabe von 20 Seiten liefert das Modell robuste Ergebnisse; bei 40+ Seiten bleiben Edit Distance unter 0,11 und Distinct-35 bei 97 % erhalten
- Wiederholungsfehler liegen an der erschwerten Erkennung kleiner Schrift im Mehrseitenmodus Base (1024×1024), nicht an einem Orientierungsverlust durch R-SWA
Effizienzanalyse
- Vergleich der Ausgabe-TPS unter idealen Parallelitätsbedingungen (Prefill-Länge fix auf 10)
- Bei 256 Tokens ist die Inferenzgeschwindigkeit beider Modelle nahezu identisch
- Mit wachsender Ausgabelänge sinken die TPS von DeepSeek OCR kontinuierlich; bei 6.000 Tokens liegt es 35 % hinter Unlimited OCR
- Das bestätigt erneut, dass eine konsistente Generierungsgeschwindigkeit eine Kernanforderung für OCR-Aufgaben mit langen Dokumenten ist
Grenzen und künftige Aufgaben
- Bei endlicher Kontextlänge (z. B. 32K) ist echtes unbegrenztes Parsing wegen der Begrenzung der Prefill-Länge nicht möglich — trotz der hohen Kompressionsrate des DeepEncoder wird der Prefill mit zunehmender Seitenzahl länger
- Kurzfristig ist geplant, Modelle mit längerer Kontextlänge wie 128K zu trainieren, um mehr Seiten beim Prefill zu unterstützen
- Langfristig soll ein Prefill Pool aufgebaut werden, damit das Modell lernt, Prefill-KV-Chunks automatisch zu fetch-en und so den Effekt des Umblätterns durch Menschen zu imitieren, mit dem Ziel eines wirklich unbegrenzten OCR
- R-SWA soll auf referenzbasierte Aufgaben wie ASR und Übersetzung übertragen werden
- Das Modell ist auf Hugging Face und ModelScope verfügbar, das Paper ist auf arXiv veröffentlicht
1 Kommentare
Hacker-News-Kommentare
Ziemlich interessant. So wie ich es verstehe, haben die Forschenden wohl einen Architektur-Hack gefunden, der verhindert, dass eine KI beim Lesen langer Dokumente immer weiter Speicher ansammelt.
Normalerweise versucht eine KI beim Transkribieren eines 100-seitigen PDFs, sich an alle bereits gelesenen Wörter zu erinnern, und dieser Kurzzeitspeicher, der KV-Cache, wächst linear mit O(N), bis der VRAM ausgeht oder man an Grenzen stößt. Deshalb bauen Entwickler oft holprigen Code, der ein PDF seitenweise zerlegt, verarbeitet und danach wieder zusammensetzt.
Unlimited OCR teilt den Fokus mit Reference Sliding Window Attention (R-SWA) in zwei Pfade auf. Einer ist eine globale Referenz, die das Originalbild des Dokuments vollständig betrachtet, der andere eine lokale Generierung, die den vom Modell selbst erzeugten Textspeicher auf ein enges gleitendes Fenster wie die letzten 128 Wörter begrenzt. Für lokale KI dürfte das ziemlich spannend sein, und ich bin gespannt, was die Community daraus macht und wie sie es erweitert.
Sehr feine Details wie etwa, was jemand heute Morgen gegessen hat, können im Moment nützlich sein, haben langfristig aber abgesehen von allgemeinen Tendenzen kaum Bedeutung. Um ein Gespräch zu rekonstruieren, muss man ein gutes Gleichgewicht finden, ohne alles Heranzuziehen, was bisher besprochen wurde; deshalb scheint dieser Ansatz eine nähere Betrachtung wert zu sein.
Ich habe mir vor Kurzem ein Tablet für Noten gekauft, hauptsächlich als Ersatz für den gebündelten Jazz Real Book bei Jam-Sessions. Mit der Handykamera gescannte Seiten sind halbwegs okay, aber die Größe ist fest und sie haben viele Artefakte.
Es wäre schön, spontan für Bb- oder Eb-Instrumente transponieren zu können, aber weil es Scans sind, ist das natürlich unmöglich. Als ich mir den Stand der optischen Notenerkennung angesehen habe, kam ich zu dem Schluss, dass Musik aus AI-Sicht fast noch Neuland ist. Optische Notenerkennung ist ziemlich miserabel, und auch das Verständnis von AI für Musiktheorie ist im Bereich tatsächlicher Notenbilder miserabel. LLMs sind bei textlichen Erklärungen von theoretischen Konzepten, die wohl als Online-Text im Training vorkamen, einigermaßen brauchbar.
Das Problem scheint zu sein, dass es noch an einem digitalen Format fehlt, das die Punkte auf Papier, die Musiker lesen, sauber kodiert. Notenschrift ist ziemlich reichhaltig. MIDI wurde primär dafür geschaffen, die für Wiedergabe oder Performance nötigen Aspekte abzubilden, und enthält daher nicht alles, was für symbolisches Verständnis nötig ist. MusicXML scheint dem digitalen Format, das die von Musikern gewünschten Informationen enthält, am nächsten zu kommen, aber es fehlt an guten Trainingskorpora, die MusicXML-Repräsentationen mit Notenbildern oder Audio verknüpfen. Vermutlich liegt das daran, dass MusicXML allein nicht genug Informationen für den Notensatz enthält.
Werkzeuge wie MuseScore müssen viele Layout-Informationen nachverfolgen, die sich nicht in MusicXML ausdrücken lassen. Das LilyPond-Format ist weniger wortreich als MusicXML und enthält etwas mehr für Notensetzer nützliche Informationen, aber die meisten erstellen Noten nicht in LilyPond. Nebenbei finde ich LilyPond wegen des Zustands seiner Jazz-Schriften enttäuschend. Ich mag es nicht, im Jazz-Kontext „klassisch“ aussehende Noten zu sehen. Jedes Mal, wenn ich bei OCR eine ziemlich gut aussehende inkrementelle Verbesserung sehe, muss ich an den katastrophalen Zustand von OMR denken.
verovio kann in SVG setzen und dabei möglichst viele Informationen der ursprünglichen MEI-Partitur bewahren, sodass sich genug Metadaten extrahieren lassen, um echte Detektionsdatensätze für Deep-Learning-Modelle zu erstellen. Es gibt auch ein grob zusammengehacktes Skript, das aus einem mit verovio gesetzten Notensatz-Set einen COCO-Datensatz erzeugt: https://github.com/kwon-young/music/blob/main/svg2pl.py
Der dabei erstellte synthetische Notendatensatz wurde ebenfalls veröffentlicht: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... Wer darauf einen Detektor trainieren möchte, ist willkommen. OMR wird wohl deshalb so vernachlässigt, weil die meisten den Schwierigkeitsgrad dieser Aufgabe massiv unterschätzen. Es ist eine spezialisierte Aufgabe mit extrem vielfältigen Formen und einer sehr komplexen grafischen Grammatik.
Dabei wird schmerzhaft deutlich, dass Musik in keinem AI-Trainingsdatensatz je als wichtiger Bestandteil betrachtet wurde. Dass Opus 4.8 Musiktheorie heute ziemlich erstaunlich gut versteht und erklären kann, ist beeindruckend, aber wenn man es bittet, Noten zu transkribieren oder OCR/OMR zu machen, produziert es selbstbewusst MusicXML-/LilyPond-Versionen von „2 + 2 = Pferd“. Ich hoffe, dass auch dieses vernachlässigte Feld von der wachsenden AI-Welle erfasst wird, aber bisher ist es geradezu unfair unterbewertet.
Natürlich liefert sie nicht alle zusätzlichen Informationen, die man für Notensatz oder eine vollständige Musikrepräsentation braucht, aber es gibt Forschungsdatensätze wie https://github.com/smashub/choco. Für Analysearbeiten habe ich auch den Datensatz https://github.com/MarkGotham/When-in-Rome verwendet, aber auch der entspricht nicht zu 100 % dem, wonach ich suche. Für den Einsatz auf dem Tablet als Ersatz für Jazz-Standards und zum Transponieren könnte dir die App „iReal Pro“ gefallen. Für diesen Anwendungsfall ist sie deutlich besser als Kamerascans.
Dass dort steht „Dank an Deepseek-OCR, Deepseek-OCR-2 und die wertvollen Modelle und Ideen von PaddleOCR“, ist eine stilvolle Haltung.
Zur Info: „Unlimited OCR Works“ ist eine Parodie auf Unlimited Blade Works aus Fate/stay night. Unlimited Blade Works ist ursprünglich als Magie konzipiert, mit der man von anderen geschaffene Waffen kopieren kann.
Das Paper steht unter https://arxiv.org/abs/2606.23050
Zur Einordnung: Ich nutze lokales OCR für einen kleinen RAG-Anwendungsfall mit Zitaten, die ich in Büchern gelesen habe, und auch ich teile die Eingabe in Chunks auf, um RAM zu sparen. Deshalb finde ich es interessant, dass so ein natürlicher Ansatz auch bei Streaming-Modellen funktioniert.
Das wirkt viel vielversprechender als das, was Mistral gerade veröffentlicht hat. Zufall? Eher nicht.
Dieser Ansatz ließe sich vermutlich in irgendeiner Kombination auch für Bildgenerierung nutzen. Man könnte ein Bild lesen oder betrachten und dann in einem Tool wie Illustrator/Inkscape oder direkt in SVG mit dem Zeichnen anfangen und fehlende Teile später ergänzen.
Ich frage mich, wie das im Vergleich zu infinty parser 2 abschneidet, das andere OCR-Tools scheinbar übertroffen hat: https://huggingface.co/datasets/allenai/olmOCR-bench
Fairerweise gibt es keinen OCR-Benchmark mit nur einem Sieger, und dieses Tool taucht bisher noch nirgends auf.
Vielleicht klinge ich wie jemand, der keine Ahnung von der Welt hat, aber was ist eigentlich der wirkliche Grund, warum Unternehmen wirklich gute Software als Open Source veröffentlichen?
Sollten Baidu oder Google sie nicht lieber für sich behalten und den Wert daraus ziehen, damit die Konkurrenz nicht nachziehen kann?
Das Unternehmen gewinnt Ansehen, was beim Recruiting-Funnel hilft. Manchmal kann man damit auch strategisch Konkurrenten unter Druck setzen, so wie Meta Ollama veröffentlicht hat
Meine Versuche mit OCR per AI hatten immer halluzinierte Ergebnisse dabei, deshalb war es schwer, so etwas in Produktion einzusetzen. Ich frage mich, ob es hier dasselbe Problem gibt
Ein einfaches Beispiel ist, wenn Wörter, die in einer anderen Sprache stehen bleiben sollten, automatisch ins Englische übersetzt werden und dadurch der Effekt kaputtgeht
Bei Transkriptionen will man fast sichere Ergebnisse oder eine klare Markierung, dass etwas nicht zuverlässig lesbar war. Man kann aus dem Kontext raten, aber man muss wissen, ob bei einem OCR die Vermutung auf etwas anderem beruhte als darauf, dass sich die Buchstaben in Reihenfolge zu einem Wort zusammensetzen.
Zum Beispiel hat bei Volkszählungsdokumenten auf familysearch.com ein Transkribent einen Namen zu Joseph „korrigiert“, obwohl die tatsächlichen Buchstaben im handschriftlichen Dokument Josepth waren und das dort tatsächlich eine regionale Variante der Schreibweise war. In einem anderen Dokument schrieb der Verfasser „Joh“ als Abkürzung, und vermutlich hat ein menschlicher Transkribent es als John übertragen; das ist zwar die plausibelste Lesart, aber tatsächlich falsch. Manchmal ist wichtig, dass etwas nur eine Vermutung ist, und manchmal braucht man einfach nur die beste Vermutung
Wenn man das restliche Dokument verwendet und nur die zu testende Seite oder den Absatz ausnimmt, kann man vermeiden, dass die zu prüfende Passage direkt aus Bildartefakten reproduziert wird. Nach der Rekonstruktion könnte man dann per optischem Vergleich abweichende Zeichen abgleichen, Fehler finden und den Vorgang wiederholen. Teuer wäre es, aber eine 100%ige Erkennung ließe sich garantieren
Die Ausgabe behält Kanji/Hiragana und Englisch dort, wo es nötig ist, und versucht nicht zu übersetzen. Es hat etwa 200 Seiten pro Stunde umgewandelt
Ich weiß nicht, was aus Reducto geworden ist. Vor 12 bis 15 Monaten sah es ziemlich vielversprechend aus