LLM набирают 2,3% при генерации Beancount DSL: бенчмарк LLMFinLiteracy

Эту статью я ждал с самого LOG-001: прямую эмпирическую проверку того, могут ли LLM генерировать валидные транзакции в формате Beancount DSL на основе финансовых сценариев на естественном языке. Фигероа и др. из Берлинского университета прикладных наук представили то, что они по праву называют первой опубликованной оценкой LLM в генерации финансовых транзакций для plain-text бухгалтерии. Краткий ответ: не могут, по крайней мере, надежно, даже при использовании промптинга «цепочка рассуждений» (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 — запускались локально из-за конфиденциальности финансовых данных. Корпус включает 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 образцов) для серьезных выводов о дисперсии.

Самый интересный методологический пробел — отсутствие итеративного протокола или протокола на основе обратной связи. Ни вызова инструментов, ни самокоррекции, ни цикла обратной связи с компилятором — только генерация в один проход. Учитывая, что CRITIC (LOG-012) и связанные работы показывают, что итеративное уточнение с инструментами существенно повышает точность в задачах с проверяемым результатом, эксперимент с «компилятором Beancount в цикле» дал бы гораздо больше информации о возможности практического применения.

Почему это важно для Finance AI

Каждое проектное решение для агента записи Bean Labs опирается на предположения о том, что LLM могут делать с Beancount DSL. Эта статья — первая эмпирическая точка опоры. Основные выводы отрезвляют, но они также поддаются полезной интерпретации.

Во-первых, типы ошибок специфичны, а не случайны. Ошибки баланса и неизвестные счета — две доминирующие проблемы, и обе решаемы с помощью цикла обратной связи с компилятором: компилятор Beancount точно говорит, какой счет неизвестен и сбалансирована ли транзакция. Архитектура агента, которая итерирует на основе вывода компилятора, а не генерирует один раз и останавливается, должна существенно превзойти результаты прогона в один этап. Во-вторых, синтаксис дается «бесплатно». Модели явно усвоили поверхностную грамматику Beancount; они просто не могут надежно перевести финансовое намерение в правильное движение по счетам. Это различие важно для того, во что инвестировать: в промптинг или в дообучение (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) — наиболее релевантная работа для создания агента коррекции с компилятором в цикле поверх архитектуры, оцениваемой в данной статье.