DOKUMENTEN-KI · OCR · LAYOUT · VISUELLE SUCHE

Dokumenten-KI: welcher Ansatz löst welches Dokumentenproblem?

Ein Scan, eine mehrspaltige Tabelle, ein handschriftlich ausgefülltes Formular und ein Vertrag mit gemischtem Layout sind vier verschiedene Probleme, keine Variante desselben. Welcher technische Ansatz zu welchem Dokumenttyp passt und wie sich die Qualität an den eigenen Unterlagen prüfen lässt, sollte feststehen, bevor ein Ansatz in den Betrieb geht.

Dokumentenbestand einordnen Zur KI-Beratung

Oder: 20-Minuten-Erstgespräch anfragen

AKTUALISIERT: 13. September 2026
LESEZEIT: 8 Min.
THEMA: Dokumenten-KI

Vier Probleme, kein Einheitsfall: Scans, Tabellen, Formulare und Handschrift verlangen unterschiedliche Technik und scheitern auf unterschiedliche Weise.
Layout trägt Bedeutung: LayoutLM verbesserte den Wert beim Formularverständnis von 70,72 auf 79,27, weil das Modell Text und Position gemeinsam lernt (Xu u. a., KDD 2020).
Suche ohne Texterkennung: ColPali vergleicht eine Frage direkt mit dem Bild einer Seite und braucht dafür keine vorherige Texterkennung (Faysse u. a., ICLR 2025).
Kein Ansatz gewinnt überall: OmniDocBench zeigt, dass klassische Pipelines und durchgängige Bild-Sprach-Modelle je nach Dokumenttyp eigene Stärken haben (Ouyang u. a., CVPR 2025).

Warum braucht nicht jedes Dokument dieselbe Technik?

Ein sauberer Scan, eine Tabelle, ein Formular und ein handschriftlicher Vermerk unterscheiden sich darin, wo ihre Information sitzt: in Zeichen, in Zellen, in festen Feldern oder in variabler Handschrift. Eine Technik, die für Fließtext gut liest, kann an einer Tabelle scheitern, und umgekehrt. Die Wahl beginnt deshalb beim Dokumenttyp, nicht bei einem einzelnen Werkzeug.

Eingangsrechnungen und die formatgebundene E-Rechnung folgen eigenen Formaten und Prüfschritten und bleiben hier bewusst außen vor. Die drei Ebenen Texterkennung, Layout und Bedeutung im Überblick erklärt der Leitfaden Dokumente mit KI verstehen.

Wer den Dokumenttyp zuerst benennt, spart sich Testläufe mit dem falschen Werkzeug.

Wann reicht klassische Texterkennung, und wann nicht mehr?

Klassische Texterkennung reicht, wenn die Information im Fließtext steht und die Lesereihenfolge einfach ist: Berichte, Protokolle, Verträge ohne komplexes Layout. Sie stößt an Grenzen, sobald Spalten, Tabellen oder Formularfelder die Bedeutung tragen, weil sie Zeichen in Lesereihenfolge liefert, aber die Zugehörigkeit einer Zahl zu einer Spalte nicht von sich aus kennt.

Erkennt die vorgeschaltete Layoutanalyse zwei Spalten nicht, liest die Texterkennung über die Spaltengrenze hinweg, und jede Zeile ergibt einen plausiblen, aber inhaltlich falschen Satz. Das Ergebnis wirkt sauber und ist trotzdem unbrauchbar, ein stiller Fehler, der selten sofort auffällt.

Ein kurzer Eigentest zeigt das schnell: eine Tabelle aus einem Scan kopieren und prüfen, ob die Werte danach noch in der richtigen Zeile stehen.

Was leisten layoutbewusste Modelle bei Tabellen und Formularen?

Layoutbewusste Modelle verarbeiten zu jedem Wort auch seine Position auf der Seite, oft zusammen mit dem Seitenbild. Dadurch lernen sie, dass ein Wert neben einer Feldbezeichnung zu genau diesem Feld gehört und eine Zahl in einer bestimmten Spalte eine andere Bedeutung hat als dieselbe Zahl anderswo. Für Formulare und Tabellen ist das der entscheidende Unterschied zur reinen Texterkennung.

Der Datensatz DocLayNet zeigt, dass darauf trainierte Modelle robuster über verschiedene Dokumenttypen hinweg arbeiten als Modelle, die nur eine Art von Dokument gesehen haben (Pfitzmann u. a., KDD 2022). Ein System, das nur an einer Vorlage trainiert wurde, überträgt sich selten zuverlässig auf eine andere.

Für Tabellen speziell misst die Metrik TEDS, wie nah die erkannte Struktur samt Zellinhalt an der richtigen liegt, ein feineres Bild als eine reine Zeichenfehlerrate.

Wie findet visuelle Dokumentensuche die richtige Seite ohne Texterkennung?

Visuelle Dokumentensuche vergleicht eine Frage direkt mit dem Bild einer Seite, statt vorher jedes Zeichen zu erkennen. Sie zerlegt die Seite in viele kleine Bildausschnitte, bettet jeden als Vektor ein und sucht für jeden Wortteil der Frage den ähnlichsten Ausschnitt. So bleiben Tabellen, Diagramme und Schriftgrößen als visuelle Hinweise erhalten, die eine reine Textsuche verliert.

Der Ansatz ColPali stellte dazu den Benchmark ViDoRe vor, weil bestehende Suchsysteme überwiegend den extrahierten Text auswerten und visuelle Hinweise ignorieren (Faysse u. a., ICLR 2025). Ein kompakteres Modell wie ModernVBERT zeigt seither, dass sich das mit deutlich weniger Parametern nachbilden lässt (Teiletche u. a., arXiv 2025).

Visuelle Suche liefert eine Seite, keinen zitierfähigen Text. Für Volltext und exakte Werte bleibt Texterkennung nötig, oft als zweiter Schritt nur auf den gefundenen Seiten.

Welcher Ansatz passt zu welchem Dokumentenproblem?

Fünf wiederkehrende Fälle lassen sich einem naheliegenden Ansatz zuordnen: saubere Scans der klassischen Texterkennung, Tabellen und Formulare layoutbewussten Modellen, gemischte oder unbekannte Layouts der visuellen Suche, und Handschrift grundsätzlich der menschlichen Prüfung. Der Ablauf unten zeigt, wie diese Zuordnung in einem konkreten Fall entsteht.

Vom Dokumenttyp zum passenden Ansatz

01Dokumenttyp sichtenScan, Tabelle, Formular, Fließtext, Handschrift
02Informationsträger bestimmenZeichen, Zellen, feste Felder oder Bildinhalt
03Aufgabe benennenExakte Werte oder die richtige Seite finden
04Ansatz wählenOCR, layoutbewusstes Modell, visuelle Suche oder Kombination
05An eigenen Beispielen prüfenNicht am Benchmark, sondern am eigenen Bestand

Dokumentproblem	Was schwer daran ist	Naheliegender Ansatz
Sauberer Scan, Fließtext	Nur Bildqualität und Schräglage, keine Struktur zu bewahren	Klassische Texterkennung (OCR)
Tabelle, auch über Seiten hinweg	Bedeutung liegt in Zeile und Spalte, nicht im einzelnen Zeichen	Layoutbewusstes Modell, Prüfung über die Tabellenmetrik TEDS
Formular mit festen Feldern	Ein Wert muss dem richtigen Feldnamen zugeordnet werden	Layoutbewusstes Modell mit Feldschema und Konfidenzwert je Feld
Gemischtes oder unbekanntes Layout	Kein festes Muster, unterschiedliche Vorlagen je Quelle	Visuelle Dokumentensuche, die das Seitenbild direkt vergleicht
Handschrift	Hohe Fehlerrate, starke Unterschiede zwischen Schreibenden	Erwartung begrenzen, jedes Feld zur menschlichen Prüfung geben

Fünf Dokumentprobleme und ihr naheliegender Ansatz

Viele reale Bestände mischen mehrere dieser Fälle auf derselben Seite, ein Formular mit einer handschriftlichen Unterschrift etwa. Dann greifen mehrere Ansätze nacheinander, nicht anstelle voneinander.

Extraktion oder Suche: welche Aufgabe stellt sich in diesem Bestand?

Extraktion überträgt Werte in ein festes Schema und braucht dafür exakte Zeichen. Suche soll zu einer Frage die richtige Seite finden und verzeiht kleine Zeichenfehler, solange die Seite gefunden wird. Wer die Aufgabe vorher benennt, wählt die passende Technik und vermeidet, visuelle Suche für eine Aufgabe einzusetzen, die zitierfähigen Text verlangt.

Extraktion, Suche und Archiverschließung im Vergleich

Kriterium	Extraktion	Suche und Frage-Antwort	Archiv erschließen
Ziel	Werte in feste Felder übertragen	Passende Seite zu einer Frage finden	Bestand durchsuchbar und zitierbar machen
Braucht exakte Zeichen	Ja	Nein, die Seite zählt	Ja, für Volltext und Zitate
Naheliegender Kern	Layoutbewusste Extraktion mit Prüfregeln je Feld	Visuelle Suche oder eine hybride Textsuche	Texterkennung, ergänzt um visuelle Suche für Layoutfälle
Wichtigste Messgröße	Anteil korrekt befüllter Felder	Trefferquote unter den ersten Ergebnissen	Zeichenfehlerrate und Auffindbarkeit

Ein bewährtes Muster verbindet beide Wege: Eine schnelle visuelle Suche grenzt die relevanten Seiten ein, und nur auf diesen läuft eine gründliche Texterkennung, deren Ergebnis weiterverarbeitet oder zitiert wird. Das hält den aufwendigen Schritt klein und verhindert, dass ein früher Erkennungsfehler bereits die Suche verdirbt.

Wie prüft man, ob ein gewählter Ansatz am eigenen Bestand wirklich trägt?

Die Qualität prüft man getrennt nach Ebene, an einem Testsatz aus eigenen, bewusst schwierigen Dokumenten mit vorher festgelegten Sollwerten: Zeichenfehlerrate für erkannten Text, Tabellentreue für Tabellen, Feldgenauigkeit für Extraktion und Trefferquote für Suche. Eine einzelne Gesamtnote verdeckt, auf welcher Ebene ein Fehler tatsächlich entsteht.

94,36 %Genauigkeit von Menschen auf DocVQA, einem Frage-Antwort-Test über 12.000 Dokumentbilder, als Bezugspunkt für SystemwerteMathew u. a., WACV 2021

19Layoutkategorien im Benchmark OmniDocBench, der neun Dokumentquellen bis hin zu Handschrift abdecktOuyang u. a., CVPR 2025

568.000Tabellenbilder mit HTML-Struktur im Datensatz PubTabNet, Grundlage der Tabellenmetrik TEDSZhong u. a., arXiv 2019

Checkliste

Testsatz für den eigenen Dokumentenbestand

0 von5

Für das Team, das einen Ansatz vor dem Einsatz prüft. Die Liste speichert nichts.

Schwierige Fälle bewusst aufgenommenSchlechte Scans, mehrspaltige Seiten, Tabellen über Seitengrenzen, Handschrift, nicht nur die typischsten Dokumente.
Sollwerte von einer fachkundigen Person geprüftFür Extraktion die richtigen Feldwerte, für Suche die richtige Seite zu jeder Testfrage.
Ebenen getrennt gemessenZeichen, Struktur, Felder und Treffer einzeln ausgewertet, damit klar ist, wo ein Fehler entsteht.
Konfidenzschwelle festgelegtAb welcher Unsicherheit ein Feld zur menschlichen Prüfung geht, statt stillschweigend übernommen zu werden.
Stichprobe gegen das Original geprüftAuch bei guten Kennzahlen einzelne Ergebnisse neben dem Seitenbild ansehen, um stille Fehler zu finden.

Womit beginnt man die Auswahl für einen konkreten Bestand?

Der naheliegende Start ist eine kleine, ehrliche Stichprobe: fünfzehn bis zwanzig echte Dokumente aus dem eigenen Bestand, absichtlich mit den schwierigsten Fällen darunter, gegen zwei Ansätze getestet, etwa Texterkennung mit Layoutanalyse gegen visuelle Suche.

Das Ergebnis zeigt fast immer, dass beide Wege für unterschiedliche Teile desselben Bestands gebraucht werden. Diese Erkenntnis ist günstiger, wenn sie an zwanzig Dokumenten entsteht, statt nach dem Rollout an tausenden.

Ob Dokumente dabei das eigene Netz verlassen müssen, ist eine eigene Frage der Architektur, kein technisches Muss. Texterkennung, Layoutmodelle und kompakte visuelle Suchmodelle laufen auf eigener Hardware, wie Offline-LLM im Unternehmen für Sprachmodelle allgemein einordnet. iiterate Technologies GmbH entwickelt solche Auswertungsstrecken von der Architektur über die Umsetzung bis zum Betrieb, auf Kundeninfrastruktur oder in EU-Hosting (Leistungen).

Belege aus unserer Arbeit

VERTRAUT VON TEAMS, DIE KI ERNST NEHMEN

Häufige Fragen

Reicht ein einziges Werkzeug für einen gemischten Dokumentenbestand?

Selten. Ein Bestand aus Scans, Tabellen und Formularen verlangt fast immer eine Kombination: klassische Texterkennung für Fließtext, ein layoutbewusstes Modell für Tabellen und Felder, visuelle Suche für uneinheitliche Layouts. Welche Kombination trägt, zeigt ein Test an einer Stichprobe des eigenen Bestands, nicht eine allgemeine Empfehlung.

Kann ein multimodales Sprachmodell die Texterkennung vollständig ersetzen?

Für einzelne Aufgaben ja, etwa eine Frage zu einer einzelnen Seite. Als Ersatz für nachvollziehbare, zitierfähige Texterkennung taugt es nur eingeschränkt, weil seine Ausgabe keine Koordinaten je Zeichen liefert und Werte plausibel ergänzt werden können, die auf der Seite gar nicht stehen. Ein Abgleich mit der Belegstelle bleibt deshalb nötig.

Funktioniert visuelle Dokumentensuche auch mit deutschen Unterlagen?

Grundsätzlich ja, weil das Verfahren am Bild der Seite ansetzt und nicht an einer Sprache. Die Trefferqualität hängt trotzdem an Schriftbild, Layoutvielfalt und Bildqualität der eigenen Dokumente. Ein kurzer Test mit eigenen Fragen an eigene Seiten zeigt schneller, ob der Ansatz trägt, als jeder veröffentlichte Benchmarkwert.

Wie geht man mit Tabellen um, die sich über mehrere Seiten fortsetzen?

Seitenweise Verarbeitung verliert bei der Fortsetzung häufig die Kopfzeile, und die Werte stehen ohne erkennbaren Bezug da. Abhilfe schaffen Verfahren, die mehrere Seiten gemeinsam lesen, oder eine Nachbearbeitung, die Kopfzeilen gezielt an Fortsetzungsseiten weitergibt. Solche Tabellen gehören ausdrücklich in den eigenen Testsatz, weil sie in öffentlichen Benchmarks selten vorkommen.

Was ist der Unterschied zwischen Layoutanalyse und Extraktion?

Layoutanalyse bestimmt, welche Bereiche einer Seite Überschrift, Tabelle, Abbildung oder Formularfeld sind und in welcher Reihenfolge sie gelesen werden. Extraktion nutzt diese Struktur, um bestimmte Werte in ein festes Schema zu übertragen. Eine verlässliche Extraktion setzt eine gute Layoutanalyse voraus, ersetzt sie aber nicht.

Muss handschriftlicher Inhalt grundsätzlich manuell geprüft werden?

In der Praxis ja, solange keine eigene Messung am konkreten Schriftbild etwas anderes zeigt. Handschrift streut zwischen Schreibenden stark, und ein automatisch erkannter Wert kann plausibel und trotzdem falsch sein. Handschriftliche Felder gehören deshalb grundsätzlich in eine Prüfliste, bevor ein Wert weiterverarbeitet wird.