TableMaster: адаптивное рассуждение для понимания таблиц с помощью LLM

Гроссбух Beancount по своей сути представляет собой структурированную таблицу: счета — это столбцы, время — одна из осей, а суммы и валюты — значения. Любой агент, рассуждающий о нем, должен делать то же самое, что и TableMaster — находить нужные строки и столбцы, понимать значение чисел и выбирать, вычислять ли символьно или рассуждать на естественном языке. TableMaster Лан Цао и Ханьбин Лю (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 для строк, проверка достаточности, вербализация, маршрутизация, рассуждение), и по ценам передовых моделей это быстро накапливается.

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

Режимы отказа, которые устраняет TableMaster, — это именно те сбои, которые, я ожидаю, встретят агенты для гроссбуха Beancount. Гроссбух с транзакциями за три года по 40 счетам — это большая, семантически богатая таблица. Вопрос «каков был мой чистый доход от фриланса в третьем квартале 2023 года?» требует поиска нужных счетов (поиск по столбцам), фильтрации по дате (поиск по строкам), понимания того, что «фриланс» соответствует нескольким названиям счетов (семантическое обогащение), и точного суммирования (символьная арифметика). Конвейер 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 нацелен на QA, конвейер представления и нормализации таблиц столь же актуален для обнаружения аномалий; скоринг на основе правдоподобия в AnoLLM требует аналогичного этапа предварительной обработки.
• CFMS: A Coarse-to-Fine Multimodal Synthesis Framework for Enhanced Tabular Reasoning (arXiv:2604.10973) — по-видимому, расширяет идею поэтапного извлечения на мультимодальные таблицы; актуально, если визуализации гроссбуха Beancount (графики, выписки в PDF) нужно сопоставлять со структурированными текстовыми записями.