Eingescannte Dokumente — Anträge, Verträge, Rechnungen — enthalten strukturierte Informationen in unstrukturierter Form. Namen, Adressen, Vertragsnummern, Datumsangaben: alles ist da, aber in freiem Text, handschriftlichen Notizen oder schlecht formatierten Tabellen.
Der naive Ansatz — alles dem LLM übergeben — scheitert in der Praxis an Halluzinationen, fehlender Formatvalidierung und mangelnder Nachvollziehbarkeit. Die Lösung: eine mehrstufige Pipeline, die jeder Komponente genau die Aufgabe gibt, die sie am besten kann.
Die Pipeline verarbeitet eingescannte Dokumente in sieben Stufen. Kernänderung gegenüber dem ursprünglichen Ansatz: räumliches Key-Value-Pairing (KVP) liefert strukturierten Kontext für das LLM. Das LLM bekommt keine Format-Restriktionen — nur Labels, Enums und semantische Hints. Alle Formatprüfungen passieren deterministisch danach.
DLA + OCR Deterministisch
Layout-Erkennung (Document Layout Analysis) + OCR in einem Schritt. Liefert Zeilen mit Bounding Boxes, gruppiert in Layout-Regionen.
OCR-Qualitätsprüfung Deterministisch
Proxy-Score aus Zeichenqualität, Worterkennung, Strukturerkennung und Längenverhältnis. Kein ML — rein heuristisch.
KVP — Räumliche Paare Deterministisch
Findet räumlich benachbarte Textblöcke per asymmetrischer Distanz (rechts/unten bevorzugt). Keine Label/Value-Klassifikation — das Zuordnen übernimmt das LLM.
LLM-Extraktion LLM
Prompt enthält semantische Feldbeschreibungen, Enum-Werte und gefilterte KVP-Paare als räumlichen Kontext. Bewusst keine Format-Hints — die verleiten das LLM zum Erfinden passender Werte.
Deterministische Validierung Deterministisch
Prüft jeden extrahierten Wert gegen deklarierte Restriktionen. Auto-Korrekturen: trim, strip, Datumsformat, Dezimalbereinigung. Ergebnis pro Feld: ok / corrected / failed / missing.
Bestätigungsdialog Human
Quelldokument + extrahierte Werte mit Ampel-Status. Fehlgeschlagene Felder hervorgehoben. Der Mensch bestätigt, korrigiert oder bricht ab.
Form Fill + Self-Repair Deterministisch LLM
Formulardaten werden eingetragen. Bei serverseitigen Validierungsfehlern greift ein Self-Repair-Mechanismus: LLM-Korrektur, ggf. menschlicher Fallback.
Viele OCR-Engines liefern keinen eigenen Konfidenz-Score. Stattdessen lässt sich ein Proxy-Score aus dem erkannten Text selbst berechnen — rein deterministisch, kein ML.
| Check | Gewichtung | Was wird gemessen |
|---|---|---|
| Zeichenqualität | 30% | Anteil druckbarer Zeichen vs. Steuerzeichen, Box-Symbole, Null-Bytes |
| Worterkennung | 30% | Anteil erkannter Wörter (Wörterbuch / Sprachcheck) |
| Strukturerkennung | 20% | Erkennbare Muster: Datumsformate, PLZ-artige Zahlen, Namens-Patterns |
| Längenverhältnis | 20% | Ist die Textlänge plausibel für die Dokumentgröße, oder verdächtig kurz/leer? |
KVP findet räumlich benachbarte Textblöcke — ohne zu wissen, was Labels und was Werte sind. Die Zuordnung zu Zielfeldern ist nicht KVPs Aufgabe. Es liefert nur: „diese zwei Blöcke stehen nebeneinander.“
| Schritt | Was passiert |
|---|---|
| Flatten | Alle OCR-Zeilen über alle Sektionen sammeln. Noise-Filter: leere Zeilen und Zeilen >80 Zeichen entfernen. |
| Nearest Neighbor | Für jede Zeile den nächsten Nachbarn per asymmetrischer Distanz finden. Rechts-von und unterhalb werden bevorzugt (Formular-Pattern). |
| Pass 1 — Mutual | Wenn A→B und B→A: Paar mit hoher Konfidenz (gegenseitig nächste Nachbarn). |
| Pass 2 — Fallback | Verbleibende Zeilen, sortiert nach Distanz. A→B aber B→C → trotzdem Paar, niedrigere Konfidenz. Sortierung verhindert, dass entfernte Zeilen nahe Nachbarn „stehlen“. |
| Filter | Paare, bei denen beide Seiten ALL-CAPS ohne Ziffern sind (zwei Headings/Labels), werden vor der LLM-Übergabe entfernt. |
Das LLM bekommt drei Informationsquellen: semantische Feldbeschreibungen (ohne Beispielwerte), Enum-Listen (erlaubte Werte) und KVP-Paare als räumlichen Kontext.
Prüft jeden extrahierten Wert gegen die deklarierten Feld-Restriktionen. Keine Prüfung ohne Deklaration — wenn ein Feld kein pattern hat, wird es nicht geprüft. Das System macht keine Annahmen.
| Check | Regelquelle | Aktion bei Fehler |
|---|---|---|
| Regex-Match | pattern |
Auto-Fix versuchen (strip non-matching chars), sonst failed |
| Maximale Länge | maxLength |
Abschneiden + corrected |
| Erlaubte Werte | enum |
Fuzzy-Match (Levenshtein) gegen Enum-Liste, sonst failed |
| Format | format |
Datum: parse + reformat, sonst failed |
| Pflichtfeld leer | required |
Status missing |
Keine fachliche Logik. Prüfungen wie „Kundennummer existiert im System“ oder „Adresse liegt im Zielgebiet“ sind serverseitige Validierungen. Die fängt der Self-Repair-Mechanismus nach dem Form Fill in Stufe 7.
Der Bestätigungsdialog zeigt das Quelldokument neben den extrahierten Werten, mit Ampel-Status pro Feld. Kein Wert gelangt in ein Formular, ohne dass ein Mensch ihn gesehen hat.
Quelldokument
Name: Maria Huber
Straße: Hauptstr. 12
PLZ / Ort: 80331 München
Vertragsnr.: 48O7123
Beginn: 1. April 2025
Tarif: Premium
Extrahierte Daten
Grün = Wert ok. Gelb = automatisch korrigiert (Original sichtbar). Rot = ungültig oder fehlend, manuelle Eingabe erforderlich. Der OCR-Qualitätsscore wird als Info-Badge angezeigt.
Die Pipeline ist als Eskalationskette aufgebaut: schnelle deterministische Methoden zuerst, teurere KI-Methoden nur bei Bedarf, der Mensch als letzte Instanz.
KVP
„Was steht nebeneinander?“
~0ms, deterministischNER (z.B. GLiNER)
„Welches Feld passt?“
~50ms, deterministischLLM
„Was bedeutet das im Kontext?“
~1500ms, probabilistischMensch
„Bitte prüfen“
∞Das LLM ist die letzte Instanz vor dem Menschen — nicht die zweite. Ein NER-Modell wie GLiNER übernimmt das semantische Mapping für eindeutige Fälle (~50ms, deterministisch). Das LLM wird nur noch für Felder aufgerufen, die das NER-Modell nicht zuordnen kann. Entscheidend: das NER-Modell bekommt strukturierte KVP-Paare als Input, nicht rohen OCR-Text.
Was nicht funktioniert hat
| Ansatz | Problem |
|---|---|
| NER auf rohem OCR-Text | Kann Labels nicht von Werten unterscheiden. Gibt Labels als Werte zurück, klebt Zeilen zusammen. |
| ALL-CAPS-Heuristik für Labels | Bei handschriftlichen Formularen sind auch Werte in Großbuchstaben. Falsche Paare mit hoher Konfidenz. |
| NER-Ergebnisse als LLM-Kontext | Falsche NER-Zuordnungen vergiften den LLM-Prompt. Ergebnis schlechter als ohne NER. |
| Format-Hints im Extraktions-Prompt | LLM erfindet passende Werte statt zu lesen. Auch Beispielwerte in Beschreibungen verzerren das Ergebnis. |
Was funktioniert hat
| Ansatz | Wirkung |
|---|---|
| KVP ohne Klassifikation | Räumliche Paare als Kontext: „ORT steht neben Stuttgart“ — das LLM weiß, wo Werte stehen. |
| Feldbeschreibungen ohne Beispielwerte | Semantische Hints: „oft als NR. beschriftet“ halfen dem LLM, Felder zu finden, die KVP nicht gepairt hatte. |
| Gefilterte KVP-Paare | Paare, bei denen beide Seiten ALL-CAPS sind (zwei Headings), werden entfernt → weniger Noise für den LLM. |
LLMs halluzinieren — besonders bei formatierten Werten. Wenn ein Prompt „PLZ (5 Ziffern)“ enthält, erfindet das LLM eine gültige PLZ, statt zuzugeben, dass es den Wert nicht finden kann. Durch die Trennung von Extraktion (LLM) und Validierung (deterministisch) wird dieses Problem strukturell gelöst.
Die Pipeline funktioniert mit jeder OCR-Engine, die Bounding-Box-Informationen liefert (z.B. Surya, Tesseract, Google Vision). Entscheidend sind die Koordinaten der erkannten Textzeilen — sie ermöglichen das räumliche Pairing in Stufe 3.
Ja. Das NER-Modell (z.B. GLiNER) ist eine optionale Optimierungsstufe. Ohne NER übernimmt das LLM die gesamte semantische Zuordnung — das funktioniert zuverlässig, dauert aber länger (~1500ms statt ~50ms pro Dokument für die Mapping-Phase).
Dokumentenverarbeitung
für Ihr Unternehmen?
Wir beraten Sie zum Aufbau zuverlässiger Extraction Pipelines — von der Architektur bis zur Produktivsetzung.
Kontakt aufnehmen