Chain-of-Table: Evoluerende Tabellen in de LLM-Redeneerketen

Ik blijf terugkomen op dezelfde ongemakkelijke observatie over tabelgebaseerd redeneren: wanneer LLM's hun werk over tabellen uitleggen met gewone chain-of-thought tekst, vertellen ze over de ene representatie terwijl ze redeneren over een andere. Chain-of-Table, een Google Research-paper gepubliceerd op ICLR 2024, neemt deze spanning serieus en stelt een eenvoudige oplossing voor: laat de tabel zelf de tussenliggende redeneerstatus dragen, niet de tekst.

Het paper

Wang et al. presenteren Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding (arXiv:2401.04398, ICLR 2024). Het paper behandelt een tekortkoming van standaard chain-of-thought prompting bij toepassing op tabelgegevens: CoT redeneert in natuurlijke taal, maar tabellen zijn gestructureerde artefacten, en de talige beschrijving van tabeltransformaties is zowel langdradig als verliesgevoelig. Het kernidee is om het LLM een reeks programmatische tabelbewerkingen te laten plannen — filteren, groeperen, sorteren, kolom selecteren, kolom toevoegen — waarbij elke bewerking wordt uitgevoerd om een tussentijdse tabelstatus te produceren. Deze geëvolueerde tabel wordt vervolgens als invoer voor de volgende stap teruggegeven aan het LLM. Het uiteindelijke antwoord wordt gegenereerd op basis van de eindstatus van de tabel in plaats van een lange tekstketen. De auteurs maken een expliciete vergelijking met SQL-ontwikkeling: een ervaren analist schrijft tussenstappen met CREATE TABLE ... AS SELECT, niet één enkele monsterlijke query. Chain-of-Table formaliseert die praktijk voor LLM-agents.

De evaluatie omvat drie benchmarks: WikiTableQuestions (WikiTQ), TabFact en FeTaQA. Het primaire model is PaLM 2, met cross-validatie op GPT-3.5 en LLaMA 2 70B.

Belangrijkste ideeën

• Chain-of-Table behaalt een denotatie-nauwkeurigheid van 67,31% op WikiTQ tegenover 61,48% voor Dater, de sterkste eerdere baseline — een verbetering van +5,83 procentpunt.
• Bij tabellen die de 4.000 tokens overschrijden, groeit de voorsprong naar +10,25 punten (44,87% vs. 34,62%), wat in de praktijk de plek is waar de methode er het meest toe doet.
• De nauwkeurigheid op TabFact bereikt 86,61% tegenover 84,63% voor Dater; de FeTaQA BLEU-score verbetert van 29,47 naar 32,61.
• De vijf atomaire bewerkingen — f_select_row, f_select_column, f_group_by, f_sort_by, f_add_column — dekken het overgrote deel van de redeneerpatronen in deze benchmarks; f_group_by doet het meeste werk op WikiTQ, waar tellen de meest voorkomende foutoorzaak is.
• Chain-of-Table vereist maximaal 25 monstergeneraties per vraag, tegenover 50 voor Binder and 100 voor Dater — een efficiëntiewinst van 50–75% naast een betere nauwkeurigheid, wat uitzonderlijk is in LLM-onderzoek waar de afweging bijna altijd de andere kant op gaat.
• De aanpak is model-agnostisch: het presteert consistent beter dan tekst-CoT baselines in PaLM 2, GPT-3.5 en LLaMA 2.

Wat overeind blijft — en wat niet

De centrale empirische bijdrage van het paper is solide. De benchmarks zijn standaard, de baselines zijn eerlijk en het efficiëntieverhaal is overtuigend. Het expliciet maken van de tabel als tussenliggende representatie in plaats van deze in proza te beschrijven is een helder idee met een intuïtieve motivatie. De resultaten op grote tabellen zijn het meest overtuigende bewijs: wanneer de tabel nauwelijks in de context past, is het progressief inkorten tot de essentie duidelijk beter dan het produceren van nog meer tekst.

Dat gezegd hebbende, zijn er reële hiaten. De analyse van foutpropagatie is oppervlakkig. Als het LLM een foutief f_select_row argument genereert in stap twee van een keten van vijf stappen, draait elke volgende bewerking op een gecorrumpeerde tussentijdse tabel en is het eindantwoord waardeloos. Het paper rapporteert geaggregeerde nauwkeurigheid, maar analyseert niet hoe vaak redeneringen falen door fouten in vroege stappen versus late stappen, of dat de aanpak robuust is tegen gedeeltelijk foutieve bewerkingen. Voor een methode die afhankelijk is van een reeks correcte aanroepen, is dit een betekenisvolle omissie.

Het vocabulaire van bewerkingen is ook een gok. Vijf bewerkingen dekken de meeste patronen in WikiTQ en TabFact omdat die benchmarks zijn ontworpen rond relationele tabeltaken. Echte financiële tabellen — balansen, grootboek-proefbalansen, belastingoverzichten — vereisen routinematig joins tussen gerelateerde tabellen, berekende aggregaten met voorwaarden (SOM van debetbedragen WAAR rekening BEGINT MET '6') en pivot-transformaties. Geen daarvan zit in de set bewerkingen. De auteurs erkennen dit impliciet, maar testen het niet.

Ten slotte is er geen theoretische verklaring waarom tussentijdse tabelstatussen beter zouden zijn dan tussentijdse tekst. De intuïtie is aantrekkelijk, maar het paper is puur empirisch. Vervolgonderzoek (TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025) stapte snel over op adaptieve hybride benaderingen die SQL en tekstueel redeneren mengen, wat suggereert dat de gemeenschap hetzelfde gat zag als ik: pure tabelbewerkingen zijn niet universeel beter, alleen beter op de geteste benchmarks.

Waarom dit belangrijk is voor finance AI

Voor Beancount grootboek-agents sluit de architectuur van Chain-of-Table bijna perfect aan op wat ik wil in een write-back pipeline. Een Beancount-query zoals "wat zijn mijn netto uitgaven per categorie voor Q1, exclusief transacties met de tag :ignore?" vereist exact het soort sequentiële tabeltransformaties die het paper voorstelt: rijen filteren op datum, filteren op tag, groeperen per rekeningcategorie, bedragen optellen. Als de agent dat kan plannen als een keten van expliciete tussenbewerkingen in plaats van één enkele query te genereren of er in proza over te redeneren, is het audittraject leesbaar en elke stap onafhankelijk verifieerbaar.

De verbetering in efficiëntie bij grote tabellen is ook direct relevant. Een meerjarig Beancount-grootboek met tienduizenden transacties overschrijdt gemakkelijk de 4.000 tokens wanneer het wordt gematerialiseerd. De verbetering van 10 punten in dat regime is geen artefact van de benchmark; het weerspiegelt wat er werkelijk gebeurt wanneer de tabel progressief moet worden versmald voordat het redeneren nauwkeurig kan zijn.

Het ontbrekende stuk voor Beancount is de join-bewerking. Dubbel boekhouden koppelt transacties over rekeningen heen, en elke reconciliatietaak vereist redeneren over ten minste twee rekeningoverzichten. Chain-of-Table zoals gepubliceerd kan dat niet uitdrukken. Het uitbreiden van het vocabulaire met cross-account joins is de voor de hand liggende volgende technische stap voor een productie-redeneeragent voor Beancount.

Wat nu te lezen

• Chain-of-Query: Unleashing the Power of LLMs in SQL-Aided Table Understanding via Multi-Agent Collaboration (2025, arXiv:2508.15809) — breidt het concept van bewerkingen uit naar multi-agent SQL-generatie, wat het gat rond joins aanpakt.
• TableMaster: A Recipe to Advance Table Understanding with Language Models (arXiv:2501.19378) — introduceert adaptief redeneren dat schakelt tussen tabelbewerkingen en tekstuele CoT; het meest directe vervolg op Chain-of-Table.
• DATER: Decomposition-based Text-to-SQL for LLMs over Long Context (arXiv:2308.01463) — complementaire decompositie-aanpak voor complexe SQL over grote schema's, relevant voor het ontwerp van beanquery NL-interfaces.