Multimodale LLMs für Charts und Tabellen wenn Zahlen als Bild kommen.

Ein erheblicher Teil der wertvollsten Finanzinformationen liegt nicht als sauberer Datenstrom vor, sondern als Bild: Investor-Präsentationen mit eingebetteten Diagrammen, gescannte Geschäftsberichte, Chart-Grafiken aus Research-Notes, Tabellen in PDFs, die sich nicht markieren lassen. Klassisches OCR scheitert an Layout und Kontext, manuelles Abtippen kostet Zeit und produziert Fehler. Multimodale LLMs - also Modelle, die Bilder und Text gemeinsam verarbeiten - versprechen hier einen Durchbruch: Sie lesen ein Chart-Bild, verstehen die Achsen, extrahieren Tabellenwerte und ordnen sie ein. Das funktioniert in vielen Fällen erstaunlich gut, in anderen bricht es auf eine Weise, die im Finanzkontext gefährlich ist, weil eine falsch erkannte Zahl plausibel aussieht. Dieser Beitrag zeigt, wo der Ansatz wirklich trägt, wo seine Grenzen liegen, wie man die Genauigkeit validiert und wie eine Pipeline aussieht, die Bilddaten verlässlich in nutzbare Zahlen verwandelt - ohne sich auf die Magie zu verlassen.

Wo Finanzdaten als Bild gefangen sind.

Wer Marktdaten verarbeitet, kennt das Problem: Die maschinenlesbaren Quellen sind oft die uninteressanten. Strukturierte Kursdaten gibt es per API, aber die spannenden Details - die Margenentwicklung in einem Segment, eine Guidance-Grafik, ein Wettbewerbsvergleich - stecken in Bildern, die nie für die Maschine gedacht waren.

Typische Quellen sind Investor-Decks, in denen die Kernaussagen als gestaltete Diagramme erscheinen; gescannte oder als Bild-PDF vorliegende Geschäftsberichte, besonders bei kleineren oder ausländischen Unternehmen; Chart-Grafiken aus Sell-Side-Research, die als Screenshot weitergereicht werden; und Tabellen, die in PDFs zwar wie Text aussehen, technisch aber als Bild oder als unbrauchbar verschachtelte Layout-Struktur vorliegen.

Der gemeinsame Nenner: Die Information ist vorhanden, für den Menschen lesbar, aber für die automatisierte Pipeline unzugänglich. Bisher blieb nur manuelles Abtippen - fehleranfällig, langsam, schlecht skalierbar. Genau diese Lücke adressieren multimodale Modelle, und das ist der eigentliche Grund für das Interesse: nicht weil es technisch beeindruckend ist, sondern weil es einen realen, teuren Engpass auflöst.

Was Vision-fähige LLMs tatsächlich leisten.

Multimodale LLMs verarbeiten ein Bild nicht wie klassisches OCR Zeichen für Zeichen, sondern interpretieren es im Zusammenhang. Das macht den Unterschied. Ein OCR-System liest in einer Balkengrafik vielleicht die Achsenbeschriftung als losen Text. Ein gutes Vision-LLM versteht, dass es eine Grafik ist, erkennt die Struktur, ordnet Balken den Kategorien zu und kann die Werte in eine Tabelle überführen.

In der Praxis bedeutet das eine deutlich höhere Robustheit gegenüber Layout-Variation. Das Modell kommt mit unterschiedlichen Tabellenstilen klar, mit verbundenen Zellen, mit Fußnoten, mit gemischten Sprachen. Es kann auf Nachfrage auch erklären, was es sieht, und seine Unsicherheit kommunizieren - wenn man es richtig anweist.

Realistische Stärken liegen vor allem bei klaren, gut aufgelösten Tabellen mit moderater Komplexität, bei einfachen Balken- und Säulendiagrammen mit beschrifteten Werten und bei der Strukturierung von halb-tabellarischen Inhalten. Hier erreichen aktuelle Modelle bei sauberem Ausgangsmaterial oft Feldgenauigkeiten im hohen Bereich. Das ist gut genug, um den Menschen von der Fleißarbeit zu entlasten - aber nicht gut genug, um ohne Prüfung in eine Handelsentscheidung zu fließen.

Wo es bricht - und warum das gefährlich ist.

Die Grenzen multimodaler Modelle sind im Finanzkontext besonders heikel, weil ein Fehler nicht als Fehler erscheint. Wenn das Modell eine '7' als '1' liest oder eine Achsenskalierung falsch interpretiert, liefert es weiterhin eine plausible Zahl. Es gibt kein Warnsignal. Genau diese stille Plausibilität macht unvalidierte Extraktion riskant.

Typische Bruchstellen sind:

• Liniencharts ohne Wertbeschriftung: Werte muss das Modell von der Position relativ zur Achse ableiten - das ist Schätzen, kein Lesen, und entsprechend ungenau.
• Dichte, verschachtelte Tabellen: Bei vielen Spalten, verbundenen Zellen und Fußnoten verrutscht die Zuordnung von Werten zu Zeilen oder Spalten.
• Schlechte Bildqualität: niedrige Auflösung, Kompressionsartefakte, schiefe Scans senken die Genauigkeit spürbar.
• Vorzeichen, Einheiten und Maßstäbe: Klammern für negative Werte, Tausender- versus Millionen-Skalierung, Prozent versus Basispunkte - hier passieren systematische, leicht zu übersehende Fehler.
• Halluzinierte Vollständigkeit: Fehlt eine Zelle oder ist sie unleserlich, neigt das Modell dazu, einen plausiblen Wert zu ergänzen statt 'unleserlich' zu melden.

Der letzte Punkt ist der gefährlichste. Ein Modell, das eine fehlende Zahl rät und nicht kennzeichnet, untergräbt das Vertrauen in den gesamten Datensatz. Deshalb ist die Anweisung, Unsicherheit explizit zu markieren, keine Feinheit, sondern Pflicht.

Validierung ist nicht optional.

Keine extrahierte Zahl sollte ungeprüft in eine Pipeline gelangen. Die entscheidende Frage ist nicht, ob das Modell Fehler macht - das tut es -, sondern wie man sie zuverlässig abfängt. Mehrere Validierungsschichten haben sich bewährt und ergänzen sich.

Erstens automatische Plausibilitätsprüfungen: Summieren sich Tabellenspalten zu den ausgewiesenen Gesamtwerten? Liegen Werte in einem erwartbaren Bereich? Passt die Größenordnung zu bekannten Vorperioden? Solche Regeln fangen einen großen Teil grober Lesefehler ohne menschliches Zutun.

Zweitens Mehrfach-Extraktion: Dasselbe Bild mehrfach durchs Modell schicken, idealerweise mit leicht variierter Anweisung, und auf Abweichungen prüfen. Wo die Läufe übereinstimmen, ist die Konfidenz hoch; wo sie auseinandergehen, geht der Fall in die manuelle Prüfung. Das kostet zusätzliche Token, ist aber günstig im Verhältnis zum vermiedenen Fehler.

Drittens der Mensch an der richtigen Stelle: Nicht alles prüfen, sondern gezielt das, was die automatischen Schichten als unsicher markieren. Eine gut gebaute Pipeline extrahiert hundert Tabellen automatisch und legt dem Menschen nur die fünf vor, bei denen etwas nicht stimmt. So entsteht echte Entlastung statt nur Verlagerung der Arbeit. Wer ein eigenes kleines Testset mit bekannten Soll-Werten pflegt, kann die reale Genauigkeit für die eigenen Dokumenttypen messen, statt sich auf allgemeine Versprechen zu verlassen.

Eine belastbare Extraktions-Pipeline.

Eine produktionstaugliche Pipeline besteht aus mehr als einem Modellaufruf. Sinnvoll ist ein gestufter Ablauf, der jede Stufe nachvollziehbar macht und Fehler früh isoliert.

Die Vorverarbeitung wird oft unterschätzt. Ein höher aufgelöstes, sauber zugeschnittenes Bild verbessert die Extraktionsqualität spürbar - manchmal mehr als ein Modellwechsel. Wer ein großes PDF in einem Stück verarbeitet, verschenkt Genauigkeit; einzelne Tabellen oder Charts gezielt auszuschneiden lohnt sich.

Die Anweisung an das Modell sollte das Ausgabeformat exakt vorgeben - am besten ein striktes Schema -, explizit nach Einheiten und Vorzeichen fragen und unleserliche Felder mit einem klaren Marker statt mit einem geratenen Wert verlangen. Diese drei Details heben die nutzbare Genauigkeit deutlich an, ohne dass ein anderes Modell nötig wäre.

Kosten, Geschwindigkeit und sensible Daten.

Multimodale Inferenz ist teurer und langsamer als reine Textverarbeitung, weil Bilder viele Token erzeugen. Pro Seite oder Chart fällt ein Vielfaches der Token einer reinen Textanfrage an. Für die Verarbeitung einzelner Investor-Decks ist das irrelevant; wer Tausende Seiten monatlich verarbeitet, sollte die Kosten vorab durchrechnen und die Mehrfach-Extraktion gezielt nur bei unsicheren Fällen einsetzen statt pauschal.

Die Geschwindigkeit ist für die meisten Research-Workflows unkritisch - eine Verzögerung von einigen Sekunden pro Bild fällt nicht ins Gewicht, solange die Verarbeitung im Hintergrund läuft und nicht interaktiv blockiert. Anders sieht es aus, wenn große Batches zeitnah verarbeitet werden müssen; dann wird Parallelisierung und Kostenmanagement zum Thema.

Der heikelste Punkt sind die Daten selbst. Investor-Decks, Research-Notes und interne Tabellen sind oft vertraulich oder kursrelevant, bevor sie veröffentlicht werden. Wer solche Bilder an eine externe Cloud-API schickt, gibt sie aus der Hand - vertraglich abgesichert, aber außer Haus. Für strikt vertrauliche Inhalte führt der Weg zu selbst gehosteten multimodalen Modellen, deren Bildverständnis bei klaren Tabellen heute brauchbar ist, bei komplexen Charts den führenden Cloud-Modellen aber oft noch nachläuft. Diese Abwägung - Qualität gegen Datenhoheit - sollte am Anfang stehen, nicht am Ende.

Wann sich der Ansatz lohnt - und wann nicht.

Multimodale Extraktion ist kein Selbstzweck. Sie lohnt sich, wenn drei Bedingungen zusammenkommen: Die Information liegt nur als Bild vor, sie wird regelmäßig und in nennenswertem Umfang gebraucht, und das manuelle Abtippen wäre teuer oder fehleranfällig. Trifft das zu - etwa bei der laufenden Auswertung von Investor-Präsentationen über viele Unternehmen hinweg - ist der Zeitgewinn erheblich.

Nicht lohnen tut es sich, wenn die Daten auch strukturiert verfügbar sind. Wer Kurs- oder Fundamentaldaten per API beziehen kann, sollte das tun und nicht den Umweg über Screenshots gehen - das wäre, eine zuverlässige Quelle gegen eine fehleranfällige zu tauschen. Ebenso wenig lohnt der Aufwand bei Einzelfällen: Eine einzelne Tabelle tippt man schneller selbst ab, als eine validierte Pipeline dafür aufzubauen.

Die ehrliche Gesamteinschätzung: Multimodale LLMs sind ein starkes Werkzeug, um einen realen Engpass zu lösen, aber kein Ersatz für sorgfältige Validierung. Sie verschieben die menschliche Arbeit vom stumpfen Abtippen hin zum gezielten Prüfen - und das ist ein guter Tausch, solange man die Prüfung nicht wegspart. Wer den Validierungsschritt überspringt, weil das Modell so überzeugend wirkt, baut sich eine Datenbasis, die im entscheidenden Moment nicht trägt.

Sie stecken regelmäßig Finanzdaten aus Bildern und PDFs in Ihr Research und wollen das zuverlässig automatisieren? Unverbindlich anfragen — wir schauen gemeinsam auf Ihre Dokumenttypen, bauen eine Extraktions-Pipeline mit echter Validierung und klären, ob Cloud-Modelle reichen oder eine On-Premise-Lösung wegen der Datensensibilität nötig ist.