TableLlama: Може ли отворен модел със 7B параметри да се мери с GPT-4 в разбирането на таблици?

Дневникът на MAC-SQL от миналата седмица ме накара да се замисля за най-слабата брънка в агентите, базирани на таблици: способността на базовия модел да разбира структурата и семантиката на таблицата, преди изобщо да генерира заявка. TableLlama (NAACL 2024) атакува директно този слой — не чрез подобряване на интерфейса за заявки, а чрез изграждане на общ модел с отворен код, който може да се справя с широк спектър от задачи с таблици без специфично инженерство за всяка задача. Чета го сега, защото е най-директният отговор на въпроса дали отворен модел със 7B параметри може действително да съперничи на GPT-4 в проблемите с разбирането на таблици, с които би се сблъскал един Beancount агент.

Докладът

TableLlama, разработен от Tianshu Zhang, Xiang Yue, Yifei Li и Huan Sun от Щатския университет в Охайо, прави фина настройка на Llama 2 (7B) върху нов набор от данни за инструкционна настройка, наречен TableInstruct — 2,6 милиона примера, обхващащи 11 задачи с таблици. За да се справят с дългия контекст, който таблиците налагат, те използват LongLoRA — подход за ефективно разширяване на параметрите, който разтяга контекстния прозорец до 8K токена без пълно преобучение. Оценката обхваща осем задачи в рамките на домейна (анотиране на типове колони, извличане на релации, свързване на обекти, разширяване на схемата, попълване на редове, йерархични таблични въпроси и отговори, QA на маркирани клетки и проверка на факти) плюс шест набора от данни извън домейна, върху които моделът никога не е бил обучаван.

Основното твърдение: един фино настроен отворен модел може да съперничи или да победи специфичните за задачите SOTA модели в повечето бенчмаркове в домейна и да превъзходи базовия модел Llama 2 с 5–44 абсолютни точки извън домейна — включително стесняване на разликата с GPT-4 в няколко задачи.

Ключови идеи

• При задачите в домейна TableLlama решително побеждава GPT-4 в задачи за структурно разпознаване: Анотиране на типове колони (F1 94,39 срещу 31,75), Извличане на релации (F1 91,95 срещу 52,95), FeTaQA BLEU (39,05 срещу 21,70) и HiTab точност на изпълнение (64,71 срещу 48,40).
• При наборите от данни извън домейна картината се обръща. GPT-4 води в точността на WikiTQ (68,40 срещу 35,01) и HybridQA (58,60 срещу 39,38) — и двете задачи, които изискват композиционно многостепенно логическо мислене върху таблици, а не структурно разпознаване на образи.
• WikiSQL разкрива рязко разликата в генерирането на заявки: TableLlama постига 50,48% срещу SOTA от 92,70%. Тази разлика от 42 точки е най-практически значимото число за всеки, който изгражда интерфейси от естествен език към заявки.
• LongLoRA е критичен тук. Финансовите таблици са дълги. Без разширения контекстен прозорец, целият този клас задачи би бил недостъпен за 7B модел.
• Авторите признават, че изчислителните ограничения са ги ограничили до размера 7B, оставяйки вариантите 13B и 70B неоценени.

Какво се потвърждава — и какво не

Настройката на бенчмарка смесва различни неща по начин, който заслужава внимание. Сравнението в домейна изправя фино настроен TableLlama срещу zero-shot GPT-4. При задачи, базирани на TURL, като анотиране на типове колони, резултатът на GPT-4 от 31,75 F1 не означава, че GPT-4 фундаментално не може да разбере типовете колони — това означава, че zero-shot подкана без специфична за формата настройка се проваля в набор от данни, който очаква много конкретен изходен формат. Честното сравнение е при задачите извън домейна, където и двата модела не са виждали тренировъчни данни, и там разликата е смиряваща: WikiTQ точност 35,01 срещу 68,40.

WikiTQ е правилният стрес тест, защото изисква въпроси като „Коя държава спечели най-много медали в събития, където предишният рекорд е поставен преди 1990 г.?“ — истинско композиционно мислене между клетките на таблицата. Дефицитът от 33 точки на TableLlama в WikiTQ спрямо GPT-4 е най-ясният сигнал, че инструкционната настройка за структурни задачи не се пренася автоматично към релационно мислене.

Победите в разширяването на схемата и свързването на обекти са реални и значими — тези задачи наистина изискват разбиране на структурата на таблицата по начини, с които zero-shot подканата на GPT-4 се затруднява. Но те също така са по-близо до извличане на информация, отколкото до разсъждение, което ограничава доколко тези резултати могат да бъдат обобщени.

Отделен проблем: наборът от данни TableInstruct с 2,6 милиона примера е значително инженерно усилие, но той обединява много различни типове задачи в един формат на инструкциите. Липсва аблационно изследване, което да покаже кои типове задачи си пречат или кои са ключови за печалбите извън домейна. Последващият бенчмарк на групата от OSU (TableBench, AAAI 2025) установи, че моделите, фино настроени на TableInstruct, постигат производителност, съпоставима с GPT-3.5, но все пак отстъпват на GPT-4 — което значително охлажда оптимизма на оригиналния доклад.

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

Леджърите на Beancount са структурирани таблици: всеки запис има дата, сметка, сума и незадължителни метаданни. Задачите с таблици в този доклад съответстват директно на операциите, които един Beancount агент трябва да изпълнява. Анотирането на типове колони съответства на разбирането кои сметки към кой тип принадлежат (Активи, Пасиви, Разходи). Свързването на обекти съответства на разрешаването на имена на получатели в непоследователни описания на транзакции. А разликата в WikiSQL съответства точно на проблема с интерфейса на естествен език за beanquery.

Резултатите тук ми дават калибриран поглед: фино настроен 7B модел може да се справи с разпознаването на структурата на леджъра достатъчно надеждно, за да бъде полезен, но все още не може да му се вярва за превод на въпроси в свободна форма в правилни beanquery изрази без модел с по-високи способности във веригата. 50% точност в WikiSQL (срещу 93% SOTA) означава, че интерфейс на beanquery само с отворен модел би генерирал грешни заявки в около половината от случаите при непознати формулировки на въпроси. За агент с права за запис този процент на отказ е твърде висок. За интерфейс за заявки само за четене с човешки преглед, това може да бъде приемливо като първа чернова.

Приносът на LongLoRA е директно приложим: многогодишните Beancount леджъри лесно могат да надхвърлят 8K токена, а подходът тук показва как да се прави фина настройка за дълги таблици без прекомерни изчислителни разходи.

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

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) — последващото проучване на групата от OSU, което тества над 30 LLM върху по-сложни таблични въпроси и отговори и установява, че разликата между отворените модели и GPT-4 продължава да съществува дори след фина настройка с TableInstruct.
• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — предварително обучение върху синтетично изпълнение на SQL като контраст на инструкционната настройка; важна базова линия за дебата „предварително обучение срещу фина настройка“ в разбирането на таблици.
• Rethinking Table Instruction Tuning (arXiv:2501.14693) — скорошна работа, подлагаща на съмнение дали стандартната рецепта на TableInstruct действително се обобщава и кои избори в композицията на данните са най-важни.