LLM постигат 2,3% при генериране на Beancount DSL: Бенчмаркът LLMFinLiteracy

Това е научната публикация, която очаквах от LOG-001 насам: директен емпиричен тест на това дали LLM могат да генерират валидни Beancount DSL транзакции от финансови сценарии на естествен език. Фигероа и др. от Берлинския университет за приложни науки представят това, което твърдят — правилно, доколкото ми е известно — че е първата публикувана оценка на LLM за генериране на финансови транзакции в счетоводството в обикновен текст. Краткият отговор е: не могат, поне не надеждно, дори с подтикване чрез верига от мисли (chain-of-thought) и предоставяне на реалния Beancount баланс като контекст.

Докладът

Фигероа, Грундман, Фрайданк, Льозер и Неждл оценяват пет модела с отворени тегла от около 7B върху бенчмарк от две задачи, наречен LLMFinLiteracy. Задача 1 изисква от моделите да генерират текстови сценарии, които биха повлияли на даден коефициент на ликвидност (коефициент на обща, бърза или абсолютна ликвидност), като се използва реален тримесечен баланс от една от пет компании, листнати на DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). Задача 2 изисква от моделите да преведат тези сценарии в компилируеми Beancount транзакции. Компилаторът Beancount служи като еталонен инструмент за проверка на синтаксиса; експерти в областта оценяват семантичната коректност. Докладът въвежда таксономия на грешките от 12 класа за двете задачи и използва подкана с 9 стъпки на верига от мисли, която включва правилата на двойното счетоводство, пример за вход/изход и реалния баланс на компанията във формат Beancount. Оценените модели — Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B и CodeQwen-1.5-7B — бяха пуснати локално (on-premise) поради чувствителността на финансовите данни. Корпусът възлиза на общо 1500 генерирани проби, като 300 стратифицирани записа са оценени от човешки експерти.

Ключови идеи

• Само 7 от 300 оценени двойки сценарий-транзакция (2,3%) са били напълно коректни от край до край; дори ограничаването до трите модела с общо предназначение повишава процента само до 3,8%.
• Двата най-добри модела, Qwen-2-7B и Mistral-7B, генерират коректни сценарии само в 21,67% и 20,00% от случаите, и коректни компилируеми транзакции само в 16,67% и 10,00% от случаите.
• Моделите, специализирани в програмен код (CodeLlama, CodeQwen), постигат 0% и в двете задачи; те са отговорили на шаблона за подкана с буквалния низ „Processed — Waiting for next input“, напълно игнорирайки задачата.
• Синтаксисът не е тесното място: нито един модел не е произвел нито една синтактична грешка. Неуспехите са изцяло в счетоводната логика — грешките в балансирането доминират при Qwen-2 (61,67%) и Llama-3 (38,33%), докато Mistral предимно реферира към сметки, които не съществуват в предоставения баланс (45% грешки за непознати сметки).
• Значителна част от транзакциите, които се компилират успешно, са семантично погрешни — любимият трик на моделите е да наричат намаляването на пасив „продажба на вашия дълг“, което увеличава касовата наличност, но по грешна причина.
• GPT-4o, използван като автоматизиран съдия, не успя да сигнализира за несъответствия във всички 10 абсурдни сценария, които му бяха показани, потвърждавайки, че самооценката на LLM не е надежден филтър за качество на счетоводните резултати.
• Моделите до голяма степен копират примера за вход/изход в подканата, вместо да обобщават: 7-те правилни двойки силно наподобяват предоставената примерна структура на транзакцията.

Какво се потвърждава — и какво не

Основният емпиричен принос на доклада е солиден. Компилаторът Beancount е обективен, възпроизводим критерий за коректност, а използването на реални фирмени баланси вместо примерни данни добавя екологична валидност. Йерархичната таксономия на грешките е обмислена внимателно — спирането на оценката при първата грешка избягва изкуственото завишаване на „частичното признание“ за безполезни резултати.

Въпреки това има очевидни ограничения, които авторите до голяма степен признават. Пет модела с отворени тегла от около 7B от 2023–2024 г. са тесен отрязък от ландшафта на възможностите; GPT-4o и Claude бяха изключени поради съображения за поверителност, което е разбираемо, но означава, че водещото число (2,3% коректност) подценява предната линия на технологиите. Формулите за финансовите коефициенти бяха съзнателно изключени от подканите, за да се тестват присъщите знания в областта — методологически интересен избор, но такъв, който прави резултатите несравними с всяка система, която разумно би включила документация на формулите. И 300 оценени от хора проби в пет модела, три коефициента и пет компании са скромно количество; клетките за модел на коефициент са твърде малки (12 проби), за да се направят силни заключения за отклоненията.

Най-интересният методологически пропуск е липсата на какъвто и да е итеративен протокол или такъв, базиран на обратна връзка. Без извикване на инструменти (tool-calling), без самокорекция, без цикъл на обратна връзка от компилатора — само генериране от един опит (one-shot). Като се има предвид, че CRITIC (LOG-012) и свързаните с него трудове показват, че интерактивното прецизиране с инструменти значително подобрява точността при задачи с проверими резултати, експеримент с компилатор Beancount в цикъла би бил далеч по-информативен относно възможностите за внедряване.

Защо това е важно за AI във финансите

Всяко дизайнерско решение за агента за обратен запис на Bean Labs почива на предположения за това какво могат да правят LLM с Beancount DSL. Този доклад е първата емпирична опора. Водещите констатации са отрезвяващи, но също така интерпретируеми по полезен начин.

Първо, режимите на отказ са специфични, а не случайни. Грешките в балансирането и непознатите сметки са двата доминиращи проблема и двата са решими с цикъл на обратна връзка от компилатора: компилаторът Beancount ви казва точно коя сметка е непозната и дали транзакцията е балансирана. Архитектура на агент, която итерира върху изхода на компилатора — вместо да генерира веднъж и да спре — би трябвало значително да превъзхожда резултатите от един опит тук. Второ, синтаксисът е „безплатен“. Моделите ясно са научили повърхностната граматика на Beancount; те просто не могат надеждно да преведат финансовото намерение в правилни движения по сметките. Тази разлика е важна за това къде да се инвестира в подтикване (prompting) и фина настройка (fine-tuning). Трето, констатацията, че GPT-4o не може автоматично да оценява качеството на счетоводството, вдига летвата за всяка автоматизирана система за проверка: необходим ви е компилаторът, плюс проверки на място от експерти в областта, а не LLM критик.

Докладът също така потвърждава нещо, което подозирах от работата по откриване на аномалии (LOG-049): LLM, работещи върху финансови транзакции, компилират и изпращат твърде лесно. Категорията „Неправилно | Компилира се“ — транзакции, които преминават синтактичната проверка, но са семантично погрешни — е точно режимът на отказ, който защитната преграда за обратен запис трябва да улови. Една транзакция може да се балансира перфектно и все пак да осчетоводи приходи като намаление на пасив, което би останало неоткрито от всяка чисто синтактична проверка.

Какво да прочетете след това

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — оценяване на аномалии въз основа на вероятност като алтернатива на подхода за групово откриване; съчетава се естествено със сигнал от компилатора Beancount за маркиране на структурно валидни, но статистически аномални записи.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — пренасочва решения с ниска степен на увереност към по-голям модел или човек; директно адресира въпроса кога един агент за обратен запис в Beancount трябва да отложи решението за преглед от човек, вместо да продължи след цикъл на обратна връзка от компилатора.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — най-релевантният съществуващ труд за изграждане на агент за корекция с компилатор в цикъла върху архитектурата, която този доклад оценява.