FinMCP-Bench: Бенчмаркінг агентів LLM для реального використання фінансових інструментів під управлінням MCP

MCP став стандартом де-факто для підключення інструментів LLM — Anthropic представила його наприкінці 2024 року, і до початку 2026 року всі основні постачальники моделей прийняли його. FinMCP-Bench (arXiv:2603.24943, ICASSP 2026) — це перший бенчмарк, побудований на реальних серверах інструментів MCP спеціально для фінансових агентів, і він з’явився саме вчасно, щоб показати, чи допомагає ця стандартизована інфраструктура агентам виконувати корисну фінансову роботу.

Дослідження

Цзе Чжу, Імінь Тянь та колеги з команди Qwen DianJin Alibaba Cloud, YINGMI Wealth Management та Університету Сучжоу представляють FinMCP-Bench — набір для оцінки з 613 зразків, що охоплює 10 категорій фінансових сценаріїв і 33 субсценарії. Інструменти не є фіктивними — бенчмарк базується на 65 реальних фінансових серверах інструментів, сумісних з MCP, отриманих з реальних логів продуктивної експлуатації фінансового асистента Qieman APP. Автори класифікують зразки на три типи: 145 з одним інструментом, 249 з кількома інструментами та 219 багатоходових. Вони тестують шість моделей: сімейство Qwen3 з 4B, 30B та 235B параметрами (всі з розширеним мисленням), а також DeepSeek-R1, GPT-OSS-20B та Seed-OSS-36B. Основними метриками оцінки є точність інструментів (Tool Precision), повнота інструментів (Tool Recall), F1-міра інструментів (Tool F1) та коефіцієнт точного збігу (Exact Match Rate, EMR), який вимагає, щоб кожен виклик інструменту в послідовності був абсолютно правильним.

Основні ідеї

• MCP як основа для оцінки: використання реальних визначень серверів MCP замість синтетичних схем API усуває значний розрив між оцінкою в бенчмарках і тим, з чим агенти стикаються в розгорнутих фінансових системах.
• Трирівневий поділ за складністю: зразки з одним інструментом, кількома інструментами та багатоходові зразки відрізняються не лише кількісно — вони виявляють якісно різні типи помилок.
• Багатоходовий колапс: найкраща модель (Qwen3-235B) досягає 60% EMR на одному інструменті, 10,62% EMR на кількох інструментах і 3,08% EMR на багатоходових завданнях. Падіння від одиночного до багатоходового сценарію становить 20 разів.
• Tool F1 більш поблажливий: та сама модель отримує 66,85%, 69,42% та 41,56% TF1 у трьох налаштуваннях — це показує, що моделі часто вибирають правильні інструменти, але помиляються в порядку, параметризації або відстеженні діалогу.
• Повнота перевершує точність у сценаріях з одним інструментом: моделі схильні викликати зайві інструменти при невпевненості, а не пропускати їх. Це безпечніший режим відмови для фінансових завдань, але він все одно означає зайві виклики API та шум у процесі міркування.
• Нелінійне масштабування розміру: Qwen3-30B не завжди перевершує Qwen3-4B у всіх субсценаріях, що спростовує припущення, що більша модель завжди краща для багатоступеневого використання інструментів.

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

Використання реальних логів експлуатації як джерела для прикладів з одним інструментом — найсильніший методологічний вибір у цій роботі. Це заземлює бенчмарк у реальну поведінку користувачів, а не в сценарії, вигадані дослідниками, що рідко зустрічається в літературі про ШІ у фінансах. Зразки з кількома інструментами та багатоходові зразки синтетично розширені за допомогою графів залежностей та промптів для рольових ігор, що цілком виправдано, враховуючи вартість маркування, але це створює ризик: процес синтезу зазвичай створює чистіші та більш структуровані запити, ніж ті, що пишуть реальні користувачі. Показник 3,08% EMR у багатоходових завданнях тривожний, але його слід інтерпретувати обережно — EMR вимагає повної правильності всієї послідовності, тому один неправильний проміжний виклик інструменту призводить до невдачі всього завдання. Це суворий і, можливо, нереалістичний стандарт для експлуатації; метрики з частковим зарахуванням, такі як TF1, дають більш нюансовану картину.

Чого немає в статті: відсутній аналіз того, чи є розрив у продуктивності насамперед проблемою розуміння вхідних даних (модель неправильно інтерпретує бажання користувача), проблемою форматування виводу (правильний намір, але невірний формат виклику інструменту) чи проблемою міркування (неправильні проміжні висновки). Без цього розподілу важко зрозуміти, куди спрямувати інженерні зусилля. Стаття також оцінює моделі ізольовано; немає перевірки того, чи змінює додавання кроку верифікації або рефлексії картину багатоходових сценаріїв.

Бенчмарк також глибоко прив’язаний до конкретних 65 інструментів Qieman, що обмежує можливість перенесення результатів на інші фінансові платформи з іншим набором інструментів.

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

FinMCP-Bench — це найбільш наближена до реальності оцінка того, що насправді робив би агент запису Beancount: отримання запиту користувача, визначення відповідного інструменту (або ланцюжка інструментів), їх послідовний виклик та обробка наступних кроків діалогу. Багатоходовий EMR у 3,08% — це протверезна перевірка реальністю. Агент Beancount, який керує багатоступеневим коригуванням реєстру — наприклад, перекласифікація набору транзакцій між рахунками за певний період, потім звірка, а потім створення звіту — це саме той тип багатоходового завдання з кількома інструментами, в якому сучасні моделі зазнають невдачі майже повсюдно за стандартами точного збігу.

Контекст MCP має пряме відношення: Python API Beancount, інтерфейс beanquery та REST-рівень fava — все це можна обернути як сервери MCP. FinMCP-Bench показує нам, що протокол не є вузьким місцем — ним є міркування над послідовностями викликів інструментів.

Висновки про те, що повнота викликів перевищує точність (моделі викликають занадто багато інструментів), також важливі для безпеки запису: агент, який викликає інструмент зміни реєстру, коли було потрібно лише читання, може непомітно пошкодити дані. Метрики оцінки, орієнтовані на точність, а не на повноту, повинні бути основним сигналом безпеки для агентів, що мають право запису.

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

• JSONSchemaBench (arXiv:2501.10868) — оцінює надійність структурованого виводу на 10 тисячах схем JSON; безпосередньо розглядає, чи є помилки форматування викликів інструментів у FinMCP-Bench проблемою обмеженого декодування.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — фундаментальна база для навчання використанню інструментів, відносно якої позиціонується FinMCP-Bench; розуміння її деревоподібного пошуку вглиб прояснює, що додає методологія логів експлуатації FinMCP-Bench.
• WildToolBench (arXiv:2604.06185) — оцінює використання інструментів на реальних запитах користувачів «у дикій природі»; висновок про те, що жодна модель не перевищує 15% точності на довільній поведінці користувачів, доповнює підхід FinMCP-Bench з логами експлуатації.