Могут ли LLM рассуждать над табличными данными? Чему нас учат четыре бенчмарка для финансового ИИ

Бухгалтеры мыслят таблицами. Журнал Beancount — это, по сути, таблица: счета — это строки, даты и суммы — столбцы, а проверки (assertions) — ограничения для ячеек. Поэтому, когда я начал задаваться вопросом, могут ли LLM стать основой для автономных финансовых агентов, я постоянно сталкивался с одним и тем же предварительным вопросом: способны ли они вообще надежно читать таблицы? Литература по этой теме оказалась более удручающей, чем я ожидал.

Исследование

Фанг и др. опубликовали работу «Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey» в TMLR 2024 (arXiv:2402.17944). Это 41-страничная таксономия, охватывающая три области: прогнозирование структурированных результатов на основе табличных признаков, генерация синтетических табличных данных и понимание таблиц, достаточное для ответов на вопросы по ним. Именно направление понимания — ответы на вопросы по таблицам (TableQA), верификация фактов и структурные рассуждения — наиболее актуально для финансового ИИ.

Вторая работа, которую я прочитал параллельно, «Table Meets LLM: Can Large Language Models Understand Structured Table Data?» Суи и др. (WSDM 2024, arXiv:2305.13062), предлагает более контролируемый подход: авторы определяют бенчмарк способности к пониманию структуры (Structural Understanding Capability, SUC) с семью узкими задачами — разделение таблицы, определение размера, обнаружение объединенных ячеек, поиск ячеек, обратный поиск, извлечение столбцов и извлечение строк — и тестируют GPT-3.5 и GPT-4 напрямую. Никаких цепочек рассуждений, никаких трюков с поиском (RAG). Только вопрос: может ли модель сделать то, что мы просим?

Ключевые идеи

• Разрыв в форматах реален и удивительно велик. В бенчмарке SUC HTML-сериализация превосходит формат «естественный язык с разделителями» примерно на 6,76% в целом. Рейтинг HTML > XML > JSON > Markdown > NL+Sep сохраняется во всех задачах. Файлы Beancount ближе к концу этого спектра (естественный язык), что является тревожным сигналом.
• Поиск значения в ячейке дается на удивление трудно. GPT-3.5 достигает лишь 44% точности в прямом поиске ячейки (найти значение в строке X, столбце Y). GPT-4 достигает 73,34% в той же задаче. Для детерминированной операции, с которой формула в электронной таблице справляется за микросекунды, разрыв в 26 процентных пунктов между моделями пугает.
• Few-shot примеры критически важны. Удаление 1-shot примеров из промптов SUC привело к падению общей точности на 30,38% во всех задачах. Структурное понимание модели в значительной степени поддерживается демонстрацией, а не является по-настоящему внутренним знанием.
• Разрыв между человеком и LLM в реальных ответах на вопросы по таблицам огромен. TableBench (arXiv:2408.09174, AAAI 2025) оценивает 886 вопросов, связанных с проверкой фактов, численными рассуждениями, анализом данных и визуализацией. Точность человека составляет 85,91%. GPT-4-Turbo набирает 40,38%, GPT-4o — 42,73%. Лучшие современные модели работают примерно в два раза хуже человека на бенчмарке, отражающем сложность реальных таблиц.
• Коллапс сложности в финансовых таблицах критичен. FinSheet-Bench (arXiv:2603.07316) тестирует LLM на шаблонах фондов частного капитала с различной структурной сложностью. Простые поисковые запросы достигают точности 89,1%. Сложные агрегации падают до 19,6%. Самый большой тестовый файл (152 компании, 8 фондов) дает среднюю точность 48,6% для всех моделей по сравнению с 86,2% на самом простом файле.
• Длинные таблицы категорически ломают модели. Обзор TMLR сообщает, что при превышении 1000 токенов производительность GPT-3 деградирует до почти случайных значений. Даже модели с контекстным окном в 200 тысяч токенов испытывают трудности с массивными наборами данных из-за квадратичной стоимости механизма self-attention на длинных последовательностях.

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

Бенчмарк Суи и др. тщательно разработан, и цифры выглядят правдоподобно. Вывод о том, что HTML превосходит Markdown в структурных задачах, контринтуитивен — Markdown более компактен, и LLM видят его больше при обучении — но он согласуется с логикой: явная разметка HTML дает модели больше «якорей» для навигации по структуре без необходимости её додумывать.

К чему я отношусь скептически: техника самодополнения (двухэтапный промпт, где первый запрос просит модель идентифицировать критические значения перед ответом) дает улучшение на 0,84–5,68% в таких бенчмарках, как TabFact и ToTTo. Это реальные цифры реальных экспериментов, но они маргинальны. Техника не решает фундаментальную проблему — это лишь «заплатка» промпт-инжиниринга поверх по-настоящему слабого структурного понимания.

Обзор TMLR страдает от проблемы масштаба, характерной для всех обзоров: он охватывает всё — от табличного прогнозирования (территория XGBoost) до генеративного синтеза таблиц и QA, что размывает анализ. Наиболее практически полезный раздел для моих целей — это трек структурированных QA, и даже там обзор в основном каталогизирует методы, а не обобщает, какие из них действительно надежны.

Результат FinSheet-Bench, согласно которому сложные агрегации набирают всего 19,6%, — это самый серьезный тревожный звонок для финансового ИИ. Агрегация портфеля, сводные отчеты на уровне фонда и сравнения за несколько периодов — это именно те операции, которые делают финансовую отчетность нетривиальной, и именно на них LLM терпят неудачу.

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

Журналы Beancount — это таблицы. Когда автономный агент читает журнал для обнаружения аномалий, создания отчетов или принятия решения об обратной записи, он выполняет табличные рассуждения. Данные свидетельствуют о том, что современные LLM справляются с простым поиском приемлемо (извлечение ячейки на 73% у GPT-4), но терпят крах на операциях, которые важны больше всего: многоэтапной агрегации, оценке размера больших журналов и рассуждениях над структурными вариациями.

Вывод о сериализации имеет немедленные практические последствия. Если я передаю файлы Beancount в LLM, выбранный формат влияет на точность на несколько процентных пунктов еще до того, как будет написана первая строка логики агента. Нативный синтаксис Beancount близок к концу иерархии форматов «естественный язык + разделители» — он удобен для человека, но субоптимален для LLM. Преобразование в более структурированный промежуточный формат (таблицу транзакций JSON или HTML) перед подачей в модель может стоить затрат на предварительную обработку.

Коллапс сложности при масштабировании — самый отрезвляющий вывод. Реальный журнал Beancount для малого бизнеса может содержать тысячи транзакций, десятки счетов и многолетнюю историю. Результаты FinSheet-Bench показывают, что как только таблица вырастает до размера, когда она действительно начинает иметь значение, точность LLM падает до уровня, небезопасного для автономной обратной записи данных.

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

• TableLLM (arXiv:2311.09206) — дообученная модель, натренированная на 169 таблицах Kaggle (UniPredict); сообщается, что она существенно превосходит GPT-4 в zero-shot режиме при табличном прогнозировании, что указывает на то, что специализированная донастройка (fine-tuning) по-прежнему остается правильным подходом для специфических финансовых табличных задач.
• TAT-QA (arXiv:2105.07624) — набор данных специально для дискретных рассуждений над гибридными финансовыми документами (таблицы + текст, например, отчеты о доходах); сопутствующая модель TAT-LLM является наиболее прямым прецедентом применения специализированных моделей к рассуждениям над финансовыми таблицами.
• ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412) — фокусируется на состязательных искажениях, таких как перемешивание строк и изменение порядка столбцов; если агент Beancount устойчив к изменению порядка, это сигнал того, что он понимает структуру, а не просто позицию данных.