- Beim Extrahieren von Informationen aus komplexen Dokumenten bewahren traditionelle OCR- und Parsing-Verfahren die Bedeutung oft nicht zuverlässig
- Morphik setzt mit visuellen Dokument-Embeddings auf Basis des ColPali-Modells einen Ansatz um, der sogar Tabellen, Diagramme und Layout-Kontext direkt versteht
- Gegenüber bestehenden Pipelines ist diese Methode bei Genauigkeit und Informationserhalt deutlich überlegen und erreichte in Benchmark-Tests bis zu 95,56 % Genauigkeit
- Zusätzlich wurde durch die Einführung von MUVERA und Turbopuffer die Geschwindigkeit bei der Suche in großen Dokumentbeständen verbessert
- Ziel ist künftig eine praxisnahe Automatisierung von Dokumentarbeit, etwa durch Multi-Dokument-Inferenz, Workflow-Integration und Interpretation auf Expertenniveau
Grenzen des Parsings komplexer Dokumente und die Mühen von RAG
- Beim Versuch, Informationen aus komplexen PDF-Dokumenten mit gemischten Diagrammen, Schaubildern und Tabellen zu extrahieren, geht in OCR- und Parsing-Pipelines häufig genau die Information verloren, die man eigentlich benötigt
- In realen Szenarien zeigen sich die Grenzen klassischer Pipelines besonders bei verschachtelten Tabellen, wichtigen Diagrammen, stark kommentierten technischen Dokumenten und sogar Handbüchern ohne Text
- Schritte einer klassischen Pipeline:
- Anwendung von OCR auf PDFs (Zahlen oder Zeichen können falsch gelesen werden)
- Versuch der Trennung von Tabellen/Diagrammen mit einem Layout-Erkennungsmodell (mit hoher Fehlerwahrscheinlichkeit)
- Rekonstruktion der Lesereihenfolge (wobei der visuelle Fluss verloren gehen kann)
- Erkennung von Diagramm-Beschriftungen (Nuancen gehen oft verloren)
- Text-Chunking (zusammengehörige Informationen können getrennt werden)
- Erzeugung von Vektor-Embeddings und Speicherung in einer Vektor-DB (Positionsinformation und Kontext gehen verloren)
- Beispiel: Selbst eine einfache Tabelle kann dazu führen, dass „1,000“ als „l,0O0“ gelesen wird oder dass Tabelle und Kopfzeile getrennt werden, sodass Summenberechnungen scheitern
- Häufige reale Informationsverluste sind etwa, dass Diagrammlegenden als Fließtext missverstanden werden oder Prozentwerte an falsche Stellen verstreut landen
Neuer Ansatz: Wechsel zu visuell basierter Dokumentverarbeitung
- Das Morphik-Team fand den Wendepunkt mit der Frage: „Was wäre, wenn man Dokumente wie Menschen als visuelle Objekte versteht?“
- Durch aktuelle Forschung (ColPali) und Fortschritte bei Vision Language Models (VLMs) ist es möglich, Bilder direkt zu embeddieren und so den Gesamtkontext sowie visuelle Informationen eines Dokuments ohne Parsing oder OCR zu erhalten
- Jede Dokumentseite wird als hochauflösendes Bild verarbeitet und in Patch-Einheiten zerlegt, um Embeddings zu erzeugen, die sowohl visuelle als auch textuelle Informationen abbilden
- Der SigLIP-So400m Vision Transformer erzeugt Embeddings visueller Patches, während das Sprachmodell PaliGemma-3B die Dokumentstruktur versteht
- Für Anfragen wie „Umsatztrend in Q3“ wird mit einer Late-Interaction-Suche die relevante Information präzise extrahiert, einschließlich visueller Hinweise wie Text, Diagramme, Tabellen und Farben
- Position im Dokument, Layout, Farben, Graphverläufe und alle weiteren visuellen Informationen bleiben erhalten – ähnlich dazu, wie Menschen ein Dokument auf einen Blick erfassen
Vergleich zwischen traditionellem Parsing und dem ColPali-Ansatz
- In klassischen parsingbasierten Pipelines geht bei jedem Schritt Information verloren, und weil Text- und Bild-Embeddings getrennt sind, lassen sich räumliche Beziehungen im Dokument nicht interpretieren
- Der ColPali-Ansatz hingegen integriert alle Informationen in einem einzigen visuellen Embedding-Raum und bewahrt damit die Gesamtbedeutung und den Kontext des Dokuments
- In realen Benchmarks (mit Fokus auf Finanzdokumente, auf öffentlichen Datensätzen) erzielte Morphik (auf ColPali-Basis) bis zu 95,56 % Genauigkeit; zum Vergleich: bestehende LangChain+OpenAI-Text-Embeddings kamen auf 72 %, OpenAI File Search nur auf 13,33 %
- Im ViDoRe-Benchmark erreichte der visuelle Ansatz gegenüber klassischen Parsing-Verfahren eine um mehr als 14 Prozentpunkte höhere Leistung nach nDCG@5
Performance-Optimierung und Einsatz in der Praxis
- Der Nachteil des frühen Ansatzes war zunächst die geringere Geschwindigkeit durch hohe Rechenlast, da die Architektur eine Vektorsuche für jeden Patch erforderte und damit für zig Millionen Anfragen pro Sekunde ungeeignet war
- Unter Bezug auf das MUVERA-Paper wurde ein Verfahren eingeführt, das Multi-Vektor-Suche durch Single-Vektor-Suche ersetzt (Encoding mit fixer Dimension)
- In Kombination mit der spezialisierten Vektor-DB Turbopuffer wurde die Abfragegeschwindigkeit von 3–4 Sekunden auf etwa 30 ms verbessert
- Dadurch wurde die Suche in Millionen von Dokumenten mit deutlich höherer Geschwindigkeit als beim herkömmlichen Text-Parsing möglich
Anwendungsfelder und einfache API
- Unterstützt hochpräzise Suche in unterschiedlichsten Dokumenttypen ohne Verlust visueller Struktur und Informationen
- Finanzdokumente, bei denen komplexe Tabellen und Diagramme entscheidend sind
- Technische Handbücher mit Fokus auf Zeichnungen
- Layoutbasierte Informationsextraktion aus Rechnungen und Belegen
- Verständnis visueller und numerischer Inhalte in Forschungsarbeiten
- Erkennung layoutbasierter Beziehungen in medizinischen Akten
- Die API ist sehr einfach aufgebaut: Dokument hochladen und anschließend in natürlicher Sprache fragen; unterstützt werden Anfragen wie „Zeige mir alle Verträge mit Strafklauseln über 10.000 Dollar“
Blick nach vorn: Multi-Dokument-Intelligenz und tieferes Verständnis
- Multi-Dokument-Intelligenz: Funktionen zur gegenseitigen Referenzierung und Informationsverfolgung über mehrere Dokumente hinweg sind in Entwicklung
- Über die Suche in einem einzelnen Dokument hinaus wird das Verfolgen und Schlussfolgern von Beziehungen zwischen mehreren Dokumenten unterstützt (z. B. von Vertragsklauseln über regulatorische Dokumente bis hin zu Ausführungshandbüchern)
- Agentisches Verständnissystem: Über einfaches Frage-Antworten im Dokument hinaus soll logisches Schlussfolgern zwischen Chunks automatisiert werden, etwa Klausel-Extraktion → Prüfung mit anderen Dokumenten → Cross-Check von Details
- Workflow-Integration: Die Dokumentautomatisierung soll für reale Geschäftsprozesse weiterentwickelt werden, etwa beim Vergleich von Bedingungen über mehrere Verträge hinweg oder bei der Nachverfolgung der Historie technischer Entscheidungen
Grenzen und nächste Ziele
- Der aktuelle Ansatz erreicht noch nicht Interpretation auf Expertenniveau und kontextuelle Urteilsfähigkeit
- Besonders bei tiefgehender Interpretation wie durch Finanzexperten bestehen noch technische Lücken; auch Zuverlässigkeit und Quantifizierung von Unsicherheit erfordern für Enterprise-Anforderungen weitere Entwicklung
- Die Kombination visuellen Verständnisses mit domänenspezifischen Wissensgraphen, kausales Schlussfolgern und die Bereitstellung von Verlässlichkeitsmetriken sind zentrale nächste Aufgaben
Fazit
- Dokumente sollten als visuelle Wissensobjekte behandelt werden; über die Grenzen des Parsings hinaus ist bildbasiertes Dokumentverständnis in RAG-Umgebungen die bessere Lösung
- Morphik will einen neuen Standard für die Extraktion von Dokumentinformationen setzen und zielt auf die Automatisierung komplexer Dokument-Workflows sowie den Einsatz in realen Arbeitsprozessen
- Weitere Funktionen lassen sich unter morphik.ai ausprobieren
1 Kommentare
Hacker-News-Kommentare
Es gibt mehrere grundlegende Probleme, die man unbedingt kennen sollte.
LLMs werden in der Regel zunächst mit 4k Text-Token vortrainiert und danach auf lange Kontextfenster erweitert. (Von 4000 auf 4001 zu gehen ist einfach, aber bei Bildern ist das wegen der anderen Tokenisierung nicht möglich.)
Das führt dazu, dass man außerhalb der Trainingsverteilung landet, und sobald mehr als zwei oder drei Bilder verarbeitet werden, treten Halluzinationsprobleme massiv auf.
PDFs mit einer Auflösung von 1536×2048 verbrauchen 3- bis 5-mal mehr Token als Text, wodurch die Inferenzkosten steigen und Antworten langsamer werden.
Bei niedrigerer Auflösung werden die Bilder unscharf.
Bilder sind schon in ihrer Originalgröße schwergewichtig, sodass allein das Herunterladen der benötigten Bilder pro Anfrage zusätzliche Latenz verursacht.
In kleinen Benchmarks funktioniert das bei Finanzdokumenten mit vielen Diagrammen und Tabellen natürlich besser als einfaches Text-Chunking.
Persönlich würde ich gern sehen, wie es wäre, Bilder wie bei Gemini per OCR annotieren zu lassen und dann die Ergebnisse zu vergleichen.
Ein End-to-End-Bildansatz ergibt in Spezialfällen Sinn, etwa bei Patenten oder Architekturdiagrammen, ist aber wirklich das letzte Mittel.
LLMs haben das Problem, bei unlesbaren Stellen plausibel wirkenden Text zu erfinden, was das Ergebnis noch chaotischer machen kann.
Zum Beispiel funktionierte GPT4.1 bei einem Screenshot in der Größe 1296×179 perfekt, aber wenn man ihn auf 50 % verkleinert und mit 650×84 eingibt, gibt es statt "Pdf's at 1536 × 2048 use 3 to 5X more tokens" den Text "A PNG at 512x 2048 is 3.5k more tokens" zurück.
Meistens macht es das richtig, aber man muss auf solche veränderten feinen Details achten.
Eine interessante Eigenschaft der gemma3-Familie ist, dass der Speicherbedarf bei der Verarbeitung nicht steigt, wenn man die Eingabebildgröße erhöht.
Das liegt daran, dass der Encoder der zweiten Stufe auf Token fester Größe komprimiert.
In der Praxis ist das ziemlich nützlich.
Aber dann müsste der gesamte zu verarbeitende Dokumentensatz zwingend durch ein großes VLM laufen.
Das könnte zu teuer und zu langsam werden.
Hier gibt es eindeutig einen Trade-off.
In den meisten Fällen war der aktuelle Ansatz am effektivsten.
Es gibt Fälle, in denen man alles in ein LLM steckt, obwohl das je nach Situation unpassend sein kann.
Nicht alles muss unbedingt mit einem LLM verarbeitet werden.
Das könnte sich zu einer Idee weiterentwickeln, die die RAG-Pipeline verändert.
Für jedes RAG-Ergebnis könnte man in einem Modellschritt direkt aus dem Bild die Informationen extrahieren, die für die Nutzeranfrage relevant sind, und diese (Text-)Ergebnisse als Eingabe für die finale Generierung sammeln.
So könnte man die Token-Grenzen mehrerer Bilder umgehen und den Bildverständnisprozess parallelisieren.
Meine Kollegen und ich haben so etwas vor sechs Monaten für eine französische Regierungsbehörde implementiert.
Wir stellen es hier als Open Source bereit: https://github.com/jolibrain/colette
Es ist nicht unser Kerngeschäft und liegt eher brach, aber mit etwas Tuning arbeitet es ziemlich effizient.
Das eigentlich Spannende ist, dass sich die gesamte Pipeline vollständig differenzierbar machen lässt, sodass man viz rag speziell für bestimmte Datensätze feinabstimmen kann.
Auch das Layout-Modell lässt sich anpassen, was präzises Dokumentenverständnis ermöglicht.
In den meisten Fällen ist das größte Hindernis der Bedarf an hochwertigen Evaluationsdatensätzen. (Das ist immer das Hindernis.)
Ich habe mehrere Benchmark-Studien zu OCR vs. Bild + allgemeines LLM durchgeführt: https://getomni.ai/blog/ocr-benchmark
Das größte Problem bei direkter Extraktion aus Bildern sind mehrseitige Dokumente.
Bei Einzelseiten war direktes Bild minimal besser als (OCR=>LLM vs. Bild=LLM), aber ab mehr als fünf Bildern fiel die Genauigkeit im Vergleich zu einem OCR-First-Ansatz stark ab.
Tatsächlich ist Long-Context-Recall schon bei Text eine schwierige Aufgabe, auch wenn LLMs dafür optimiert sind, während Long-Context-Recall bei Bildern noch deutlich hinterherhinkt.
Es ist auch recht effektiv, direkt über Bilder eine kleine LLM-Transformationsschicht zu legen. (Also nicht direkt OCR zu machen, sondern fünf Bilder gleichzeitig an ein kleines Vision-Modell zu schicken, das nur die wichtigsten Punkte des Dokuments extrahiert.)
Derzeit erforsche ich, wie man den Cache oder die Attention-Maps von LLMs anpassen kann, damit größere Bild-Batches besser funktionieren.
Ansätze wie Sliding Window oder Infinite Retrieval wirken vielversprechend.
Meine persönliche Vermutung ist, dass Bild-Long-Context bald kein großes Problem mehr sein wird, wenn man sieht, wie schnell sich multimodale Modelle weiterentwickeln.
Dieser Blogpost macht gute Punkte zur Nutzung von Vision-Modellen für Retrieval, aber ich möchte auf ein paar Probleme hinweisen.
Document Parsing ist die Umwandlung eines Dokuments in strukturierten Text wie Markdown/JSON (oder bei Extraktion in schema-konforme Ausgaben).
RAG ist nur eine davon, es gibt noch viele andere Anwendungsfälle.
ColPali ist großartig für Retrieval, aber zumindest nativ nicht für reines Document Parsing geeignet.
Der Autor erwähnt hauptsächlich Visual-Retrieval-Benchmarks.
Oft funktioniert das besser als Standard-OCR, aber
a. es gibt weiterhin Long-Tail-Probleme bei der Genauigkeit
b. Metadaten wie Confidence Scores und Bounding Boxes fehlen
c. auch eine Screenshot-Pipeline erfordert Aufwand, wenn sie ausgereift sein soll
Bild-Token sind viel leistungsfähiger, aber Text-Token sind bei den Speicherkosten deutlich günstiger, sodass man beim Retrieval gegen ganze Dokumente statt gegen Chunks abfragen kann.
(Zur Einordnung: Ich bin CEO von llamaindex und habe mit LlamaCloud sowohl Parsing als auch Retrieval gemacht; das ist nur eine allgemeine Sicht.)
Ich habe letztes Jahr ziemlich viel Zeit in den Bau eines Systems zur Analyse von Patentdokumenten investiert.
Patente enthalten viele unterschiedliche Inhaltstypen wie abstrakte Diagramme, chemische Formeln und mathematische Gleichungen, daher ist es wirklich knifflig, die Daten für LLMs passend vorzubereiten.
Die einfachste Methode, die ich gefunden habe, war, jede Seite wie ein Foto zu konvertieren und dann das LLM ein JSON mit einer Beschreibung des Inhalts sowie Metadaten erzeugen zu lassen, etwa Seitennummer und Anzahl visueller Elemente.
Komplexe Bilder kann man einfach vom Modell beschreiben lassen.
So lässt sich das JSON leicht in einen beliebigen Vector Store einbetten.
Es ist schwer zu sagen, wie kosteneffizient das ist, aber dieser Ansatz ist einfacher und wirksamer als das, was der Autor vorschlägt.
Wenn ein Modell zum Beispiel aus einem Diagramm die x/y-Paare größtenteils korrekt extrahiert, kann es trotzdem passieren, dass bei einer gezielten Frage nach einem bestimmten x/y-Wert etwas ausgelassen wird.
Wenn man dem Modell in der Inferenzphase das Bild direkt zeigt, kann es genau auf das antworten, wonach der Nutzer fragt, deshalb ist dieser Ansatz effektiver.
Das einzige echte Hindernis hier ist die Qualität des Retrievals, und das ist ein relativ kleines Problem.
Wenn der passende Kontext sauber geliefert wird, deckt das LLM den Rest von selbst ab.
Sonst steigt die Zahl der Probleme bei OCR, Parsing, Bildbeschreibung usw. sprunghaft an.
Es zeigt aber auch, dass die Chance für LLMs vor allem darin liegt, bestehenden Wert neu zu klassifizieren oder neu zu verarbeiten, etwa bei Patentdokumenten.
In den 90er- und 2000er-Jahren waren Softwareunternehmen erfolgreich, indem sie bestehende Papierunterlagen in Datenbanken überführt haben.
Neue und wertvolle Datensätze von Grund auf zu schaffen, erfordert weiterhin viel Investition und Aufwand.
Meiner Erfahrung nach ist dieser Ansatz nicht besonders gut.
Je nach Schriftart sind o und 0 schwer zu unterscheiden.
Wenn man Dokumente (doc/xls/pdf/html) in Bilder umwandelt, gehen genau solche Unterscheidungsinformationen verloren.
Bei Seriennummern usw. können selbst Menschen das manchmal nicht mehr auseinanderhalten.
Deshalb ist es durchaus vernünftig, PDFs zu rendern und dann daraus zu extrahieren.
Bei den übrigen Formaten ist es besser, das Dokument direkt zu parsen.
Praktisch ist es bei der Gestaltung von Seiten jedoch oft viel effektiver fürs Debugging, dem Modell das echte Bild zu zeigen, statt nur den Code zu übergeben.
Probleme wie 1 vs I und 0 vs O gibt es tatsächlich, aber bei Dokumenten mit vielen Diagrammen und Charts habe ich oft erlebt, dass reine Bilder viel einfacher funktionieren.
(Das könnte Selection Bias sein.)
Ich habe mehrere Minuten versucht, einen Terminplan in Gemini zu kopieren und dazu Fragen zu stellen, aber selbst als HTML funktionierte das nicht richtig.
Am Ende habe ich einen Screenshot gemacht, unnötige Teile mit schwarzen Kästen abgedeckt und das Bild eingegeben, und dann funktionierte es sehr gut.
Ich bin neugierig, weil dieses Problem mit multimodalem RAG doch eigentlich schon gelöst zu sein scheint.
Mit Flash 2.5, Sonnet 3.7 usw. bekomme ich ziemlich zufriedenstellende Ergebnisse bei der Bildanalyse.
Ich habe eher das Gefühl, dass ich mit Bildern bessere Antworten bekomme als mit Text.
https://www.youtube.com/watch?v=p7yRLIj9IyQ
Allerdings sind Multi-Vektoren im Rohzustand, die Grundlage von multimodalem RAG, sehr schwer zu handhaben, und Ähnlichkeitsberechnungen sind extrem teuer, was das Skalieren erschwert.
Quantisierung, Umwandlung in Single-Vektor-Repräsentationen (Encodings mit fester Dimension), Indexierungsoptimierung usw. sind nötig.
Genau daran arbeiten wir bei Morphik.
Ich habe ebenfalls einmal versucht, alle Rechnungen auf einen Schlag zu scannen: Ich habe nur die Anhänge aus dem Postfach extrahiert, dann per Skript einzeln hochgeladen und „Rechnung: ja/nein“ sowie jede Position, den Firmennamen, das Datum, die Rechnungsnummer usw. extrahieren lassen.
Insgesamt war die Erkennungsrate hoch, und obwohl die LLM-Aufrufe über drei Stunden liefen, war mir das egal, weil alles automatisiert war.
Danach ließ ich das LLM sogar mit Kontoauszügen abgleichen, und nur einige Rechnungen fehlten, die nicht als Anhang eingegangen waren.
Allerdings war das Matching zwischen Rechnung und Kontoauszug ziemlich schwach; selbst bei nur wenigen Dollar Abweichung behauptete es einfach, das sei der passende Auszug.
Also scheint man vorerst doch noch Buchhalter zu brauchen.
Die Kosten habe ich nicht wirklich abgeschätzt, ich habe ein günstiges Modell wie Claude 3.7 verwendet.
Ich verstehe, warum ColPali intuitiv und leistungsfähig wirkt, aber dokumentenbasierte Verarbeitung hat trotzdem ihre Vorteile.