Dein LLM ist keine Dokumenten-Pipeline

Es gibt in jedem KI-Projekt diesen Moment, in dem die Demo so gut aussieht, dass dein Gehirn leise anfängt, Code zu löschen. Du siehst zu, wie ein Modell einen Kontoauszug "liest", und denkst: das ist es. Wir können OCR überspringen. Wir können das Layout-Parsing überspringen. Vielleicht können wir die halbe Pipeline überspringen. In der Filmversion drückt jemand Enter und JSON fällt wie ein Wasserfall aus der Cloud.

In der Realität ist der Wasserfall ein Tropfen. Und jemand muss immer noch den Wischmopp holen.

Wir schreiben dies aus dem Narbengewebe des Versuchs heraus, LLMs und VLMs dazu zu bringen, eine End-to-End-Extraktion bei Finanz-PDFs durchzuführen. Nicht bei sorgfältig kuratierten Dreiseitern mit perfektem Kerning, sondern bei den unglamourösen PDFs, die in der Produktion auftauchen: 120 Seiten, mehrere Layouts und ein paar Scans in der Mitte, mit einem Kaffeering, der dir um Seite 42 herum ein hilfreiches Wasserzeichen liefert.

Wenn du das Ende vorwegnehmen willst: Modelle sind großartige Assistenten innerhalb einer Dokumenten-Pipeline. Sie geben schreckliche Pipelines ab.

Der erste Treffer

Mein erster Erfolg war fast filmreif. Ich zeigte einem Vision-Language-Model eine saubere Seite. "Gib mir Datum, Händler, Betrag, Saldo." Es gehorchte höflich, in JSON. Die Tabellengrenzen sahen richtig aus. Die Dezimalzeichen stimmten. Ich schrieb eine Slack-Nachricht an das Team, die mit "Was wäre, wenn…" begann.

Das ist der Teil, wo die Kamera zu einer Montage schneidet, in der ich "Was wäre, wenn…" an einem echten Kontoauszug ausprobiere.

Die gleiche Bank, ein anderes Template. Summen umbenannt von "Dieser Zeitraum" in "Zwischensumme". Sollbuchungen als positive Werte gedruckt. Ein Seitenumbruch, der eine Zeilenbeschreibung in der Mitte durchschneidet. Ein Slogan in der Kopfzeile, den das Modell als letzte Zeile einer Transaktion interpretiert. Ein Scan mit hellgrauen Gitterlinien, die gerade genug verschwinden, um die Zeilenerkennung zu verwirren. Verpasste Zeile, veränderter Inhalt, Wiederholungen.

Hilfsbereit ist das Problem. Hilfsbereit ist nicht auditierbar.

Hier ist ein konkretes Beispiel, wo VLMs stolpern, selbst mit Mistral AIs Anspruch des „weltbesten OCR-Modells“.

Vergleicht man die beiden, verschwindet die Haben-Spalte (Credit) und mehrere Werte landen in den falschen Spalten – ein klassisches Versagen bei der Tabellenstruktur.

Im Gegensatz dazu sind Holofins Modelle speziell auf finanzielle Tabellenstrukturen trainiert. Auf diesen Seiten – und diese befinden sich am unteren Ende der Komplexitätsskala – stellen sie das volle Schema wieder her und korrigieren die Zellzuweisungen mit perfekter Genauigkeit. Wenn man die manuelle Dateneingabe ersetzen will, ist eine korrekte Struktur in der OCR-Phase nicht verhandelbar.

Die leisen Arten, wie ein Modell falsch liegen kann

Was uns nervös macht, sind nicht die offensichtlichen Fehler. Die sind leicht zu fangen. Was uns nervös macht, sind die plausiblen Fehler.

Du kannst dir die Ausgabe eines Modells ansehen und das Gefühl haben, alles sei in Ordnung. Die Zahlen sind formatiert. Die Felder sind vorhanden. Das JSON validiert. Erst später bemerkst du, dass ein scheinbar vernünftiges "Total" eine Year-to-Date-Zahl ist, oder dass ein Anfangssaldo als Transaktion gelesen wurde, oder dass eine umgebrochene Zeile zwei Händler zu einer Chimäre verschmolz, die nie existierte. Niemand warf einen Fehler; das System machte einfach weiter.

Wir dachten früher, das sei ein Genauigkeitsproblem. Ist es nicht (oder nicht nur). Es ist ein Kalibrierungs-Problem. Genauigkeit ist "Wie nah sind wir dran?". Kalibrierung ist "Wie sehr sollten wir dem vertrauen?". Modelle wirken in Demos genau. Pipelines brauchen Kalibrierung in der Produktion.

Wie wir gesehen haben, gibt es Blogposts und öffentliche Tests, die dies bestätigen. Einige als "OCR-fähig" vermarktete VLMs können tatsächlich saubere Tabellen auf sauberen Seiten lesen, stolpern aber über genau die Art von Unordnung, die wir gerade beschrieben haben. Scan-Qualität, Layout-Drift, Vorzeichen von Beträgen: Die Arten von Variationen, die in der realen Welt Routine sind, verwandeln selbstbewusste Extraktionen in selbstbewusste Fiktion. Man braucht keine böse Absicht, um zu halluzinieren; man braucht nur Seite 57.

Die Kosten, die niemand in der Demo nennt

Da ist auch noch die Rechnung.

Nimm ein konservatives Beispiel: einen 120-seitigen Kontoauszug. Selbst wenn man es in zwei Seiten pro Anfrage aufteilt (chunking), sendet man ~60 Prompts. Du fügst Anweisungen hinzu, vielleicht ein paar Beispiele, um die Ausgaben zu stabilisieren. Wenn du ein VLM verwendest, ist jede Seite ein Image Embedding zusätzlich zu den Tokens. Multipliziere das mit 60. Multipliziere mit Retries. Multipliziere mit einem zweiten Durchlauf, wenn du merkst, dass du eine Verifizierung brauchst. Latenz steigt von „zackig“ auf „mach dir einen Tee“. Die Kosten steigen von Cents auf Euros.

Größenordnung, kein Versprechen: Die Verarbeitung einer Datei mit über 100 Seiten mit einem einzigen großen VLM kann im Bereich von „mehreren Euro pro Dokument“ landen, und Minuten an Wall-Time kosten.

Du kannst das natürlich herunterschrauben, aber beachte, was das impliziert. Genau die Tricks, die es erschwinglich machen (kleinere Modelle, weniger Aufrufe, straffere Prompts), kommen meist daher, dass man weniger mit dem Modell und mehr mit Code macht. Was uns zum langweiligen, unüberspringbaren Teil bringt.

Und die Rechnung bläht sich leise auf, wenn man „k‑LLM“ oder Agentic-Cleverness hinzufügt. Du routest die seltsamen Seiten zu einem zweiten Modell, sampelst zweimal, um sicherer zu sein, fügst einen Verifizierungsdurchlauf hinzu, vielleicht erst Captioning und dann Extrahieren – jedes Sicherheitsnetz ist ein weiterer Round-Trip und ein weiterer laufender Zähler. Was wie ein Aufruf aussah, wird zu einem kleinen Komitee, und die Kosten blähen sich einfach auf.

Die Pipeline, die du am Ende sowieso baust

Irgendwann hörten wir auf zu fragen: "Kann ein Modell das lesen?" und fingen an zu fragen: "Wenn das Modell das liest, können wir es beweisen?"

Beweise sind unsexy. Es bedeutet, dass du Koordinaten für jedes Token behältst. Es bedeutet, dass du einem Regulator die Pixel-Box auf Seite 83 zeigen kannst, die zu "€-1.237,45" wurde. Es bedeutet, dass du Anfangs- und Endsalden über Seiten hinweg abgleichst (Reconciliation) und ausflippst, wenn die Summe der Deltas nicht übereinstimmt. Es bedeutet, dass du bemerkst, wenn zwei verschiedene Summen auf derselben Seite stehen und sich nicht einig sind, dass sie Summen sind.

Du kannst all das mit Modellen machen. Aber sobald du genug von dem Gerüst geschrieben hast, um sicher zu sein (die OCR-Redundanz, die Geometrie, die strikten Parser, die Reconciliation), passiert eine lustige Sache: das Modell ist nicht mehr der Held. Es ist der Spezialist, den man bei Streitfällen und Randfällen hinzuzieht.

Das ist eine gute Sache.

Wo das Modell tatsächlich glänzt

Wir mögen diese Modelle immer noch. Wir mögen sie nur im richtigen Umfang.

Wenn zwei deterministische Durchläufe sich über die 'Soll/Haben'-Vorzeichenkonvention uneinig sind – zum Beispiel Beträge, die als positive Werte mit einer separaten D/C-Spalte gedruckt werden –, bitte das Modell zu schlichten und seine Wahl zu erklären. Wenn sich eine Kopfzeile leise von 'Frais' zu 'Frais de tenue de compte' oder 'Commissions d’intervention' geändert hat, bitte das Modell, es auf dein kanonisches Schema abzubilden. Wenn es eine Fußnote wie 'dont TVA 20 %' oder einen 'CB différé'-Abschnitt gibt, der verschiebt, wann Beträge angewendet werden, bitte das Modell, dies zu markieren, bevor du einen Stapel von Transaktionen falsch klassifizierst.

Mit anderen Worten: Behandle das Modell als Richter oder Übersetzer. Bitte es nicht, der Scanner, der Parser und der Buchhalter zu sein.

Aber werden Modelle nicht besser?

Absolut. Wir würden uns freuen, in sechs Monaten falsch zu liegen. Größere Kontexte reduzieren den Chunking-Schmerz. Vision Backbones verbessern sich ständig. Tool-Use und Multi-Pass helfen enorm.

Selbst dann verschwinden die Teile, die uns bei Finanzdokumenten wichtig sind, nicht: Herkunft (Provenance), Abgleich (Reconciliation), Drift-Erkennung und die Fähigkeit, jede Zahl jemandem zu erklären, der sich nicht für deine Prompts interessiert. Bessere Modelle machen die Ermessensentscheidungen sauberer. Sie entbinden uns nicht davon, Belege zu liefern.

Wenn dein Anwendungsfall „Extrahiere Summen aus glänzenden Einseitern“ ist, ist die Black Box vielleicht in Ordnung. Wenn dein Anwendungsfall „Verarbeite 120 Seiten gemischter Qualität von 17 Banken, erfülle ein SLA und bestehe ein Audit“ ist, wirst du immer noch die Leitplanken wollen. Du wirst auch wollen, dass die Rechnung vorhersehbar ist.

Die unsichtbare Checkliste, die wir jetzt mit uns herumtragen

Wir drucken keine Checkliste mehr aus; wir tasten nur danach wie nach Schlüsseln in der Tasche. Können wir einen 120-seitigen Kontoauszug verarbeiten, ohne Timeouts zu werfen? Behalten wir Seiten- und Koordinaten-Herkunft für jeden extrahierten Wert bei? Wenn wir die Transaktionen summieren, erhalten wir das Saldo-Delta, oder haben wir irgendwo ein Loch? Was passiert, wenn ein Modell auf Seite 87 stehen bleibt: Machen wir weiter oder verstecken wir den Fehler in einem sauberen JSON-Umschlag? Könnten wir das mit ausgeschalteten Modellen laufen lassen und trotzdem etwas Brauchbares erhalten? Werden wir bemerken, wenn eine Bank leise „Template v7“ einführt und eine Spalte verschiebt, oder wird das System die neue Realität höflich akzeptieren und Unsinn unter den richtigen Feldnamen ablegen?

Das sind keine Deep-Learning-Fragen. Es sind Software-Fragen. Was ehrlich gesagt tröstlich ist.

Wenn du einen Streit anfangen musst, such dir einen kleinen aus

Das Ding, das konsequent Kosten senkt und Vertrauen erhöht, ist Umfangsdisziplin (Scope Discipline). Bitte das Modell, zwischen Kandidaten zu wählen, nicht Struktur zu erfinden. Bitte um einen Index, nicht um einen Absatz. Fasse mehrdeutige Zellen zusammen (Batching), sodass 20 Entscheidungen einen Round-Trip kosten. Cache alles, was du kannst: Wenn du ein Template gesehen hast, lerne seine Eigenheiten einmal und verwende dieses Wissen wieder. Und wenn das Modell verliert, stelle sicher, dass es auf eine Weise verliert, die ein Mensch mit einem Klick beheben kann.

Tu dies und du erhältst die Magie dort, wo es zählt: in den seltsamen Ecken, wo Regeln brüchig werden. Lass das weg, und du erhältst einen sehr teuren Weg, selbstbewusst falsch zu liegen.

LLMs und VLMs bleiben der erfreulichste Teil des Stacks, solange sie nicht der ganze Stack sind. Der Job ist es nicht, die langweiligen Teile zu eliminieren. Der Job ist es, langweilige Dinge zu bauen, damit die Magie etwas Stabiles hat, auf dem sie stehen kann.

Bei Holofin setzen wir auf diese Disziplin: Baue zuerst das zuverlässige Gerüst – Provenance, Reconciliations, Drift-Checks – und lade dann Modelle ein, dort zu schlichten, wo Regeln verschwimmen. Das hält Fehler lokal und laut, macht Kosten vorhersehbar und lässt die Magie ihren Teil tun, ohne die ganze Last zu tragen.

Update Dezember 2025: Mistral OCR 3

Wir haben dieses Thema im Dezember 2025 erneut aufgegriffen, als Mistral mistral-ocr-3 veröffentlichte. Trotz der neuen Version und anhaltender Behauptungen über verbessertes Dokumentenverständnis beobachteten wir dieselben räumlichen Probleme bei Tabellen: Spalten verschmelzen, Werte landen in falschen Zellen und die Haben-Spalte (Credit) verschwindet bei denselben Kontoauszugsproben. Die fundamentale Herausforderung der Wiederherstellung von Tabellenstrukturen bleibt durch General-Purpose VLMs ungelöst.