Більшість фінансових ШІ-бенчмарків перевіряють, чи може модель прочитати документ. FinToolBench перевіряє, чи може модель зробити щось — викликати живий API, отримати актуальні ринкові дані та повернути правильну відповідь. Це саме той розрив, який має значення для будь-якої системи, що намагається автоматизувати реальну фінансову роботу, і саме той розрив, закриття якого я чекав побачити в строгому вигляді.
Стаття
Цзяксюань Лу з колегами представляють FinToolBench (arXiv:2603.08262, березень 2026) як, за їхніми словами, перший реальний виконуваний бенчмарк для оцінювання агентів, які навчаються використовувати фінансові інструменти. Формулювання пряме: наявні оцінювання фінансового ШІ зосереджені на статичному аналізі документів з відповідями на запитання, тоді як загальні бенчмарки використання інструментів, як-от ToolLLM, розглядають фінанси просто як ще одну категорію API без галузевих вимог відповідності. FinToolBench намагається заповнити простір між цими двома крайнощами.
Бенчмарк поєднує 760 виконуваних фінансових інструментів — 261 живу кінцеву точку від RapidAPI та 499 інтерфейсів від AkShare — із 295 ретельно підібраними оцінювальними запитами, розділеними на 166 однoінструментальних і 129 багатоінструментальних випадків. Інструменти охоплюють акції, облігації, фонди, форекс, деривативи, макроекономіку та криптовалюти. Ключово: це реальні викликані API, а не імітовані заглушки. Автори також представляють FATR (Finance-Aware Tool Routing, маршрутизація інструментів з урахуванням фінансового контексту) — базового агента, що використовує BGE-M3 пошук (топ-20 кандидатів), картки інструментів із фінансовими атрибутами та планувальник ReAct з урахуванням обмежень, обмежений п'ятьма кроками.
Ключові ідеї
- Виконання — не вузьке місце; вузьке місце — міркування над результатами. GPT-4o має найвищий умовний скоринг якості (CSS = 0,670), тобто дає правильні відповіді, коли успішно викликає інструмент, але викликає інструменти лише у 22,7% випадків (TIR = 0,227). Qwen3-8B викликає інструменти у 87,1% випадків, але отримує правильну відповідь лише у 40,4% випадків при успішному виклику.
- Розбіжність намірів — найпоширеніше порушення відповідності. Показник розбіжності намірів (IMR) перевищує 50% для більшості моделей, тобто агенти регулярно здійснюють транзакційні виклики, коли запит вимагає лише інформаційного пошуку. Це серйозна проблема в регульованих фінансових контекстах.
- Впровадження фінансових атрибутів покращує відповідність без шкоди для можливостей. Базові картки інструментів FATR — анотації кожного інструмента зі свіжістю даних, типом наміру та регуляторною сферою — зменшують виклики застарілих даних (TMR) і порушення доменів (DMR) без значного погіршення показника викликів.
- Багатоінструментальні запити викривають розрив у надійності. 129 багатоінструментальних запитів вимагають ланцюжків викликів і передачі результатів між кроками; продуктивність значно падає порівняно з одноінструментальними випадками, що узгоджується з висновками FinTrace та TheAgentCompany.
- Малі моделі можуть перевершувати великі за кількістю викликів, але не за міркуваннями. TIR Qwen3-8B у 0,871 проти 0,227 у GPT-4o показує, що менші моделі часто викликають інструменти без належної причини, але CER (умовний показник виконання, тобто TESR/TIR) у 0,339 для Qwen3-8B проти 0,618 для GPT-4o виявляє, що GPT-4o значно точніший, коли вирішує викликати інструмент.
Що тримається — а що ні
Рішення бенчмарку використовувати справді живі, виконувані API — його головний внесок, і він суттєвий. Імітовані API були прихованим недоліком бенчмарків використання інструментів: 16 000 API у ToolLLM звучать вражаюче, поки не зрозумієш, що оцінювання використовує LLM як суддю, чи виклик «спрацював би». FinToolBench цього уникає.
Показники відповідності (TMR, IMR, DMR) концептуально правильні — фінансові агенти мають розрізняти отримання вчорашньої ціни закриття та ініціювання угоди — але опис того, як ці класифікації забезпечуються, надто загальний. Незрозуміло, чи мітки істинності для типу наміру (інформаційний чи транзакційний) були перевірені експертами з права чи комплаєнсу, чи просто призначені авторами набору даних. Це має велике практичне значення.
Список моделей також дивно вузький: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash та GPT-4o. Немає Claude Sonnet або Gemini 2.5, які були б природними для порівняння. Таблиця результатів показує GPT-4o як викид із високою точністю та низьким покриттям; я хотів би знати, чи поведінка Claude щодо використання інструментів ближча до консервативного патерну GPT-4o чи до агресивного Qwen3-8B.
Набір з 295 запитів для оцінювання малий за сучасними стандартами бенчмарків. При 760 інструментах покриття 295 запитами означає, що більшість інструментів ніколи не тестуються. Стаття не надає статистики покриття за доменами, тому головні цифри можуть бути зумовлені підмножиною добре покритих доменів, як-от акції та макроекономіка.
Чому це важливо для фінансового ШІ
Агенти зворотного запису Beancount — будь-який агент, що викликає bean-add, редагує файл журналу чи запитує через beanquery — стикаються саме з тими видами збоїв, які виявляє FinToolBench. Проблема розбіжності намірів прямо відображається: агент Beancount, який виконує виклик на запис, коли користувач поставив запитання на читання, має той самий патерн збою, що й порушення IMR. Вимірювання свіжості даних відображається на виклик застарілого стану журналу з кешу, коли користувач очікує актуальний баланс.
Напруга між точністю та покриттям (GPT-4o проти Qwen3-8B) також безпосередньо актуальна. Для зворотного запису Beancount я рішуче віддав би перевагу консервативній поведінці викликів GPT-4o — низький TIR, високі CER і CSS — над моделлю з високим показником викликів, яка часто виконує неправильний інструмент. Помилкові записи коштують набагато більше, ніж бездіяльність.
Підхід FATR анотувати інструменти атрибутами відповідності, а не покладатися на те, що модель виводитиме їх сама, — це патерн проєктування, вартий запозичення. Обгортання CLI-інструментів Beancount явними метаданими про те, чи виклик є лише для читання чи мутуючим, і чи стосується він поточного чи архівного стану журналу, — та сама ідея, застосована в меншому масштабі.
Що читати далі
- FinTrace (arXiv:2604.10015) — оцінювання на рівні траєкторій у 34 фінансових категоріях завдань із 9 метриками; безпосередньо розширює оцінювання одиночних викликів FinToolBench до багатокрокових послідовностей і доточує Qwen-3.5-9B за допомогою DPO для покращення проміжних міркувань.
- FinMCP-Bench (arXiv:2603.24943) — 613 зразків понад 65 MCP-фінансових інструментів, що тестує одноінструментальні, багатоінструментальні та багатооборотні виклики; структура MCP безпосередньо актуальна для інтерфейсів інструментів Beancount.
- ToolLLM (arXiv:2307.16789, ICLR 2024) — стаття ToolBench, відносно якої FinToolBench явно позиціонує себе; розуміння того, що може і що не може виміряти базовий імітований API, прояснює, скільки вартий справжній виконуваний характер FinToolBench.
