Повечето финансови AI бенчмаркове тестват дали моделът може да чете документ. FinToolBench тества дали моделът може да направи нещо — да извика действащ API, да изтегли актуални пазарни данни и да върне правилен отговор. Това е пропастта, която има значение за всяка система, опитваща се да автоматизира реална финансова работа, и това е пропастта, която чаках да видя затворена строго.
Статията
Jiaxuan Lu и колегите му представят FinToolBench (arXiv:2603.08262, март 2026) като това, което твърдят, че е първият реален изпълним бенчмарк за оценка на агенти, които се учат да използват финансови инструменти. Рамката е директна: съществуващите финансови AI оценки се фокусират върху статични въпроси и отговори върху документи, докато общите бенчмаркове за използване на инструменти като 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 от 0,871 на Qwen3-8B срещу 0,227 на GPT-4o показва, че по-малките модели са прибързани, но CER (Условен Процент на Изпълнение, т.е. TESR/TIR) от 0,339 за Qwen3-8B срещу 0,618 за GPT-4o разкрива, че GPT-4o е далеч по-прецизен, когато реши да извика инструмент.
Какво издържа — и какво не
Изборът на бенчмарка да използва наистина действащи, изпълними API е основният му принос и той е съществен. Подиграваните API бяха мръсната тайна на бенчмарковете за използване на инструменти: 16-те хиляди API на ToolLLM звучат впечатляващо, докато не осъзнаеш, че оценката използва LLM като съдия за това дали едно повикване "би" проработило. FinToolBench избягва това.
Метриките за съответствие (TMR, IMR, DMR) са концептуално правилни — финансовите агенти трябва да знаят разликата между извличане на вчерашната closing цена и иницииране на сделка — но описанието в статията за това как се налагат тези класификации е слабо. Не е ясно дали етикетите за истина за типа на намерението (информационен срещу транзакционен) са били проверени от правни или регулаторни експерти, или просто са присвоени от авторите на набора от данни. Това има голямо значение на практика.
Списъкът с модели също е странно тесен: 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 или запитва beanquery — срещат точно тези типове провал, които FinToolBench разкрива. Проблемът с несъответствието на намеренията се пренася директно: Beancount агент, който издава запис при въпрос за четене, има същия сигнал за провал като нарушение на IMR. Измерението на свежестта се пренася върху извикването на остаряло кеширано състояние на ledger, когато потребителят очаква текущия баланс.
Напрежението между прецизност и покритие (GPT-4o срещу Qwen3-8B) също е непосредствено релевантно. За Beancount запис силно бих предпочел консервативното поведение на GPT-4o при извикване — нисък TIR, висок CER и CSS — пред модел с високо извикване, който често изпълнява грешния инструмент. Грешните записи струват много повече от липсата на действие.
Подходът на FATR да анотира инструментите с регулаторни атрибути, вместо да разчита на модела да ги изведе, е дизайнерски модел, който си заслужава да се възприеме. Опаковането на Beancount CLI инструменти с изрични метаданни за това дали дадено повикване е само за четене или променящо, и дали се отнася до текущо или архивирано състояние на ledger, е същата идея, приложена в по-малък мащаб.
Какво да прочетете след това
- 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.
