TableLlama: Kan een open 7B-model GPT-4 evenaren in tabelbegrip?

Het MAC-SQL-logboek van vorige week zette me aan het denken over de zwakste schakel in tabelgebaseerde agents: het vermogen van het onderliggende model om de tabelstructuur en semantiek te begrijpen nog voordat het een query genereert. TableLlama (NAACL 2024) pakt die laag direct aan — niet door de query-interface te verbeteren, maar door een generalistisch open-source model te bouwen dat een breed scala aan tabeltaken aankan zonder taakspecifieke engineering. Ik lees het nu omdat het het meest directe antwoord is op de vraag of een open 7B-model daadwerkelijk GPT-4 kan evenaren in de tabelbegripproblemen waar een Beancount-agent mee te maken krijgt.

Het artikel

TableLlama, door Tianshu Zhang, Xiang Yue, Yifei Li en Huan Sun aan de Ohio State University, finetunet Llama 2 (7B) op een nieuwe instructie-tuning dataset genaamd TableInstruct — 2,6 miljoen voorbeelden verdeeld over 11 tabeltaken. Om de lange context die tabellen vereisen aan te kunnen, gebruiken ze LongLoRA, een parameterefficiënte uitbreidingsmethode die het contextvenster oprekt naar 8K tokens zonder volledige hertraining. De evaluatie beslaat acht binnen-domein taken (kolomtype-annotatie, relatie-extractie, entiteitskoppeling, schema-augmentatie, rijpopulatie, hiërarchische tabel-QA, QA met gemarkeerde cellen en feitverificatie) plus zes buiten-domein datasets waarop het model nooit is getraind.

De belangrijkste claim: een enkel gefinetuned open model kan de taakspecifieke SOTA op de meeste binnen-domein benchmarks evenaren of verslaan, en het Llama 2-basismodel met 5–44 absolute punten buiten het domein overtreffen — inclusief het verkleinen van de kloof met GPT-4 op verschillende taken.

Kernideeën

• Bij binnen-domein taken verslaat TableLlama GPT-4 overtuigend op structurele herkenningstaken: Kolomtype-annotatie (F1 94,39 vs. 31,75), Relatie-extractie (F1 91,95 vs. 52,95), FeTaQA BLEU (39,05 vs. 21,70) en HiTab-executieprecisie (64,71 vs. 48,40).
• Bij buiten-domein datasets draait het beeld om. GPT-4 loopt voorop bij WikiTQ-precisie (68,40 vs. 35,01) and HybridQA (58,60 vs. 39,38) — beide taken die compositioneel multi-hop redeneren over tabellen vereisen in plaats van structurele patroonherkenning.
• WikiSQL legt de kloof in query-generatie pijnlijk bloot: TableLlama scoort 50,48% tegenover een SOTA van 92,70%. Deze kloof van 42 punten is het meest praktisch relevante getal voor iedereen die NL-naar-query-interfaces bouwt.
• LongLoRA is hier de dragende kracht. Financiële tabellen zijn lang. Zonder het uitgebreide contextvenster zou deze hele klasse van taken onbereikbaar zijn voor een 7B-model.
• De auteurs erkennen dat computerbeperkingen hen beperkten tot de 7B-grootte, waardoor de 13B- en 70B-varianten niet zijn geëvalueerd.

Wat standhoudt — en wat niet

De benchmark-opzet vergelijkt appels met peren op een manier die kritisch moet worden bekeken. De binnen-domein vergelijking zet een gefinetunede TableLlama af tegen een zero-shot GPT-4. Bij op TURL gebaseerde taken zoals kolomtype-annotatie betekent de score van 31,75 F1 voor GPT-4 niet dat GPT-4 fundamenteel geen kolomtypes kan begrijpen — het betekent dat een zero-shot prompt zonder formaatspecifieke tuning faalt op een dataset die een zeer specifieke uitvoerindeling verwacht. De eerlijke vergelijking vindt plaats bij buiten-domein taken, waar beide modellen geen trainingsdata hebben gezien, en daar is de kloof ontnuchterend: WikiTQ-precisie 35,01 vs. 68,40.

WikiTQ is de juiste stresstest omdat het vragen vereist als "Welk land won de meeste medailles in evenementen waar het vorige record voor 1990 werd gevestigd?" — echt compositioneel redeneren over tabelcellen. Het tekort van 33 punten van TableLlama op WikiTQ ten opzichte van GPT-4 is het duidelijkste signaal dat instructie-tuning op structurele taken niet automatisch overgaat in relationeel redeneren.

De winst op schema-augmentatie en entiteitskoppeling is reëel en betekenisvol — die taken vereisen oprecht begrip van tabelstructuur op manieren waar een zero-shot GPT-4 prompt moeite mee heeft. Maar ze liggen ook dichter bij retrieval dan bij redeneren, wat de mate waarin deze resultaten gegeneraliseerd kunnen worden beperkt.

Een ander punt van zorg: de TableInstruct-dataset met 2,6 miljoen voorbeelden is een aanzienlijke technische inspanning, maar het voegt zeer verschillende taaktypes samen in één instructieformaat. Er is geen ablatie die laat zien welke taaktypes elkaar storen of welke cruciaal zijn voor de winst buiten het domein. De eigen vervolgbenchmark van de OSU-groep (TableBench, AAAI 2025) wees uit dat modellen die zijn gefinetuned op TableInstruct prestaties leveren die vergelijkbaar zijn met GPT-3.5, maar nog steeds tekortschieten bij GPT-4 — wat het optimisme van het oorspronkelijke artikel aanzienlijk tempert.

Waarom dit belangrijk is voor financiële AI

Beancount-grootboeken zijn gestructureerde tabellen: elke boeking heeft een datum, rekening, bedrag en optionele metadata. De tabeltaken in dit artikel zijn direct te vertalen naar de handelingen die een Beancount-agent moet uitvoeren. Kolomtype-annotatie vertaalt zich naar het begrijpen van welke rekeningen bij welk rekeningtype horen (Activa, Passiva, Kosten). Entiteitskoppeling vertaalt zich naar het herleiden van begunstigdenamen bij inconsistente transactieomschrijvingen. En de WikiSQL-kloof komt precies overeen met het probleem van de beanquery NL-interface.

De resultaten hier geven me een gekalibreerd beeld: een gefinetuned 7B-model kan de herkenning van de grootboekstructuur betrouwbaar genoeg afhandelen om nuttig te zijn, maar het kan nog niet worden vertrouwd om vrije vragen te vertalen naar correcte beanquery-expressies zonder een krachtiger model in de loop. De 50% WikiSQL-precisie (tegenover 93% SOTA) betekent dat een beanquery-interface met enkel een open model in ongeveer de helft van de gevallen foutieve queries zou genereren bij onbekende vraagformuleringen. Voor een write-back agent is dat foutpercentage te hoog. Voor een read-only query-interface met menselijke controle zou het acceptabel kunnen zijn als eerste concept.

De LongLoRA-bijdrage is direct toepasbaar: meerjarige Beancount-grootboeken kunnen gemakkelijk de 8K tokens overschrijden, en de aanpak hier laat zien hoe je kunt finetunen voor lange tabellen zonder buitensporige rekenkracht.

Wat nu te lezen

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) — het eigen vervolgonderzoek van de OSU-groep dat 30+ LLM's test op complexere tabel-QA en concludeert dat de kloof tussen open modellen en GPT-4 blijft bestaan, zelfs na TableInstruct-finetuning.
• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — pre-training op synthetische SQL-executie als contrast met instructie-tuning; een belangrijke basislijn voor het debat over pre-training versus fine-tuning in tabelbegrip.
• Rethinking Table Instruction Tuning (arXiv:2501.14693) — recent werk dat zich afvraagt of het standaard TableInstruct-recept daadwerkelijk generaliseert en welke keuzes in de datasamenstelling het belangrijkst zijn.