Чи можуть LLM аналізувати табличні дані? Що чотири бенчмарки кажуть про ШІ у фінансах

Таблиці — це те, як мислять бухгалтери. Ledger 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 напряму. Жодних ланцюжків міркувань (reasoning chains) чи прийомів із пошуком (retrieval tricks). Просто: чи може модель зробити те, що ми просимо?

Основні ідеї

• Розрив у форматах реальний і напрочуд великий. У бенчмарку 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) до генеративного синтезу таблиць і відповідей на питання, що розмиває аналіз. Найбільш корисним розділом для моїх цілей є трек структурованих відповідей на питання, і навіть там огляд здебільшого каталогізує методи, а не синтезує, які з них справді надійні.

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

Чому це важливо для фінансового ШІ

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

Висновок щодо серіалізації має безпосередні практичні наслідки. Якщо я передаю файли Beancount в LLM, обраний формат впливає на точність на кілька відсоткових пунктів ще до того, як я напишу хоч один рядок логіки агента. Власний синтаксис Beancount близький до кінця ієрархії форматів «NL+Sep» — зручний для людей, але субоптимальний для LLM. Конвертація в більш структурований проміжний формат (JSON або HTML таблицю транзакцій) перед подачею в модель може бути вартою витрат на попередню обробку.

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

Що почитати далі

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