Chain-of-Table: Еволюиращи таблици във веригата от разсъждения на LLM

Често се връщам към едно и също неудобно наблюдение относно табличните разсъждения: когато големите езикови модели (LLM) обясняват работата си върху таблици чрез обикновена верига от мисли (chain-of-thought) в текстов формат, те описват едно представяне, докато разсъждават върху друго. Chain-of-Table, научна публикация на Google Research, представена на ICLR 2024, приема това противоречие сериозно и предлага просто решение — нека самата таблица носи междинното състояние на разсъжденията, а не текстът.

Статията

Wang и др. представят Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding (arXiv:2401.04398, ICLR 2024). Статията разглежда пропуските при стандартното подтикване чрез верига от мисли (CoT), приложено към таблични данни: CoT разсъждава на естествен език, но таблиците са структурирани артефакти, а езиковото описание на трансформациите на таблиците е едновременно многословно и води до загуба на информация. Основната идея е да се позволи на LLM да планира последователност от програмни операции върху таблицата — филтриране, групиране, сортиране, избор на колона, добавяне на колона — като се изпълнява всяка от тях, за да се създаде междинно състояние на таблицата, което след това се подава обратно на модела като вход за следващата стъпка. Крайният отговор се генерира от финалното състояние на таблицата, а не от дълга текстова верига. Авторите правят изрична аналогия с разработката на SQL: опитният анализатор пише междинни стъпки CREATE TABLE ... AS SELECT, а не една монолитна заявка. Chain-of-Table формализира тази практика за LLM агенти.

Оценката обхваща три бенчмарка: WikiTableQuestions (WikiTQ), TabFact и FeTaQA. Основният използван модел е PaLM 2, с кръстосана проверка върху GPT-3.5 и LLaMA 2 70B.

Ключови идеи

• Chain-of-Table постига точност на денотацията от 67,31% при WikiTQ срещу 61,48% за Dater, най-силният предходен базов модел — подобрение от +5,83 процентни пункта.
• При таблици, надвишаващи 4000 токена, предимството нараства до +10,25 пункта (44,87% срещу 34,62%), което е моментът, в който методът е най-важен на практика.
• Точността при TabFact достига 86,61% срещу 84,63% за Dater; BLEU показателят при FeTaQA се подобрява от 29,47 на 32,61.
• Петте атомарни операции — f_select_row, f_select_column, f_group_by, f_sort_by, f_add_column — обхващат по-голямата част от моделите на разсъждение, наблюдавани в тези бенчмаркове; f_group_by върши най-много работа при WikiTQ, където броенето е доминиращият режим на отказ.
• Chain-of-Table изисква най-много 25 генерирани проби на въпрос срещу 50 за Binder и 100 за Dater — печалба в ефективността от 50–75% заедно с по-добра точност, което е наистина необичайно в изследванията на LLM, където компромисът почти винаги е в обратната посока.
• Подходът е независим от модела: той последователно превъзхожда текстовите CoT базисни модели при PaLM 2, GPT-3.5 и LLaMA 2.

Какво издържа проверката на времето и какво не

Централният емпиричен принос на статията е солиден. Бенчмарковете са стандартни, базовите линии са честни, а историята с ефективността е убедителна. Превръщането на самата таблица в експлицитно междинно представяне, вместо описването ѝ в проза, е чиста идея с интуитивна мотивация, а резултатите върху големи таблици са най-убедителното доказателство: когато таблицата едва се побира в контекста, прогресивното ѝ съкращаване чрез операции до това, което е важно, е ясно по-добро от генерирането на още повече текст.

Въпреки това, съществуват реални пропуски. Анализът на разпространението на грешки е повърхностен. Ако LLM генерира грешен аргумент за f_select_row на втората стъпка от верига от пет стъпки, всяка следваща операция се изпълнява върху повредена междинна таблица и крайният отговор е безполезен. Докладът отчита общата точност, но не анализира колко често разсъжденията се провалят поради грешки в ранните стъпки спрямо грешки в късните стъпки, или дали подходът е устойчив на частично грешни операции. За метод, който зависи от последователност от правилни извиквания, това е съществен пропуск.

Наборът от операции също е залог. Пет операции покриват повечето модели в WikiTQ и TabFact, тъй като тези бенчмаркове са проектирани около задачи с релационни таблици. Реалните финансови таблици — баланси, оборотни ведомости, данъчни планове — рутинно изискват обединения (joins) на свързани таблици, изчислени агрегати с условия (SUM на дебити, КЪДЕТО сметката ЗАПОЧВА С '6') и пивотни трансформации. Нито една от тях не е в набора от операции. Авторите косвено признават това, но не го тестват.

И накрая, липсва теоретично обяснение защо междинните състояния на таблицата трябва да са по-добри от междинния текст. Интуицията е привлекателна, но статията е чисто емпирична. Последващите трудове (TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025) бързо преминаха към адаптивни хибридни подходи, които смесват SQL и текстови разсъждения, което подсказва, че общността е забелязала същия пропуск като мен: чистите таблични операции не са универсално по-добри, а само по-добри в тестваните бенчмаркове.

Защо това е важно за финансовия изкуствен интелект

За Beancount агентите за счетоводни книги архитектурата на Chain-of-Table съвпада почти идеално с това, което искам от конвейер за записване (write-back). Заявка в Beancount като „какви са нетните ми разходи по категории за първото тримесечие, изключвайки трансакции с таг :ignore?“ изисква точно този вид последователни трансформации на таблици, които се предлагат в статията: филтриране на редове по дата, филтриране по таг, групиране по категория на сметката, сумиране на суми. Ако агентът може да планира това като верига от експлицитни междинни операции, вместо да генерира една единствена заявка или да разсъждава за нея в проза, одитната пътека е четима и всяка стъпка е независимо проверима.

Подобрението на ефективността при големи таблици също е пряко релевантно. Многогодишна счетоводна книга в Beancount с десетки хиляди трансакции лесно надхвърля 4000 токена при визуализация. Подобрението от 10 пункта в този режим не е артефакт на бенчмарка; то отразява това, което действително се случва, когато таблицата трябва да бъде прогресивно стеснена, преди разсъжденията да станат прецизни.

Липсващата част за Beancount е операцията за обединение (join). Двойното счетоводство свързва трансакциите между сметките и всяка задача по равняване изисква разсъждения върху поне две времеви линии на сметки. Chain-of-Table във вида, в който е публикуван, не може да изрази това. Разширяването на набора от операции, за да включва обединения между сметки, е очевидната следваща инженерна стъпка за производствен агент за разсъждения в Beancount.

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

• Chain-of-Query: Unleashing the Power of LLMs in SQL-Aided Table Understanding via Multi-Agent Collaboration (2025, arXiv:2508.15809) — разширява концепцията за операции към генериране на SQL чрез множество агенти, което адресира липсата на обединения (joins).
• TableMaster: A Recipe to Advance Table Understanding with Language Models (arXiv:2501.19378) — въвежда адаптивно разсъждение, което превключва между таблични операции и текстова верига от мисли (CoT); най-прякото продължение на Chain-of-Table.
• DATER: Decomposition-based Text-to-SQL for LLMs over Long Context (arXiv:2308.01463) — допълващ подход за декомпозиция за сложен SQL върху големи схеми, уместен за дизайна на интерфейси на естествен език за beanquery.