FinToolBench: Оценяване на LLM агенти при използване на финансови инструменти в реалния свят

Повечето бенчмаркове за финансово AI тестват дали един модел може да прочете документ. FinToolBench тества дали моделът може да направи нещо — да извика API в реално време, да получи текущи пазарни данни и да върне правилен отговор. Това е разликата, която е от значение за всяка система, опитваща се да автоматизира реална финансова работа, и е празнината, която чаках някой да запълни стриктно.

Докладът

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

Бенчмаркът съчетава 760 изпълними финансови инструмента — 261 крайни точки (endpoints) в реално време от RapidAPI и 499 интерфейса от AkShare — с 295 стриктно подбрани заявки за оценка, разделени на 166 случая с един инструмент и 129 случая с няколко инструмента. Инструментите обхващат домейни като акции, облигации, фондове, форекс, деривати, макроикономика и криптовалути. От решаващо значение е, че това са реални, призовими API, а не имитации (mocked stubs). Авторите също така въвеждат FATR (Finance-Aware Tool Routing), базов агент, използващ BGE-M3 извличане (топ-20 кандидати), карти с инструменти, анотирани с финансови атрибути, и ReAct планьор, съобразен с ограниченията, лимитиран до пет стъпки.

Ключови идеи

• Изпълнението не е тясното място — разсъждаването върху резултатите е. GPT-4o има най-висок Conditional Soft Score (CSS = 0,670), което означава, че дава правилни отговори, когато успешно извика инструмент, но извиква инструменти само в 22,7% от времето (TIR = 0,227). Qwen3-8B извиква инструменти в 87,1% от времето, но получава правилния отговор само в 40,4% от случаите, когато успява.
• Несъответствието на намерението е доминиращият провал в съответствието. IMR (Intent Mismatch Rate) надвишава 50% при повечето модели, което означава, че агентите рутинно извършват трансакционни повиквания, когато заявката изисква само информационно търсене. Това е сериозен проблем в регулираните финансови контексти.
• Инжектирането на финансови атрибути помага за съответствието, без да вреди на способностите. Картите с инструменти на базовия FATR — анотиращи всеки инструмент с актуалност, тип намерение и регулаторен домейн — намаляват повикванията на остарели данни (TMR) и нарушенията на домейна (DMR), без да влошават значително процента на извикване.
• Заявките с множество инструменти излагат на показ празнината в надеждността. 129-те заявки с множество инструменти изискват верижни повиквания и предаване на резултати между стъпките; производителността спада значително в сравнение със случаите с един инструмент, което съответства на констатациите от FinTrace и TheAgentCompany.
• Малките модели могат да превъзхождат големите по извикване, но не и по разсъждение. TIR на Qwen3-8B от 0,871 срещу 0,227 за GPT-4o показва, че по-малките модели са по-склонни към често извикване, но CER (Conditional Execution Rate, т.е. 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 заявки означава, че повечето инструменти никога не се тестват. Докладът не съобщава статистики за покритие по домейни, което означава, че водещите числа могат да се движат от подмножество добре покрити домейни като акции и макроикономика.

Защо това е важно за финансовия AI

Beancount агентите за обратно записване — всеки агент, който извиква bean-add, коригира файл на главната книга (ledger file) или прави заявка към 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.