Die Dokumentenerkennung der Alibaba Group im Praxistest
Im vorherigen Artikel ging es um das KI-Modell DocOwl 1.5, die neueste Entwicklung der Alibaba Group auf dem Gebiet der allgemeinen Dokumentenerkennung. Die zugehörige wissenschaftliche Veröffentlichung hat viel Aufmerksamkeit erhalten und hatte einiges zu bieten: Anhand einiger Beispiele wurde das zuverlässige Auslesen und Lokalisieren von Texten in komplexen Dokumenten demonstriert. Zudem die Extraktion von Tabellen, die Analyse von Diagrammen und die Auswertung von Schlüsselinformationen. Alles in einem Modell und Open Source inkl. der zugehörigen Trainingsdaten. Auf den entsprechenden Test-Benchmarks erzielte das Modell überragende Ergebnisse im Vergleich zur Konkurrenz.
Wie bereits in meinem vorherigen Artikel beschrieben, ergaben sich allerdings einige Fragen bzgl. der Nutzbarkeit unter alltäglichen Bedingungen und unter wirtschaftlichen Gesichtspunkten: Wie schneidet das Modell auf „echten“ Daten wie z.B. unsauberen Scans oder gar Smartphone-Fotos ab? Welche Hardware-Anforderungen stellt das Modell und wie sind die Laufzeiten? Diese Fragen möchte ich in diesem Artikel klären. Dazu habe ich das Modell aus dem offiziellen Huggingface-Space geladen und einige Fotos, Scans und PDF-Dokumente vorbereitet und das Modell bzgl. verschiedener Standard-Aufgaben getestet. Die Ergebnisse der Tests sowie eine Analyse der Hardware-Anforderungen folgen unten. Zunächst aber ein kleiner Disclaimer.
Disclaimer
Wie man in der Auswertung der Tests sehen wird, fallen die Ergebnisse an vielen Stellen erstaunlich schlecht aus. Dies ist zum Einen damit zu begründen, dass es sich bei einem Teil der Test um Edge-Cases handelt, die ich gewählt habe, um die Grenzen des Modells auszuloten. Tatsächlich fällt die Performance des Modells aber auch auf Daten, die aus meiner Sicht genau die Trainingsdomäne abdecken, deutlich schlechter aus, als ich nach der Veröffentlichung erwartet hatte.
Lässt man die Möglichkeit einer problematischen Auswahl der Show-Cases in der Originalveröffentlichung (wie ein Test-Train Leak in den Daten) außer Betracht, kann ich dafür keine zufriedenstellende Erklärung finden. Vielleicht habe ich das Modell falsch verwendet, allerdings habe ich mich an die Beispiele vom Original-Repository gehalten und viele Variationen durchgespielt. Zum Teil habe ich eins zu eins den Code aus offiziellen Antworten zu Github-Issues verwendet, was auch keine Veränderung gebracht hat. Zudem funktionieren die selben Prompts bei manchen Bildern, bei anderen aber nicht.
Bedienfehler meiner Seite halte ich daher für unwahrscheinlich. Vielleicht möchte es allerdings jemand selbst ausprobieren: Die Online-Demo ist frei verfügbar und einfach zu bedienen. Das Format der Prompts kann man aus den unten gezeigten Beispielen entnehmen. Vielleicht findet ja jemand einen besseren Zugang zum Modell.
1. Auslesen lokalisierter Texte
Der erste Use-Case, den ich hier untersuchen möchte, sollte zum Grundrepertoire einer guten allgemeinen Dokumentenerkennung gehören: Das gezielte Auslesen bestimmter Textbereiche im Dokument. Dazu lokalisiert man zunächst einen relevanten Textbereich (z.B. mit einem vorgeschalteten Text-Detektor) und instruiert anschließend das Modell, diesen Text auszulesen. Im Folgenden habe ich die Fähigkeiten von DocOwl 1.5 auf dieser Aufgabe für verschiedene Dokumententypen getestet, wobei das Format der Anfragen der Konvention aus der Veröffentlichung zu DocOwl 1.5 entspricht.
Der erste Fall, die mittlere Seite eines gescannten Fahrzeugscheins in guter Qualität, ist in Abb. 1 zu sehen.
(Abbildung 1: Lokalisierung und Auslesen verschiedener Felder auf einem gescannten Fahrzeugschein. Die roten Textboxen wurden nachträglich eingefügt, das Modell hat sie nicht gesehen.)
Der Text wurde in allen drei gezeigten Fällen offensichtlich gut lokalisiert, da die Leseergebnisse zu dem passen, was das Modell auslesen sollte. Das räumliche Verständnis des Modells scheint also prinzipiell zu funktionieren. Beim Auslesen der Texte zeigt das Modell auch eine solide Performance: Im zweiten Fall macht es zwar mehrere Fehler (das „l“ in „Spl.“ sieht tatsächlich eher aus wie eine Eins), in den anderen beiden Fällen liest das Modell aber fehlerfrei. Das finde ich einigermaßen beeindruckend, wenn man bedenkt, dass das Modell ohne jegliches Nachtraining auf eine ihm unbekannte Dokumentenklasse angewendet wurde. Es zeigen sich hier allerdings auch schon erste Schwächen beim Auslesen der Texte.
Soweit, so gut: Gescannte Dokumente sind tatsächlich in der Trainingsmenge von DocOwl 1.5 enthalten. Wie sieht es aus, wenn man sich deutlich aus dem Bereich der Trainingsmenge entfernt? Dazu ist in Abb. 2 ein Foto eines Fahrzeugscheins zu erkennen.
Abbildung 2: Foto eines Fahrzeugscheins zur Auswertung der Modell-Performance. Die roten Textboxen wurden nachträglich eingefügt, das Modell hat sie nicht gesehen.
Die erste auf diesem Foto getestete Anfrage gilt dem Fahrzeughersteller (="TESLA (USA)"):
Query: „Identify the text within the bounding box <bbox>422, 448, 510, 473</bbox>“DocOwls Antwort:
DocOwl 1.5: „2017/1151:WLTP“Dieser Text steht tatsächlich vier Zeilen weiter unten, ist davon abgesehen aber korrekt ausgelesen. Das sieht wie eine Schwäche bei der Lokalisierung aus.
Das gleiche passiert allerdings beim Versuch, das Kennzeichen oder die Reifenspezifikationen (ganz rechts in der Mitte) auszulesen. DocOwl 1.5 bleibt bei der Antwort „2017/1151:WLTP “. Beim Auslesen des Fahrzeugmodells („Model 3“), kommt schließlich die Antwort „(5“, was eher wie eine Halluzination wirkt.
Was genau im Modell beim Auslesen dieses Fotos passiert, ist schwer zu sagen. Es wirkt, als sei das Modell einfach überfordert. D.h. es hat kann natürlich keine Überforderung fühlen, allerdings beobachtet man oft, dass Modelle erratische, nicht nachvollziehbare Ergebnisse liefern, wenn sie mit Daten konfrontiert werden, die weit außerhalb ihrer Trainingsmenge liegen. Eben wie Menschen, die mit einer neuen Aufgabe vollkommen überfordert sind. In diesem Sinne ist das gezeigte Verhalten also zu erwarten.
Nachdem wir das Modell nun ein wenig an seine Grenzen getrieben haben, folgt hier noch ein Beispiel, das durch die Trainingsmenge des Modells abgebildet sein sollte: Eine „perfekte“ Rechnung, direkt aus einem PDF-Dokument in eine Bilddatei umgewandelt. Hier gibt es keinerlei Verunreinigungen wie bei Scans oder Fotos, die Ausrichtung des Dokuments ist perfekt, die Schrift absolut sauber.
Vergleichbare Dokumente sind in großen Mengen in den Trainingsdaten von DocOwl 1.5 enthalten, entsprechend gut sollte das Ausleseergebnis ausfallen. Ein Heimspiel quasi.
Abbildung 3: Lokalisierung und Auslesen verschiedener Felder auf einer deutschen Rechnung (direkter PDF-Export). Die Textboxen wurden nachträglich eingefügt, das Modell hat sie nicht gesehen.
Schaut man sich die Ergebnisse allerdings einmal an, sind sie tatsächlich eher enttäuschend. Im Beispiel aus Abb. 3 wurde der Abrechnungszeitraum oben rechts im Bild noch einwandfrei ausgelesen. Bei dem Eintrag aus dem Tabellenkopf unten rechts zeigt sich allerdings schon ein erster Fehler: das „(EUR)“ am Anfang des Eintrags wurde halluziniert. Das sollte eigentlich nicht passieren.
Versucht man nun noch die Umsatzsteuer-ID des Rechnungsstellers oben links auszulesen, bekommt man als Antwort „Rechnungsdatum 2024/01/13“, was eine Zeile darüber rechts am Rand steht, also offensichtlich deutlich falsch lokalisiert wurde. Wieso das passiert, ist schwer nachzuvollziehen. Eine Idee wäre, dass es daran liegt, dass es sich um ein deutsches Dokument handelt, das Modell allerdings auf einem englischen Datensatz trainiert wurde. Das würde meines Erachtens nach allerdings eher zu einer Leseschwäche führen, also z.B. zu einzelnen Buchstabenfehlern. Dass dadurch die Lokalisierung grob durcheinander gerät, dürfte unwahrscheinlich sein. Tatsächlich sind die Texte an sich ja fehlerfrei gelesen. Es wurden lediglich Teile halluziniert oder falsch lokalisiert.
Um ein Problem mit der Sprache auszuschließen, kann man das gleiche Experiment mit einem englischen Dokument durchführen. Z.B. auf einem Muster einer englischen Rechnung von canva.com (siehe Abbildung 4). Das Ergebnis ist vergleichbar: Ein Feld wurde sauber gelesen, zwei falsch lokalisiert.
Abbildung 4: Lokalisierung und Auslesen verschiedener Felder auf einer englischen Rechnung (direkter PDF-Export). Die Textboxen wurden nachträglich eingefügt, das Modell hat sie nicht gesehen. (Quellen: canva.com)
Hier läuft offensichtlich etwas schief.
2. Auslesen und Lokalisieren von Tabellen
Der zweite Use-Case, den ich hier betrachten möchte, ist das Auslesen von Tabellen. D.h. das Parsen von Tabellen ins Markdown Format. Letzteres ist ein gängiges Datenformat zur Speicherung strukturierter Daten, das sehr einfach gehalten, aber vergleichsweise ausdrucksstark ist.
Dazu halte ich mich wieder an die Konvention der DocOwl-Veröffentlichung und verwende Prompts in der Form „Convert the table into Markdown format“ oder „Parse the table into Markdown syntax“. Beide haben in etwa die gleichen Ergebnisse geliefert, weswegen ich nur die erste Variante zeige.
Zunächst einmal ein praxisnahes Beispiel: Der Versuch, Tabellen direkt aus den beiden gezeigten Rechnungsdokumenten auszulesen (blaue Boxen in Abb. 3 und Abb. 4). Für die obere Tabelle der deutschen Rechnung aus Abb. 3 ergibt sich:
Query: „Convert the table within the bounding box <bbox>63, 433, 935, 508</bbox> into Markdown format.“DocOwl 1.5: „| Rechnung | Preis/Einheit (EUR) | Anzahl | Steuern (%) | Total (EUR) |
| --- | --- | --- | --- | --- |
| Beschreibung | 8.39 | 1 | 19 | 8.39 |
| Premium- | 8.39 | 1 | 19 | 8.39 |
| Konnektivität | 8.39 | 1 | 19 | 8.39 |
| Teilsumme | 8.39 | 1 | 19 | 8.39 |
| Gesamtbetrag (EUR) | 9.99 | 1 | 19 | 9.99 |
| Code | Gesamtbetrag (EUR) | Steuern (%) | Gesamtbetrag (EUR) | Gesamtbetrag (EUR) |
| DESR | 8.39 | 19.00 | 1.60 | 1.60 |
| Tesla Germany GmbH Ludwig-Prandtl-Straße 27 - 29, 12568 Berlin, Deutschland Amtgericht Charlottenburg, HRB 235281 B Geschäftsführer: Stephan Werkman, Simon Zwahlen, Joseph Gruber“Und für die untere:
Query: „Convert the table within the bounding box <bbox>63, 433, 935, 508</bbox> into Markdown format.“DocOwl 1.5: „Tesla Germany GmbH
Ludwig-Prandtl-Straße 27 - 29
12526 Berlin DE
UST-IdNr: DE265761887
[...]
Code Gesamtbetrag (EUR) Steuer (%) Gesamtsumme Steuern (EUR)
DESR 8.39 19.00 1.60“Der erste Versuch ergibt immerhin eine Markdown Tabelle, allerdings mit Zeilen und Spalten vermischt und auch beide Tabellen miteinander kombiniert. Bei der zweiten Tabelle liest DocOwl 1.5 lediglich teile des Dokumententextes aus. Das Gleiche passiert beim Versuch, die Tabelle in der englischen Rechnung auszulesen. Lokalisation und Extraktion von Tabellen gleichzeitig funktioniert also offensichtlich nicht.
In der Veröffentlichung zu DocOwl 1.5 sieht es allerdings auch so aus, als wäre die Tabellenextraktion nicht in Kombination mit der Lokalisierung trainiert worden. Daher hier ein weiterer Versuch: Das Auslesen der isolierten Tabellen.
3. Auslesen von isolierten Tabellen
Zum Auslesen der isolierten Tabellen habe ich die Tabellen der oben gezeigten Rechnungsdokumente ausgeschnitten und das Modell wie gehabt entlang der Konvention aus der Veröffentlichung zu DocOwl 1.5 instruiert.
Abbildung 5: Auslesen der isolierten Tabellen aus Abb.3.
Die erste Tabelle der deutschen Rechnung führt zur Ausgabe eines Teils des Tabellenkopfes gefolgt von der Ausgabe tausender Leerzeichen. Hier bekommt das Transformer-Modell im LLM für die Text-Ausgabe offensichtlich erst sehr spät das End-Token, das die Ausgabe stoppt. Möglicherweise liegt das daran, dass im Tabellenkopf die Trennzeichen zwischen den Spalten fehlen?
Die zweite Tabelle funktioniert jedenfalls einwandfrei. Der Text ist fehlerfrei ausgelesen und die Ausgabe ist gültiges Markdown. Das Gleiche gilt für die Tabelle aus der englischen Musterrechnung. Sehr gut! Aus meiner Sicht funktioniert das Auslesen isolierter Tabellen aus sauberen PDF-Exporten also prinzipiell gut, auch wenn das Modell Instabilitäten aufweist, die für eine produktive Nutzbarkeit behoben werden müssten.
Abbildung 6: Auslesen der isolierten Tabelle aus Abb.4.
4. Extraktion von Schlüsselinformationen
Um das Extrahieren von Schlüsselinformationen zu testen, habe ich mich auf die Untersuchung der beiden Rechnungen konzentriert, da die gezeigten Fahrzeugscheine keine bzw. nicht lesbare Feldbezeichner aufweisen. Eine allgemeiner Dokumentenerkennung, die nicht explizit auf solchen Dokumenten trainiert wurde, hat hier daher keine Chance die aufgedruckten Texte einer semantischen Bedeutung zuzuweisen.
Im Falle der beiden Rechnungsdokumente zeigt sich ein durchwachsenes Bild. Auf die Frage nach dem Rechnungssteller und dem Gesamtbetrag der deutschen Rechnung antwortet das Modell korrekt. Die Frage nach dem Rechnungsempfänger beantwortet es jedoch mit „Tesla Germany GmbH“. Hier ist allerdings wieder anzumerken, dass das Modell nicht auf Deutsch trainiert wurde (auch wenn das zugrundeliegende LLM weitestgehend sprachagnostisch sein dürfte).
Abbildung 7: Extraktion verschiedener Schlüsselinformationen einer deutschen Rechnung (direkter PDF-Export). Die Textboxen wurden nachträglich eingefügt, das Modell hat sie nicht gesehen.
Wie sieht es also bei der englischen Muster-Rechnung aus? Das Ergebnis ist ähnlich. In diesem Fall sind Rechnungsempfänger und Gesamtsumme korrekt, der Rechnungssteller allerdings falsch. Fragt man das Modell hingegen „Who is the sender?“ kommt das korrekte Ergebnis.
Abbildung 8: Extraktion verschiedener Schlüsselinformationen einer englischen Rechnung (direkter PDF-Export). Die Textboxen wurden nachträglich eingefügt, das Modell hat sie nicht gesehen.
Das Ergebnis ist also auch in diesem Fall insgesamt durchwachsen, auch wenn die meisten Schlüsselinformationen korrekt ausgelesen wurden.
Hardware-Anforderungen und Laufzeit
Alle oben beschriebenen Experimente wurden auf einer NVIDIA GeForce RTX 4090 mit 24 GB VRAM durchgeführt und damit auf der zur Zeit stärksten frei verkäuflichen Consumer-GPU. Zum Vergleich: Eine Tesla T4, welche die Standard Cloud-GPU für Inference-Aufgaben ist (d.h. für die reine Ausführung eines Modells, nicht fürs Training), verfügt über 16 GB VRAM und erreicht etwa 1/8 der Rechengeschwindigkeit einer Geforce 4090. Bei Kosten von ca. 300€ pro Monat pro GPU-Instanz (ggf. günstiger bei Anwendung von Laufzeitrabatten).
Während der Inference wurden ca. 19 GB VRAM auf der GeForce 4090 belegt, was die Kapazitäten einer Tesla T4 überschreitet, während die Laufzeit bei etwa 0,7-3,6 Sekunden pro Ausführung lag, je nach Länge der Rückgabe des Modells (ausgenommen aus dieser Betrachtung ist der fehlgeschlagene Versuch der Tabellenextraktion, der zur Ausgabe tausender Leerzeichen führte).
Beide Werte, die Speichernutzung sowie die Laufzeit, sind recht hoch für ein einzelnes KI-Modell. Verfügt man also über kein eigenes Rechenzentrum und möchte DocOwl 1.5 in der Cloud hosten, wäre die günstigste Variante eine Maschine mit zwei Tesla T4, d.h. einem Kostenpunkt von insgesamt etwa 600€ pro Monat pro Modell-Instanz (ggf. abzüglich Rabatte). Und das bei einer zu erwartenden Laufzeit von etwa 6-24 Sekunden für gängige Anfragen. Um vertretbare Laufzeiten zu erreichen müsste man auf stärkere GPU Modelle ausweichen wie z.B. die A100, welche allerdings Kosten in Höhe von 1000-2000€ pro Monat verursacht, je nach Langzeitrabatten und benötigter Hardware-Peripherie.
Fazit
Nach der Untersuchung mehrerer Use-Cases auf verschiedenen Dokumenten-Typen zeigt sich ein sehr durchwachsenes und insgesamt ernüchterndes Bild von der Performance von DocOwl 1.5. Im Falle eines guten Scans und für perfekte PDF-Exporte ist die Qualität der Leseergebnisse durchaus vertretbar, auch wenn vereinzelt Lesefehler und mehrfach Fehllokalisierungen zu sehen waren. Das Auslesen von isolierten Tabellen funktionierte z.T. auch gut, hat aber in einem Fall zu einer Instabilität des Modells geführt. Schlüsselinformationen wurden in vielen Fällen gut extrahiert, allerdings ist auf das Ergebnis wenig Verlass, da in beiden untersuchten Fällen z.T. Absender und Empfänger verwechselt wurden.
Generell hätte ich nach den in der Veröffentlichung zu DocOwl 1.5 gezeigten Ergebnissen erwartet, dass das Auslesen von perfekten PDF Dokumenten einwandfrei funktioniert. Insgesamt wirkt DocOwl 1.5 eher ein erstes Proof of Concept, das die prinzipielle Machbarkeit einer allgemeinen Dokumentenerkennung zeigt, allerdings noch einige Arbeit bis zur produktiven Nutzbarkeit benötigt. Nach einer ersten Sichtung der Trainigsdaten von DocOwl 1.5 vermute ich, dass diese Arbeit vor allem auf Datenseite (Diversifizierung und Qualitätssicherung) zu leisten sein dürfte.
Auch die wirtschaftliche Nutzbarkeit von DocOwl 1.5 würde ich kritisch beurteilen. Um eine API aufzubauen, die für Kunden vertretbare Laufzeiten bietet (die Frage, ob Kunden mit der Leseperformance zufrieden wären, sei an dieser Stelle ausgeklammert), müsste man auf teure GPU Modelle zurückgreifen, die schnell zu mehreren 1000 € laufender Kosten pro Monat führen können, für wenige gehostete Modell-Instanzen. Solche Beträge dürften sich in meinen Augen schwer auf Kunden umlegen lassen.
Comments