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

FinTrace (arXiv:2604.10015) пристига една седмица след FinToolBench, който отразих миналия път, и двете публикации са в директен диалог помежду си. Докато FinToolBench измерва дали агентът извиква правилните инструменти, FinTrace задава по-трудния въпрос: дори когато агентът извиква правилните инструменти, разсъждава ли той в действителност върху резултатите? Тази разлика е същината на статията и, според мен, същината на целия проблем с Beancount агента за обратно записване (write-back).

Статията

Cao и др. представят FinTrace, бенчмарк от 800 експертно анотирани траектории, обхващащи 34 категории финансови задачи от реалния свят в нива на трудност: лесно, средно и трудно. Авторите изграждат своята оценка около рубрика от девет метрики, организирани по четири оси: коректност на действието (tool-calling F1, релевантност към задачата), ефективност на изпълнението (ефективност на стъпките, резултат за излишък), качество на процеса (логическа прогресия, използване на информация, резултат за напредък) и качество на резултата (степен на преминаване на задачата, качество на крайния отговор). Те оценяват 13 LLM модела и също така пускат FinTrace-Training, набор от данни от 8196 подбрани траектории на предпочитания за фина настройка.

Основното твърдение е, че водещите модели са усвоили подбора на инструменти, но системно се провалят на по-трудната стъпка: използването на това, което инструментите връщат. Бенчмаркът изследва това с 5-степенна скала за използване на информация, логическа прогресия и резултат за напредък, плюс алгоритмични метрики за tool F1 и ефективност на стъпките.

Ключови идеи

• Най-добре представящият се модел, Claude-Opus-4.6, постига Tool-Calling F1 от 0.896 — силен подбор — но получава само 3.23/5 за използване на информация (Information Utilization), най-слабата от четирите метрики, ориентирани към изхода.
• Степента на преминаване на задачите (Task Pass Rate) на Claude-Opus-4.6 е 2.65/5, а качеството на крайния отговор (Final Answer Quality) е 3.34/5; дори топ моделът не произвежда последователно правилни и пълни отговори.
• Qwen-3.5-9B показва дегенериращ модел: почти перфектна ефективност на стъпките (1.000) и излишък (1.000), защото почти не извиква никакви инструменти, което се отразява в Tool-Calling 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, които разкриват какво се случва между стъпките. Коефициентът на съгласие между оценителите (Cohen's κ) от 0.89 върху 100-пробна валидация е окуражаващ за бенчмарк, изграден частично върху LLM съдии.

Въпреки това, няколко методологични избора ограничават доверието в числата. 34-те категории задачи не са изброени в основната статия — те са оставени за Приложение Б — така че не мога да кажа колко представителни са те за реалната финансова практика. Нивата на трудност са дефинирани чрез процентилни рангове в рамките на собствения пул от заявки на бенчмарка, което е кръгов измерител: „трудно“ просто означава необичайно спрямо останалите 800 траектории, а не трудно в някакъв абсолютен смисъл.

Анализът на фината настройка е фрустриращ. Обучението на 9B модел върху FinTrace-Training подобрява междинните разсъждения, но качеството на крайния отговор остава ниско. Статията приписва това на „прекъсване на връзката“ между процеса и резултата, но не обяснява защо. Най-вероятното обяснение — че на 9B модел му липсва способността за извикване на факти и аритметичните умения, необходими за финансови задачи, независимо от качеството на траекторията — остава неразгледано. Показването на DPO резултати само за Qwen-3.5-9B също прави невъзможно да се разбере дали по-големите модели се възползват повече.

Скептичен съм и към общото агрегиране на резултатите. Комбинирането на алгоритмични метрики (F1 ∈ [0,1]) с оценки от LLM съдии по 5-степенни скали на Ликерт чрез нормализиране към [0,1] и усредняване смесва много различни типове откази. Модел, който извиква напълно погрешни инструменти, не е същият тип „повреден“ като модел, който извиква правилните инструменти и след това игнорира изхода.

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

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

Метриката за използване на информация (Information Utilization) е тази, която бих следил най-внимателно за всеки Beancount агент. Фактът, че най-добрият наличен модел постига 3.23/5 по този показател в контролиран финансов бенчмарк, трябва да бъде ограничаващ фактор за всяко внедряване в реална среда. Това е аргумент за задължителен човешки преглед на всяка операция по записване, поне докато не видим този резултат стабилно над 4.0.

FinTrace също така потвърждава това, което ReDAct подсказа миналата седмица: правилната архитектура не е разсъждение на LLM от край до край (end-to-end), а конвейер (pipeline), който екстернализира проверката. Агент, който подбира инструментите добре (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.