TableMaster: Adaptívne uvažovanie pre porozumenie tabuľkám pomocou LLM

Hlavná kniha Beancount je vo svojej podstate štruktúrovaná tabuľka: účty ako stĺpce, čas ako jedna os, sumy a meny ako hodnoty. Akýkoľvek agent, ktorý nad ňou uvažuje, musí robiť to, čo TableMaster — nájsť správne riadky a stĺpce, pochopiť, čo čísla znamenajú, a vybrať si, či bude počítať symbolicky alebo uvažovať v prirodzenom jazyku. TableMaster od Langa Cao a Hanbinga Liu (arXiv:2501.19378) je najschopnejšia pipeline na porozumenie tabuľkám bez jemného doladenia (fine-tuning), akú som doteraz videl, a chcel som pochopiť, či skutočne posúva stav techniky koncepčným spôsobom, alebo len vrství heuristiky promptingu, kým sa nepohne benchmark.

Práca

TableMaster je framework založený na promptingu, ktorý rieši štyri špecifické režimy zlyhania LLM pri tabuľkovom odpovedaní na otázky: modely majú problém lokalizovať relevantnú bunku vo veľkej tabuľke, uniká im sémantický kontext zakódovaný v hlavičkách stĺpcov, halucinujú aritmetiku pri uvažovaní v čistom texte a zlyhávajú, keď symbolické uvažovanie (SQL, Python) narazí na zašumené dáta alebo dáta zmiešaných typov. Autori reagujú na každé zlyhanie vyhradeným modulom, ktoré sú zostavené do trojstupňovej pipeline. Prvá fáza vytvára „tabuľku záujmu“ (table-of-focus) — orezanú podtabuľku obsahujúcu iba riadky a stĺpce relevantné pre dotaz — pomocou vyhľadávania stĺpcov zoradených pomocou LLM a filtrovania riadkov pomocou SQL. Druhá fáza verbalizuje túto podtabuľku do prirodzeného jazyka a kontroluje, či je extrahovaný výrez skutočne dostatočný na zodpovedanie otázky, pričom ho v prípade potreby iteratívne rozširuje. Tretia fáza aplikuje adaptívne uvažovanie: LLM sa pri každom dotaze rozhodne, či spustí reťazec myšlienok (chain-of-thought) nad verbalizovaným popisom, alebo vygeneruje a spustí Python či SQL, pričom symbolická cesta je vedená popisom v prirodzenom jazyku, aby zvládla prípady, keď sú hodnoty v tabuľke neusporiadané reťazce namiesto čistých čísel.

Žiadny nový model nie je trénovaný. Všetko beží na univerzálnych LLM (GPT-3.5-turbo, GPT-4o-mini, Llama-3.1-70B) prostredníctvom promptingu.

Kľúčové myšlienky

• V benchmarku WikiTQ s modelom GPT-4o-mini dosahuje TableMaster 78,13 % v porovnaní s 55,60 % pri Chain-of-Table a 64,73 % pri PoTable na rovnakom modeli — čo predstavuje zlepšenie o 13,40 bodu oproti ďalšej najlepšej základnej línii (baseline).
• Rovnaký vzorec platí aj pri GPT-3.5-turbo (68,21 % oproti predchádzajúcemu najlepšiemu výsledku ~58 %) a Llama-3.1-70B (77,95 %), čo ukazuje, že zisky nie sú špecifické pre konkrétny model.
• V benchmarku TabFact (overovanie faktov) dosahuje TableMaster s GPT-4o-mini 90,12 % oproti 84,24 % pri Chain-of-Table — ide o menšie, ale konzistentné zlepšenie.
• Ablácia odhaľuje, že odstránenie textového uvažovania škodí najviac (–4,28 %), nasledované odstránením extrakcie štruktúry (–3,38 %). Adaptívne prepínanie medzi režimami je skutočne nosným prvkom.
• Veľkosť tabuľky je dominantným prediktorom zlyhania: výkon degraduje monotónne s rastúcim počtom riadkov, stĺpcov a tokenov, bez ohľadu na model.
• Symbolické uvažovanie degraduje o 31,8 % na zašumených tabuľkách oproti 20,5 % pri textovom uvažovaní — textovo vedená symbolická cesta existuje práve na zmiernenie tohto režimu zlyhania.
• Samotné textové uvažovanie degraduje o 20,1 % pri dotazoch náročných na výpočty oproti 72,4 % pri úlohách bez výpočtov — čo presne ilustruje, prečo na hybridnom prepínaní záleží.

Čo obstojí — a čo nie

Diagnóza štyroch výziev je dobre odôvodnená a jasne mapuje skutočné prípady zlyhania. Ablácia je úprimná: odstránenie ktoréhokoľvek komponentu škodí, pričom rozsah je úmerný tomu, ako veľmi sa daný komponent v skutočnosti využíval. To je silnejšie ako bežná ablácia, kde odstránenie komponentov nič nemení, pretože model sa naučil ich obchádzať.

Čo považujem za ťažšie vyhodnotiteľné, je samotný klasifikátor adaptívneho uvažovania. Rozhodnutie o tom, či smerovať dotaz na text alebo kód, robí LLM pod vplyvom promptingu — práca neuvádza, ako často je toto smerovanie správne, čo sa stane, keď zlyhá (napr. nasmeruje výpočet na text), alebo či by podobný výsledok nedosiahlo jednoduché pravidlo (obsahuje dotaz aritmetické operátory?). Vzhľadom na to, že textové uvažovanie je najväčším prispievateľom v ablácii, mám podozrenie, že väčšina dotazov predvolene končí v textovej ceste a symbolická vetva nesie menší podiel, než naznačuje rámcovanie.

Porovnanie s Chain-of-Table je tiež mierne nafúknuté kontextom. Pôvodné hodnotenie Chain-of-Table využívalo PaLM 2 a GPT-3.5 — číslo 55,60 % pre Chain-of-Table zobrazené pre GPT-4o-mini môže odrážať skôr nedostatočné vyladenie promptov Chain-of-Table pre tento model než skutočnú architektonickú výhodu. To neznehodnocuje výsledok, ale znamená to, že hlavný rozdiel by sa mal čítať ako horná hranica skutočného zlepšenia.

Práca prešla od januára 2025 šiestimi revíziami, čo je nezvyčajné. Rozsah je obmedzený na anglické datasety a tabuľky do niekoľkých stoviek riadkov. Nie je prezentovaná žiadna analýza nákladovej réžie — každý dotaz si teraz vyžaduje viacero volaní LLM (zoradenie stĺpcov, SQL pre riadky, kontrola dostatočnosti, verbalizácia, smerovanie, uvažovanie) a pri cenách špičkových modelov sa to rýchlo sčítava.

Prečo na tom záleží pre finančnú AI

Režimy zlyhania, ktoré TableMaster rieši, sú presne tie, s ktorými očakávam, že sa stretnú agenti pre hlavnú knihu Beancount. Účtovná kniha s trojročnou históriou transakcií na 40 účtoch je veľká, sémanticky bohatá tabuľka — otázka „aký bol môj čistý príjem z práce na voľnej nohe v 3. štvrťroku 2023?“ vyžaduje nájdenie správnych účtov (vyhľadávanie stĺpcov), filtrovanie podľa dátumu (vyhľadávanie riadkov), pochopenie, že „práca na voľnej nohe“ sa mapuje na niekoľko názvov účtov (sémantické obohatenie) a presné sčítanie súm (symbolická aritmetika). Pipeline TableMaster, aplikovaná na rozhranie beanquery, by útočila presne na tieto kroky.

Obmedzenie, ktoré pri účtovných knihách zaváži najviac, je mierka. Tabuľky WikiTQ majú maximálne niekoľko desiatok riadkov a pár stĺpcov; skutočná viacročná kniha Beancount má tisíce záznamov. Práca ukazuje, že výkon degraduje monotónne s veľkosťou tabuľky a netestuje nad rámec niekoľkých stoviek riadkov. Extrakcia tabuľky záujmu má tento problém riešiť, ale SQL filter riadkov je sám o sebe dotazom generovaným LLM nad celou tabuľkou — čo ťažký problém skôr presúva, než rieši. Prirodzeným ďalším krokom je súčinnosť s hierarchickou pamäťou v štýle MemGPT alebo s vopred indexovanou vrstvou beanquery.

Textovo vedená symbolická cesta je priamo aplikovateľná na Beancount. Sumy v hlavnej knihe sú často obklopené metadátami (kódy mien, anotácie šarží, značky nákladovej bázy), ktoré by spôsobili zlyhanie naivného Python parsera pre desatinné čísla. Uzemnenie generovania kódu v popise v prirodzenom jazyku o tom, čo má kód vypočítať, je rozumným zmiernením, hoci potrebuje systematické vyhodnotenie na reálnych exportných formátoch Beancount.

Čo si prečítať ďalej

• H-STAR: LLM-driven Hybrid SQL-Text Adaptive Reasoning on Tables (arXiv:2407.05952) — najpriamejší predchodca adaptívneho smerovania TableMaster s dvojstupňovou stratégiou extrakcie (najprv stĺpce, potom riadky); stojí za priame porovnanie architektúr, aby sme pochopili, čo TableMaster pridáva.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — zatiaľ čo TableMaster sa zameriava na QA, reprezentácia tabuľky a pipeline normalizácie sú rovnako relevantné pre detekciu anomálií; bodovanie založené na pravdepodobnosti v AnoLLM vyžaduje podobnú fázu predbežného spracovania.
• CFMS: A Coarse-to-Fine Multimodal Synthesis Framework for Enhanced Tabular Reasoning (arXiv:2604.10973) — zdá sa, že rozširuje myšlienku extrakcie od hrubej po jemnú na multimodálne tabuľky; relevantné, ak je potrebné zosúladiť vizualizácie knihy Beancount (grafy, PDF výpisy) so štruktúrovanými textovými záznamami.