Document OCR: Problem gelöst?

DocOwl 1.5 von der Alibaba Group geht einen großen Schritt hin zur allgemeinen Dokumentenanalyse. Doch kann die Software halten, was sie verspricht?

Eine solide automatisierte Dokumentenerkennung im Sinne des Visual Document Understanding (VDU) ist ein Problem, das seit Jahrzehnten Forscher und Entwickler beschäftigt. Der Begriff VDU meint das inhaltliche und semantische Verstehen von strukturierten Daten, wie z.B. in Formularen (Fahrzeugscheinen, Personalausweisen etc.) oder in wissenschaftlichen Auswertungen mit Diagrammen und Tabellen. Das Schwierige dabei ist jedoch nicht, den jeweils abgebildeten Text auszulesen (das bietet eine handelsübliche OCR). Im Ergebnis bekommen wir einen mehr oder weniger großen Haufen Text ausgelesen, aus dem wir die benötigten Information händisch heraussuchen müssen. Wünschen würden wir uns jedoch einen strukturierten Datensatz, der die Basis für einen zuverlässigen digitalen Dunkelverarbeitungsprozess bildet.

Titelbild: Ein großer Haufen Text. Automatisch generiert durch https://leonardo.ai.

Was ist Visual Document Understanding (VDU)?

Ein Beispiel: Nehmen wir an, wir sind an der Schadstoffklasse von Autos interessiert (z.B. weil wir ein THG Anbieter sind) und müssen dazu täglich hunderte Fahrzeugscheine auslesen. Händisch wäre dieser Prozess sehr aufwendig, daher versuchen wir es mit einer OCR Software. Im Falle unseres Firmenwagens kommt dabei z.B. in etwa so etwas heraus:

MS KI261E \n Kaitos GmbH \n 61.2 Vort \n 02.03. 29 \n M1 \n 81480 AA2000257 \n AA \n Tesla \n 0.03 \n E1LR. \n B.Gb 1s5N \n 120001 1288 \n 4694 \n 1443 \n 11225 \n 18.50 \n 1700-1713 \n 1110 \n 11103 \n 2014 \n 1257 \n 1257 \n 2014 \n • Model 3 \n TESLA (USA) \n Fz.z.Pers. bef b. 8 spi \n Limousine \n 51. 5 \n 235/15R18 98Y \n 2351503 9. 08Y \n 715/2007*2018/1832AX \n BLAU \n 2017/1151.WLTP.reine Elekt-69ze1*2007/46*1293 15. \n 115/ \n 0004.031 \n 22.0121 \n LIK GA611190. \n • Battentekapazität 55 KWh \n Dorotheenstraße 26 A \n 48145 Münster \n 02.03.2021

Einmal abgesehen von den üblichen OCR Lesefehlern: Was ist hier die Schadstoffklasse? Um das stabil automatisch auswerten zu können, sollte das Resultat der Dokumentenerkennung eher so aussehen:

{
  "kennzeichen": "MS KI261E",
  "fahrzeughalter": "Kaitos GmbH",
  "anschrift": "Dorotheenstraße 26A, 48145 Münster",
  ...
  "schadstoffklasse": "Elektro",
  ...
}

Diese Daten lassen sich einfach automatisch weiterverarbeiten und damit lässt sich ein effizienter Abwicklungsprozess aufbauen.

Es gibt unzählige solcher Use-Cases und entsprechend viele Methoden und Anbieter, die sich damit befassen, diese Art von strukturierten Daten zu generieren. Entweder direkt aus einem Bild oder auf Basis eines rohen OCR Ergebnisses. Bisher allerdings ohne durchschlagenden Erfolg, jedenfalls wenn man von einer allgemeinen Lösung spricht. D.h. einer Lösung, die mit beliebigen Dokumenten umgehen kann, auch ohne sie im Training jemals explizit gesehen zu haben. An genau solch einer Lösung arbeitet eine Gruppe von Forschern der Alibaba Group und mit ihrer neuen Veröffentlichung DocOwl 1.5 scheinen sie einen großen Schritt in diese Richtung gegangen zu sein. Hier ein grober Abriss ihres Ansatzes.

Was ist DocOwl?

DocOwl 1.5 ist ein großes Foundational Model, das im Wesentlichen aus einem großen, austrainierten Sprachmodell (dem LLM Llama-7B) und einem sogenannten Vision Transformer (ViT) besteht. Man kann sich die Aufgabenteilung dieser beiden Komponenten in etwa wie folgt vorstellen:

der Vision Transformer (ein populäres KI-Modell zur Verarbeitung von Bildern) hat die Aufgabe, ein Bild von einem Dokument zu verarbeiten und daraus eine Repräsentation mit niedriger Anzahl von Dimensionen zu machen (hier ein Vektor mit 1024 Zahlen). Letzterer wird auch Feature-Vektor genannt und soll nach dem Training Informationen über die in dem Bild enthaltenen Wörter tragen.

das LLM bekommt den Feature Vektor aus dem ViT, extrahiert daraus die im Bild enthaltenen Wörter und "versteht" ihren Zusammenhang. Es ist also dafür zuständig die Daten einer Bedeutung zuzuordnen.

Vereinfacht gesagt: Der ViT liest und das LLM versteht. Oder anders ausgedrückt, der ViT übernimmt die Aufgabe der OCR und erzeugt rohen Text, während das LLM aus der losen Abfolge von Wörtern einen strukturierten Datensatz macht, da es Zusammenhänge innerhalb des rohen "Texthaufens" erkennt. Diese grobe Struktur von DocOwl 1.5 ist an sich nichts Neues und wurde in der einen oder anderen Form bereits mehrfach umgesetzt.

Was DocOwl 1.5 allerdings von den anderen sogenannten Multimodal Large Language Models (MLLM) absetzt, sind zum Einen geschickte architektonische Entscheidungen beim Aufbau der einzelnen Komponenten bzw. wie sie miteinander verbunden werden. Zum Anderen ist es die Art, wie es trainiert wird, d.h. mit welchen Daten und auf welche Aufgabenstellungen (Details zur Implementierung und den Trainingsdaten folgen in einem späteren Artikel). Beides zusammen führt dazu, dass DocOwl 1.5 gewissermaßen eine Art räumliches Verständnis entwickelt, was essentiell ist zum Verständnis strukturierter Daten in Dokumenten. Das LLM von DocOwl 1.5 sieht also tatsächlich nicht nur einen rohen "Texthaufen", sondern auch, wo die einzelnen Texte auf dem Dokument lokalisiert sind. Daraus kann es über den reinen Textinhalt hinweg ableiten, wie die einzelnen Textbausteine zueinander in Beziehung stehen (dies ist natürlich eine stark vereinfachte Darstellung. Wo genau die Grenze der Aufgabenteilung zwischen ViT und LLM verlaufen, ist schwer zu sagen; Details dazu folgen im erwähnten späteren Artikel).

Was kann DocOwl?

...Texte lokalisieren.

Die Lokalisierungsfähigkeiten zeigen sich sehr eindrucksvoll an einigen Beispielen, die in der Veröffentlichung zu DocOwl 1.5 zu finden sind. Abbildung 2 illustriert die Fähigkeit von DocOwl 1.5, Texte zu lokalisieren bzw. lokalisierte Texte auszulesen an zweien davon.

Abbildung 2: Beispiele zur Lokalisierungsfähigkeit von DocOwl 1.5. Quelle: https://arxiv.org/abs/2403.12895

Im ersten Beispiel ist klar zu erkennen, wie stark das "räumliche Verständnis" von DocOwl 1.5 ist. In einem recht großen Dokument mit vielen verschiedenen Inhalten und anspruchsvollem Layout kann es den gewünschten Satz aufspüren und sehr präzise lokalisieren. Gerade Letzteres ist sehr beeindruckend, da LLMs (und es ist das LLM, das die Frage gestellt bekommt) eigentlich nicht dazu gemacht sind, räumlich zu "denken", sondern nur ein sprachliches Verständnis der Welt haben. Dies zeigt also, dass das Zusammenspiel aus dem ViT als visueller Komponente und dem LLM als sprachlichen Teil sehr gut funktioniert.

Das zweite Beispiel von Abb. 2 zeigt die umgekehrte Richtung. Das Modell bekommt die Koordinaten des gewünschten Textes und soll ihn dann auslesen. Auch dies funktioniert sehr gut, d.h. der Text wird offensichtlich gut lokalisiert, allerdings unterlaufen dem System kleinere Fehler beim Lesen (die rot gedruckten Zeichen in der Ausgabe des Modells). Z.B. liest es "2/14/20" anstatt "2/11/20", was wie ein einfacher Lesefehler wirkt. Der zweite Fehler "1:45" statt "1:53" wirkt dagegen eher wie eine Lokalisierungsschwäche, da das System sich hier anscheinend in der Zeile vertan hat. Ähnliches gilt für den Fehler "Mo" statt "Tu", wo es offensichtlich eine Zeile zu weit oben geschaut hat. Dass ähnliche Fehler dem Menschen aber auch ständig passieren, zeigt die fehlerhafte Markierung im Text "1:45". Da hätte die 5 auch rot sein sollen... :)

Die beiden gezeigten Beispiele sowie auch die anderen, die sich im Paper finden lassen, deuten für mich darauf hin, dass das Problem der allgemeinen Dokumentenerkennung konzeptionell gelöst ist. In ihrer aktuellen Umsetzung weist das System aber noch Schwächen auf (mehr zu den Implikationen bzgl. der Nutzbarkeit folgen weiter unten).

...Tabellen auslesen

Abbildung 2 hat deutlich gezeigt, dass das Lokalisieren von einzelnen Textbausteinen in Dokumenten gut funktioniert. Ein weiteres Beispiel aus der Veröffentlichung zu DocOwl 1.5 zeigt, dass das System dies auch in größerem Umfang beherrscht. Im oberen Teil von Abb. 3 bekommt DocOwl die Aufgabe in einem Dokument eine Tabelle auszulesen und in einen strukturierten Datensatz im Markdown Format umzuwandeln (in Techniker-Sprech "parsen").

Abbildung 3: Beispiele zum Auslesen einer Tabelle und eines Balkendiagramms.

Quelle: https://arxiv.org/abs/2403.12895

Man sieht, dass auch dies sehr gut funktioniert. Die Tabelle scheint mir einwandfrei gelesen (trotz der schlechten Auflösung; oder ist das bloß ein Darstellungsfehler in der Veröffentlichung?) und die im Bild enthaltenen Werte stünden damit programmatisch für eine automatisierte Weiterverarbeitung zur Verfügung. Damit wäre das Zielbild, das ich eingangs am Beispiel des Fahrzeugscheins unseres Firmenwagens beschrieben habe, prinzipiell erreicht. Sehr beeindruckend!

Das zweite Beispiel geht noch ein Stück weiter. Hier ist die Übertragungsleistung, die DocOwl erbringen muss, größer, da es nicht nur die räumliche Struktur einer Tabelle eins zu eins übertragen muss, sondern ein grafisch aufwendigeres Balkendiagramm auslesen soll. Hier stehen die semantisch zusammengehörigen Werte nicht sauber aufgereiht unter- bzw. nebeneinander, sondern sind komplexer angeordnet. Aber auch dies scheint dem System keine Schwierigkeiten zu machen und es überträgt die Daten erneut in eine Tabelle im Markdown-Format.

...Dokumente analysieren

Wie wir gesehen haben, beherrscht DocOwl 1.5 die wichtigsten Grundlagen zum Auswerten von Dokumenten offensichtlich sehr gut: Das genaue Lokalisieren von Texten inkl. semantischer Zuordnung der einzelnen Bausteine zueinander, sowie das Auslesen der Wörter selbst (Stichwort OCR). Die letzten beiden Beispiele, die ich hier zeigen möchte, veranschaulichen, dass DocOwl 1.5 es nicht nur schafft, eher "dumme" Parsing-Aufgaben zu lösen: Es kann aus den ausgelesenen Daten (über eine grundlegende Zuordnung untereinander hinaus) zudem komplexe semantische Zusammenhänge extrahieren. Es kann also in dem Sinne die Fähigkeiten eines austrainierten LLMs voll ausspielen, um ein Dokument zu verstehen.

Abbildung 4: Beispiele aus dem Bereich Visual Question Answering (VQA). Quelle: https://arxiv.org/abs/2403.12895

Die beiden Beispiele aus Abbildung 4 zeigen die Fähigkeiten von DocOwl 1.5 im Bereich des Visual Question Answering (VQA). Hier wird dem Modell in natürlicher Sprache eine Frage gestellt und es soll dazu eine zutreffende Antwort in natürlicher Sprache formulieren (anstatt nur den Inhalt des betreffenden Bereichs auszulesen oder zu parsen). Um dies zu gewährleisten haben die Entwickler DocOwl 1.5 mittels eines selbst zusammengestellten "instruction tuning" Datasets austrainiert ("fine tuning"), ähnlich wie OpenAI ChatGPT aus GPT4 gemacht hat. Das Ergebnis ist DocOwl 1.5-Chat, das detaillierte Gesamtzusammenhänge in natürlicher Sprache formulieren kann.

Das erste Beispiel aus Abb. 4 demonstriert dies sehr schön. Das Modell gibt einerseits die gefragte Zahl zurück, bettet diese aber auch noch inhaltlich in den Kontext des gesamten Dokumentes ein. Dies zeigt sich noch eindrucksvoller am zweiten Beispiel. Das System beantwortet nicht nur stumpf die Frage, sondern erklärt auch, woher die Aussage stammt. In rot markiert zeigt sich allerdings auch eine große und allzu bekannte Schwäche des Systems: Der letzte Teil der Antwort klingt zwar äußerst plausibel, ist aber frei erfunden. Wie alle LLMs neigt auch DocOwl 1.5 zu Halluzinationen, was auch zu erwarten ist, da die Sprachverarbeitung auf einem handelsüblichen LLM basiert.

Und was kann DocOwl 1.5 eigentlich nicht?!

Anhand der vorangegangenen Beschreibungen kann man erkennen, wie beeindruckend die Fähigkeiten von DocOwl 1.5 aus meiner Sicht sind. Es kann mit großen Dokumenten mit komplexer Struktur umgehen, Texte sehr genau lokalisieren und auslesen und strukturierte Daten wie Tabellen und Diagramme in ein programmatisch zugängliches Format parsen. In den gezeigten Beispielen konnte man allerdings auch erkennen, dass das System noch deutliche Schwächen aufweist. DocOwl 1.5-Chat zeigt die üblichen Halluzinationen, sodass man seine Aussagen mit Vorsicht behandeln muss. DocOwl 1.5 selbst lokalisiert und liest zwar beeindruckend gut für einen allgemeinen Ansatz. Der erste Eindruck ist allerdings, dass es nicht an spezialisierte Lösungen heranreichen wird. D.h. als ein vorgelagerter Schritt einer teilautomatisierten Lösung dürfte es durchaus hilfreich sein. Für eine voll automatische Datenverarbeitung ohne signifikante menschliche Nachkontrolle scheinen die Leseergebnisse sowie die Lokalisierung einzelner Wörter aber noch nicht ausreichend zu sein.

Ein weiteres Aufgabenfeld, das für DocOwl 1.5 kaum zugänglich sein wird, ist das Auslesen von Dokumenten, die zum Verständnis Vorwissen benötigen. Ein Beispiel sind deutsche Fahrzeugscheine (siehe Abb. 1): Während man die Felder auf der ersten Seite (Kennzeichen, Anschrift etc.) durch ihre Bezeichnung auf dem Schein eindeutig zuordnen kann, ist dies auf den anderen beiden Seiten kaum möglich. Welches der Felder beschreibt z.B. den Reifendurchmesser? Prinzipiell könnte man hier mit der aufgedruckten Feldnummerierung arbeiten, allerdings ist diese in den meisten Bildern, mit denen ich im Rahmen meiner Arbeit zu tun habe, nicht lesbar.

Für solche Fälle müsste man das Modell z.B. mit Kontext-Wissen konditionieren können (Stichwort "One-/Few-Shot Learning"). Z.B. mit einem Muster-Schein, auf dem die einzelnen Felder mit Beschreibung markiert sind, sodass das Modell weiß, welche Bedeutung hinter dem jeweiligen Feld steckt (dies ist bei DocOwl 1.5 nicht möglich). Oder man müsste das Modell auf einem speziell angefertigten Datensatz fine-tunen, was allerdings aufgrund der Modell-Größe sehr aufwendig sein dürfte. Die Vorteile im Vergleich zu einem kleineren Spezialisten-Modell wären da fraglich.

Eine letztes Problem, das ich bei der produktiven Nutzung von DocOwl 1.5 sehe, ist, wie gut die Performance auf echten "dreckigen" Daten ist. Soweit es im Paper beschrieben und in den Beispielen erkennbar ist, wurde das System größtenteils auf Bildern aus PDFs, Websiten o.ä. trainiert, d.h. auf perfekten, sauberen Bildern, die bestenfalls künstlich verzerrt wurden. Erfahrungsgemäß bleibt dabei immer eine Generalisierungslücke, d.h. ein System, das im Training keine oder zu wenige "echte" Bilder wie verrauschte Scans oder Handyfotos gesehen hat, spezialisiert sich auf perfekte Bilder und macht Abstriche bei den echten. Die Performance auf "echten" Bildern bleibt also abzuwarten und lässt sich erst evaluieren, sobald die trainierten Modelle zugänglich sind ("Coming soon" heißt es noch im offiziellen Repository).

Ich warte auf jeden Fall gespannt auf die Modelle und die zugehörigen Trainingsdaten. Dann wird sich zeigen, was DocOwl 1.5 unter realistischen Bedingungen zu bieten hat und was nicht.

Problem gelöst?

Nach den Ausführungen im vorangegangenen Abschnitt dürfte klar sein, dass meine Antwort auf diese Frage durchmischt ausfällt. Aus meiner Sicht kann man sagen, dass das Problem der allgemeinen Dokumentenerkennung konzeptionell gelöst ist und es nur noch eine Frage der Zeit ist, wann die Ausleseperformance die volle marktreife erlangt hat. Dies betrifft jedenfalls das reine Parsen von Dokumenten wie durch DocOwl 1.5. Die Chat-Variante weißt die üblichen Probleme durch Halluzinationen auf, von denen fraglich ist, wann und wie das in den Griff zu bekommen ist. Was also konzeptionell das Parsen von strukturierten Daten wie Tabellen betrifft, lautet meine Antwort "Konzeptionell, ja".

Betrachtet man allerdings die Nutzbarkeit solcher Modelle unter wirtschaftlichen Gesichtspunkten, sieht die Sache etwas anders aus. Auch hier treten die von den erfolgreichen LLMs bekannten Probleme auf. Mehr noch als die reinen LLMs sind MLLMs wie DocOwl 1.5 extrem Ressourcen-hungrig. Dies trifft besonders auf MLLMs für Dokumente zu, da hier wie erwähnt hohe Auflösungen bei den Eingangsbildern benötigt werden. Wie groß das Modell im Endeffekt sein wird, lässt sich erst beantworten, wenn die trainierten Gewichte veröffentlicht sind. Meine Erwartung ist allerdings, dass es auf einer handelsüblichen GPU kaum ausgeführt werden, geschweige denn weiter trainiert werden kann. Bei den geringen Margen, die auf dem Markt der Dokumentendigitalisierung zu bekommen sind, scheint mir eine direkte wirtschaftliche Verwertung solcher MLLMs daher bis auf Weiteres wenig lukrativ. Auch hier bleibt abzuwarten, was zukünftige Entwicklungen bringen und wie stark die Modellgrößen sich in Zukunft verringern lassen.

Mein Eindruck ist also, dass sich die allgemeine Dokumentenerkennung sowohl in der Qualität der Informationsextraktion, als auch unter Betrachtung der Wirtschaftlichkeit bis auf Weiteres nicht gegen spezialisierte Modelle wird behaupten können. Letztere lassen sich bis auf extrem hohe Genauigkeiten trainieren und sehr schlank konzipieren, sodass sogar auf handelsüblichen CPUs Laufzeiten im Zehntel-Sekunden Bereich möglich sind. Der Bereich der vollautomatisierten großangelegten Dokumentenverarbeitung gehört aus meiner Sicht also weiterhin den kleinen, spezialisierten Modellen. Wo die allgemeinen MLLMs aus meiner Sicht durchaus werden Punkten können, ist bei der Teilautomatisierung von Prozessen im kleineren Stil. Verarbeitet man beispielsweise nur ab und an ein Dokument bzw. zwar viele verschiedene Arten von Dokumenten, aber jeweils in kleinerer Stückzahl, lohnt sich der Aufwand, einen Spezialisten zu trainieren eher nicht. In diesem Fall kann es sich lohnen, pro Dokument gesehen hohe Kosten in Kauf zu nehmen und im Zweifelsfall die Rückgabe des Modells noch einmal händisch zu kontrollieren.

Auf die Frage "Problem gelöst?" gibt es von mir daher ein klares "Jein!".