Können LLMs über tabellarische Daten schlussfolgern? Was vier Benchmarks über Finanz-KI verraten

Tabellen sind die Art und Weise, wie Buchhalter denken. Ein Beancount-Hauptbuch ist im Grunde eine Tabelle – Konten als Zeilen, Daten und Beträge als Spalten, Assertions als Beschränkungen über Zellen hinweg. Als ich anfing zu fragen, ob LLMs autonome Finanzagenten antreiben können, stieß ich immer wieder auf dieselbe Vorabfrage: Können sie überhaupt zuverlässig eine Tabelle lesen? Die Literatur dazu ist vernichtender, als ich erwartet hatte.

Die Studie

Fang et al. veröffentlichten „Large Language Models (LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey“ in TMLR 2024 (arXiv:2402.17944). Es handelt sich um eine 41-seitige Taxonomie, die drei Bereiche abdeckt: die Vorhersage strukturierter Ergebnisse aus tabellarischen Merkmalen, die Generierung synthetischer tabellarischer Daten und das Verständnis von Tabellen, das ausreicht, um Fragen dazu zu beantworten. Der Bereich Verständnis – Tabellen-Frage-Antwort-Systeme (TableQA), Faktenprüfung und strukturelles Schlussfolgern – ist der Ort, an dem die relevanteste Arbeit für Finanz-KI stattfindet.

Die Studie, die ich parallel dazu gelesen habe, „Table Meets LLM: Can Large Language Models Understand Structured Table Data?“ von Sui et al. (WSDM 2024, arXiv:2305.13062), verfolgt einen kontrollierteren Ansatz: Sie definieren einen Benchmark für strukturelle Verständnisfähigkeit (Structural Understanding Capability, SUC) mit sieben eng gefassten Aufgaben – Tabellenpartitionierung, Größenbestimmung, Erkennung verbundener Zellen, Zellen-Lookup, Reverse-Lookup, Spaltenabruf und Zeilenabruf – und testen GPT-3.5 und GPT-4 direkt. Keine Argumentationsketten, keine Retrieval-Tricks. Nur: Kann das Modell tun, was wir verlangen?

Kernaussagen

• Die Formatlücke ist real und überraschend groß. Im SUC-Benchmark übertrifft die HTML-Serialisierung das Format „Natürliche Sprache mit Trennzeichen“ insgesamt um etwa 6,76 %. Das Ranking – HTML > XML > JSON > Markdown > NL+Sep – bleibt über alle Aufgaben hinweg konsistent. Beancount-Dateien liegen näher am Ende des Spektrums der natürlichen Sprache, was ein Warnsignal ist.
• Zellen-Lookup ist überraschend schwierig. GPT-3.5 erreicht nur eine Genauigkeit von 44 % beim direkten Zellen-Lookup (finde den Wert in Zeile X, Spalte Y). GPT-4 erreicht bei derselben Aufgabe 73,34 %. Für eine deterministische Operation, die eine Tabellenkalkulationsformel in Mikrosekunden bewältigt, ist eine Lücke von 26 Prozentpunkten zwischen den Modellen alarmierend.
• Few-Shot-Beispiele sind von entscheidender Bedeutung. Das Entfernen von 1-Shot-Beispielen aus den SUC-Prompts führte zu einem Rückgang der Gesamtgenauigkeit um 30,38 % über alle Aufgaben hinweg. Das strukturelle Verständnis des Modells wird stark durch Demonstrationen gestützt und ist nicht wirklich internalisiert.
• Die Kluft zwischen Mensch und LLM bei realen Tabellen-Fragen ist enorm. TableBench (arXiv:2408.09174, AAAI 2025) bewertet 886 Fragen in den Bereichen Faktenprüfung, numerisches Schlussfolgern, Datenanalyse und Visualisierung. Die menschliche Genauigkeit liegt bei 85,91 %. GPT-4-Turbo erreicht 40,38 %, GPT-4o kommt auf 42,73 %. Die derzeit besten Modelle erbringen etwa die Hälfte der menschlichen Leistung in einem Benchmark, der die Komplexität der realen Welt widerspiegeln soll.
• Der Komplexitätskollaps bei Finanz-Tabellenkalkulationen ist gravierend. FinSheet-Bench (arXiv:2603.07316) testet LLMs an Vorlagen für Private-Equity-Fonds mit unterschiedlicher struktureller Komplexität. Einfache Abfragen erreichen eine Genauigkeit von 89,1 %. Komplexe Aggregationen fallen auf 19,6 %. Die größte Testdatei (152 Unternehmen, 8 Fonds) liefert eine durchschnittliche Genauigkeit von 48,6 % über alle Modelle hinweg, verglichen mit 86,2 % bei der einfachsten Datei.
• Lange Tabellen bringen Modelle kategorisch zum Scheitern. Die TMLR-Studie berichtet, dass jenseits von 1000 Token die Leistung von GPT-3 auf ein nahezu zufälliges Niveau abfällt. Selbst Modelle mit einem Kontextfenster von 200.000 Token haben aufgrund der quadratischen Kosten der Self-Attention bei langen Sequenzen Schwierigkeiten mit massiven Datensätzen.

Was Bestand hat – und was nicht

Der Benchmark von Sui et al. ist sorgfältig konzipiert und die Zahlen sind glaubwürdig. Die Erkenntnis, dass HTML bei strukturellen Aufgaben besser abschneidet als Markdown, ist kontraintuitiv – Markdown ist kompakter und LLMs sehen im Training mehr davon –, deckt sich aber mit den Erwartungen: Das explizite Tagging von HTML gibt dem Modell mehr Ankerpunkte, um durch die Struktur zu navigieren, ohne sie ableiten zu müssen.

Woran ich zweifle: Die Technik der Selbst-Augmentierung (ein zweistufiges Prompting, bei dem der erste Prompt das Modell auffordert, kritische Werte zu identifizieren, bevor es antwortet) führt zu Verbesserungen von 0,84–5,68 % bei nachgelagerten Benchmarks wie TabFact und ToTTo. Das sind reale Zahlen aus realen Experimenten, aber sie sind marginal. Die Technik löst das grundlegende Problem nicht – sie ist ein Prompt-Engineering-Patch auf einem tatsächlich schwachen strukturellen Verständnis.

Die TMLR-Studie leidet unter dem für alle Übersichtsarbeiten typischen Problem des Umfangs: Sie deckt alles ab, von der tabellarischen Vorhersage (XGBoost-Territorium) über die generative Tabellensynthese bis hin zu Frage-Antwort-Systemen, was die Analyse verwässert. Der für meine Zwecke nützlichste Abschnitt ist der Bereich zum strukturierten Frage-Antwort-System, und selbst dort katalogisiert die Studie eher Methoden, anstatt zu synthetisieren, welche davon tatsächlich zuverlässig sind.

Die Erkenntnis aus FinSheet-Bench, dass komplexe Aggregationen nur 19,6 % erreichen, ist das spezifischste Alarmzeichen für den Finanzbereich. Portfolio-Aggregationen, Rollups auf Fondsebene und Mehrperiodenvergleiche sind genau die Operationen, die eine Finanzberichterstattung nicht trivial machen – und genau dort versagen LLMs.

Warum dies für Finanz-KI wichtig ist

Beancount-Hauptbücher sind Tabellen. Wenn ein autonomer Agent ein Hauptbuch liest, um Anomalien zu erkennen, Berichte zu erstellen oder über einen Rückschreibvorgang (Write-back) zu entscheiden, führt er tabellarische Schlussfolgerungen durch. Die Beweise deuten darauf hin, dass aktuelle LLMs einfache Abfragen einigermaßen gut beherrschen (Zellenabruf bei 73 % für GPT-4), aber bei den Operationen kollabieren, auf die es am meisten ankommt: mehrstufige Aggregation, Größenschätzung für große Hauptbücher und Schlussfolgerungen über strukturelle Variationen.

Die Erkenntnis zur Serialisierung hat unmittelbare praktische Auswirkungen. Wenn ich Beancount-Dateien in ein LLM einspeise, beeinflusst das gewählte Format die Genauigkeit um mehrere Prozentpunkte, noch bevor ich eine einzige Zeile Agenten-Logik geschrieben habe. Die native Syntax von Beancount liegt nahe am „NL+Sep“-Ende der Formathierarchie – lesbar für Menschen, suboptimal für LLMs. Die Konvertierung in ein strukturierteres Zwischenformat (eine JSON- oder HTML-Tabelle von Transaktionen), bevor sie einem Modell zugeführt wird, könnte den Aufwand der Vorverarbeitung wert sein.

Der Komplexitätskollaps bei großen Datenmengen ist die ernüchterndste Erkenntnis. Ein reales Beancount-Hauptbuch für ein kleines Unternehmen kann Tausende von Transaktionen, Dutzende von Konten und eine mehrjährige Historie umfassen. Die Ergebnisse von FinSheet-Bench legen nahe, dass die Genauigkeit von LLMs, sobald eine Tabelle eine Größe erreicht, bei der sie tatsächlich relevant wird, in einen Bereich abfällt, der für autonome Rückschreibvorgänge nicht sicher ist.

Was man als Nächstes lesen sollte

• TableLLM (arXiv:2311.09206) – ein feingetuntes Modell, das auf 169 Kaggle-Tabellen trainiert wurde (UniPredict); es soll GPT-4 bei der tabellarischen Vorhersage ohne spezifisches Training (Zero-Shot) deutlich übertreffen, was darauf hindeutet, dass domänenspezifisches Feintuning immer noch der richtige Ansatz für finanzspezifische Tabellenaufgaben ist.
• TAT-QA (arXiv:2105.07624) – ein Datensatz speziell für diskretes Schlussfolgern über hybride Finanzdokumente (Tabellen + Text, wie z. B. Ergebnisberichte); das zugehörige TAT-LLM-Modell ist der direkteste Vorläufer für die Anwendung spezialisierter Modelle auf das Schlussfolgern in Finanztabellen.
• ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412) – konzentriert sich auf adversariale Störungen wie das Vertauschen von Zeilen und das Umordnen von Spalten; wenn ein Beancount-Agent robust gegenüber Umordnungen ist, ist dies ein Signal dafür, dass er die Struktur und nicht die Position versteht.