Endlich durchgeblickt: Table Extraction richtig evaluieren

Der Auftrag schien einfach: Tabellen aus PDF-Dokumenten extrahieren. Was als Projekt für zwei Wochen begann, entwickelte sich zur ernüchternden Erfahrung. Während Smartphones mühelos Gesichter in Menschenmengen erkennen und KI-Systeme Kunst erschaffen, scheitern dieselben Technologien an dem, was auf den ersten Blick so einfach erscheint: dem korrekten Auslesen von Tabellen aus PDF-Dokumenten. 

Das liegt nicht daran, dass es sich um einen Randbereich handelt. Bereits 2019 verursachten ineffiziente Dokumentenprozesse jährlich rund zwölf Milliarden US-Dollar an Verlusten bei Fortune-500-Unternehmen [1]. Seitdem haben sich Technologien wie Computer Vision und Large Language Models stark weiterentwickelt. Dennoch zeigen aktuelle Benchmarks wie OmniDocBench, dass selbst modernste Modelle bei der Tabellenextraktion im Schnitt nur eine Score von etwa 80% erreichen [2]. Perfekte Ergebnisse bleiben also die Ausnahme. Vor diesem Hintergrund stellt sich eine zentrale Frage: 

Wie gelingt es, strukturierte Informationen aus komplexen PDF-Dokumenten verlässlich zu extrahieren, wenn selbst die leistungsfähigsten Modelle regelmäßig scheitern?

Genau mit dieser Fragestellung haben wir uns im Rahmen eines Kundenprojekts beschäftigt. Die Dokumente reichten von gescannten Papierformularen bis hin zu digitalen PDFs mit Textlayer. Dabei wurde schnell klar, dass nicht nur die Extraktion selbst, sondern vor allem die Bewertung der Ergebnisse eine Herausforderung darstellen.

In diesem Artikel stellen wir daher nicht nur unseren technischen Ansatz vor, sondern beleuchten insbesondere die Evaluation der Tabellenextraktion. Wir zeigen, welche Methoden sich in der Praxis bewährt haben, welche Fallstricke zu beachten sind und wie eine zuverlässige Bewertung zur Grundlage für echte Fortschritte wird.

Eine Tabelle und ihre Schwierigkeiten

Wie die meisten wahrscheinlich wissen, setzt sich eine Tabelle aus Zeilen, Spalten, Zellen und Kopfzeilen zusammen.

• Zeilen verlaufen waagrecht und bündeln sämtliche Informationen zu einem einzelnen Datensatz.
• Spalten verlaufen senkrecht und gruppieren gleichartige Merkmale über mehrere Datensätze hinweg.
• An den Schnittpunkten von Zeilen und Spalten liegen die Zellen, in denen die konkreten Werte stehen.
• Kopfzeilen, meist ganz oben oder links, erklären die Bedeutung der Zeilen und Spalten und sorgen so für Orientierung.

In der Praxis ist dieses Raster jedoch selten so geradlinig. Eine Tabelle kann auch so aussehen wie folgt:

Dabei sind typische Sonderfälle beispielsweise:

1. Zusammengefasste Zellen, die sich über mehrere Zeilen oder Spalten ziehen und Beziehungen verdeutlichen.
2. Verschachtelte Tabellen, die in einer einzelnen Zelle zusätzliche Detailinformationen aufnehmen.
3. Mehrstufige Kopfzeilen, die Spalten thematisch gruppieren und echte Hierarchien bilden.
4. Anmerkungen und Fußnoten, die bestimmte Zellen kommentieren oder relativieren.
5. Leere Zellen, die auf fehlende, irrelevante oder bewusst ausgelassene Inhalte hindeuten.

Daraus wird ersichtlich: Tabellen sind weit mehr als einfache Datenraster. Sie werden in erster Linie für Menschen gestaltet und sind auf schnelle visuelle Erfassung statt auf maschinelle Verarbeitung optimiert. Ihr hoher Informationsgehalt entsteht durch komplexe visuelle und logische Strukturen, deren Bedeutung sich oft erst durch menschliche Interpretation erschließt. Genau darin liegt die größte Herausforderung automatischer Table Extraction: Zellen nicht nur zu erkennen, sondern sie im jeweiligen Kontext richtig zu deuten.

Der Use Case

In diesem Artikel steht die Messung der Ergebnisqualität unserer Tabellenextraktion im Fokus. Doch bevor wir zu den Metriken und Evaluierungsschritten kommen, lohnt sich ein kurzer Blick auf die zugrunde liegende Architektur unserer Lösung.

Wie bereits beschrieben, wollen wir die Beziehungen zwischen Textelementen und Tabellenstrukturen präzise erkennen. Um dieses Ziel zu erreichen, entwickelten wir eine Lösung, die aus zwei Hauptkomponenten besteht:

Azure AI Document Intelligence

Azure Document Intelligence ist ein Cloud-Dienst, der Texte, Tabellen und weitere strukturierte Inhalte aus PDFs oder Bildern ausliest. Die Resultate lassen sich als JSON, HTML oder Markdown ausgeben.

In unserem Anwendungsfall setzen wir das Layout-Modell ein. Es erkennt die visuelle Struktur eines Dokuments (Lesereihenfolge, Tabellen, Textblöcke) und liefert den Inhalt als Markdown. So können wir eine Vielzahl verschiedener Dokumente verarbeiten, ohne ein spezifisches Modell trainieren zu müssen. 

Eine stichprobenartige Analyse zeigte jedoch, dass Tabellen häufig falsch interpretiert werden, weshalb die nächste Komponente umso wichtiger wird.

LLM-gestütztes Processing

Damit wir trotz Extraktionsfehlern ein sauberes Zielformat erhalten, übergeben wir die extrahierten Informationen an ein Large Language Model. DSPy orchestriert dabei die Prompts und validiert den LLM-Output direkt gegen unsere Pydantic-Modelle. Auf diese Weise lassen sich selbst unvollständig oder fehlerhaft erkannte Tabellen rekonstruieren und zuverlässig in das gewünschte Zielformat abbilden.

Wichtig: Die Tabellen im PDF entsprechen nicht immer eins zu eins dem Output unserer Anwendung, da wir im Processing die Inhalte in ein vorgegebenes Zielformat mappen, manchmal sogar aus verschiedenen Tabellen. Ein Beispiel dafür zeigt der folgende Verlauf.

Beispielablauf:

1. Original-PDF: Tabellenausschnitt mit übersichtlichem Layout.

1. Azure DI Markdown-Output: Einige Zellen sind fälschlich zusammengeführt; Spaltenköpfe sind unvollständig.

1. DSPy + Pydantic: Acht definierte Spalten werden extrahiert; jede Datenzeile wird als Pydantic-Objekt gespeichert. Ergebnis: Trotz Layout- und OCR-Fehlern sind alle Werte korrekt gemappt und könnten wieder tabellarisch dargestellt werden.

Damit ist die Grundlage für die anschließende Evaluierung gelegt. Wichtig ist also, dass wir nicht nur die Qualität der Extraktion messen, sondern auch die Leistung des LLM-gestützten Post-Processings.

Evaluation und ausgewählte Metriken

Nachdem wir die Architektur skizziert haben, widmen wir uns dem Kern dieses Beitrags: der Evaluation. Dabei spielt es keine Rolle, ob die Tabellen direkt aus dem PDF entnommen oder nachträglich durch Post-Processing transformiert wurden. Entscheidend ist, dass der erzeugte Prediction-Output zuverlässig mit dem Ground Truth (Goldstandard) verglichen werden kann und (im besten Fall 🙂) beide dieselbe Struktur besitzen.

Für diesen Abgleich stehen zahlreiche Metriken bereit, von einfachen Kennzahlen bis hin zu komplexen Verfahren. Wir beginnen mit den grundlegenden Ansätzen:

Einfacher Strukturabgleich der Tabelle

Eine der schlichtesten Prüfungen ist der Vergleich der Tabellenform:

• Spaltenzahl: Stimmt die Anzahl der extrahierten Spalten mit der Soll-Spaltenzahl überein?
• Zeilenzahl: Entspricht die Anzahl der extrahierten Zeilen der erwarteten Zeilenzahl?

Da wir die Spalten in unserem Ansatz programmatisch fixieren, richtet sich unser Augenmerk vor allem auf die Zeilen. Die Accuracy bezüglich der Zeilen berechnen wir mit folgender Formel: 

table_rows_accuracy = 1 – rowstruth– rowspredmax(rowstruth, rowspred)

Der reine Formabgleich zeigt, ob die Extraktion grundsätzlich in die richtige Richtung geht, liefert aber noch keine Aussage über deren inhaltliche Qualität. Dafür müssen die Zellinhalte verglichen werden.

Reihen-Matching – Grundlage für die inhaltliche Evaluation 

Bevor ein inhaltlicher Vergleich zwischen Prediction- und Ground-Truth-Tabellen möglich ist, muss ein zentrales Problem gelöst werden: strukturelle Abweichungen auf Zeilenebene. Während die Spalten in unserem Fall fest vorgegeben sind, können Zeilen fehlen, zusätzlich auftreten oder falsch gruppiert sein. Ein Vergleich auf Basis fixer Zellindizes greift daher oft ins Leere. Ein eindeutiger Primärschlüssel wäre ideal, fehlt aber meist oder kann durch OCR-Fehler unbrauchbar werden.

Die Konsequenz: Wir benötigen ein robustes Verfahren, das auch mit unvollständigen oder fehlerhaften Extraktionen verlässliche Zeilen-Zuordnungen ermöglicht..

Unsere Lösung kombiniert zwei Bausteine:

1. Hungarian Algorithm zur optimalen Zuordnung von Vorhersage- und Zielzeilen 
2. Ein Distanz- bzw. Ähnlichkeitsmaß, das die inhaltliche Nähe der Zeilen misst

Ziel ist ein robustes Matching, das auch mit teilweisen oder unsauberen Extraktionsergebnissen korrekt arbeitet. Wie das konkret funktioniert, zeigen wir anhand eines Beispielszenarios mit zwei typischen Fehlerfällen:

Ausgangspunkt: Die Zieltabelle

Wir nehmen eine einfache Tabelle mit zwei Zeilen als Ground-Truth und betrachten zwei Fehlerfälle:

• Fall 1: Eine Zeile wurde nicht extrahiert + Extraktionsfehler

• Fall 2: Es wurden zu viele Zeilen extrahiert + Extraktionsfehler

Matching mit dem Hungarian Algorithm

Für die Zuordnung von Vorhersage- zu Ground-Truth-Zeilen setzen wir den Hungarian-Algorithmus ein. Dazu erstellen wir eine Kostenmatrix, in der jede Kombination zweier Zeilen durch eine Distanz repräsentiert wird. Diese Distanz misst die Abweichung der Zeileninhalte und bildet somit die Grundlage für das optimale Matching.

Simple Distanzmatrix mittels Strafterm

Beim ersten Versuch haben wir jede Abweichung zwischen zwei Zellen mit einem Strafwert (+1) bewertet. Dieser Strafterm lässt sich je nach Relevanz der Spalte individuell gewichten. Aus der resultierenden Distanzmatrix wählt der Hungarian-Algorithmus das Zeilenpaar mit der geringsten Gesamtdistanz als Match aus.

In unserem Beispiel zu Fall 1 weist eine Prediction-Zeile klar die geringste Distanz zu einer bestimmten Ground-Truth-Zeile auf. Das Matching ist eindeutig, die übrig­bleibende Prediction-Zeile wird als fehlend markiert. Bei klar strukturierten und weitgehend fehlerfreien Daten funktioniert dieser Ansatz zuverlässig.

Anders sieht es bei Fall 2 aus: Mehrere Prediction-Zeilen weisen nahezu identische Distanzen zu derselben Ground-Truth-Zeile auf (etwa durch leichte OCR-Fehler). Der Algorithmus trifft hier eine quasi willkürliche Wahl, weil alle Kandidaten gleich „gut“ passen.

In Szenarien mit leicht variierenden oder fehlerbehafteten Zeilen reicht die simple Strafterm-Metrik nicht aus. Wir benötigen ein feiner auflösendes Ähnlichkeitsmaß, um solche Mehrfachtreffer eindeutig aufzulösen.

Der Versuch über die semantische Distanz von Vektorembeddings

Ein erster Ansatz zur Verbesserung des Zeilen-Matchings war die Nutzung semantischer Ähnlichkeit: Jede Datenzeile wurde zu einem normierten Textstring (z. B. durch Zusammenfügen der Zellinhalte) umgewandelt und per Sentence-BERT in einen Vektor eingebettet. Auf Basis der Kosinus-Ähnlichkeit dieser Vektoren berechneten wir eine Distanzmatrix und wendeten erneut den ungarischen Algorithmus zur optimalen Zuordnung an, diesmal nicht auf Basis von Strafpunkten, sondern semantischer Nähe.

Der Vorteil: Leicht abweichende, aber sinngleiche Zeilen wie „520 MPa“ und „ca. 520 MPa“ lassen sich korrekt matchen, wo das vorherige Verfahren scheitern würden.

Betrachten wir den Fall 2, der nicht eindeutig zugeordnet werden konnte, kann dieser nun erfolgreich zugeordnet werden:

In der Praxis zeigte sich jedoch eine klare Schwäche: Sentence-BERT ist auf Fließtext trainiert und nicht auf Zahlen, IDs oder kurze technische Werte. Unser Ziel war lexikalische Ähnlichkeit („sehen gleich aus“), nicht semantische Bedeutung („meinen das Gleiche“). Ein Beispiel zeigt das Problem:

• „456“ vs. „4B6“ → Kosinus-Ähnlichkeit: 0.436
• „456“ vs. „123“ → Kosinus-Ähnlichkeit: 0.5453

Sentence-BERT hält also „456“ und „123“ für ähnlicher, obwohl „4B6“ fast identisch aussieht. Für solche Fälle war ein anderer Metrikansatz erforderlich.

Die Lösung: Levenshtein Distanz

Um die Schwächen semantischer Ähnlichkeitsmaße auszugleichen, nutzen wir die normierte Levenshtein-Ähnlichkeit. Sie misst, wie viele minimale Bearbeitungsschritte (Einfügen, Löschen, Ersetzen) nötig sind, um einen String in einen anderen zu überführen. Der Abstand wird anschließend durch die maximale Stringlänge normiert. Je kleiner der Wert, desto ähnlicher die Zeichenketten.

Beispiel:

„Haus“ ↔ „Maus“ → 1 Ersetzung

→ normierte Distanz: 1 / 4 = 0,25

→ normierte Ähnlichkeit: 0,75

Für unser vorheriges Beispiel gilt für die Levensthein-Ähnlichkeit also:

• „456“ zu „4B6“ → Levensthein-Ähnlichkeit: 0.667

• „456“ zu „123“ → Levensthein-Ähnlichkeit: 0.0

Im Gegensatz zu Sentence-BERT erkennt die Levenshtein-Distanz die visuelle Nähe korrekt.

Natürlich ist auch diese Metrik nicht frei von Schwächen. In der Praxis hat sich gezeigt, dass sie in bestimmten Fällen ebenfalls an ihre Grenzen stößt. Ein kurzes Beispiel verdeutlicht das Problem:

• 0,001 ↔ 0,01 erfordern nur eine Bearbeitungs­operation (ein Löschen). Die normierte Levenshtein-Distanz beträgt 0,25, obwohl die Werte sich numerisch um den Faktor 10 unterscheiden.

Daher gilt: Bei numerischen Werten ist zusätzliche Validierung oder Plausibilitätsprüfung nötig.

Qualitativer Abgleich der Zelleninhalte

Nach einem längeren Exkurs zum Thema Matching liegen uns nun Vorhersage- und Ground-Truth-Paare vor, sodass ihre Zellen direkt gegenübergestellt werden können. Dabei lässt sich ermitteln, wie viele korrekt erkannte Werte das Modell geliefert hat.

Konkret betrachten wir bis dato also:

• die Anzahl der Vorhersagen,
• die Anzahl der erwarteten Werte,
• und die Anzahl korrekt vorhergesagter Zellen.

Aus diesen Größen lassen sich zentrale Metriken ableiten:

• Precision – Wie viele der erkannten Zellen waren korrekt?
• Recall – Wie viele der erwarteten Zellen wurden richtig erkannt?
• F1-Score – Optionaler Mittelwert aus Precision und Recall für eine ausgewogene Bewertung.

Diese Kennzahlen liefern eine erste Einschätzung der Extraktionsgenauigkeit. Bezogen auf unsere Beispielfälle ergibt sich daraus folgendes Bild:

Was dabei auffällt: Während das Zeilen-Matching bereits abgestuft erfolgt, bleibt der Zellvergleich bisher binär. Jede Abweichung zählt als Fehler, selbst wenn sie minimal ist. Beispiel: „03“ vs. „3“ -> formal unterschiedlich, inhaltlich identisch.

Um solche Fälle differenzierter zu erfassen, verwenden wir auch auf Zellebene die normierte Levenshtein-Distanz, praktischerweise wird diese beim Matching bereits bestimmt. Sie ermöglicht eine gestufte Bewertung der Ähnlichkeit und schafft so ein realitätsnäheres Bild der Extraktionsleistung.

Erweiterte Metriken zur Tabellenbewertung

Für unsere Evaluation decken die vorgestellten Metriken bereits die wichtigsten Aspekte ab, weil in unserem Anwendungsfall insbesondere Zeilenvollständigkeit und korrekte Zellinhalte im Vordergrund stehen. Dennoch lohnt sich ein Blick auf etablierte Metriken aus der Tabellenerkennung, allein schon der Vergleichbarkeit wegen, da sie in vielen Benchmarks als Standard gelten. Zwei häufig genutzte Verfahren sind:

• Tree Edit Distance based Similarity (TEDS): prüft vor allem Struktur-Abweichungen wie fehlende / verschobene Zeilen und deckt damit Layout-Fehler auf.
• Grid Table Similarity (GriTS): vergleicht Zellraster samt Inhalt und zeigt OCR-bedingte Text- oder Positionsfehler in Zeilen und Spalten.

Zusammen können sie ein gutes Bild der Tabellenqualität geben und zeigen, wo genauer hingeschaut werden sollte. Unser Use-Case zeigt aber: Die Metriken sind fallbedingt individuell zu wählen.

Logging mit MLflow

Während Metriken eine zentrale Rolle bei der Bewertung spielen, ist bei der Verarbeitung vieler Dokumente vor allem eines entscheidend: Nachvollziehbarkeit. Es genügt nicht, nur quantitative Kennzahlen wie Zeilen- oder Zellenabdeckung zu erfassen, auch qualitative Informationen, etwa zur Art und Ursache von Extraktionsfehlern, müssen systematisch dokumentiert werden. Genau dafür kommt in unserer Pipeline MLflow zum Einsatz.

Die Extraktions- und Evaluationspipeline verarbeitet PDF-Dokumente in mehreren Schritten von der OCR-basierten Umwandlung in Markdown über die semantische Segmentierung bis hin zur LLM-gestützten Extraktion und dem Mapping strukturierter Tabellen. Jeder Verarbeitungsschritt ist modular aufgebaut und wird mit MLflow protokolliert. Hierzu setzen wir den mlflow.trace-Dekorator ein, der Parameter und Zwischenergebnisse automatisch auf Dokument- und Tabellenebene erfasst.

Am Ende eines Durchlaufs werden zentrale Kennzahlen, etwa Zeilenanzahl, Zellenabdeckung oder Levenshtein-Scores, direkt in MLflow geloggt. Zusätzlich werden vollständige Extraktionsergebnisse, Vergleichsdaten sowie diagnostische Informationen wie Matching-Matrizen gespeichert. In Fällen mit auffälligen Abweichungen kommt ein LLM-basiertes Diagnosemodul zum Einsatz, das mögliche Ursachen erkennt und diese als cause_of_failure-Tag im MLflow-Run hinterlegt.

Dank der hierarchischen Struktur der Runs (Hauptlauf → Dokument → Tabellenart) entsteht ein klar gegliederter, reproduzierbarer Prozess, ideal für Iterationen, Fehleranalysen und automatisierte Reports.

MLflow ist damit in diesem Projekt weit mehr als nur ein Logging-Tool: Es bildet die Grundlage für Transparenz, systematische Diagnose und gezielte Weiterentwicklung der Extraktionspipeline.

Fazit

Der Weg von einer rohen PDF-Tabelle hin zu strukturierten, verlässlichen Daten ist oft deutlich länger, als man zunächst vermutet. Eine saubere, durchdachte Evaluation ist dabei unverzichtbar, besonders dann, wenn LLM-gestütztes Post-Processing ins Spiel kommt.

Im Projekt wurde schnell klar: Keine einzelne Metrik und kein einzelner Verarbeitungsschritt reichen aus, um die Extraktionsqualität vollständig zu bewerten. Erst das Zusammenspiel verschiedener Ebenen schafft echte Aussagekraft und ermöglicht gleichzeitig, gezielt zu erkennen, warum etwas funktioniert oder eben nicht.

Unsere 7 wichtigsten Learnings

• Struktur zuerst: Spalten- und Zeilenzählung decken grobe Fehler sofort auf. 

• Robustes Zeilen-Matching: Hungarian + passende Distanz ist die Basis für faire Zellvergleiche. 

• Binär ist zu grob: „03“ vs. „3“ darf kein Totalausfall sein. 

• Levenshtein doppelt hilfreich: Geeignet für zeichenbasierte Kostenfunktion im Matching und abgestufte Zellmetrik. 

• Embeddings selektiv nutzen: Gut für Fließtext, schwach bei IDs und Zahlen. 

• MLflow schafft Transparenz: Vollständiges Logging aller Zwischenergebnisse erleichtert Iterationen. 

• Prompt-Guidance statt Nachkorrektur: DSPy + Pydantic erzwingen das gewünschte Zielschema schon im LLM-Output.

Es erfordert also eine mehrstufige Kontrolle: strukturellen Vorab-Check, intelligentes Zeilen-Matching, fein abgestufte Zellmetriken und konsequentes Logging. Erst diese Kombination macht den Prozess nachvollziehbar und die Ergebnisse belastbar. Die Evaluation ist somit nicht das Ende des Prozesses, sondern der Beginn Ihres Wettbewerbsvorteils.

Die entscheidende Frage ist also nicht: Können Sie Tabellen extrahieren?
Sondern: Können Sie belegen, wie gut es wirklich funktioniert?

Die nächsten Entscheidungen in Ihrem Projekt bestimmen, ob Ihre Lösung zu den wenigen gehört, die in Produktion überzeugen oder zu einem Teil der 12 Milliarden US-Dollar Kostenfalle werden, die ineffiziente Dokumentenprozesse jährlich verursachen.

Kurz gesagt:
Wer sauber misst, versteht seine Ergebnisse.
Wer versteht, kann verbessern.
Und wer verbessert, gewinnt.