FinTrace: оцінка виклику інструментів LLM для фінансових завдань на рівні траєкторії

FinTrace (arXiv:2604.10015) з'явився через тиждень після FinToolBench, про який я писав минулого разу, і ці дві роботи ведуть прямий діалог одна з одною. Там, де FinToolBench вимірює, чи викликає агент правильні інструменти, FinTrace ставить складніше питання: навіть якщо агент викликає правильні інструменти, чи справді він аналізує результати? Це розмежування є ключовим моментом статті і, на мою думку, основною проблемою для агентів запису (write-back) у Beancount.

Про статтю

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

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

Ключові ідеї

• Найкраща модель, Claude-Opus-4.6, досягає показника Tool-Calling F1 0,896 — сильний вибір — але отримує лише 3,23/5 за використання інформації, що є найнижчим результатом серед чотирьох метрик, орієнтованих на результат.
• Коефіцієнт проходження завдань (Task Pass Rate) у Claude-Opus-4.6 становить 2,65/5, а якість фінальної відповіді — 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, які показують, що відбувається в проміжках. Коефіцієнт Каппа Коена 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. Агент, який надійно викликає правильні інструменти CLI Beancount, але потім неправильно інтерпретує результат — наприклад, парсить відповідь про балансовий звіт і робить запис не на той рахунок — гірший за відсутність автоматизації: він створює впевнено помилкові записи в реєстрі, які виглядають правильними для звичайного перевіряльника.

Метрика використання інформації — це те, за чим я б стежив найуважніше для будь-якого агента 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.