- Ausgehend von der Einsicht: „Wenn man Text als Bild darstellt, kann man dieselben Informationen mit deutlich weniger Tokens enthalten“
- Das Modell schlägt einen neuen Ansatz vor, der Textinformationen als 2D-visuelle Darstellung komprimiert, und validiert experimentell das Konzept einer visionsbasierten Komprimierung (Optical Compression), um lange Kontexte effizient zu verarbeiten
- Das Modell besteht aus DeepEncoder (Encoder) und DeepSeek3B-MoE-A570M (Decoder) und erreicht auch bei hochauflösenden Eingaben einen geringen aktiven Speicherverbrauch sowie ein 10- bis 20-faches Token-Kompressionsverhältnis
- Es hält 97 % OCR-Präzision bei 10-facher Komprimierung und über 60 % Genauigkeit selbst bei 20-facher Komprimierung, was praktische Möglichkeiten für die Forschung zu Langkontext-Komprimierung und Vergessensmechanismen aufzeigt
- Auf OmniDocBench übertrifft es GOT-OCR2.0 (256 Tokens/Seite) mit nur 100 Vision-Tokens und erzielt gegenüber MinerU2.0 (durchschnittlich 6000+ Tokens/Seite) mit unter 800 Tokens eine bessere Leistung
- Mit einer einzelnen A100-40G-GPU lassen sich mehr als 200.000 Seiten Daten pro Tag erzeugen; damit ist es als Daten-Engine für großskaliges LLM/VLM-Training von hohem praktischem Wert
1. Forschungshintergrund
- Bestehende LLMs haben die strukturelle Grenze, dass der Rechenaufwand quadratisch mit der Sequenzlänge steigt
- Das Paper startet von der Einsicht: „Wenn man Text als Bild darstellt, kann man dieselben Informationen mit deutlich weniger Tokens enthalten“
- Dies wird als Langkontext-Komprimierung auf Basis visueller Tokens (Context Optical Compression) definiert, wobei OCR als experimentelle Bühne gewählt wird
- Damit wird ein neuer Weg aufgezeigt, wie visuelle Darstellungen die Kontexteffizienz von LLMs verbessern können
2. Modellarchitektur
- DeepSeek-OCR = DeepEncoder + DeepSeek3B-MoE-Decoder
- DeepEncoder: SAM (Window Attention) + CLIP (Global Attention) + 16-facher Token-Kompressor
- DeepSeek3B-MoE: 6 von 64 Experten aktiv, insgesamt 570M aktive Parameter
- Unterstützung für Multi-Resolution-Modi (Tiny~Gundam)
- Unterstützt Eingaben mit 512~1280 Auflösung und verarbeitet kombiniert bis zu 9 Tiles
- Der Gundam-Modus ist für Dokumente mit ultrahoher Auflösung (z. B. Zeitungen) ausgelegt und verwendet bis zu 800 Vision-Tokens
3. Daten-Engine
- Kombination aus insgesamt drei Datentypen:
- OCR-1.0-Daten: 30M Seiten, dokumentbasiert in 100 Sprachen, mit feinen Layout- und Textannotationen
- OCR-2.0-Daten: 16M Datensätze für komplexe Erkennung wie Diagramme, chemische Formeln (SMILES) und geometrische Formen
- Allgemeine Vision-Daten: zur Erhaltung des CLIP-basierten visuellen Verständnisses, 20 % des Gesamtbestands
- Nur-Text-Daten: 10 % zur Ergänzung der Sprachfähigkeiten
- Gesamtverteilung der Trainingsdaten
- OCR 70 % / Vision 20 % / Text 10 %
4. Trainingspipeline
- Training in zwei Stufen: DeepEncoder → DeepSeek-OCR
- Auf insgesamt 20 Knoten (8×A100 GPU) mit Datenparallelität DP=40 und globalem Batch von 640
- Trainingsgeschwindigkeit: 90B Tokens/Tag für Textdaten, 70B Tokens/Tag für multimodale Daten
5. Evaluationsergebnisse
(1) Kompressionsexperiment (Fox-Benchmark)
- 97 % Genauigkeit bei 10-facher Komprimierung, über 60 % selbst bei 20-facher Komprimierung
- Je länger oder komplexer das Dokument, desto stärker nimmt die Leistung ab; dies wird jedoch als Möglichkeit zur Simulation eines „Vergessensmechanismus“ interpretiert
- Bei Kompressionsraten von 10× oder weniger ist eine nahezu verlustfreie Kontextrekonstruktion möglich
(2) Reale Dokumentenerkennung (OmniDocBench)
- Vergleich der Modi Tiny (64 Tokens) bis Gundam (800 Tokens)
- Gegenüber GOT-OCR2.0 (256 Tokens) ist der Small-Modus (100 Tokens) überlegen
- Gegenüber MinerU2.0 (7.000 Tokens) erzielt Gundam (800 Tokens) bessere Ergebnisse
- Der benötigte Token-Bedarf variiert je nach Dokumenttyp
- Folien, Reports: 64~100 Tokens ausreichend
- Zeitungen, wissenschaftliche Arbeiten: 400~800 Tokens erforderlich
6. Qualitative Analyse (Qualitative Study)
- Deep-Parsing-Modus
- Strukturierte Extraktion von Diagrammen, Formen, chemischen Formeln und natürlichen Bildern mit einem einzigen Prompt möglich
- Mehrsprachige Erkennung
- Unterstützung für PDFs in rund 100 Sprachen, einschließlich Sprachen mit geringerer Verbreitung wie Arabisch und Singhalesisch
- Allgemeines visuelles Verständnis
- Führt auch Bildbeschreibung, Objekterkennung und Grounding aus
- In Verbindung mit LLMs als Basismodell für vision-sprachliche kombinierte Schlussfolgerung nutzbar
7. Diskussion und Implikationen
- DeepSeek-OCR ist der erste Versuch, die Grenzen der Langtext-Komprimierung auf Basis von Vision-Tokens zu erkunden,
und quantifiziert damit das Konzept „Ein Bild sagt mehr als tausend Worte“
- Selbst bei 10× Komprimierung ist eine nahezu verlustfreie Rekonstruktion möglich → Erweiterung auf Komprimierung von Gesprächsverläufen, Optimierung des Langzeitgedächtnisses usw. denkbar
- Vorgeschlagen wird außerdem eine Simulation von Token-Dämpfung ähnlich biologischen Vergessenskurven, indem die Bildauflösung im Zeitverlauf reduziert wird
8. Fazit
- DeepSeek-OCR ist ein empirisches Modell für 10- bis 20-fache Kompressionsabbildung zwischen Text und visueller Darstellung und präsentiert ein neues Paradigma zur Überwindung der Grenzen von LLMs bei der Verarbeitung langer Kontexte
- Über OCR hinaus dürfte es künftig auf digitale-optische gemischte Pretraining-Verfahren sowie auf ultralangfristige Kontextmodelle auf Basis von „Optical Context Memory“ erweitert werden
- Der Code ist veröffentlicht und kann für Forschung sowie als kommerzielle Daten-Engine genutzt werden
- DeepSeek-OCR erhält im Vergleich zu bestehender OCR-Open-Source Aufmerksamkeit durch eine LLM-basierte Architektur, die visuelle Informationen effektiv kodiert
- Mit Unterstützung für verschiedene Auflösungen (512×512~1280×1280) und dem dynamischen Gundam-Modus ist es sehr anpassungsfähig an unterschiedliche Einsatzumgebungen
- Durch klares Prompt-Design werden verschiedene Arbeitsmodi wie allgemeine Bildbeschreibung, Markdown-Konvertierung, layoutignorierendes OCR und Diagramm-Parsing unterstützt
- Die Anbindung an Branchen-Benchmarks wie Fox, OminiDocBench wurde geprüft und anhand realer Dokumentverarbeitungs-Experimente validiert
- Es übernimmt und implementiert die Stärken und Ideen anderer populärer Projekte wie GOT-OCR2.0 und PaddleOCR
- Unterstützte Auflösungen
- Tiny: 512×512 (64 Vision-Tokens)
- Small: 640×640 (100 Vision-Tokens)
- Base: 1024×1024 (256 Vision-Tokens)
- Large: 1280×1280 (400 Vision-Tokens)
- Dynamic mode (=Gundam): freie Auflösung (n×640×640 + 1×1024×1024)
- Parallele Inferenz für PDFs und Bilder sowie hohe Verarbeitungsgeschwindigkeit
- Auf einer A100-GPU sind bei der PDF-Verarbeitung rund 2.500 Tokens/Sekunde möglich
- Technischer Hintergrund und Einbindung ins Ökosystem
- Zu 100 % in Python implementiert
- Unterstützung sowohl für vLLM als auch für Transformers als die beiden wichtigsten Inferenzumgebungen
- Nutzung zentraler Benchmarks und Evaluations-Frameworks wie OpenChart, Fox und OminiDocBench
- Anbindung an frühere Modelle wie GOT-OCR2.0, PaddleOCR und Vary, Übernahme von Ideen und Leistungsverbesserungen
1 Kommentare
Hacker-News-Kommentare
Diese Arbeit ist nicht einfach nur ein weiteres VLM für OCR, sondern geht zu interessanteren Themen wie Kompression über.
Zum Beispiel gibt es das Zitat: „Wir führen frühe Forschung zur Grenze der Vision-Text-Kompression durch und untersuchen, wie viele Vision-Token nötig sind, um Text-Token zu dekodieren. Vorläufige Ergebnisse zeigen, dass DeepSeek-OCR nahezu verlustfreie OCR-Kompression mit etwa einem 10-fachen Verhältnis erreicht und selbst bei 20-facher Kompression noch 60 % Genauigkeit beibehält.“
Intuitiv bedeutet das, dass ein Vision-Token so viele Informationen wie 10 Text-Token enthalten würde.
Ich würde gern eine Erklärung bekommen, warum so ein Ergebnis aus informationstheoretischer Sicht herauskommt, so dass es auch ein Einsteiger verstehen kann.
Ich frage mich, ob Text-Token noch zu stark in kleine Einheiten zerlegt sind (redundant sind oder unter Entropie-Codierung liegen), oder ob man durch den Übergang zu Vision-Token die Grenzen der „Wortebene“ verlässt und näher an die Entropie herankommen kann, ähnlich wie der Unterschied zwischen arithmetischer Codierung und Huffman-Codes.
Außerdem wird in der Arbeit beim Umgang mit großem Kontext das Bild tatsächlich herunterskaliert, und es geht auch um die Entsprechung von Informationsverlust im Text- und im Bildbereich.
Text-Token sind quantisierte Untereinheiten (Subwords), während Vision-Token nur im Embedding-Raum existieren.
In LLMs ist die Text-Tokenisierung strukturell eine Lookup-Tabelle aus (kleinen) Token-IDs und (großen) Vektor-Embeddings.
Wenn man Text an ein LLM übergibt, wird der String an Tokengrenzen zerlegt, in Token-IDs umgewandelt, und dann werden die Vektoren aus der Lookup-Tabelle geladen, um eine Matrix zu bilden (
context matrix).Die Übertragung einer tatsächlichen Text-Token-Sequenz ist effizient, weil man nur ein Zahlenarray (IDs) übergeben muss, normalerweise aus etwa ~100.000 eindeutigen Token-IDs.
Die Embedding-Matrix selbst zu übertragen wäre dagegen ineffizient, weil Embeddings aus Tausenden von Float-Zahlen bestehen.
Bilder werden anders kodiert. Man verarbeitet die Bilddaten vor und schickt sie direkt in einen neuronalen Bild-Encoder, der sie in Vektoren umwandelt, und diese Vektoren werden dann in den Kontext eingefügt.
Das heißt, Bild-Token haben weder Token-IDs noch eine Lookup-Tabelle, sondern gehen direkt von den Daten zum Embedding.
Folglich müsste man zur Übertragung von Bild-Token die Embeddings selbst senden, was ineffizient ist.
Selbst wenn ein Bild in weniger Token kodiert wird, ist die Kapazität jedes einzelnen Tokens viel größer.
Kurz gesagt: Text-Token haben eine klare Zuordnung von ganzen Zahlen (0~n) zu Vektoren und damit genau „n“ Auswahlmöglichkeiten.
Bild-Token dagegen sind m-dimensionale Float-Arrays (Vektoren) und haben daher einen viel größeren Token-Raum.
Auch beim Muster ist es so, dass Text-Token direkt an fortlaufende UTF-8-Bytes gebunden sind und meist nicht einmal über Wortgrenzen hinausgehen; globale Muster wie „dieser Satz stammt aus Hamlet“ oder „dieser Abschnitt ist auf Spanisch“ lassen sich also nicht in einem einzigen Token ausdrücken.
Ich weiß nicht genau, wie Bildeingaben in multimodalen LLMs eingebettet werden, aber grundsätzlich verstehe ich es so, dass das Bild in ein Raster zerlegt und jeder Bereich kodiert wird.
Bei DeepSeeks Experiment scheint es weniger um informationstheoretische Eigenschaften zu gehen als darum, wie stark man die Auflösung senken oder die Raster-/Patch-Größe verändern kann und trotzdem noch genug Details behält, um OCR korrekt auszuführen.
Ich wünschte, Karpathy würde NanoChat multimodal erweitern und dabei Know-how zu solchen Kodierungsprozessen teilen.
Das sinnvolle Kompressionsverhältnis kann letztlich nur von der relativen Größe der Auflösung eines einzelnen Zeichens und der Patch-Größe jedes Vision-Token abhängen.
Nur so kann die Zahl der per OCR extrahierten Text-Token am Ende unabhängig von der Bildauflösung bleiben.
Jedes Text-Token ist meist eine Subword-Einheit, aber die Vision-Token eines VLM liegen im semantischen Raum.
Ein semantischer Raum kann Informationen viel stärker komprimieren als eine Subword-Zerlegung.
Hinweis: Ich bin kein Experte, das ist nur ein spontaner Gedanke.
LLMs sind so aufgebaut, dass der Rechenaufwand quadratisch mit der Anzahl der Token wächst.
Deshalb versucht man in VLMs, Text-Token in Vision-Token zu komprimieren.
Vermutlich versucht man, Text zuerst als Bild zu rendern und dann zu tokenisieren, um die Rechenkosten zu senken.
PyTorch war auf NVIDIA Spark (ARM64) etwas knifflig, aber ich konnte es zum Laufen bringen, indem ich Claude Code als Root in einem neuen Docker-Container ausgeführt habe.
Detaillierte Notizen gibt es hier.
Das eigentliche Ergebnis kann man unter diesem Link sehen; getestet wurde mit dem OCR-Originalbild (hier).
Das OCR-Ergebnis ist insgesamt sehr solide.
Direkt unter dem Zitat hat das Modell aber unnötige Inhalte hinzugefügt und damit halluziniert, und es dann auch noch mit der nächsten Spalte verbunden.
Danke für den schnellen Test.
Dass am Anfang des Texts das „A“ fehlt, ist noch nachvollziehbar (vermutlich war der Anteil von Zeitungsartikeln im Datensatz gering).
Interessanter finde ich aber, dass der ganze Teil „Hallucination is a risk and...“, das Thema neben dem Autor (
theme) und auch der letzte E-Mail-Teil komplett fehlen.Allein dieses Experiment wäre meiner Meinung nach schon einen eigenen Beitrag wert.
„Claude Code als Root in einem neuen Docker-Container ausführen“
Mich würde konkret interessieren, wie man es so konfiguriert, dass es mit Root-Rechten läuft.
(Falls das erklärt ist, schaue ich im Haupttext nach.)
In der Arbeit wird Anna’s Archive nicht erwähnt.
Ich denke, DeepSeek könnte das Angebot von Anna genutzt haben, OCR-Forschern Zugriff auf eine chinesische Non-Fiction-Sammlung mit 7,5 Millionen Büchern (350 TB) zu geben.
Das ist sogar größer als Library Genesis.
Referenz-Blog
In einer früheren DeepSeek-Arbeit wird Anna’s Archive direkt erwähnt.
„Wir haben 860K englische und 180K chinesische E-Books aus Anna’s Archive sowie Millionen K-12-Prüfungsaufgaben bereinigt.“
Siehe die DeepSeek-VL-Arbeit.
Ich frage mich, warum man überhaupt eine Zugriffsfreigabe brauchen sollte, nur weil jemand fremde Bücher speichert.
Mir kam auch sofort Anna’s Archive in den Sinn, und ich frage mich, wann ein per OCR verarbeitetes Datenset veröffentlicht wird.
Das bedeutet wohl auch, dass das Datenset am Ende nie veröffentlicht wird.
In so einer Situation sorge ich mich, dass auch Anna’s Archive letztlich durch LLM-Unternehmen ausgenutzt wird und verschwindet.
Es reicht offenbar nicht einmal, dass META schon 70 TB aus Library Genesis per Torrent abgesaugt hat.
Hier ein Erfahrungsbericht zum tatsächlichen Niveau aktueller und anderer Benchmarks.
Der OmniAI-Benchmark ist nicht besonders gut.
Stattdessen empfehle ich OmniDocBench.
Mistral OCR ist im Vergleich zu Open-Source-OCR-Modellen und auch zu Gemini deutlich schwächer.
End-to-End-OCR ist weiterhin sehr schwierig.
Ein Pipeline-Ansatz (Layout-Erkennung → Bestimmung der Lesereihenfolge → OCR je Element) funktioniert besser.
Komplexes Tabellen-Parsing ist weiterhin eine große Herausforderung.
Mich würde auch interessieren, wie Apples Vision Framework im Benchmark-Vergleich mit solchen Modellen abschneidet.
Es ist auf fast allen Apple-Geräten eingebaut und liefert in der Praxis hochwertige und schnelle OCR-Ergebnisse, vor allem für PDF-Konvertierung, aber kaum jemand scheint davon zu wissen.
Ich würde wirklich gern sehen, wo es in Benchmarks landet.
Laut dem OmniAI-Benchmark liefert Omni OCR die beste Leistung.
Wahrscheinlich würde kaum jemand so ein Ergebnis hinterfragen.
Ich frage mich, welche Vorteile und Unterschiede LLM-basiertes OCR im Vergleich zu Diensten wie Azure AI Document Intelligence(Link) oder Google Vision API(Link) hat.
OmniAI benchmarkt sein eigenes LLM und Cloud-OCR gegeneinander.
OmniAI-Benchmark-Blog (Stand Februar 2025)
Seitdem haben sich LLMs schnell weiterentwickelt.
Die Qwen3-VL-Familie, besonders Qwen3-VL-235B-A22B-Instruct, liefert zuletzt die besten Ergebnisse.
Ich vermute, dass kommerzielle/proprietäre OCR-Modelle bei realen Dokumenten weiterhin besser sein werden.
Der Grund sind große Mengen hochwertiger privater Trainingsdatensätze.
Öffentliche LLMs wurden mit arxiv, E-Books und ähnlichen eher forschungsnahen Daten trainiert und sind deshalb bei echten Geschäftsdokumenten zwangsläufig schwächer.
Der LLM-Ansatz reduziert zwar Zeichenersetzungsfehler (Typos, Varianten), aber die Konsistenz auf der Ebene einer ganzen Seite ist eher schlechter.
Wie bei Nicht-OCR-LLMs kann auch komplett falscher Output entstehen.
Bei CJK-Zeichen erzeugt klassische OCR nach wie vor viele unpassende Ersetzungen.
Es gibt zu viele sehr ähnliche Zeichen, die sich teils nur unter dem Mikroskop oder auf Binärebene unterscheiden lassen.
Ein LLM kann mögliche Zeichenfolgen stärker einschränken, daher kann man sich genauere Ergebnisse erhoffen.
Schon allein diese Überlegung ist eine Motivation, LLM-basiertes OCR einzusetzen.
Ich kann zu anderen Modellen nichts sagen, aber bei uns läuft ein Lebenslauf-Parsing-System mit Azure AI Document Intelligence, und wir sind ziemlich zufrieden.
Am Anfang muss man etwas auf das Tuning achten, aber im letzten Jahr mussten wir fast nichts mehr anfassen.
Ich habe mehrere VLMs getestet, von kleineren Modellen wie Granite und Qwen bis hin zu großen Modellen, und mein Fazit ist, dass sie als vollständiger Ersatz für klassische OCR enttäuschend sind.
Unser System nimmt Kundendokumente entgegen und gibt standardisierte Dokumente mit dem gewünschten Markup zurück, als rasterbasierte Multi-Page-Bitmaps.
Für uns ist die Präzision der Koordinatenextraktion bis auf einzelne Zeichen oder Wörter wichtig, aber in der Praxis sind die Positionsangaben der VLMs viel zu ungleichmäßig, komplett halluziniert oder zu vage, um die benötigte Genauigkeit und Granularität zu garantieren.
Bisher verwenden wir deshalb Tesseract-basiert plus Bereinigungsroutinen für die Ergebnisse und nutzen die Textausgabe von VLMs nur gelegentlich ergänzend, wenn kein strukturiertes Datenset vorhanden ist.
Unser Anwendungsfall ist vermutlich ein sehr spezieller Bedarf, und für die meisten Menschen reicht wahrscheinlich einfach ein Textdump oder eine Markdown-/HTML-Konvertierung.
Aber ich habe das Gefühl, dass zwischen den Behauptungen, diese Modelle hätten „OCR vollständig gelöst“, und der tatsächlichen Erfahrung eine ziemlich große Lücke besteht.
Hast du schon das Preview-Modell moondream 3 ausprobiert?
Im Blogpost heißt es, es übertreffe mehrere VLMs und sei zugleich ein leichtgewichtiges Modell.
Siehe Startseite, Modell, Blog.
Mich würde interessieren, ob in den Kundendokumenten handschriftlicher Text vorkommt.
Man könnte auch zuerst mit einem CNN Bounding-Boxes für den Text finden und dann pro Box ein VLM ausführen.
Mein persönlicher Eindruck war, dass OCR inzwischen einigermaßen ein gelöstes Problem ist.
Der OmniAI-Benchmark wurde auch nicht mit neueren Modellen aktualisiert; ich denke, der Grund ist, dass allgemeine LLMs inzwischen besser sind als die OCR im Benchmark selbst.
Wenn ich tatsächlich jede Seitenabbildung in Gemini 2.5 Flash Lite werfe und Markdown extrahieren lasse, kostet das ungefähr 20 Cent pro 1000 Seiten, und die Ergebnisse waren sehr gut.
Ich frage mich, was an OCR heute noch schwierig ist.
Die meisten OCR-/LLM-Systeme, selbst Gemini Pro 2.5, haben weiterhin Probleme damit, komplexe Tabellen in Markdown/HTML umzuwandeln.
Mehrere Header, zusammengeführte Zellen, Spalten mit Checkboxen und ähnliche Probleme treten häufig auf, und Tabellen über mehrere Seiten hinweg werden ebenfalls nicht richtig verstanden.
Auch Llamaindex scheitert daran deutlich.
Mich würde interessieren, welches OCR-/LLM-System bei solchen Problemen besser ist.
Beispiel für komplexe Tabellen,
komplettes ICAO-Checklist-Beispiel
Eigentlich ist nicht OCR, sondern HTR (Handwritten Text Recognition / Handschriftenerkennung) nach wie vor schwierig.
Durch LLMs ist die Genauigkeit stark gestiegen, aber Fehler sind für Menschen nun oft noch schwerer zu finden, weil unleserliche Stellen einfach frei erfunden werden.
Wenn man akzeptieren kann, dass bei nicht erkannten Stellen nicht „ich weiß es nicht“ ausgegeben wird, sondern frei erfundene Ergänzungen, dann ist das Problem natürlich gelöst.
(Nicht sarkastisch gemeint, in manchen Situationen ist das tatsächlich okay.)
Ich bin der Autor des OmniAI-Benchmarks.
Der Grund, warum es keine Updates mit neueren Modellen gibt, ist, dass wir die OCR-API im Produkt selbst zurückgefahren haben.
Intern nutzen wir sie weiterhin, und der Benchmark wurde nur aus Faulheit nicht aktualisiert.
Gemini ist bei OCR am besten.
Wenn die Ausgabe aber dem Trainingsmaterial zu nahekommt, gibt es häufig einen
recitation-Fehler, bei dem rund 10 % der Ausgabe plötzlich abbrechen.Wenn im PDF-Mix leere Seiten vorkommen, entstehen außerdem absurd komische Halluzinationen mit neu erfundenem Inhalt.
OpenAI ist auch nicht schlecht, aber GPT5 ist nicht besser als GPT-4o oder 4.1.
Einige Inhalte wie Header/Footer verschwinden oft, und wenn eine Seite seitlich gedreht ist, spielt das Modell verrückt.
Inhalte mit Ausweisen, medizinischen Unterlagen oder hohem PII-Risiko werden auch häufig selbständig abgelehnt.
Ich halte das absolut nicht für ein gelöstes Problem.
Versuch mal, eine Zeitschrift mit ungewöhnlichem Layout per OCR zu verarbeiten, das ist unmöglich.
Ich sammle Vintage-Magazine und probiere ständig die neueste OCR-Technik aus, aber am Ende braucht es immer enorm viel manuelle Nacharbeit.
Ich frage mich, ob es kein kleines „OCR-Modell“ gibt.
Ich muss nur Seriennummern aus Fotos in einer Produktionsumgebung extrahieren und brauche kein vollständiges Dokument-Parsing.
Für so eine Aufgabe ein Modell mit 3 Milliarden Parametern einzusetzen, wirkt völlig überdimensioniert.
Mich würde interessieren, wie sich DeepSeek-OCR im Vergleich zu Tesseract(Link) schlägt.
Ich nutze
ocrmypdf(Link) sehr gern und lokal funktioniert es für mich hervorragend.Selbst wenn Tesseract real bei 80 % läge und moderne Modelle auf 95 % kommen,
wäre es die Überlegung absolut wert, falls man dafür mit dem 100-fachen an Festplattenbedarf, Kubernetes/Docker und GPUs mit 16 GB VRAM als Infrastrukturpreis bezahlt.
Ich verfolge die neueste Forschung nicht mehr richtig und würde gern eine ELI5-Erklärung dazu bekommen, was das hier ist und warum es wichtig ist.
Im Titel auf GitHub oder im Paper geht es um OCR, aber in der Zusammenfassung und in
readme.mdgeht es plötzlich um LLM-Kontextkompression, was mich verwirrt.Ich suche jemanden, der erklären kann, wie diese beiden Dinge zusammenhängen und was der größere Zusammenhang ist.
Das Bild enthält also Informationen im Umfang von „1000 Token“.
Tatsächlich muss man das Bild aber in Features/Embeddings umwandeln (dekodieren).
Wenn das Bild dann als 100 „Bild-Token“ verarbeitet wird und diese Bild-Token in 1000 „Text-Token“ umgewandelt werden,
hat man die Ausgabe rein aus Dekodierungssicht 10-fach komprimiert übertragen.
Aus Sicht des LLM bedeutet das: Wenn man den Inhalt im Voraus in einer 10-fach kleineren latenten Darstellung komprimieren kann, kann man ohne 1000 Token/Embeddings auskommen und trotzdem gleichwertige oder bessere Ergebnisse erzeugen.