Могат ли LLM да разсъждават върху таблични данни? Какво ни казват четири бенчмарка за финансовия ИИ

Таблиците са начинът, по който мислят счетоводителите. Главната книга на Beancount е по същество таблица — сметките като редове, датите и сумите като колони, потвържденията (assertions) като ограничения между клетките. Така че, когато започнах да се питам дали LLM могат да захранват автономни финансови агенти, продължавах да се сблъсквам с един и същ предварителен въпрос: могат ли те изобщо да четат надеждно таблица? Литературата по този въпрос е по-обезкуражаваща, отколкото очаквах.

Статията

Фанг и др. публикуваха „Големи езикови модели (LLM) върху таблични данни: Предсказване, генериране и разбиране — Обзор“ в TMLR 2024 (arXiv:2402.17944). Това е таксономия от 41 страници, обхващаща три области: предсказване на структурирани резултати от таблични характеристики, генериране на синтетични таблични данни и разбиране на таблици достатъчно добре, за да се отговаря на въпроси за тях. Направлението за разбиране — отговаряне на въпроси върху таблици (TableQA), проверка на факти и структурни разсъждения — е мястото, където се намира най-подходящата работа за финансовия ИИ.

Статията, която прочетох заедно с нея, „Таблицата среща LLM: Могат ли големите езикови модели да разбират структурирани таблични данни?“ от Суи и др. (WSDM 2024, arXiv:2305.13062), прилага по-контролиран подход: те дефинират бенчмарк за възможност за структурно разбиране (SUC) със седем тесни задачи — разделяне на таблица, откриване на размер, откриване на слети клетки, търсене в клетка, обратно търсене, извличане на колона и извличане на ред — и тестват директно GPT-3.5 и GPT-4. Без вериги от разсъждения, без трикове за извличане. Просто: може ли моделът да направи това, което искаме?

Ключови идеи

• Пропастта във формата е реална и изненадващо голяма. В бенчмарка 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 кадър (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, което размива анализа. Най-приложимият раздел за моите цели е направлението за структурирани въпроси и отговори, и дори там обзорът предимно каталогизира методи, вместо да синтезира кои от тях са действително надеждни.

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

Защо това е важно за финансовия ИИ

Книгите на Beancount са таблици. Когато автономен агент чете главна книга, за да открие аномалии, да генерира отчети или да вземе решение за записване обратно (write-back), той извършва таблично разсъждение. Доказателствата сочат, че настоящите LLM се справят сравнително добре с прости търсения (извличане на клетки при 73% за GPT-4), но се сриват при операциите, които са най-важни: многостепенна агрегация, оценка на размера за големи книги и разсъждения върху структурни вариации.

Констатацията за сериализацията има преки практически последици. Ако подавам файлове на Beancount към LLM, избраният от мен формат влияе върху точността с няколко процентни пункта, преди още да съм написал и един ред логика на агента. Нативният синтаксис на Beancount е близо до края „NL+Sep“ на йерархията на форматите — четим за хора, субоптимален за LLM. Преобразуването в по-структурирано междинно представяне (JSON или HTML таблица с транзакции), преди подаването към модел, може да си заслужава разходите за предварителна обработка.

Сривът на сложността при мащабиране е най-изтрезвяващата констатация. Реална книга на 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 е устойчив на пренареждане, това е сигнал, че той разбира структурата, а не позицията.