Большинство финансовых ИИ-бенчмарков проверяют, может ли модель прочитать документ. FinToolBench проверяет, может ли модель сделать что-то — вызвать живой API, получить актуальные рыночные данные и вернуть правильный ответ. Именно этот разрыв важен для любой системы, пытающейся автоматизировать реальную финансовую работу, и именно его закрытие я ждал увидеть строгим образом.
Статья
Цзясюань Лу и коллеги представляют FinToolBench (arXiv:2603.08262, март 2026) как, по их утверждению, первый реальный исполнимый бенчмарк для оценки агентов, обучающихся использовать финансовые инструменты. Постановка прямая: существующие финансовые ИИ-оценки фокусируются на статическом Q&A по документам, в то время как общие бенчмарки использования инструментов, такие как 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) концептуально верны — финансовые агенты должны понимать разницу между получением вчерашней цены закрытия и инициированием сделки — но описание того, как обеспечивается эта классификация, в статье поверхностно. Неясно, были ли метки истинности для типа намерения (информационный vs. транзакционный) проверены юридическими или комплаенс-экспертами или просто назначены авторами набора данных. Это имеет большое значение на практике.
Список моделей также удивительно узок: 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 к аннотированию инструментов атрибутами соответствия, а не к опоре на модель, которая должна их выводить самостоятельно, — это шаблон проектирования, который стоит перенять. Обёртывание 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.
