Перейти к контенту

FinTrace: Оценка траекторий вызова инструментов LLM для финансовых задач

· 6 мин чтения
Mike Thrift
Mike Thrift
Marketing Manager

FinTrace (arXiv:2604.10015) появилась спустя неделю после FinToolBench, о которой я писал в прошлый раз, и эти две работы напрямую дискутируют друг с другом. Если FinToolBench измеряет, вызывает ли агент нужные инструменты, то FinTrace задает более сложный вопрос: даже если агент вызывает правильные инструменты, проводит ли он на самом деле рассуждения на основе полученных результатов? Это различие является ключевым моментом статьи и, на мой взгляд, основной проблемой всей задачи создания агентов записи для Beancount.

Статья

2026-07-06-fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks

Цао и соавторы представляют FinTrace — бенчмарк из 800 аннотированных экспертами траекторий, охватывающих 34 категории реальных финансовых задач трех уровней сложности: легкий, средний и сложный. Авторы строят свою оценку вокруг рубрики из девяти метрик, организованных по четырем осям: правильность действий (F1 вызова инструментов, релевантность задаче), эффективность исполнения (эффективность шагов, показатель избыточности), качество процесса (логическая последовательность, использование информации, показатель прогресса) и качество результата (коэффициент прохождения задач, качество итогового ответа). Они оценивают 13 LLM, а также выпускают FinTrace-Training — набор данных из 8 196 отобранных траекторий предпочтений для дообучения.

Основное утверждение заключается в том, что передовые модели освоили выбор инструментов, но систематически терпят неудачу на более сложном этапе: использовании того, что возвращают инструменты. Бенчмарк проверяет это с помощью 5-балльной шкалы для использования информации, логической последовательности и показателя прогресса, а также алгоритмических метрик для F1 инструментов и эффективности шагов.

Ключевые идеи

  • Лучшая модель, Claude-Opus-4.6, достигает F1 вызова инструментов 0.896 — отличный выбор — но набирает всего 3.23/5 по Использованию информации, самой слабой из четырех метрик, ориентированных на результат.
  • Коэффициент прохождения задач у Claude-Opus-4.6 составляет 2.65/5, а качество финального ответа — 3.34/5; даже топовая модель не всегда выдает правильные и полные ответы.
  • Qwen-3.5-9B демонстрирует дегенеративный паттерн: почти идеальная эффективность шагов (1.000) и избыточность (1.000), потому что она почти не вызывает инструменты, что отражается в F1 вызова инструментов 0.109. Эффективно, но бесполезно.
  • Обучение на FinTrace-Training улучшает метрики промежуточных процессов (логическая последовательность растет с 2.29 до 2.56 с DPO; показатель прогресса — с 2.00 до 2.30), но качество финального ответа остается заблокированным — ни один вариант не превышает в среднем 1.21 по шкале 1–5 для малых моделей.
  • DPO превосходит SFT в подавлении катастрофических режимов отказа: доля оценок «Логическая последовательность» равных 1 падает с 11.9% (SFT) до 9.5% (DPO).
  • Самая худшая подкатегория для всех 13 моделей — Reasoning QA, где Claude-Opus-4.6 набирает всего 0.62 в целом — жесткий потолок даже для сильнейшей модели.

Что подтверждается, а что нет

Основной вывод о том, что выбор инструмента и рассуждение над ним разделимы, хорошо мотивирован, а рубрика из четырех осей является реальным вкладом. Предыдущие бенчмарки, такие как FinToolBench, останавливаются на трассировках выполнения; FinTrace добавляет метрики качества процесса, оцениваемые LLM, которые показывают, что происходит в промежутках. Коэффициент κ Коэна между экспертами 0.89 на валидации из 100 примеров обнадеживает для бенчмарка, частично построенного на судьях-LLM.

Тем не менее, несколько методологических решений ограничивают доверие к цифрам. 34 категории задач не перечислены в основной статье — они вынесены в Приложение B — поэтому я не могу сказать, насколько они репрезентативны для реальной финансовой практики. Уровни сложности определяются процентильным рангом внутри собственного пула запросов бенчмарка, что является круговым показателем: «сложный» означает просто необычный по сравнению с другими 800 траекториями, а не сложный в каком-либо абсолютном смысле.

Анализ дообучения расстраивает. Обучение модели 9B на FinTrace-Training улучшает промежуточные рассуждения, но качество финального ответа остается неудовлетворительным. В статье это объясняется «разрывом» между процессом и результатом, но не объясняется причина. Самое правдоподобное объяснение — что модели 9B не хватает памяти фактов и арифметических способностей, необходимых для финансовых задач, независимо от качества траектории — осталось без внимания. Демонстрация результатов DPO только для Qwen-3.5-9B также делает невозможным понимание того, получают ли больше пользы крупные модели.

Я также скептически отношусь к агрегации общих баллов. Объединение алгоритмических метрик (F1 ∈ [0,1]) с оценками судей-LLM по 5-балльной шкале Ликерта путем нормализации к [0,1] и усреднения смешивает совершенно разные типы сбоев. Модель, которая вызывает неправильные инструменты, — это не тот же тип поломки, что и модель, которая вызывает правильные инструменты, а затем игнорирует результат.

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

Основной вывод напрямую переносится на проблему записи (write-back) в Beancount. Агент, который надежно вызывает нужные инструменты Beancount CLI, но затем неверно интерпретирует результат — скажем, разбирает ответ по балансовому отчету и делает запись не на тот счет — хуже, чем отсутствие автоматизации: он создает уверенно ошибочные записи в реестре, которые выглядят правильными для случайного проверяющего.

Метрика «Использование информации» — это то, за чем я бы следил внимательнее всего для любого агента Beancount. Тот факт, что лучшая доступная модель набирает 3.23/5 по этому показателю в контролируемом финансовом бенчмарке, должен стать сдерживающим фактором для любого промышленного внедрения. Это аргумент в пользу обязательной проверки человеком любой операции записи, по крайней мере до тех пор, пока мы не увидим, что этот балл стабильно превышает 4.0.

FinTrace также подтверждает то, что ReDAct предполагал на прошлой неделе: правильная архитектура — это не сквозное рассуждение LLM, а конвейер, который выносит проверку вовне. Агент, который хорошо выбирает инструменты (Tool F1 ~0.9), а затем передает результаты на отдельный этап валидации перед действием, более надежен, чем тот, который пытается рассуждать над необработанным выводом инструмента за один проход.

Что читать дальше

  • FinMCP-Bench (arXiv:2603.24943): сопутствующая статья, использующая MCP как стандарт интерфейса инструментов, следующая в списке чтения — напрямую сопоставима с FinTrace, но построена на другом протокольном уровне.
  • "Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): появилась одновременно и оценивает вызов инструментов вне финансов; прояснит, является ли разрыв в использовании информации специфичным для домена или общим.
  • "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): нацелена на те же режимы отказов при вызове функций с точки зрения обучающих данных и может объяснить, чего не хватает в DPO FinTrace-Training.