Chain-of-Table: Эволюция таблиц в цепочке рассуждений LLM

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

Статья

Ванг и соавт. представляют Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding (arXiv:2401.04398, ICLR 2024). Статья устраняет пробел, оставляемый стандартным CoT-промптингом при работе с табличными данными: CoT рассуждает на естественном языке, но таблицы — это структурированные артефакты, а языковое описание преобразований таблиц является одновременно многословным и чреватым потерями данных. Основная идея заключается в том, чтобы позволить LLM планировать последовательность программных операций над таблицей — фильтрацию, группировку, сортировку, выбор столбца, добавление столбца — выполняя каждую из них для создания промежуточного состояния таблицы и возвращая эту обновленную таблицу в 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 достигает точности обозначения (denotation accuracy) 67,31% на WikiTQ по сравнению с 61,48% у Dater, сильнейшей предыдущей базовой модели — улучшение на +5,83 процентных пункта.
• На таблицах, превышающих 4 000 токенов, преимущество возрастает до +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 дебетов WHERE счет STARTS WITH '6') и поворотных преобразований (pivot). Ничего из этого нет в наборе операций. Авторы признают это косвенно, но не тестируют.

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

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

Для агентов книг Beancount архитектура Chain-of-Table почти идеально ложится на то, что я хочу видеть в конвейере записи. Запрос Beancount, такой как «каковы мои чистые расходы по категориям за первый квартал, исключая транзакции с тегом :ignore?», требует именно тех последовательных преобразований таблиц, которые предлагает статья: фильтрация строк по дате, фильтрация по тегу, группировка по категории счета, суммирование сумм. Если агент сможет спланировать это как цепочку явных промежуточных операций вместо генерации одного запроса или рассуждений о нем в тексте, аудиторский след будет читаемым, а каждый шаг — независимо проверяемым.

Улучшение эффективности работы с большими таблицами также имеет прямое отношение к делу. Многолетняя книга Beancount с десятками тысяч транзакций легко превышает 4 000 токенов при материализации. Улучшение на 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, что решает проблему отсутствия соединений.
• 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 на естественном языке.