Von Jay, aus 凹非寺
量子位 | Öffentlicher Account QbitAI
Halt, RSI auf OCR angewendet, und der Effekt ist SO stark??
Kürzlich hat ein chinesisches Open-Source-Modell mit nur 1.3B Parametern die Dokumentenanalyse überrundet.
Platz 1 in gleich drei Bestenlisten: OmniDocBench, olmOCR-Bench und DocParsingBench.
Zu Benchmark-Punkten sagen wir mal nichts weiter – schauen wir uns direkt die Beispieldateien an.
Handgeschriebene Notizen aus Höherer Mathematik im alten Stil, mit einem Klick zu MD konvertiert.
Es kann sogar chemische Strukturformeln zeichnen ...
Krass – praktisch alles kann geparst werden.
Was ich aber nicht erwartet hatte: Es ist auch noch verdammt schnell???
Auf einer einzelnen RTX PRO 6000 dauerte die End-to-End-Dokumentenanalyse von 100 Seiten nur101 Sekunden。
Ups, jetzt wird die Effizienz von Firma A beim Destillieren von Papierbüchern durchstarten (nicht ernst gemeint).
Auch in der internationalen Entwickler-Community ist es riesig populär und hat bereits über 1.1K GitHub Stars erhalten.
Zeitweise war es sogar die heißeste Daily News auf Twitter.
Und all das verdankt sich jenem Konzept, das gerade am sexiesten in der KI-Branche ist –
RSI.
Diese selbst-evolutionär angetriebene OCR-Neuheit heißt OXR.
Optical „Everything" Recognition.
Platz 1 weltweit in drei Bestenlisten
Dokumentenanalyse – ein Berg, der unspektakulär klingt, aber bis heute nicht vollständig erobert wurde.
Konventionelle OCR steht bei einem scheinbar völlig normalen PDF oft vor einem Katastrophen-Szenario.
Zweispaltige Papers werden hintereinander ausgelesen, handschriftliche Formeln werden zu Zeichensalat, große tabellenübergreifende Strukturen brechen komplett auseinander, und chemische Strukturformeln werden von vielen Tools kurzerhand als wirre Linien weggeworfen ...
Sobald solch schlechte Extraktion in RAG eingespeist wird, ist selbst das klügste Modell lahmgelegt – und auch alle nachgelagerten Tool Calls fallen aus.
Jetzt ist diese Barriere, die der KI den Zugang zu hochwertigem Kontext versperrt, endlich durchbrochen.
- OmniDocBench: 97.18, Platz 1 (von der Shanghai AI Laboratory als Open Source veröffentlicht, deckt 10 Klassen komplexer Dokumente ab)
- olmOCR-Bench: 87.84, Platz 1 (vom renommierten US-KI-Institut Ai2 entwickelt, mit über 7000 Unit-Test-artigen, harten Aufgaben)
- DocParsingBench: 87.76, Platz 1 (#1, deckt 5 Branchen und 14 reale Geschäftsszenarien ab)
Ein Open-Source-Dokumentenanalyse-Modell namens OXR hat in allen drei Weltklasse-Bestenlisten den ersten Platz erobert.
Darüber hinaus ist der gesamte Bewertungsprozess samt Code vollständig als Open Source verfügbar und reproduzierbar.
Ich habe es auch selbst kurz ausprobiert, und es ist wirklich anders. Endlich keine künstliche Dummheit mehr.
Bei früheren Tools habe ich im Grunde nur erwartet, dass sie Bilder in Text umwandeln, und den Rest hat die KI selbst durch Rätseleign und Inferenz erledigt.
OXR hingegen kann auf einen Schlag13 Arten von Dokumentelementen schlucken:
Tabellen, Formeln, Codeblöcke, Bilder, chemische Gleichungen, Fußnoten, Kopfzeilen, Fußzeilen, Stempel …
In konkreten Szenarien angewendet sieht das so aus:
Zeitschriften: Ausgabe als strukturiertes MD mit vollständig erhaltener semantischer Struktur und Lesereihenfolge.
Mathematische Formeln: direkte Umwandlung in standardmäßigen LaTeX-Code.
Fachliteratur?
Auch hier muss das LLM nicht mehr langsam selbst Werkzeuge zum Lesen aufrufen; ein zweispaltiges Layout beeinträchtigt die Qualität nicht.
Sogar mathematische Prüfungsarbeiten können geparst werden???
Sieht so aus, als könnte GPT Grundschulkindern künftig besser bei den Sommerhausaufgaben helfen o(╥﹏╥)o.
Am spannendsten ist natürlich die Open-Source-Sache.
Man muss wissen: Die Bedeutung der Open-Source-Stellung solcher vertikalen Kleinmodelle ist eine ganz andere als bei LLMs.
Ehrlich gesagt: Obwohl Open-Source-LLMs gut sind, haben sie für normale Nutzer kaum Bedeutung.
Selbst ein Modell mit nur 27B hat absurde lokale Deploykosten – mindestens ein M5 Pro 64G nötig –, ganz abgesehen von der Frage der Ausgabegeschwindigkeit.
Aber dieser OXR,der hat nur 1.3B …
Was bedeutet das?
Mit einer RTX 3060 läuft es praktisch mit voller Leistung – unbegrenztes Freiladungen-abstauben.
Auch die Entwickler im Ausland sind rundum zufrieden.
Kann was.
Also: Wie schafft ein 1.3B-Dokumentanalysemodell die SOTA-Genauigkeit?
Das Geheimnis liegt komplett im Post-Training –
es basiert ausgerechnet auf RSI???
Enthüllung des RSI-Trainings
Lange Zeit herrschte bei allen eine feste Denkweise:
Um höchste Präzision zu erreichen, muss man Modelle mit zehn Milliarden Parametern stapeln und massenhaft manuelle Annotationen.
Aber ganz ehrlich: Im Bereich Dokumentanalyse sind annotierte Daten ein Fass ohne Boden.
Die Layouts sind schrullig, professionelle Formeln, Code und Diagramme sind verzweigt komplex – reine manuelle Annotation kostet nicht nur himmelhoch Geld, die Fehlerrate manueller Annotationen ist auch selbst erschreckend hoch.
Die langen Bad Cases der realen Welt kann man niemals erschöpfend erfassen. Der Ingenieur müht sich, schlechte Stichproben herauszusuchen, sie manuell zu korrigieren und neu zu trainieren; kaum ist eine neue Version veröffentlicht, scheitert man wieder an neuen seltsamen Layouts.
Die Geschwindigkeit der Datenvorbereitung würgt die Evolution des Modells buchstäblich ab.
Das Team hat in dieser Hinsicht einige recht kühne Erkundungen unternommen.
Ihnen wurde klar, dass das Parsen von Dokumenten seit langem eine leicht übersehene Eigenschaft aufweist:
Jede Eingabe hateine objektiv bestimmte Standardantwort。
Ob der Text stimmt, ob es Fehler bei über Zeilen und Spalten laufenden Tabellen gibt oder ob Formelsymbole fehlen – all das lässt sich präzise messen.
Wenn man Richtig und Falsch objektiv beurteilen kann, warum sollte man dann auf den Menschen warten, um hinterher aufzuräumen?
Nach diesem Gedankenexperiment traf OXR eine Entscheidung:
In der Post-Training-Phase wird ein auf Dokumentparsen ausgerichtetes rekursives Selbstverbesserungs-(RSI-)Trainingsparadigma eingeführt.
Ohne auf neue manuelle menschliche Annotationen angewiesen zu sein, soll das KI-System Fehler selbst finden, Ursachen selbst analysieren, die Trainingsdaten für die nächste Runde selbst vorbereiten und sich selbst iterativ weiterentwickeln.
Dieser RSI-Prozess lässt sich grob in drei Phasen unterteilen:
1. Vorhersage und Klassifikation (Prediction&Classification)
OXR parst zunächst eine riesige Menge unbeschrifteter, echter Dokumente.
Anschließend tritt ein allgemeines multimodales Modell (General VLM) auf den Plan, das anhand des Originalbildes, der Parsergebnisse und der Beurteilungskriterien die Stichproben in drei Kategorien einteilt:
- Correct: vollständig korrekt, wird direkt durchgelassen.
- Wrong: eindeutig als falsch beurteilt, wird zur tiefgehenden Analyse weitergeleitet.
- Uncertain: instabile Vorhersagen oder Randbereiche der Verteilung, werden ebenfalls zur Analyse weitergeleitet.
Die Beibehaltung der Kategorie Uncertain ist ein eher kontraintuitives Know-How.
Wenn man dem Modell nur die beiden strikten Alternativen Correct und Wrong anbietet, wird das Zögern des Beurteilungsmodells zwangsläufig in ein eindeutiges Label gepresst, und am Ende wird dem nächsten Trainingsdurchlauf Gift verfüttert.
Mit Uncertain können unsichere Stichproben abgefangen werden.
Neben dem VLM führt OXR zusätzlich an sich selbstmehrere Rollout-Samplings durch。
Wenn eine Datei bei mehreren Durchläufen stark voneinander abweichende Ergebnisse liefert, fehlt dem Modell die Sicherheit; selbst wenn es zufällig einmal richtig liegt, wird sie direkt in die Uncertain-Menge aufgenommen.
Schließlich führt das System unter der Voraussetzung semantisch vollständig unveränderten Inhalts an diesen stark divergierenden Stichproben leichte Bildstörungen durch (geringe Skalierung, Komprimierung, leichte Unschärfe oder Verschiebung).
Wenn die Divergenz nach den Störungen weiter zunimmt, ist das Modell gegenüber solchen harmlosen visuellen Veränderungen überempfindlich, und dieser Störungsschritt wird sofort als zentrale Fehlerursache dokumentiert, die die gezielte Verstärkung in der nächsten Runde direkt anleitet.
2. Ursachenzuschreibung und Trainingsplanung (Attribution&Training Planning)
Nachdem man die falschen und schwachen Stichproben herausgefiltert hat, darf man sie keinesfalls einfach wahllos dem Modell verfüttern – man muss herausfinden, woran genau es gescheitert ist.
In dieser Phase diagnostiziert das General VLM wie ein erfahrener Arzt jede Stichprobe einzeln: Ist es eine fehlgeschlagene Ausrichtung einer über Spalten laufenden Zelle oder ein Erkennungsfehler bei handschriftlich verbundenen Schriftzügen?
Die diagnostizierten Ursachen in natürlicher Sprache werden in SigLIP2 eingespeist, um Merkmalsvektoren zu extrahieren, und anschließend durch ein unabhängiges Clustering-Modell geclustert, wodurch klare Ursachencluster (Reason clusters) entstehen.
Zum Beispiel: Eine Finanzbilanz und ein Chemie-Experimentprotokoll haben optisch und textlich rein gar nichts miteinander zu tun – aber wenn das Ursachen-Clustering ergibt, dass beide an einer bestimmten seltenen über Zeilen und Spalten laufenden Struktur scheitern, wird dies als eine gemeinsame Richtung der Datenkonstruktion destilliert.
Das ist ein präziser gezielter Schlag: Man stärkt genau dort, wo es schwach ist.
3. Datengenerierung (Data Generation)
Mit klar definierten Ursachenclustern weiß der Generator, welche Aufgaben er üben soll.
OXR geht konkret so vor: Die Ursachencluster liefern die strukturellen Schwierigkeiten, der Pool echter Stichproben liefert die Referenz für Layout und visuellen Stil.
Bei jeder Generierung neuer Daten wird ein Layoutstil aus den echten Stichproben als Anker genommen und die zu bewältigende strukturelle Schwierigkeit auf natürliche Weise darin eingebettet.
Die visuellen Schwachstellen, die zuvor in den Störungstests gefunden wurden, werden ebenfalls systematisch in die synthetische Pipeline eingespeist, um das Modell zu zwingen, sich im Training wiederholt an diese Reize zu gewöhnen.
Schließlich werden die generierten Daten einer strengen Formatvalidierung unterzogen und fließen direkt in das Training der nächsten OXR-Generation zurück.
Nach einem durchlaufenden Zyklus werden die Schwächen des Modells behoben; ein erneuter Lauf mit neuen echten Dokumenten bringt dann neue Schwächen zum Vorschein, die die nächste Iterationsrunde vorantreiben.
Damit war der RSI in seiner heutigen Form geboren.
Die Daten werden mit jeder Iteration immer vollständiger und solider.
Dies ist auch der Grund, warum OXR eine so hohe intelligente Dichte erreichen kann.
Wenn die Datenqualität hoch genug ist, muss das Modell nicht mehr auf ein aufgeblähtes Parametervolumen zurückgreifen, um Dinge auswendig zu lernen.
Die Architektur ist leichtgewichtig und steckbar (plug-and-play).
Nach dem Gespräch über Daten und Algorithmen wenden wir uns nun der nächsten Frage zu.
Genauigkeit zuerst, das kann ich nachvollziehen.
Aber die Geschwindigkeit steht auch an erster Stelle – wie ist das zu erklären???
Auf einer einzelnen RTX PRO 6000 parst OXR ein 100-seitiges Dokument end-to-end in nur 101.0 Sekunden – Platz 1 unter den Open-Source-Modellen.
Anfangs dachte ich, es läge an den kleinen Parametern.
Aber später stellte ich fest, dass die Dokumentenanalyse allein dadurch, dass das Modell klein ist, nicht gelingen kann.
Hinter all dem steckt jede Menge kontraintuitives Know-How.
Blickt man auf die technische Entwicklung der Dokumentenanalyse in den letzten zwei Jahren zurück, so hat die Branche tatsächlich mehrere Phasen durchlaufen.
Anfangs setzte man aufPipeline-Ansätze: Erkennung, Identifikation und Sortierung wurden jeweils mit separaten proprietären Modellen realisiert – das Ergebnis war extrem aufgebläht und der Wartungsaufwand ging durch die Decke.
Später wurdenVLMs zum Trend, und man erkannte, dass alle Aufgaben im Kern Abbildungen von Bildern auf Sequenzen sind. Man begann daher zu versuchen, mit einem End-to-End-Großmodell alles auf einen Schlag zu erledigen, sodass das große Modell direkt ganze Seiten an Text und Layout ausgibt.
Dieser Ansatz ist zwar elegant, aber langsam wie eine Schnecke, denn die autoregressive Generierung langer Sequenzen verschlingt enorm viel Rechenleistung.
Später noch gingPaddleOCR-VLeinen sehr eleganten Schritt:
Es vereinte Layoutanalyse (LA) und Lesereihenfolge (RO) in einem kleinen Modell und schaltete dahinter ein Recognition-Modell – so entstand eine Lösung mit zwei Modellen und zwei Phasen.
Damit wurde die Geschwindigkeit der Layouterkennung wieder auf das millisekundenschnelle Niveau herkömmlicher Objektdetektion gebracht und avancierte in den letzten zwei Jahren direkt zur branchenüblichen Standardlösung.
Doch ist das damit perfekt?
Nein. Mit jeder hinzugefügten Layoutannotation muss zwangsläufig auch eine Annotation der Lesereihenfolge mitgebunden werden, was den Aufwand der Datenverarbeitung direkt verdoppelt.
Das OXR-Team hat nach eingehender Analyse einen völlig anderen, aufgabenzentrierten Umbauansatz vorgeschlagen:
Ein eigenständiges leichtgewichtiges Modell übernimmt die Layoutanalyse (LA), während das OXR-Hauptmodell gleichzeitig die Inhaltserkennung (Recognition) und die Beurteilung der Lesereihenfolge (RO) übernimmt.
Also:
Layout-Analyse–>Erkennung+Lesereihenfolge
Diese scheinbar einfache Aufteilungs- und Kombinationsstruktur bringt im Ingenieurwesen zwei enorme qualitative Veränderungen mit sich:
Erstens,sie beseitigt den durch die Lesereihenfolge verursachten Performanceverlust vollständig.
In der gesamten Pipeline war der Zeitaufwand für die Bestimmung der Lesereihenfolge ohnehin weitaus geringer als der der Texterkennung.
Seit OXR die Bestimmung der Lesereihenfolge in das Hauptmodell integriert hat, wurde nicht nur keine zusätzliche Zeit benötigt, sondern durch die semantische Verstehensfähigkeit des Hauptmodells selbst (Content-Aware) hat sich sogar die Genauigkeit der Bestimmung der Lesereihenfolge erheblich verbessert.
Gleichzeitig wurde das vorgeschaltete Layoutanalysemodell (LA) durch das Ablegen der komplexen Sortierungsaufgabe extrem auf eine einzige Aufgabe reduziert, sodass direkt ein leichteres, hocheffizientes Erkennungsmodell eingesetzt werden kann und der Gesamtdurchsatz enorm gestiegen ist.
Zweitens,das Layoutanalysemodul ist unabhängig und vollständig austauschbar (plug-and-play).
Unterschiedliche Geschäftsbereiche haben völlig gegensätzliche Anforderungen an das Seitenlayout – das ist ein Long-Tail-Problem:
Bei einem Bereich mit gemischtem Text- und Bildlayout möchte das Content-Team den Inhalt als ein einziges Bild extrahieren, während das Wissensdatenbank-Team den darin enthaltenen Text herauslösen und als Fließtext verwenden möchte;
Bei dicht angeordneten Vier-Bild-Streifen möchte Geschäft A den gesamten Streifen ausschneiden, Geschäft B möchte ihn in vier kleine Bilder zerlegen;
……
Kurz gesagt: Es ist extrem schwer zu definieren, und es lässt sich nicht jedem gerecht werden.
Doch in OXR-Architektur ist die Layoutanalyse ein vollständig unabhängiges, austauschbares (plug-and-play) Modul –
mit minimalen Anpassungskosten wird eine maximale Flexibilität bei der Anpassung an verschiedene Geschäftsanforderungen erreicht.
Wenn Ihr Geschäft extrem spezielle Anforderungen an die Layoutaufteilung hat, etwa weil Sie alte Schriften oder medizinische Dokumente verarbeiten, können Sie problemlos ein von Ihnen selbst trainiertes, privates Layoutanalyse-Modell einsetzen und es nahtlos austauschen,
und das Backend nutzt weiterhin kostenlos OXRs leistungsstarke Inhaltserkennung.
Ökosystem ab Einsatzbereit (Out-of-the-box)
Natürlich: Da es für die Entwickler-Community geschaffen wurde, hilft das schönste Geschrei nichts – wenn sich das Modell nicht deployen lässt, ist alles umsonst.
In dieser Hinsicht bietet die offizielle Seite eine kostenlose API an, ohne Registrierung und ohne Beantragung eines Keys.
Ja, völlig kostenlos, reiner Gratis-Nutzung ...
Die offizielle Seite erklärt, dass sie den quelloffenen, kostenlosen Service mindestens solange weiter betreiben werden, wie die Serverlast noch tragbar ist.
Da bleibt ja gar nichts anderes übrig, als aufzustehen und mitzumachen!
Deshalb habe ich sofort, mit heißer Eile, diese API in meine Schreib-App integriert.
Ehrlich gesagt: Beim PDF-Parsing ist das Ergebnis im Vergleich zu vorherigen Lösungen ungleich besser.
Übrigens: Auch eine lokale Bereitstellung ist kein Problem. OXR ist vollständig mit den gängigen Inferenz-Frameworks kompatibel.
Man muss sich nicht selbst mühsam durch eine Neukompilierung von vLLM quälen; man kann den Service direkt über das offizielle Docker-Image oder die CLI durch Einbinden des Plugins mit einem Klick starten.
Derzeit sind OXRs Code, die Modellgewichte sowie der komplette Reproduktionsablauf der Benchmark-Evaluation vollständig öffentlich zugänglich.
Die Links finden sich am Ende des Artikels; Interessierte können sie sich gerne nehmen.
Natürlich, wenn Sie weitergehende Anforderungen haben, etwa die Verarbeitung weiterer Formate wie Word, PPT oder Excel, oder wenn Sie eine ausgefeiltere Nachbearbeitung und Anpassungsfähigkeit suchen, können Sie sich auch die offiziell gepflegte kommerzielle Engine ansehen.
Sie heißt SoMark.
Das ist auch der Name des OXR-Teams.
One More Thing
Zum Schluss möchte ich noch ein paar Gedanken mit euch teilen.
Warum sollten wir heute noch so viel Energie darauf verwenden, uns mit Dokumentenparsen zu befassen?
In einer Zeit, in der Agents umfassend die Arbeitsabläufe aller Branchen übernehmen, liegen die wichtigsten und fachlichsten privaten Wissensbestände, die Menschen über Jahrzehnte angesammelt haben, zum allergrößten Teil noch immer ungenutzt in jenen PDFs, Scans und Berichten mit chaotischen Formaten und komplizierten Layouts.
So schlau ein großes Sprachmodell auch sein mag: Wenn man ihm als Eingabe einen Haufen Zeichenmüll mit falscher Reihenfolge und zerbrochenen Tabellen füttert, kann es nur Halluzinationen ausspucken.
Früher haben viele OCR als eher anspruchslose Schufterei betrachtet, doch heute, vom OCR zum OXR, hat sich seine Mission vollständig verändert.
Es ist die Brücke zwischen Mensch und Maschine, die alle komplexen multimodalen Dokumente der menschlichen Welt vollständig und verlustfrei in strukturierte Assets umstrukturiert, die für Agents äußerst freundlich sind.
Ehrlich gesagt ist es ziemlich aufregend zu sehen, dass in China Teams an solchen praxisnahen, engineering-orientierten Dingen arbeiten.
Zu viele Blicke sind auf die Fancy-Narrative gerichtet; man jagt täglich neueste Technologien und vergisst darüber eine sehr wichtige Sache –
Was brauchen die Nutzer wirklich?
In der Phase, in der sich die LLM-Entwicklung heute befindet, ist die Antwort auf diese Frage definitiv nicht mehr eine höhere Modellintelligenz.
Der größere Engpass liegt in jenen Bereichen, die noch niemand erschlossen hat und in denen man Get Hands Dirty muss.
Wenn sich in dieser Sache ein Konsens bilden kann –
dann wird die Infrastruktur für Agenten,mit sichtbarem Tempo, Stück für Stück wie ein Puzzle an seinen Platz fallen.
GitHub: https://github.com/SoMarkAI/OXR
Hugging Face: https://huggingface.co/SoMarkAI/OXR-1.0
Online-Demo:
https://free-oxr.somark.cn/
Kostenlose API:
https://free-oxr.somark.cn/api/v1
SoMark-Website: https://www.somark.cn