LLM отримують 2,3% за генерацію Beancount DSL: бенчмарк LLMFinLiteracy

Це стаття, на яку я чекав з моменту LOG-001: пряме емпіричне тестування того, чи можуть LLM генерувати валідні транзакції Beancount DSL на основі фінансових сценаріїв природною мовою. Фігероа та ін. з Берлінського університету прикладних наук представляють те, що вони — цілком обґрунтовано, наскільки я можу судити — називають першою опублікованою оцінкою LLM у сфері генерації фінансових транзакцій для обліку в текстовому форматі. Коротка відповідь: вони не можуть цього робити, принаймні не надійно, навіть з використанням методу ланцюжка думок (chain-of-thought) та наявним реальним балансовим звітом Beancount як контекстом.

Про статтю

Фігероа, Грундманн, Фрейданк, Лезер та Неждль оцінюють п'ять моделей з відкритими вагами розміром ~7 млрд параметрів у межах бенчмарку з двома завданнями під назвою 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% в обох завданнях; вони відповідали на шаблон промпту буквальною строкою "Оброблено — Очікування наступного вводу", повністю ігноруючи завдання.
• Синтаксис не є перешкодою: жодна модель не припустилася синтаксичної помилки. Помилки цілком зосереджені в бухгалтерській логіці — помилки балансу переважають у 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 зразків), щоб робити впевнені висновки про варіативність.

Найцікавіша методологічна прогалина — відсутність будь-якого ітеративного протоколу або протоколу на основі зворотного зв'язку. Жодного виклику інструментів, жодної самокорекції, жодного циклу зворотного зв'язку від компілятора — лише генерація за один прохід (one-shot). Враховуючи, що CRITIC (LOG-012) та пов'язані роботи показують, що ітеративне вдосконалення за допомогою інструментів суттєво покращує точність у завданнях із результатами, які можна перевірити, експеримент із компілятором Beancount у циклі зворотного зв'язку був би значно інформативнішим щодо можливості впровадження.

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

Кожне дизайнерське рішення для агента зворотного запису 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) — найрелевантніша існуюча робота для створення агента корекції з компілятором у циклі зворотного зв'язку на основі архітектури, яку оцінює ця стаття.