FinTrace : Évaluation au niveau de la trajectoire de l'appel d'outils par les LLM pour les tâches financières

FinTrace (arXiv : 2604.10015) arrive une semaine après FinToolBench, dont j'ai parlé la dernière fois, et les deux articles sont en dialogue direct. Là où FinToolBench mesure si un agent appelle les bons outils, FinTrace pose la question la plus difficile : même lorsqu'un agent appelle les bons outils, raisonne-t-il réellement sur les résultats ? Cette distinction est le point crucial de l'article et, je pense, le point crucial de tout le problème de l'agent de réécriture (write-back) Beancount.

L'article

Cao et al. introduisent FinTrace, un benchmark de 800 trajectoires annotées par des experts couvrant 34 catégories de tâches financières réelles à travers trois niveaux de difficulté : facile, moyen et difficile. Les auteurs construisent leur évaluation autour d'une grille de neuf métriques organisées selon quatre axes : justesse de l'action (F1 de l'appel d'outil, pertinence de la tâche), efficacité de l'exécution (efficacité des étapes, score de redondance), qualité du processus (progression logique, utilisation de l'information, score de progression) et qualité des résultats (taux de réussite de la tâche, qualité de la réponse finale). Ils évaluent 13 LLM et publient également FinTrace-Training, un ensemble de données de 8 196 trajectoires de préférence sélectionnées pour le réglage fin.

L'affirmation centrale est que les modèles de pointe maîtrisent la sélection des outils mais échouent systématiquement à l'étape la plus difficile : utiliser ce que les outils renvoient. Le benchmark examine cela avec une échelle de 5 points pour l'utilisation de l'information, la progression logique et le score de progression, en plus de métriques algorithmiques pour le F1 des outils et l'efficacité des étapes.

Idées clés

• Le modèle le plus performant, Claude-Opus-4.6, atteint un F1 d'appel d'outil de 0,896 — une sélection solide — mais n'obtient que 3,23/5 pour l'utilisation de l'information, la plus faible des quatre métriques orientées vers le résultat.
• Le taux de réussite des tâches de Claude-Opus-4.6 est de 2,65/5, et la qualité de la réponse finale est de 3,34/5 ; même le meilleur modèle ne produit pas systématiquement de réponses correctes et complètes.
• Qwen-3.5-9B présente un schéma dégénéré : une efficacité d'étape (1,000) et une redondance (1,000) presque parfaites parce qu'il n'appelle pratiquement aucun outil, ce qui se reflète dans un F1 d'appel d'outil de 0,109. Efficace mais inutile.
• L'entraînement sur FinTrace-Training améliore les métriques de processus intermédiaires (la progression logique passe de 2,29 à 2,56 avec DPO ; le score de progression de 2,00 à 2,30), mais la qualité de la réponse finale reste bloquée — aucune variante ne dépasse de manière significative la moyenne de 1,21 sur l'échelle de 1 à 5 pour les petits modèles.
• Le DPO surpasse le SFT pour supprimer les modes d'échec catastrophiques : la part des scores de progression logique de 1 tombe de 11,9 % (SFT) à 9,5 % (DPO).
• La sous-catégorie universellement la plus mauvaise parmi les 13 modèles est le QA de raisonnement (Reasoning QA), où Claude-Opus-4.6 n'atteint que 0,62 au total — un plafond de verre partagé même par le modèle de pointe le plus puissant.

Ce qui tient la route — et ce qui ne tient pas

La conclusion principale — à savoir que la sélection d'outils et le raisonnement sur les outils sont dissociables — est bien motivée et la grille d'évaluation à quatre axes est une véritable contribution. Les benchmarks précédents comme FinToolBench s'arrêtent aux traces d'exécution ; FinTrace ajoute des métriques de qualité de processus jugées par LLM qui exposent ce qui se passe entre les deux. Le κ de Cohen inter-évaluateurs de 0,89 sur une validation de 100 échantillons est encourageant pour un benchmark reposant en partie sur des juges LLM.

Cela dit, plusieurs choix méthodologiques limitent ce que je peux tirer des chiffres au premier degré. Les 34 catégories de tâches ne sont pas énumérées dans le corps de l'article — elles sont reléguées à l'annexe B — je ne peux donc pas dire à quel point elles sont représentatives de la pratique financière réelle. Les niveaux de difficulté sont définis par des rangs percentiles au sein du propre pool de requêtes du benchmark, ce qui est une mesure circulaire : "difficile" signifie simplement "inhabituel par rapport aux 800 autres trajectoires", et non difficile au sens absolu.

L'analyse du réglage fin est frustrante. Entraîner un modèle 9B sur FinTrace-Training améliore le raisonnement intermédiaire mais la qualité de la réponse finale reste médiocre. L'article attribue cela à une "déconnexion" entre le processus et le résultat, mais n'explique pas pourquoi. L'explication la plus plausible — qu'un modèle 9B manque du rappel factuel et de la capacité arithmétique nécessaires pour les tâches financières, quelle que soit la qualité de la trajectoire — n'est pas abordée. Le fait de ne montrer les résultats du DPO que pour Qwen-3.5-9B rend également impossible de savoir si les modèles plus grands en bénéficient davantage.

Je suis également sceptique quant à l'agrégation globale des scores. Combiner des métriques algorithmiques (F1 ∈ [0,1]) avec des scores jugés par LLM sur des échelles de Likert de 1 à 5 en les normalisant à [0,1] et en faisant la moyenne mélange des types d'échecs très différents. Un modèle qui appelle les mauvais outils n'est pas cassé de la même manière qu'un modèle qui appelle les bons outils mais ignore ensuite le résultat.

Pourquoi c'est important pour l'IA financière

Le constat central s'applique directement au problème de la réécriture (write-back) Beancount. Un agent qui appelle de manière fiable les bons outils CLI Beancount mais interprète mal le résultat — par exemple, en analysant une réponse de bilan et en l'imputant au mauvais compte — est pire qu'une absence d'automatisation : il produit des écritures de grand livre erronées mais affirmées avec assurance, qui semblent correctes pour un réviseur occasionnel.

La métrique d'utilisation de l'information est celle que je surveillerais le plus attentivement pour tout agent Beancount. Le fait que le meilleur modèle disponible obtienne 3,23/5 à cet égard dans un benchmark financier contrôlé devrait constituer une contrainte majeure pour tout déploiement en production. Cela plaide pour une révision humaine obligatoire de toute opération de réécriture, du moins jusqu'à ce que nous voyions ce score dépasser systématiquement 4,0.

FinTrace confirme également ce que ReDAct suggérait la semaine dernière : l'architecture appropriée n'est pas un raisonnement LLM de bout en bout mais un pipeline qui externalise la vérification. Un agent qui sélectionne bien les outils (F1 d'outil ~0,9) puis transmet les résultats à une étape de validation distincte avant d'agir est plus défendable qu'un agent qui tente de raisonner sur les résultats bruts des outils en une seule passe.

Que lire ensuite

• FinMCP-Bench (arXiv : 2603.24943) : l'article compagnon utilisant MCP comme standard d'interface d'outils, prochain sur la liste de lecture — directement comparable à FinTrace mais construit sur une couche de protocole différente.
• "Benchmarking LLM Tool-Use in the Wild" (arXiv : 2604.06185) : paru simultanément, il évalue l'appel d'outils en dehors de la finance ; permettrait de clarifier si l'écart d'utilisation de l'information est spécifique au domaine ou général.
• "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv : 2604.05387) : cible les mêmes modes d'échec d'appel d'outils du point de vue des données d'entraînement et pourrait expliquer ce qui manque au DPO de FinTrace-Training.