Бенчмарк FinMaster: чому LLM отримують 96% за фінансову грамотність, але лише 3% за формування звітності

Стаття FinMaster потрапила до мого списку для читання відразу після ReAct. Якщо ReAct досліджує те, як агенти вирішують, коли діяти, то FinMaster ставить складніше запитання: наскільки добре сучасні найкращі LLM справляються з реальними бухгалтерськими робочими процесами, які ці агенти мають виконувати? Опублікований у травні 2025 року, це перший бенчмарк, який я бачив, що охоплює повний цикл — фінансову грамотність, бухгалтерський облік, аудит і консалтинг — в одній цілісній системі оцінювання.

Про статтю

Jiang та інші представляють FinMaster (arXiv:2505.13533), бенчмарк із трьох частин для оцінки LLM у фінансових робочих процесах. Перший компонент, FinSim, — це генератор синтетичних даних, який симулює п'ять типів компаній і створює операції в гроссбуху (як правильні, так і навмисно помилкові) для наповнення тестових сценаріїв без занепокоєння щодо конфіденційності реальних даних. Другий, FinSuite, об'єднує 183 завдання, що охоплюють фінансову грамотність, бухгалтерський облік, аудит і консалтинг на різних рівнях складності. Третій, FinEval, забезпечує єдиний інтерфейс для підрахунку балів. Разом автори стверджують, що FinMaster — це перший бенчмарк, який охоплює повний фінансовий цикл із нескінченною генерацією даних, захищених від витоку приватної інформації — твердження, яке витримує критику порівняно зі статичними попередниками, такими як FinBen та FinanceBench.

Ключові ідеї

• Прірва на рівні складності: моделі набирають у середньому ~96% за фінансову грамотність (читання балансових звітів, звітів про прибутки та збитки), потім падають до 40–60% на базових бухгалтерських розрахунках, нижче 20% на багатоетапних бухгалтерських завданнях і лише до 3% на формуванні фінансової звітності. Грамотність і обчислення — це не одна і та сама навичка.
• Серйозне поширення помилок: у консалтингових завданнях розрахунки одного показника мали середню точність 58%; сценарії з багатьма показниками, які ланцюжком поєднують ці розрахунки, впали до 37% — зниження на 21 пункт через накопичення дрібних помилок.
• Щільна боротьба у топі лідерів: o3-mini (середній бал 0,73), Claude-3.7-Sonnet (0,72) та DeepSeek-V3-2503 (0,70) йдуть дуже близько, що свідчить про те, що бенчмарк не є тривіальним, але межа ще не досягнута.
• Бухгалтерський облік — це найскладніша область: у всіх семи оцінених моделях бали з обліку коливалися лише від 0,04 до 0,35 — значно нижче, ніж у будь-якій іншій категорії. 3% за формування звітності означають, що LLM поки не можуть надійно синтезувати журнал операцій у цілісний фінансовий звіт.
• Моделі з логічним висновком (Reasoning) допомагають лише частково: o3-mini лідирує в цілому, але не вирішально. Ланцюжок міркувань (Chain-of-thought) працює, але він не може подолати 93-пунктовий розрив між грамотністю та формуванням звітності.
• FinSim дозволяє масштабоване стрес-тестування: попередні бенчмарки використовують статичні, фіксовані набори даних, вразливі до забруднення з часом. FinMaster може генерувати нові сценарії за запитом, що важливо для вивчення того, чи моделі узагальнюють знання, чи просто запам'ятовують.

Що підтверджується, а що — ні

Основний результат — різке погіршення багатоетапного фінансового міркування — заслуговує на довіру і відповідає патернам з LOG-001 (FinBen) та LOG-002 (Toolformer). Я вірю в результати щодо поширення помилок; це структурно схоже на те, що відбувається в будь-якому арифметичному ланцюжку. Генератор FinSim є справжнім методологічним внеском: бенчмарк, який може генерувати свіжі сценарії, протистоїть проблемі запам'ятовування, що переслідує статичні фінансові набори даних.

У чому я менш переконаний: 183 завдання — це замало для бенчмарка, який претендує на цілісне охоплення. Тридцять п'ять завдань з аудиту не можуть охарактеризувати таку широку область, як фінансовий аудит, де реальні таксономії помилок налічують сотні пунктів. Стаття зводить всю область до 12 базових типів помилок, що приховує неоднорідність реальних результатів аудиту.

Єдиний агрегований бал у таблиці лідерів також приховує важливі міждоменні патерни. Аудит і консалтинг мають дуже різні профілі для кожної моделі, і їх усереднення дає цифру, яку легко цитувати, але важко використовувати для дій.

Обмеження синтетичних даних — це палиця з двома кінцями. FinSim генерує чисті, добре структуровані дані гроссбуху. Реальні бухгалтерські системи несуть десятиліття спадщини форматів кодування, артефактів округлення валют та коригувань поза циклом, які жоден симулятор не фіксує. 3% результату на синтетичному формуванні звітності — це сумно; те саме вимірювання на заплутаних книгах реальної компанії, ймовірно, було б ще гіршим. Стаття також фокусується лише на тексті — автори визнають відсутність мультимодальності, але не вимірюють її. Більшість бухгалтерської роботи насправді відбувається у відсканованих PDF-файлах та електронних таблицях.

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

Це найбільш безпосередньо релевантна стаття для порядку денного Bean Labs з часів FinBen. Кейс використання Beancount — це, по суті, підмножина того, що оцінює FinMaster: облік на рівні транзакцій, багатоетапні розрахунки та генерація звітів. 3% за формування звітності — це протверезна цифра. Вона говорить мені, що навіть з добре розробленим каркасом агента ReAct, здатність базової моделі синтезувати правильний баланс Beancount із журналу транзакцій є ненадійною без спеціалізованого тонкого налаштування (fine-tuning) або використання RAG-систем.

Результат щодо поширення помилок безпосередньо стосується безпеки зворотного запису (write-back). Якщо ланцюжок консалтингових завдань втрачає 21 пункт точності від першого кроку до другого, то автономний агент Beancount, що виконує триетапну звірку, накопичує помилки на кожному етапі. Це вагомий аргумент на користь розбиття завдань агента на найменші можливі атомарні операції та перевірки проміжних результатів замість того, щоб покладатися на наскрізне (end-to-end) міркування LLM.

FinSim також підказує конкретний напрямок для Bean Labs: симулятор транзакцій спеціально для Beancount міг би генерувати розмічені тестові випадки для оцінки та тонкого налаштування моделей для операцій з гроссбухом. Архітектура вже є; область просто потребує адаптації.

Що почитати далі

• Financial Statement Analysis with Large Language Models (Alex Kim, Maximilian Muhn, Valeri Nikolaev; arXiv:2407.17866) — тестує здатність GPT-4 прогнозувати динаміку прибутків на основі фінансової звітності, досягаючи рівня спеціалізованих ML-моделей; корисна противага похмурим цифрам FinMaster щодо формування звітності.
• FinAuditing: A Financial Taxonomy-Structured Multi-Document Benchmark (arXiv:2510.08886) — більш детальна оцінка аудиту з міркуванням на основі кількох документів; доповнює розріджене охоплення аудиту FinMaster із його 35 завданнями.
• AuditBench: A Benchmark for Large Language Models in Financial Statement Auditing (Springer 2025) — поєднує синтезовані дані транзакцій з реальними фінансовими таблицями для перевірки виявлення та пояснення помилок; методологія безпосередньо порівнянна з аудиторським модулем FinMaster.