Chain-of-Table: Evolution von Tabellen in der LLM-Schlussfolgerungskette

Ich komme immer wieder zu derselben unbequemen Beobachtung über tabellarisches Schlussfolgern zurück: Wenn LLMs ihre Arbeit über Tabellen mit reinem Chain-of-Thought-Text erklären, beschreiben sie eine Darstellung, während sie über eine andere schlussfolgern. Chain-of-Table, ein Paper von Google Research, das auf der ICLR 2024 veröffentlicht wurde, nimmt diese Spannung ernst und schlägt eine einfache Lösung vor: Die Tabelle selbst soll den Zwischenzustand der Schlussfolgerung tragen, nicht der Text.

Das Paper

Wang et al. präsentieren Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding (arXiv:2401.04398, ICLR 2024). Das Paper adressiert eine Lücke, die das Standard-Chain-of-Thought-Prompting bei tabellarischen Daten hinterlässt: CoT schlussfolgert in natürlicher Sprache, aber Tabellen sind strukturierte Artefakte, und die sprachliche Beschreibung von Tabellentransformationen ist sowohl wortreich als auch verlustbehaftet. Die Kernidee besteht darin, das LLM eine Sequenz von programmatischen Tabellenoperationen planen zu lassen – filtern, gruppieren, sortieren, Spalte auswählen, Spalte hinzufügen –, wobei jede Operation ausgeführt wird, um einen Tabellenzwischenzustand zu erzeugen. Diese weiterentwickelte Tabelle wird dem LLM als Input für den nächsten Schritt zurückgegeben. Die endgültige Antwort wird aus dem finalen Tabellenzustand generiert und nicht aus einer langen Textkette. Die Autoren ziehen eine explizite Analogie zur SQL-Entwicklung: Ein versierter Analyst schreibt inkrementelle CREATE TABLE ... AS SELECT Schritte und keine einzelne monolithische Abfrage. Chain-of-Table formalisiert diese Praxis für LLM-Agenten.

Die Evaluierung umfasst drei Benchmarks: WikiTableQuestions (WikiTQ), TabFact und FeTaQA. Das primäre Modell ist PaLM 2, mit Kreuzvalidierung auf GPT-3.5 und LLaMA 2 70B.

Kernideen

• Chain-of-Table erreicht eine Denotationsgenauigkeit von 67,31 % auf WikiTQ gegenüber 61,48 % bei Dater, der stärksten vorherigen Baseline – eine Verbesserung um +5,83 Prozentpunkte.
• Bei Tabellen mit mehr als 4.000 Token wächst der Vorteil auf +10,25 Punkte (44,87 % vs. 34,62 %), was in der Praxis der Bereich ist, in dem die Methode am wichtigsten ist.
• Die Genauigkeit bei TabFact erreicht 86,61 % gegenüber 84,63 % bei Dater; FeTaQA BLEU verbessert sich von 29,47 auf 32,61.
• Die fünf atomaren Operationen – f_select_row, f_select_column, f_group_by, f_sort_by, f_add_column – decken die überwiegende Mehrheit der in diesen Benchmarks beobachteten Schlussfolgerungsmuster ab; f_group_by leistet die meiste Arbeit bei WikiTQ, wo Zählen der dominierende Fehlermodus ist.
• Chain-of-Table erfordert höchstens 25 Beispiel-Generierungen pro Frage, gegenüber 50 bei Binder und 100 bei Dater – ein Effizienzgewinn von 50–75 % bei gleichzeitig besserer Genauigkeit, was in der LLM-Forschung, wo der Trade-off fast immer in die andere Richtung geht, ungewöhnlich ist.
• Der Ansatz ist modellagnostisch: Er übertrifft Text-CoT-Baselines konsistent über PaLM 2, GPT-3.5 und LLaMA 2 hinweg.

Was Bestand hat – und was nicht

Der zentrale empirische Beitrag des Papers ist solide. Die Benchmarks sind Standard, die Baselines sind fair und die Effizienzgeschichte ist überzeugend. Die Tabelle selbst zu einer expliziten Zwischendarstellung zu machen, anstatt sie in Prosa zu beschreiben, ist eine saubere Idee mit intuitiver Motivation. Die Ergebnisse bei großen Tabellen sind der überzeugendste Beweis: Wenn die Tabelle kaum in den Kontext passt, ist es eindeutig besser, sie durch Operationen schrittweise auf das Wesentliche zu reduzieren, als noch mehr Text zu produzieren.

Dennoch gibt es echte Lücken. Die Analyse der Fehlerfortpflanzung ist oberflächlich. Wenn das LLM im zweiten Schritt einer fünfstufigen Kette ein falsches f_select_row-Argument generiert, läuft jede nachfolgende Operation auf einer fehlerhaften Zwischentabelle, und die endgültige Antwort ist unbrauchbar. Das Paper berichtet die aggregierte Genauigkeit, analysiert aber nicht, wie oft das Schlussfolgern aufgrund von Fehlern in frühen Schritten im Vergleich zu späten Schritten scheitert oder ob der Ansatz robust gegenüber teilweise falschen Operationen ist. Für eine Methode, die von einer Sequenz korrekter Aufrufe abhängt, ist dies eine bedeutende Auslassung.

Das Operationsvokabular ist ebenfalls eine Wette. Fünf Operationen decken die meisten Muster in WikiTQ und TabFact ab, da diese Benchmarks um relationale Tabellenaufgaben herum entwickelt wurden. Reale Finanztabellen – Bilanzen, Summen- und Saldenlisten, Steuerübersichten – erfordern routinemäßig Joins über verwandte Tabellen, berechnete Aggregate mit Bedingungen (SUMME der Soll-Buchungen WO Konto BEGINNT MIT '6') und Pivot-Transformationen. Nichts davon ist im Operationsset enthalten. Die Autoren räumen dies implizit ein, testen es jedoch nicht.

Schließlich gibt es keine theoretische Erklärung dafür, warum Tabellenzwischenzustände besser sein sollten als Textzwischenzustände. Die Intuition ist ansprechend, aber das Paper ist rein empirisch. Die Folgetexte (TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025) gingen schnell zu adaptiven Hybridansätzen über, die SQL- und Text-Schlussfolgerungen mischen. Dies deutet darauf hin, dass die Community die gleiche Lücke sah wie ich: Reine Tabellenoperationen sind nicht universell besser, sondern nur besser bei den getesteten Benchmarks.

Warum das für Finance AI wichtig ist

Für Beancount-Ledger-Agenten lässt sich die Architektur von Chain-of-Table fast perfekt auf das übertragen, was ich mir für eine Write-Back-Pipeline wünsche. Eine Beancount-Abfrage wie „Wie hoch sind meine Nettoausgaben nach Kategorie für Q1, ohne Transaktionen mit dem Tag :ignore?“ erfordert genau die Art von sequenziellen Tabellentransformationen, die das Paper vorschlägt: Zeilen nach Datum filtern, nach Tag filtern, nach Kontokategorie gruppieren, Beträge summieren. Wenn der Agent dies als Kette expliziter Zwischenoperationen planen kann, anstatt eine einzelne Abfrage zu generieren oder in Prosa darüber zu schlussfolgern, ist der Audit-Trail lesbar und jeder Schritt unabhängig verifizierbar.

Die Effizienzverbesserung bei großen Tabellen ist ebenfalls direkt relevant. Ein mehrjähriger Beancount-Ledger mit zehntausenden Transaktionen überschreitet im materialisierten Zustand leicht 4.000 Token. Die 10-Punkte-Verbesserung in diesem Bereich ist kein Benchmark-Artefakt; sie spiegelt wider, was tatsächlich passiert, wenn die Tabelle schrittweise eingegrenzt werden muss, bevor präzise Schlussfolgerungen möglich sind.

Das fehlende Puzzleteil für Beancount ist die Join-Operation. Die doppelte Buchführung verknüpft Transaktionen über Konten hinweg, und jede Abstimmungsaufgabe erfordert das Schlussfolgern über mindestens zwei Kontenverläufe. Chain-of-Table in der veröffentlichten Form kann das nicht ausdrücken. Die Erweiterung des Operationsvokabulars um kontoübergreifende Joins ist der nächste logische Entwicklungsschritt für einen produktiven Beancount-Schlussfolgerungsagenten.

Was man als Nächstes lesen sollte

• Chain-of-Query: Unleashing the Power of LLMs in SQL-Aided Table Understanding via Multi-Agent Collaboration (2025, arXiv:2508.15809) – erweitert das Operationskonzept in Richtung Multi-Agenten-SQL-Generierung, was die Join-Lücke schließt.
• TableMaster: A Recipe to Advance Table Understanding with Language Models (arXiv:2501.19378) – führt adaptives Schlussfolgern ein, das zwischen Tabellenoperationen und textuellem CoT wechselt; der direkteste Nachfolger von Chain-of-Table.
• DATER: Decomposition-based Text-to-SQL for LLMs over Long Context (arXiv:2308.01463) – komplementärer Zerlegungsansatz für komplexes SQL über großen Schemata, relevant für das Design von beanquery-NL-Schnittstellen.