TableLlama: Kann ein offenes 7B-Modell mit GPT-4 beim Tabellenverständnis mithalten?

Das MAC-SQL-Log der letzten Woche ließ mich über das schwächste Glied bei tabellenbasierten Agenten nachdenken: die Fähigkeit des zugrunde liegenden Modells, Tabellenstruktur und -semantik zu verstehen, bevor es überhaupt eine Abfrage generiert. TableLlama (NAACL 2024) greift genau diese Ebene an – nicht durch die Verbesserung der Abfrageschnittstelle, sondern durch den Aufbau eines generalistischen Open-Source-Modells, das eine breite Palette von Tabellenaufgaben ohne aufgabenspezifisches Engineering bewältigen kann. Ich lese es gerade, weil es die direkteste Antwort auf die Frage ist, ob ein offenes 7B-Modell tatsächlich mit GPT-4 bei den Tabellenverständnisproblemen mithalten kann, mit denen ein Beancount-Agent konfrontiert wäre.

Das Paper

TableLlama, von Tianshu Zhang, Xiang Yue, Yifei Li und Huan Sun an der Ohio State University, unterzieht Llama 2 (7B) einem Fine-Tuning auf einem neuen Instruction-Tuning-Datensatz namens TableInstruct – 2,6 Millionen Beispiele, die 11 Tabellenaufgaben abdecken. Um den langen Kontext zu bewältigen, den Tabellen erfordern, nutzen sie LongLoRA, einen parametereffizienten Erweiterungsansatz, der das Kontextfenster ohne vollständiges Retraining auf 8K Token ausdehnt. Die Evaluierung umfasst acht In-Domain-Aufgaben (Spaltentyp-Annotation, Relationsextraktion, Entity-Linking, Schema-Erweiterung, Zeilen-Populierung, hierarchische Tabellen-QA, Highlighted-Cell-QA und Faktenprüfung) sowie sechs Out-of-Domain-Datensätze, auf denen das Modell nie trainiert wurde.

Die Kernbehauptung: Ein einzelnes, feinabgestimmtes offenes Modell kann in den meisten In-Domain-Benchmarks mit aufgabenspezifischen SOTA-Modellen mithalten oder diese schlagen und das Llama 2-Basismodell Out-of-Domain um 5–44 absolute Punkte übertreffen – einschließlich einer Verringerung des Abstands zu GPT-4 bei mehreren Aufgaben.

Kernideen

• Bei In-Domain-Aufgaben schlägt TableLlama GPT-4 bei strukturellen Erkennungsaufgaben deutlich: Spaltentyp-Annotation (F1 94,39 vs. 31,75), Relationsextraktion (F1 91,95 vs. 52,95), FeTaQA BLEU (39,05 vs. 21,70) und HiTab-Ausführungsgenauigkeit (64,71 vs. 48,40).
• Bei Out-of-Domain-Datensätzen dreht sich das Bild. GPT-4 führt bei der WikiTQ-Genauigkeit (68,40 vs. 35,01) und HybridQA (58,60 vs. 39,38) – beides Aufgaben, die kompositionelles Multi-Hop-Denken über Tabellen erfordern, statt nur strukturelles Mustervergleich.
• WikiSQL offenbart die Lücke bei der Abfragegenerierung drastisch: TableLlama erreicht 50,48 % gegenüber einem SOTA von 92,70 %. Diese 42-Punkte-Lücke ist der praktisch relevanteste Wert für jeden, der NL-zu-Abfrage-Schnittstellen baut.
• LongLoRA ist hier entscheidend. Finanztabellen sind lang. Ohne das erweiterte Kontextfenster wäre diese gesamte Aufgabenklasse für ein 7B-Modell unerreichbar.
• Die Autoren räumen ein, dass Rechenbeschränkungen sie auf die 7B-Größe beschränkten, wodurch die 13B- und 70B-Varianten unevaluiert blieben.

Was Bestand hat – und was nicht

Der Benchmark-Aufbau vergleicht Äpfel mit Birnen auf eine Weise, die kritisch hinterfragt werden muss. Der In-Domain-Vergleich stellt ein feinabgestimmtes TableLlama einem Zero-Shot-GPT-4 gegenüber. Bei TURL-basierten Aufgaben wie der Spaltentyp-Annotation bedeutet der F1-Score von 31,75 für GPT-4 nicht, dass GPT-4 Spaltentypen grundsätzlich nicht verstehen kann – es bedeutet, dass ein Zero-Shot-Prompt ohne formatspezifisches Tuning bei einem Datensatz scheitert, der ein sehr spezielles Ausgabeformat erwartet. Der ehrliche Vergleich findet bei Out-of-Domain-Aufgaben statt, wo beide Modelle keine Trainingsdaten gesehen haben, und dort ist der Abstand ernüchternd: WikiTQ-Genauigkeit 35,01 vs. 68,40.

WikiTQ ist der richtige Stresstest, da es Fragen erfordert wie: „Welches Land hat die meisten Medaillen in Wettbewerben gewonnen, bei denen der vorherige Rekord vor 1990 aufgestellt wurde?“ – echtes kompositionelles Denken über Tabellenzellen hinweg. Das Defizit von TableLlama von 33 Punkten bei WikiTQ gegenüber GPT-4 ist das deutlichste Signal, dass Instruction-Tuning auf strukturellen Aufgaben nicht automatisch auf relationales Denken übertragbar ist.

Die Gewinne bei Schema-Erweiterung und Entity-Linking sind real und bedeutsam – diese Aufgaben erfordern tatsächlich ein Verständnis der Tabellenstruktur in einer Weise, mit der ein Zero-Shot-GPT-4-Prompt Probleme hat. Aber sie sind auch näher am Information Retrieval als am logischen Denken, was die Generalisierbarkeit dieser Ergebnisse einschränkt.

Ein weiteres Bedenken: Der TableInstruct-Datensatz mit 2,6 Mio. Beispielen ist eine beachtliche Ingenieursleistung, bündelt aber sehr unterschiedliche Aufgabentypen in ein einziges Instruction-Format. Es gibt keine Ablationsstudie, die zeigt, welche Aufgabentypen sich gegenseitig stören oder welche für die Out-of-Domain-Gewinne ausschlaggebend sind. Der eigene Nachfolge-Benchmark der OSU-Gruppe (TableBench, AAAI 2025) ergab, dass auf TableInstruct feinabgestimmte Modelle eine Leistung erzielen, die mit GPT-3.5 vergleichbar ist, aber immer noch hinter GPT-4 zurückbleibt – was den Optimismus des ursprünglichen Papers erheblich dämpft.

Warum das für Finanz-KI wichtig ist

Beancount-Hauptbücher sind strukturierte Tabellen: Jeder Eintrag hat ein Datum, ein Konto, einen Betrag und optionale Metadaten. Die Tabellenaufgaben in diesem Paper lassen sich direkt auf die Operationen übertragen, die ein Beancount-Agent ausführen muss. Die Spaltentyp-Annotation entspricht dem Verständnis, welche Konten zu welchem Kontotyp gehören (Assets, Liabilities, Expenses). Entity-Linking entspricht der Auflösung von Zahlungsempfängernamen über inkonsistente Transaktionsbeschreibungen hinweg. Und die WikiSQL-Lücke entspricht exakt dem Problem der beanquery-NL-Schnittstelle.

Die Ergebnisse hier vermitteln mir ein kalibriertes Bild: Ein feinabgestimmtes 7B-Modell kann die Erkennung der Hauptbuchstruktur zuverlässig genug bewältigen, um nützlich zu sein, aber man kann ihm noch nicht zutrauen, frei formulierte Fragen ohne ein leistungsfähigeres Modell im Prozess in korrekte beanquery-Ausdrücke zu übersetzen. Die WikiSQL-Genauigkeit von 50 % (gegenüber 93 % SOTA) bedeutet, dass eine nur auf einem offenen Modell basierende beanquery-Schnittstelle bei ungewohnten Fragestellungen etwa die Hälfte der Zeit falsche Abfragen generieren würde. Für einen Write-Back-Agenten ist diese Fehlerrate zu hoch. Für eine schreibgeschützte Abfrageschnittstelle mit menschlicher Überprüfung könnte sie als erster Entwurf akzeptabel sein.

Der LongLoRA-Beitrag ist direkt anwendbar: Mehrjährige Beancount-Hauptbücher können leicht 8K Token überschreiten, und der hier gezeigte Ansatz demonstriert, wie man auf lange Tabellen ohne prohibitive Rechenkosten feinabstimmt.

Was man als Nächstes lesen sollte

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) – der Nachfolger der OSU-Gruppe, der über 30 LLMs auf komplexeren Tabellen-QA benchmarkt und feststellt, dass die Lücke zwischen offenen Modellen und GPT-4 auch nach dem TableInstruct-Fine-Tuning bestehen bleibt.
• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) – Pre-Training auf synthetischer SQL-Ausführung als Kontrast zum Instruction-Tuning; wichtige Baseline für die Debatte zwischen Pre-Training und Fine-Tuning beim Tabellenverständnis.
• Rethinking Table Instruction Tuning (arXiv:2501.14693) – eine aktuelle Arbeit, die hinterfragt, ob das Standard-TableInstruct-Rezept tatsächlich generalisiert und welche Entscheidungen bei der Datenzusammensetzung am wichtigsten sind.