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

Большинство бенчмарков ИИ в финансах проверяют, может ли модель прочитать документ. FinToolBench проверяет, может ли модель что-то сделать — вызвать активный API, получить текущие рыночные данные и вернуть правильный ответ. Именно этот разрыв критичен для любой системы, стремящейся автоматизировать реальную финансовую работу, и я давно ждал, когда кто-то заполнит его со всей строгостью.

Статья

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

Бенчмарк объединяет 760 исполняемых финансовых инструментов — 261 активную конечную точку (endpoint) из RapidAPI и 499 интерфейсов из AkShare — с 295 тщательно отобранными оценочными запросами, разделенными на 166 одноэтапных и 129 многоэтапных кейсов. Инструменты охватывают сферы акций, облигаций, фондов, форекса, деривативов, макроэкономики и криптовалют. Важно, что это реальные, вызываемые API, а не имитации (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 запросов означает, что большинство инструментов никогда не тестируется. В статье не приводятся статистические данные по охвату каждой области, а значит, основные показатели могут определяться подмножеством хорошо охваченных областей, таких как акции и макроэкономика.

Почему это важно для финансового ИИ

Агенты обратной записи Beancount — любые агенты, которые вызывают bean-add, вносят правки в файл гроссбуха или запрашивают данные через beanquery, — сталкиваются именно с теми типами сбоев, которые выявляет FinToolBench. Проблема несоответствия намерений переносится напрямую: агент Beancount, который инициирует вызов записи, когда пользователь задал вопрос на чтение, имеет тот же признак отказа, что и нарушение IMR. Измерение актуальности (timeliness) соотносится с проблемой вызова устаревшего кэшированного состояния гроссбуха, когда пользователь ожидает текущий баланс.

Противоречие между точностью и охватом (GPT-4o против Qwen3-8B) также имеет прямое отношение к делу. Для записи в Beancount я бы предпочел консервативное поведение GPT-4o — низкий TIR, но высокие CER и CSS, — чем модель с высокой частотой вызовов, которая часто использует не тот инструмент. Ошибочные записи обходятся гораздо дороже, чем отсутствие действий (no-ops).

Подход FATR по аннотированию инструментов атрибутами комплаенса вместо того, чтобы полагаться на выводы модели, — это паттерн проектирования, который стоит перенять. Обертка инструментов командной строки 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.