FinMCP-Bench: Сравнителен анализ на LLM агенти за реално използване на финансови инструменти под MCP
MCP се превърна в де факто стандарта за свързване при използването на инструменти от LLM — Anthropic го представи в края на 2024 г., а до началото на 2026 г. всички големи доставчици на модели го приеха. FinMCP-Bench (arXiv:2603.24943, ICASSP 2026) е първият бенчмарк, изграден върху реални MCP сървъри за инструменти, специално за финансови агенти, и се появи в точния момент, за да ни каже дали тази стандартизирана инфраструктура действително помага на агентите да вършат полезна финансова работа.
Документът
Jie Zhu, Yimin Tian и колеги от екипа на Alibaba Cloud Qwen DianJin, YINGMI Wealth Management и Университета Soochow представят FinMCP-Bench — набор за оценка от 613 проби, покриващ 10 категории финансови сценарии и 33 под-сценария. Инструментите не са симулирани — 65 реални MCP-съвместими сървъра за финансови инструменти стоят зад бенчмарка, извлечени от реални производствени логове на финансовия асистент Qieman APP. Авторите класифицират пробите в три типа: 145 с един инструмент, 249 с множество инструменти и 219 с многократни ходове (multi-turn). Тестват се шест модела: фамилията Qwen3 с 4B, 30B и 235B параметри (всички с разширено мислене), плюс DeepSeek-R1, GPT-OSS-20B и Seed-OSS-36B. Основните метрики за оценка са точност на инструментите (Tool Precision), пълнота на инструментите (Tool Recall), 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, което ограничава преносимостта на резултатите към други финансови платформи с различен инвентар от инструменти.
Защо това е важно за финансовия AI
FinMCP-Bench е най-близката публикувана оценка до това, което един Beancount агент за запис (write-back agent) всъщност би правил: получаване на потребителска заявка, идентифициране на подходящия инструмент (или верига от инструменти), извикването им в съответния ред и управление на последващи ходове. Резултатът от 3,08% EMR при многократни ходове е отрезвяваща проверка на реалността. Beancount агент, който управлява многостъпкова корекция на главната книга — например прекласифициране на набор от транзакции между сметки за определен период, след това равняване и генериране на отчет — е точно типа задача с многократни ходове и инструменти, при която текущите модели се провалят почти универсално според стандартите за точно съвпадение.
Рамката на MCP е директно релевантна: Python API на Beancount, интерфейсът beanquery и REST слоят на fava могат да бъдат обвити като MCP сървъри. FinMCP-Bench ни казва, че протоколът не е тясното място — проблемът е логическото мислене върху последователностите от извиквания на инструменти.
Констатацията, че пълнотата на инструментите надвишава точността (моделите прекаляват с извикванията), също е важна за безопасността при запис: агент, който извиква инструмента за промяна на главната книга, когато е било необходимо само четене, може да повреди данните безшумно. Метриките, фокусирани върху точността (precision), а не върху пълнотата (recall), трябва да бъдат основният сигнал за безопасност за агентите с право на запис.
Какво да прочетете след това
- JSONSchemaBench (arXiv:2501.10868) — оценява надеждността на структурирания изход в 10 000 JSON схеми; директно разглежда дали повредите във форматирането на извикванията на инструменти във FinMCP-Bench са проблем на ограниченото декодиране.
- ToolLLM (arXiv:2307.16789, ICLR 2024) — фундаменталната рамка за обучение за използване на инструменти, спрямо която се позиционира FinMCP-Bench; разбирането на нейното изследване на дървета за търсене в дълбочина изяснява какво добавя методологията с производствени логове на FinMCP-Bench.
- WildToolBench (arXiv:2604.06185) — оценява използването на инструменти върху реални потребителски заявки "в дивата природа"; неговото откритие, че нито един модел не надвишава 15% точност при реално потребителско поведение, допълва подхода на FinMCP-Bench с производствени логове.
