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

Логи MAC-SQL на прошлой неделе заставили меня задуматься о самом слабом звене в агентах на базе таблиц: способности базовой модели понимать структуру и семантику таблицы еще до того, как она сгенерирует запрос. TableLlama (NAACL 2024) атакует именно этот уровень напрямую — не путем улучшения интерфейса запросов, а путем создания универсальной open-source модели, которая может справляться с широким спектром задач по таблицам без специфического проектирования под каждую задачу. Я изучаю эту работу сейчас, потому что это самый прямой ответ на вопрос: может ли открытая модель 7B на самом деле соответствовать GPT-4 в задачах понимания таблиц, с которыми столкнется агент Beancount.

Статья

TableLlama, разработанная Тяньшу Чжаном, Сян Юэ, Ифэй Ли и Хуань Сунь из Университета штата Огайо, дообучает Llama 2 (7B) на новом наборе данных для инструктивного тюнинга TableInstruct — 2,6 миллиона примеров, охватывающих 11 задач с таблицами. Чтобы справиться с длинным контекстом, который накладывают таблицы, авторы используют LongLoRA — метод эффективного расширения параметров, который увеличивает окно контекста до 8 000 токенов без полной переподготовки. Оценка охватывает восемь задач внутри выборки (аннотирование типов столбцов, извлечение отношений, связывание сущностей, дополнение схемы, заполнение строк, QA по иерархическим таблицам, 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 пункта — самый практически значимый показатель для любого, кто строит интерфейсы преобразования естественного языка в запросы (NL-to-query).
• LongLoRA здесь играет критическую роль. Финансовые таблицы длинные. Без расширенного окна контекста весь этот класс задач был бы недосягаем для модели 7B.
• Авторы признают, что вычислительные ограничения ограничили их размером 7B, оставив варианты 13B и 70B без оценки.

Что подтверждается, а что нет

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

WikiTQ — это правильный стресс-тест, потому что он требует ответов на вопросы вроде «Какая страна выиграла больше всего медалей в соревнованиях, где предыдущий рекорд был установлен до 1990 года?» — настоящее композиционное рассуждение по ячейкам таблицы. Дефицит в 33 пункта у TableLlama по сравнению с GPT-4 на WikiTQ — это четкий сигнал о том, что инструктивный тюнинг на структурных задачах не переносится автоматически на реляционное рассуждение.

Победы в дополнении схемы и связывании сущностей реальны и значимы — эти задачи действительно требуют понимания структуры таблицы способами, с которыми zero-shot промпт GPT-4 справляется с трудом. Но они также ближе к поиску (retrieval), чем к рассуждению, что ограничивает обобщаемость этих результатов.

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

Почему это важно для финансового ИИ

Регистры Beancount — это структурированные таблицы: каждая запись имеет дату, счет, сумму и опциональные метаданные. Задачи с таблицами в этой статье напрямую проецируются на операции, которые должен выполнять агент Beancount. Аннотирование типов столбцов соответствует пониманию того, какие счета к какому типу относятся (Активы, Обязательства, Расходы). Связывание сущностей соответствует разрешению имен получателей (payees) в противоречивых описаниях транзакций. А разрыв в WikiSQL точно соответствует проблеме интерфейса естественного языка для beanquery.

Результаты здесь дают мне выверенное представление: дообученная модель 7B может надежно распознавать структуру регистра, чтобы быть полезной, но ей пока нельзя доверять перевод вопросов в свободной форме в корректные выражения beanquery без участия более мощной модели в цикле. Точность WikiSQL 50% (против 93% SOTA) означает, что интерфейс beanquery только на открытой модели будет генерировать неверные запросы примерно в половине случаев при незнакомых формулировках вопросов. Для агента с правом записи (write-back) такой процент ошибок слишком высок. Для интерфейса запросов только для чтения с проверкой человеком это может быть приемлемо в качестве первого черновика.

Вклад LongLoRA применим напрямую: многолетние журналы Beancount могут легко превышать 8 000 токенов, и описанный здесь подход показывает, как дообучать модели для длинных таблиц без непомерных вычислительных затрат.

Что почитать дальше

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) — последующая работа группы OSU, в которой тестируются более 30 LLM на более сложных задачах QA по таблицам; установлено, что разрыв между открытыми моделями и 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 обобщается, и какие решения по составу данных имеют наибольшее значение.