FinToolBench: Оцінка агентів LLM на основі використання фінансових інструментів у реальних умовах

Більшість тестів фінансового ШІ перевіряють, чи може модель прочитати документ. FinToolBench перевіряє, чи може модель щось зробити — викликати живий API, отримати поточні ринкові дані та повернути правильну відповідь. Це той розрив, який має значення для будь-якої системи, що намагається автоматизувати реальну фінансову роботу, і це той розрив, на суворе усунення якого я чекав.

Стаття

Цзясюань Лу та його колеги представляють FinToolBench (arXiv:2603.08262, березень 2026 року) як те, що вони називають першим у світі реальним виконуваним тестом для оцінки агентів, які навчаються використовувати фінансові інструменти. Формулювання пряме: існуючі оцінки фінансового ШІ зосереджені на статичних питаннях та відповідях за документами, тоді як загальні тести використання інструментів, такі як ToolLLM, розглядають фінанси як просто ще одну категорію API без специфічних для галузі обмежень відповідності. FinToolBench намагається заповнити простір між цими двома видами невдач.

Бенчмарк поєднує 760 виконуваних фінансових інструментів — 261 жива кінцева точка від RapidAPI та 499 інтерфейсів від AkShare — з 295 ретельно підібраними запитами для оцінки, розділеними на 166 випадків з одним інструментом і 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 щодо анотування інструментів атрибутами відповідності, замість того щоб покладатися на модель для їх виведення, є шаблоном проектування, який варто перейняти. Огортання інструментів командного рядка 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.