TableMaster: Адаптивно разсъждение за разбиране на таблици с LLMs

Леджърът на Beancount в своята същност е структурирана таблица: сметките са колони, времето е едната ос, а сумите и валутите са стойности. Всеки агент, който разсъждава върху него, трябва да прави това, което прави TableMaster — да намира правилните редове и колони, да разбира какво означават числата и да избира дали да пресмята символно или да разсъждава чрез език. TableMaster на Lang Cao и Hanbing Liu (arXiv:2501.19378) е най-способният конвейер за разбиране на таблици, който съм виждал до момента без фина настройка, и исках да разбера дали той наистина напредва в състоянието на технологията по принципен начин или просто трупа евристики за промптване, докато бенчмаркът се премести.

Статията

TableMaster е рамка, базирана на промптове, която адресира четири специфични режима на отказ, които LLM показват при отговори на въпроси върху таблици: те се затрудняват да локализират съответната клетка в голяма таблица, пропускат семантичния контекст, кодиран в заглавията на колоните, халюцинират аритметика, когато разсъждават в чист текст, и се провалят, когато символното разсъждение (SQL, Python) се сблъска с шумни данни или смесени типове. Авторите отговарят на всеки неуспех със специализиран модул, сглобен в тристепенен конвейер. Първият етап изгражда "фокусна таблица" (table-of-focus) — съкратена подтаблица, съдържаща само редовете и колоните, съответстващи на заявката — използвайки търсене на колони, класирано от LLM, и филтриране на редове чрез SQL. Вторият етап вербализира тази подтаблица на естествен език и проверява дали извлеченият отрязък е действително достатъчен за отговор на въпроса, като итеративно го разширява, ако не е. Третият етап прилага адаптивно разсъждение: LLM решава за всяка заявка дали да изпълни верига от мисли (chain-of-thought) върху вербализираното описание или да генерира и изпълни Python или SQL, като символният път се ръководи от описанието на естествен език, за да се справя със случаи, в които стойностите в таблицата са разхвърляни низове, а не чисти числа.

Не е трениран нов модел. Всичко работи върху LLM с общо предназначение (GPT-3.5-turbo, GPT-4o-mini, Llama-3.1-70B) чрез промптване.

Ключови идеи

• На WikiTQ с GPT-4o-mini, TableMaster достига 78,13%, в сравнение с 55,60% за Chain-of-Table и 64,73% за PoTable на същия модел — подобрение от 13,40 пункта спрямо следващия най-добър базов модел.
• Същият модел се наблюдава и при GPT-3.5-turbo (68,21% срещу предишен най-добър резултат ~58%) и Llama-3.1-70B (77,95%), което показва, че ползите не са специфични за даден модел.
• На TabFact (проверка на факти), TableMaster достига 90,12% с GPT-4o-mini срещу 84,24% за Chain-of-Table — по-малко, но постоянно подобрение.
• Аблацията разкрива, че премахването на текстовото разсъждение вреди най-много (–4,28%), последвано от премахването на извличането на структура (–3,38%). Адаптивното превключване между режимите е истински съществен елемент.
• Размерът на таблицата е доминиращият предсказател за неуспех: производителността се влошава монотонно с увеличаване на броя на редовете, колоните и токените, независимо от модела.
• Символното разсъждение се влошава с 31,8% при шумни таблици срещу 20,5% за текстовото разсъждение — символният път, воден от текст, съществува именно за да омекоти този режим на отказ.
• Само текстовото разсъждение се влошава с 20,1% при заявки с много изчисления срещу 72,4% при задачи без изчисления — илюстрирайки точно защо хибридното превключване е важно.

Какво е устойчиво — и какво не

Диагнозата на четирите предизвикателства е добре обоснована и съвпада точно с реалните случаи на отказ. Аблацията е честна: премахването на който и да е компонент вреди, като мащабът е пропорционален на това колко действително е бил използван този компонент. Това е по-силно от обичайната аблация, при която премахването на компоненти не променя нищо, защото моделът се е научил да ги заобикаля.

Това, което ми е по-трудно да оценя, е самият класификатор за адаптивно разсъждение. Решението дали да се насочи заявка към текст или код се взема от LLM под влияние на промптове — статията не съобщава колко често това насочване е правилно, какво се случва, когато то сгреши (напр. насочи изчисление към текст) или дали едно просто правило (съдържа ли заявката аритметични оператори?) би работило сравнимо добре. Като се има предвид, че текстовото разсъждение е най-големият фактор в аблацията, подозирам, че повечето заявки по подразбиране поемат по текстовия път, а символният клон носи по-малка част, отколкото рамкирането предполага.

Сравнението с Chain-of-Table също е леко раздуто от контекста. Оригиналната оценка на Chain-of-Table използва PaLM 2 и GPT-3.5 — числото от 55,60% за Chain-of-Table, показано за GPT-4o-mini, може да отразява недостатъчно прецизиране на промптовете на Chain-of-Table за този модел, а не реално архитектурно предимство. Това не обезсилва резултата, но означава, че заглавната разлика трябва да се чете като горна граница на истинското подобрение.

Статията е преминала през шест ревизии от януари 2025 г., което е необичайно. Обхватът е ограничен до английски набори от данни и таблици до няколкостотин реда. Не е представен анализ на разходите — всяка заявка сега изисква множество извиквания на LLM (класиране на колони, SQL за редове, проверка за достатъчност, вербализация, насочване, разсъждение), а при цените на водещите модели това се натрупва бързо.

Защо това е важно за финансовия AI

Режимите на отказ, които TableMaster адресира, са точно тези, които очаквам да срещнат агентите за Beancount леджъри. Леджър с три години транзакции в 40 сметки е голяма, семантично богата таблица — "какъв беше нетният ми доход от работа на свободна практика през третото тримесечие на 2023 г.?" изисква намиране на правилните сметки (търсене в колони), филтриране по дата (търсене в редове), разбиране, че "freelance" съответства на няколко имена на сметки (семантично обогатяване) и точно сумиране на суми (символна аритметика). Конвейерът на TableMaster, приложен към интерфейс за beanquery, би атакувал точно тези стъпки.

Ограничението, което е най-важно за леджърите, е мащабът. Таблиците в WikiTQ имат най-много няколко десетки реда и шепа колони; един реален многогодишен леджър на Beancount има хиляди записи. Статията показва, че производителността се влошава монотонно с размера на таблицата и не тества над няколкостотин реда. Извличането на фокусна таблица е предназначено да реши това, но SQL филтърът за редове сам по себе си е генерирана от LLM заявка върху цялата таблица — премествайки трудния проблем, вместо да го решава. Взаимодействието с йерархична памет в стил MemGPT или с предварително индексиран слой beanquery е естествената следваща стъпка.

Воденият от текст символен път е директно приложим към Beancount. Сумите в леджъра често са заобиколени от метаданни (кодове на валути, анотации на партиди, маркери за себестойност), които биха накарали един наивен Python парсър за числа с плаваща запетая да се провали. Базирането на генерирането на код върху описание на естествен език за това какво трябва да изчисли кодът е разумно смекчаване на проблема, въпреки че се нуждае от систематична оценка върху реални формати за експорт от Beancount.

Какво да прочетете след това

• H-STAR: LLM-driven Hybrid SQL-Text Adaptive Reasoning on Tables (arXiv:2407.05952) — най-предишният предшественик на адаптивното насочване на TableMaster, със стратегия за извличане в два етапа (първо колони, после редове); заслужава си да се сравнят архитектурите директно, за да се разбере какво добавя TableMaster.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — докато TableMaster се фокусира върху въпроси и отговори, конвейерът за представяне и нормализиране на таблици е еднакво подходящ за откриване на аномалии; скорингът на AnoLLM, базиран на вероятности, се нуждае от подобен етап на предварителна обработка.
• CFMS: A Coarse-to-Fine Multimodal Synthesis Framework for Enhanced Tabular Reasoning (arXiv:2604.10973) — изглежда разширява идеята за извличане от общо към детайлно към мултимодални таблици; подходящо, ако визуализациите на леджъра на Beancount (графики, PDF извлечения) трябва да бъдат съпоставени със структурирани текстови записи.