Таблиците са начинът, по който мислят счетоводителите. Един Beancount журнал по същество е таблица — сметките като редове, датите и сумите като колони, а проверките като ограничения между клетки. Затова, когато започнах да питам дали LLM могат да захранват автономни финансови агенти, непрекъснато се натъквах на същия предварителен въпрос: могат ли те изобщо надеждно да четат таблица? Литературата по този въпрос е по-осъдителна, отколкото очаквах.
Документът
Fang и др. публикуваха „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?“ от Sui и др. (WSDM 2024, arXiv:2305.13062), подхожда по-контролирано: те дефинират бенчмарк за структурни способности за разбиране (Structural Understanding Capability, 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-shot примерите от подсказките на SUC доведе до спад от 30,38% в общата точност във всички задачи. Структурното разбиране на модела е силно подкрепено от демонстрация, а не истински интернализирано.
- Разликата човек-LLM при реален TableQA е огромна. 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 се влошава до почти случайно. Дори моделите с 200K контекстен прозорец се затрудняват с масивни набори от данни поради квадратичната цена на самовниманието върху дълги последователности.
Какво издържа — и какво не
Бенчмаркът на Sui и др. е внимателно проектиран и числата са достоверни. Откритието, че HTML превъзхожда markdown при структурни задачи, е контраинтуитивно — markdown е по-компактен и LLM виждат повече от него в обучението — но съответства на очакваното: изричното тагиране в HTML дава на модела повече котви, за да се ориентира в структурата, без да се налага да я извежда.
От което се съмнявам: техниката за самообогатяване (двуетапно подсказване, при което първата подсказка иска от модела да идентифицира критични стойности, преди да отговори) дава подобрения от 0,84–5,68% на downstream бенчмаркове като TabFact и ToTTo. Това са реални числа от реални експерименти, но са маргинални. Техниката не адресира основния проблем — тя е кръпка за инженеринг на подсказки върху истински слабо структурно разбиране.
Изследването в TMLR има проблема с обхвата, общ за всички изследвания: то покрива всичко — от таблично предсказване (светът на XGBoost) до генериране на синтетични таблици и QA, което разрежда анализа. Най-приложимият раздел за моите цели е направлението за структуриран QA, и дори там изследването основно каталогизира методи, вместо да синтезира кои от тях са наистина надеждни.
Откритието на FinSheet-Bench, че сложните агрегации постигат 19,6%, е най-специфичният за финансите алармен сигнал тук. Агрегацията на портфейли, сумирането на ниво фонд и многопериодните сравнения са точно операциите, които правят финансовото отчитане нетривиално — и точно там LLM се разпадат.
Защо това е важно за финансовия ИИ
Beancount журналите са таблици. Когато автономен агент чете журнал, за да открие аномалии, генерира отчети или реши за обратно записване, той извършва таблично разсъждение. Доказателствата сочат, че текущите 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 агентът е устойчив на пренареждане, това е сигнал, че разбира структурата, а не позицията.
