L'article​

Zhao, Jin, Li et Gao de l'Université de Pékin présentent FinRAGBench-V, un benchmark bilingue construit à partir de documents financiers réels : rapports de recherche, états financiers, prospectus, articles académiques, magazines et articles de presse. Le corpus de recherche est substantiel — 60 780 pages en chinois et 51 219 pages en anglais à travers environ 1 100 documents par langue — associé à 1 394 paires de questions-réponses annotées par des humains couvrant sept catégories de questions : inférence textuelle, extraction de graphiques et de tableaux, calcul numérique, requêtes sensibles au facteur temps et raisonnement multi-pages. Au-delà du jeu de données, la contribution centrale de l'article est RGenCite, un système de base qui génère des réponses accompagnées de citations visuelles au niveau du pixel sous forme de coordonnées de cadres de délimitation (bounding boxes) marquant les régions spécifiques du document qui soutiennent chaque affirmation.

Idées clés​

• La recherche multimodale domine le texte seul par une marge écrasante : ColQwen2, un extracteur vision-langage construit sur des plongements (embeddings) d'images de pages, atteint un Recall@10 de 90,13 % (chinois) et 85,86 % (anglais). Les meilleurs extracteurs textuels, BM25 et BGE-M3, plafonnent autour de 42,71 %. Cet écart n'est pas une simple erreur d'arrondi.
• La précision de la génération est faible même pour les modèles de pointe : GPT-4o sur l'anglais atteint 43,41 % de précision (ROUGE 24,66) ; o4-mini sur le chinois atteint 58,13 % (ROUGE 38,55). Il s'agit de modèles propriétaires de premier plan dotés d'une recherche solide.
• La citation au niveau de la page fonctionne ; celle au niveau du bloc non : Le rappel au niveau de la page se situe entre 75 et 93 % pour les meilleurs modèles. Le rappel au niveau du bloc — savoir quelle cellule de tableau ou région de graphique spécifique justifie une affirmation — chute entre 20 et 61 %. C'est l'écart clé pour l'auditabilité.
• Le raisonnement numérique et l'inférence multi-pages font échouer les modèles en premier : Les questions nécessitant des calculs sur plusieurs pages ou des périodes temporelles sont celles où la précision chute le plus brutalement dans tous les systèmes testés.
• Les modèles propriétaires surpassent considérablement les alternatives open-source : L'écart entre les API fermées et l'open-source est plus important ici que sur la plupart des benchmarks NLP, ce qui suggère que le raisonnement financier visuel reste un défi non résolu pour les modèles ouverts.
• L'auto-évaluation pour les citations est imparfaite : L'évaluateur de citations par recadrage d'image atteint un r de Pearson = 0,68 avec les jugements humains — raisonnable mais pas assez fiable pour s'y fier sans échantillonnage.

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

Le résultat sur la recherche est la conclusion la plus crédible de l'article. Un écart de près de 50 points de pourcentage entre les extracteurs multimodaux et textuels sur plus de 60 000 pages est trop important pour être ignoré. Lorsque vous passez un document financier à l'OCR avant l'indexation, vous détruisez les signaux de mise en page structurelle — dans quelle colonne apparaît un chiffre, si une légende de figure modifie l'interprétation d'un tableau — qui s'avèrent d'une importance cruciale pour la recherche.

Les chiffres de génération sont honnêtes mais difficiles à interpréter isolément. Les auteurs n'analysent pas quelle part de l'écart de précision est attribuable aux erreurs de recherche par rapport aux échecs de génération. Étant donné que le Recall@10 est déjà de 85,86 % pour l'anglais, une fraction significative des échecs doit se situer du côté de la génération plutôt que de la recherche. Connaître cette répartition permettrait de clarifier si le goulot d'étranglement est le raisonnement multimodal ou quelque chose de plus fondamental sur la façon dont les MLLM traitent le langage financier.

L'ensemble d'évaluation de 1 394 paires de questions-réponses est restreint par rapport à la portée du benchmark. Divisées en sept catégories et deux langues, certaines tranches comptent bien moins de 200 exemples. La signification statistique des conclusions au niveau des catégories est laissée implicite. Ce n'est pas inhabituel pour un article de benchmark, mais cela signifie que des comparaisons orientées seraient faciles à construire.

Le protocole d'évaluation des citations est une contribution intéressante, mais un r de Pearson de 0,68 avec les évaluations humaines n'est pas suffisant pour traiter l'auto-évaluation comme une vérité absolue pour l'ancrage au niveau du bloc. Les auteurs le reconnaissent ; des travaux futurs sur de meilleures mesures de citation sont explicitement mentionnés.

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

Beancount fonctionne sur des fichiers de grand livre en texte brut, ce qui rend le RAG textuel défendable pour interroger les transactions passées. Mais la tâche comptable plus large implique des documents qui ne sont résolument pas du texte brut : PDF de relevés bancaires, factures scannées, images de reçus, rapports annuels avec tableaux et graphiques intégrés. Dès qu'un agent Beancount doit rapprocher une écriture comptable d'un document source — vérifier qu'un débit particulier correspond à la facture au dossier — il effectue exactement la tâche que FinRAGBench-V évalue.

Le résultat sur les citations au niveau du bloc est ce qui compte le plus pour ce cas d'utilisation. Si un agent doit justifier une entrée de grand livre en pointant un élément de ligne spécifique dans un PDF, et que le meilleur système disponible n'atteint que 20 à 61 % de rappel au niveau du bloc, ce n'est pas prêt pour l'audit. Tout pipeline Beancount qui traite des documents sources scannés nécessite une révision humaine jusqu'à ce que ce chiffre s'améliore considérablement.

L'écart de modalité de recherche plaide également fortement contre les pipelines purement textuels pour l'ingestion de documents. Une image de reçu porte des informations de mise en page — champs de montant, noms de fournisseurs, positions des articles — que l'OCR détruit. Cette information de mise en page est précisément ce qui distingue un total de ligne d'un montant de taxe, et FinRAGBench-V montre que les extracteurs multimodaux l'exploitent d'une manière que les extracteurs textuels ne peuvent pas.

Ce qu'il faut lire ensuite​

• ColPali: Efficient Document Retrieval with Vision Language Models — le prédécesseur de ColQwen2 qui a établi l'approche de plongement visuel de page sur laquelle repose le meilleur extracteur de FinRAGBench-V [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding — s'attaque au QA visuel multi-documents avec un cadre flexible qui gère le raisonnement visuel simple et multi-sauts à travers les pages [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance — un benchmark compagnon de 2025 évaluant la sensibilité au temps dans le RAG multimodal financier, directement complémentaire à la catégorie de questions sensibles au facteur temps de FinRAGBench-V [arXiv:2503.05185]

L'article​

EnterpriseArena est une simulation d'allocation de ressources au niveau DAF sur 132 mois (11 ans). Chaque étape représente un mois. L'agent reçoit des observations partielles des finances de l'entreprise, des documents commerciaux anonymisés et des signaux macroéconomiques provenant des données de la FRED, du CBOE et de S&P Global. Il dispose d'un budget de 20 appels d'outils par mois répartis sur quatre opérations — vérification de la position de trésorerie, examen des registres financiers, analyse des conditions du marché et projection des flux de trésorerie — et doit choisir l'une des trois actions suivantes : clôturer les comptes (rapprochement), demander un financement (fonds propres ou dette, avec des résultats stochastiques) ou passer son tour. La contrainte principale est que le solde de trésorerie de l'entreprise doit rester positif à chaque étape ; une violation met fin à l'épisode avec un score de zéro. Sous réserve de survie, l'agent maximise la valorisation finale de l'entreprise selon la formule de score Rev_T × 5 + Cash_T − 5 000 × N_outils, qui pénalise explicitement l'utilisation excessive d'outils.

Onze LLM ont été évalués, notamment Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B et Qwen3.5-9B, aux côtés d'une base de référence d'experts humains validée par deux professionnels de la finance ayant respectivement 8 et 14 ans d'expérience.

Idées clés​

• Les taux de survie varient considérablement selon les modèles : Qwen3.5-9B survit à 80 % des tests, Gemini-3.1-Pro à 50 %, Claude-Haiku-4.5 et GLM-5 à 20 % chacun, tandis que GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B et Mixtral-8x7B tombent tous à 0 %. La moyenne globale des LLM est de 26 %.
• Les modèles les plus volumineux ne surpassent pas systématiquement les plus petits : Qwen3.5-9B (9 milliards de paramètres, 80 % de survie, valorisation finale de 78,8 M$) bat de manière décisive Qwen3.5-397B (397 milliards de paramètres, 20 % de survie) et GPT-5.4 (0 % de survie).
• L'écart avec les humains est important : la base de référence humaine atteint 100 % de survie et une valorisation finale de 152,2 M$ ± 29,6 M$ ; la moyenne des LLM est de 28,2 M$ avec 26 % de survie.
• La clôture comptable est le goulot d'étranglement critique : les experts humains clôturent les comptes (rapprochement) lors de 94,3 % des étapes ; les LLM n'atteignent qu'une moyenne de 19,3 %. C'est pourtant cette action qui produit les états financiers réels et permet des décisions ultérieures rationnelles.
• La collecte d'informations sans action est mortelle : Qwen3.5-397B utilise massivement les outils d'analyse de marché et de prévision tout au long de la simulation, mais ne clôture presque jamais les comptes (taux de clôture de 0,0 %) et ne demande presque jamais de financement, mourant d'épuisement de trésorerie malgré sa « connaissance » de la situation.
• La pénalité budgétaire des outils compte : la formule de score punit activement les agents qui vérifient de manière compulsive au lieu d'agir, une contrainte qui reflète le coût d'opportunité réel.

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

La conception à double objectif — la survie comme contrainte stricte couplée à la valorisation finale — est l'un des choix les plus pertinents dans l'évaluation récente des agents. Elle reflète la réalité opérationnelle des directeurs financiers : on ne peut optimiser la croissance si l'on est à court d'argent. L'anonymisation des dates et de l'identité des entreprises empêche les modèles de s'appuyer sur la mémorisation de résultats historiques, ce qui constitue une réelle amélioration méthodologique par rapport aux bancs d'essai financiers utilisant des tickers et des dates réels.

La taxonomie des modes d'échec identifiée par les auteurs via des études de cas est crédible : GPT-5.4 atteint un taux de passage de 99,1 % (ce qui signifie qu'il agit à presque chaque étape en ne faisant rien), tandis que Qwen3.5-397B confond analyse et action. Ce sont des modes d'échec comportemental distincts nécessitant des remèdes différents.

Ce qui me convainc moins : l'environnement macro stochastique utilise un bruit gaussien pour simuler les chocs du marché, ce qui, de l'aveu même des auteurs, ne peut reproduire les événements de type « cygne noir » ou l'irrationalité humaine. Le budget de 20 appels d'outils par mois est également quelque peu arbitraire — les DAF réels ne font pas face à ce genre de contrainte de taux de requête sur leur propre mémoire, ce qui soulève la question de savoir si le test mesure le jugement financier à long terme ou plutôt une forme de RAG sous pression de ressources. La structure à agent unique est une autre limite explicite citée par les auteurs : les DAF réels opèrent au sein de hiérarchies de contrôleurs, d'analystes FP&A et d'équipes de trésorerie, ce que l'article ne tente pas de simuler.

Le constat selon lequel la taille du modèle ne prédit pas la survie est frappant et probablement authentique, mais le mécanisme n'est pas bien expliqué. Les auteurs le notent sans vraiment analyser s'il s'agit d'un échec de suivi des instructions, de cohérence contextuelle à long terme ou de calibration des risques.

Pourquoi c'est important pour l'IA en finance​

L'action de clôture comptable dans EnterpriseArena correspond essentiellement à l'assertion balance de Beancount et à l'étape de rapprochement du grand livre — le moment où l'agent s'engage sur une vision réelle de l'état financier avant d'agir. Le constat que les LLM ignorent cela 80 % du temps renvoie directement au problème de sécurité des écritures : un agent qui évite le rapprochement avant d'agir est un agent qui agit sur un état obsolète ou halluciné. Pour l'automatisation de Beancount, cela suggère que l'étape de rapprochement devrait être obligatoire et vérifiable — et non optionnelle — dans toute boucle d'agent.

L'horizon de 132 mois est également directement analogue à la gestion d'un grand livre sur plusieurs années. Le constat que la conscience situationnelle soutenue se dégrade avec le temps est la même dégradation que l'on attendrait d'un agent Beancount gérant cinq ans d'historique de transactions : même si l'agent dispose de toutes les données en contexte, il peut ne pas agir de manière cohérente au 60e mois. Cela suggère que des points de contrôle de rapprochement forcés et périodiques — et pas seulement des requêtes réactives — sont nécessaires dans les sessions d'agents Beancount à long terme.

Le piège de la collecte d'informations dans lequel tombe Qwen3.5-397B est un avertissement de conception utile : les agents équipés de nombreux outils de recherche peuvent préférer la recherche à l'engagement, surtout lorsque le coût d'une action erronée (corruption du grand livre) est élevé. Des contraintes budgétaires sur les outils comme celles utilisées par EnterpriseArena pourraient aider à imposer une discipline d'action dans les agents d'écriture Beancount.

Pour aller plus loin​

• EcoGym (arXiv:2602.09514) — banc d'essai économique complémentaire à long terme sur des environnements de vente, de freelance et d'exploitation sur plus de 1 000 étapes ; aucun modèle ne domine les trois, ce qui suggère que les modes d'échec d'EnterpriseArena ne sont pas propres à une seule conception de test.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — reformule la conception de flux de travail comme une recherche dans l'espace de code avec MCTS et retour d'information par LLM ; si EnterpriseArena montre que les comportements d'agents conçus manuellement échouent, AFlow est l'étape suivante évidente pour découvrir automatiquement de meilleurs pipelines.
• ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — le cadre fondamental de formation et d'évaluation de l'utilisation d'outils ; comprendre comment le comportement d'appel d'outils est appris dans ToolLLM permet de clarifier si l'échec de l'évitement d'action dans EnterpriseArena est un problème d'entraînement ou de prompting.

L'article​

Peijie Yu, Wei Liu, Yifan Yang et leurs collègues d'Alibaba présentent WildToolBench (arXiv:2604.06185), un benchmark de 256 scénarios de dialogue multi-tours comprenant 1 024 tâches tirées de schémas de comportement d'utilisateurs authentiques et basées sur environ 1 600 API publiques. L'argument central est que les benchmarks existants saturent non pas parce que les modèles sont bons, mais parce que les tâches sont artificielles. Les utilisateurs réels regroupent leurs requêtes, omettent le contexte partagé deux tours plus tôt et passent d'une question sur un outil à une conversation informelle ou à une demande de clarification — parfois au sein d'un seul message. WildToolBench opérationnalise ces modes d'échec en trois catégories de défis structurés et mesure à la fois la précision au niveau de la tâche et la précision beaucoup plus stricte au niveau de la session, qui exige de réussir les quatre tâches d'un dialogue.

Idées clés​

• La précision par session s'effondre à un chiffre pour la plupart des modèles : Gemini-2.0-Flash-Thinking mène avec 14,45 % de précision par session, suivi de Claude-4-Sonnet à 12,50 % et GPT-4o à 11,72 %. Réussir toutes les tâches d'une session de quatre tours est si difficile que même une précision de 60 % par tâche se traduit par moins de 15 % de précision par session — une taxe de probabilité composée sur chaque interaction.
• L'orchestration compositionnelle est le point de rupture le plus net : Les topologies d'outils mixtes (séquentielles et parallèles) limitent les meilleurs modèles à 25 % de précision par tâche, contre 54 à 62 % pour les chaînes purement parallèles ou séquentielles. Lorsqu'une tâche nécessite une dispersion parallèle suivie d'une fusion séquentielle, le problème de coordination dépasse ce que n'importe quel modèle actuel gère de manière fiable.
• L'intention cachée représente un écart plus important que tout ce qui a été mesuré auparavant : WildToolBench garantit que 100 % des tâches impliquent des informations implicites ou transversales aux tours de parole ; BFCL v3 n'en gère que 15,7 %. Les tâches de dépendance à longue portée — où l'information manquante remonte à plus de deux tours — sont le sous-type le plus difficile, aucun modèle ne franchissant la barre des 50 %, même au niveau de la tâche.
• Les transitions d'instructions cumulent les erreurs à un rythme linéaire : Chaque changement de politique supplémentaire (tâche d'outil → chat → clarification → tâche d'outil) fait chuter la précision d'environ 5 à 15 points de pourcentage. À trois transitions, les modèles les plus touchés perdent 30 points. Les auteurs appellent cela l'« auto-conditionnement » : les réponses précédentes biaisent l'interprétation par le modèle des instructions suivantes d'une manière difficile à corriger en milieu de session.
• Le taux de chemin optimal (Optimal Path Rate) reste inférieur à 43 % : Même lorsque les modèles terminent les tâches correctement, ils consomment des appels API excédentaires. Claude-4-Sonnet atteint le meilleur taux de chemin optimal avec 42,74 %, ce qui signifie que la majorité des exécutions correctes prennent plus d'étapes que nécessaire — un coût direct en latence et en jetons pour tout système de production.
• Les modèles spécialisés dans l'utilisation d'outils sous-performent par rapport aux modèles frontières généralistes : xLAM-2-70B et ToolACE2-8B affichent tous deux des taux d'erreur de nom de fonction incorrect dépassant 30 %, soit pire que GPT-4o ou Claude-4-Sonnet. Le réglage fin sur des corpus restreints d'utilisation d'outils semble créer de la fragilité plutôt que de la robustesse face au changement de distribution des comportements réels.

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

La conception du benchmark est solide là où cela compte le plus. La distinction entre précision par tâche et précision par session est tout à fait juste : le cumul des modes d'échec est ce qui tue les déploiements réels, et la plupart des travaux antérieurs rapportent des chiffres au niveau des tâches qui masquent cette réalité. La taxonomie des trois défis (orchestration compositionnelle, intention cachée, transitions d'instructions) est bien motivée et étayée empiriquement — les courbes de dégradation des performances selon les types de défis sont réelles et frappantes.

Le point faible est l'échelle. 1 024 tâches réparties sur 256 scénarios constituent un artefact de recherche crédible, mais c'est peu pour un classement destiné à suivre 57 modèles dans le temps. Les auteurs le reconnaissent directement et mentionnent un pipeline de mise à l'échelle automatisé pour les travaux futurs. L'autre problème est que l'expression « basé sur des journaux d'utilisateurs réels » est lourde de sens : les tâches finales sont partiellement synthétiques, construites par un système multi-agents à partir de modèles de base, puis vérifiées par des annotateurs humains. La revendication est fondée sur le réel, mais les données ne sont pas textuellement brutes — elles sont inspirées du réel. Cela compte pour l'interprétation littérale du plafond de 15 % ; une partie de l'écart pourrait se réduire si le pipeline de génération introduit une difficulté artificielle que les utilisateurs réels ne manifestent pas.

Je suis également sceptique quant à l'analyse des transitions d'instructions en tant qu'affirmation architecturale. L'article l'attribue à une limitation fondamentale, mais l'inadéquation de la distribution d'entraînement entre les objectifs de réglage fin RLHF et les sessions utilisateur multi-modales est l'explication la plus simple. C'est un problème adressable, pas structurel.

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

Les trois modes d'échec correspondent presque parfaitement à la manière dont les utilisateurs réels interagissent avec un agent d'écriture Beancount. Un utilisateur demande : « combien ai-je dépensé en courses le mois dernier, et tant que tu y es, ajoute le reçu Whole Foods d'aujourd'hui » — c'est une tâche compositionnelle regroupée en un seul tour. Il enchaîne avec : « en fait, mets 47,23 $ et non 42 $, j'ai vérifié » — c'est une correction de paramètre exigeant que l'agent suive l'état de la session. Puis il demande : « est-ce que cette catégorie est correcte ? » — c'est une demande de clarification, et l'agent ne doit pas ré-exécuter l'opération d'écriture qu'il vient de terminer. Le plafond de 25 % sur l'orchestration mixte et la chute de 30 points due aux transitions d'instructions sont exactement les modes d'échec qui se manifesteraient chez un agent de grand livre traitant des sessions utilisateur réelles.

Le constat selon lequel les modèles spécialisés sous-performent par rapport aux modèles généralistes est particulièrement pertinent. Si nous envisagions de régler finement un modèle ouvert plus petit sur des exemples d'appels d'outils spécifiques à Beancount — la stratégie évidente de réduction des coûts — WildToolBench est un avertissement direct : la spécialisation peut sacrifier la robustesse face à la distribution des comportements réels des utilisateurs. Le résultat sur le taux de chemin optimal compte aussi : un agent qui utilise deux fois plus d'appels API pour accomplir une tâche n'est pas seulement inefficace ; pour des opérations d'écriture, des appels intermédiaires redondants peuvent laisser le grand livre dans des états intermédiaires incohérents.

Ce qu'il faut lire ensuite​

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — le cadre d'entraînement fondamental contre lequel WildToolBench se positionne explicitement ; comprendre sa conception d'évaluation synthétique clarifie exactement ce que l'exécution en direct apporte.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — le travail antérieur le plus proche sur l'utilisation réaliste d'outils multi-tours ; comparer les domaines de la vente au détail/compagnies aériennes de τ-bench avec la couverture d'API publiques de WildToolBench montre à quel point le défi est généralisable.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — si le problème de transition d'instructions peut être résolu par la découverte automatique de meilleurs flux de travail d'agents plutôt que par l'augmentation des données d'entraînement, AFlow en est le mécanisme le plus crédible.

L'article​

Geng, Cai, Wang, Koeppl, Nakov et Gurevych passent en revue la littérature émergente sur l'estimation de la confiance et la calibration des LLM à travers des tâches allant des questions-réponses à choix multiples à la génération ouverte et à la traduction automatique. Le problème central : les LLM peuvent être à la fois très précis et totalement peu fiables d'une manière difficile à distinguer de l'extérieur. L'étude organise l'espace des solutions en deux branches principales — les méthodes « boîte blanche » qui exploitent l'accès aux états internes du modèle, et les méthodes « boîte noire » qui traitent le modèle comme opaque — et au sein de chacune, distingue l'estimation de la confiance de sa calibration post-hoc.

L'article a été publié à la NAACL 2024 (pages 6577–6595), révisé en mars 2024 à partir d'une soumission de novembre 2023 par une équipe issue de la TU Darmstadt, du MBZUAI et de l'Université d'IA Mohamed bin Zayed.

Idées clés​

• Confiance boîte blanche via les logits : L'approche la plus simple utilise les probabilités au niveau des tokens ou la log-vraisemblance normalisée par la longueur comme signal de confiance. Ces méthodes fonctionnent mais font face à une ambiguïté fondamentale : une faible probabilité de token peut refléter une faible confiance factuelle ou simplement une formulation inhabituelle — le modèle peut être incertain quant au choix des mots tout en étant certain du fait sous-jacent.

• Confiance boîte noire basée sur la cohérence (SelfCheckGPT) : Manakul et al. (EMNLP 2023) échantillonnent plusieurs complétions et évaluent leur cohérence mutuelle à l'aide de BERTScore, NLI ou du chevauchement de n-grammes. Aucun accès aux logits n'est nécessaire. L'idée clé : pour les faits que le LLM connaît bien, les échantillons répétés convergent ; pour les faits hallucinés, ils divergent.

• Entropie sémantique : Farquhar et al. (Nature, 2024) regroupent les réponses sémantiquement équivalentes avant de calculer l'entropie. Un LLM pourrait formuler « Paris » et « la capitale française » différemment — l'entropie brute des tokens traite ces réponses comme divergentes, contrairement à l'entropie sémantique. C'est une avancée qualitative par rapport à la cohérence au niveau des tokens que l'étude contextualise.

• La confiance verbalisée est défaillante : Lorsqu'on leur demande de fournir un pourcentage de confiance, les modèles sombrent dans l'excès de confiance. Des travaux empiriques (Groot et al., TrustNLP à l'ACL 2024) révèlent que GPT-3, GPT-3.5 et Vicuna affichent tous une erreur de calibration attendue (ECE) moyenne dépassant 0,377 pour la confiance verbalisée, avec des prédictions se regroupant dans la plage 90–100 % quelle que soit la précision réelle. Même GPT-4 — le modèle le mieux calibré évalué — n'atteint qu'un AUROC d'environ 62,7 % lorsqu'il utilise la confiance verbalisée pour discriminer les réponses correctes des incorrectes, soit à peine plus que le hasard.

• Les techniques de calibration varient selon la tâche : Pour la classification, la calibration contextuelle (soustraction du biais a priori de classe estimé avec une invite vide « [N/A] ») et le débiaisage de position (PriDE) traitent les biais systématiques connus. Pour la génération, la calibration de la vraisemblance de séquence (SLiC) affine les modèles sur des complétions classées. Le lissage par température — le correctif post-hoc le plus simple — reste compétitif dans de nombreux contextes.

• Aucun benchmark unifié n'existe : L'observation structurelle la plus accablante de l'étude est l'absence d'un benchmark unique couvrant les méthodes d'estimation de la confiance à travers les tâches et les domaines. Cela rend presque impossible la comparaison rigoureuse des méthodes. Le domaine évalue des pommes par rapport à des oranges.

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

La taxonomie est solide. La distinction boîte blanche vs boîte noire est réellement utile pour la conception de systèmes, et le traitement des méthodes basées sur les logits est honnête quant à leurs limites — les auteurs notent directement que la probabilité des tokens confond la confiance factuelle avec l'incertitude lexicale. Les praticiens sous-estiment cette confusion.

Là où l'étude me frustre : elle est largement descriptive. Il n'y a presque aucun benchmark expérimental comparant les méthodes en face à face, et les auteurs reconnaissent explicitement cela comme une limite. Je repars avec une carte claire de l'espace de conception, mais sans guide sur la méthode à utiliser pour une nouvelle tâche.

Les résultats sur la confiance verbalisée — l'AUROC de GPT-4 d'environ 62,7 % sur sa propre confiance déclarée — devraient être une connaissance canonique pour quiconque déploie des LLM en production. Ce n'est pas le cas. Des gens déploient encore des invites demandant « sur une échelle de 1 à 10, quel est votre niveau de confiance ? » et traitent la réponse comme significative. Elle ne l'est pas.

L'étude est également légère sur la question de la calibration par RLHF : l'entraînement post-entraînement avec feedback humain rend-il les modèles mieux ou moins bien calibrés ? Il existe des preuves dans les deux sens, et l'étude les élude largement.

Pourquoi cela compte pour l'IA en finance​

ReDAct fonde sa sécurité sur la possession d'un signal d'incertitude calibré provenant du modèle bon marché. L'étude montre clairement à quel point c'est difficile en réalité. Les signaux basés sur les logits sont disponibles dans les environnements en boîte blanche mais confondent incertitude lexicale et factuelle. Les méthodes basées sur la cohérence fonctionnent en boîte noire mais nécessitent plusieurs échantillons par décision — ce qui est coûteux pour un agent d'écriture Beancount à haut débit traitant un lot d'écritures de transactions.

La conclusion la plus exploitable pour Bean Labs : l'entropie sémantique regroupe les réponses sémantiquement équivalentes avant d'évaluer la cohérence, ce qui est précisément ce qui importe pour les écritures comptables où un modèle pourrait exprimer la même relation débit/crédit sous plusieurs formes syntaxiquement distinctes. Un agent Beancount devrait utiliser le regroupement sémantique sur des complétions d'écritures comptables échantillonnées — et non la variance brute au niveau des tokens — pour détecter quand il hallucine un nom de compte ou un montant.

L'échec de la calibration de la confiance verbalisée est un avertissement direct pour toute interface utilisateur qui affiche « quel est le niveau de confiance de l'IA ? » à l'utilisateur : ne faites pas confiance au chiffre produit par le modèle. Utilisez plutôt un calibrateur externe ou une méthode basée sur la cohérence, ou ne l'affichez pas du tout.

Que lire ensuite​

• Farquhar et al., « Detecting hallucinations in large language models using semantic entropy », Nature, 2024 — la méthode la plus rigoureuse issue de ce cadre d'étude ; mérite d'être lue en entier plutôt qu'à travers le résumé de l'étude.
• Manakul et al., « SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models », EMNLP 2023 (arXiv:2303.08896) — la méthode canonique basée sur la cohérence ; essentielle à comprendre avant de déployer tout signal de confiance en boîte noire.
• Groot et al., « Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models », TrustNLP à l'ACL 2024 (arXiv:2405.02917) — l'audit empirique le plus approfondi sur la façon dont la confiance verbalisée échoue selon les modèles et les tâches.

L'article​

Saibo Geng, Hudson Cooper, Michał Moskal et leurs collègues de Microsoft Research présentent JSONSchemaBench, un benchmark de 9 558 schémas issus de sources de production réelles : signatures d'appels de fonctions GlaiveAI, dépôts GitHub stratifiés par complexité de triviale à ultra, configurations d'API Kubernetes, schémas d'analyse d'événements Snowplow et la collection JSONSchemaStore. Ils évaluent six frameworks de décodage contraint — Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs et Gemini — selon trois axes : la couverture (quelle fraction de schémas le framework peut traiter), l'efficacité (surcharge de jetons par seconde par rapport à la génération non contrainte) et la qualité (précision de la tâche en aval). La grille d'évaluation inclut également la suite de tests officielle JSON Schema, qui documente 45 catégories de fonctionnalités que tout moteur conforme devrait supporter.

L'affirmation centrale est que la complexité du schéma est la variable décisive qui sépare les frameworks performants des frameworks fragiles, et qu'aucun framework ne domine sur les trois axes.

Idées clés​

• La couverture s'effondre sous la complexité des schémas. Sur les schémas simples de GlaiveAI, tous les frameworks obtiennent un score supérieur à 86 %. Mais sur les schémas GitHub-Hard — imbrication à plusieurs niveaux, définitions récursives, contraintes de motifs complexes — Guidance chute à 41 %, Llamacpp à 39 %, XGrammar à 28 % et Outlines à un catastrophique 3 %. OpenAI n'atteint que 9 % sur GitHub-Hard, et Gemini ne produit aucune sortie valide sur les schémas de complexité moyenne ou supérieure.
• Kubernetes expose une faiblesse spécifique dans XGrammar. Malgré les promesses de vitesse de XGrammar, il n'atteint que 7 % de couverture sur les schémas Kubernetes, probablement parce que ces schémas reposent sur des motifs dépendants du contexte que le pré-calcul indépendant du contexte de XGrammar ne peut pas gérer. La couverture face à un benchmark incluant des configurations Kubernetes n'est pas optionnelle pour les agents en production.
• Le manque de contraintes est plus dangereux qu'un échec de compilation. XGrammar présente 38 échecs de sous-contrainte par rapport à la suite de tests JSON Schema — ce qui signifie qu'il émet du JSON qui viole le schéma déclaré tout en signalant silencieusement un succès. Guidance n'a qu'un seul échec de ce type. Pour un agent d'écriture, une erreur de compilation est détectée au moment de la conception ; une défaillance par sous-contrainte corrompt les données au moment de l'exécution sans aucun signal.
• L'avance rapide de Guidance offre un gain de vitesse réel de 50 %. Lorsque de longues séquences déterministes sont présentes (par exemple, des noms de champs dans une structure d'objet fixe), Guidance peut avancer de plusieurs jetons par étape de décodage. Sur Llama-3.1-8B sur un A100, Guidance tourne à 6–9 ms par jeton de sortie, tandis que la génération non contrainte tourne à 15–16 ms. Outlines est plus lent que la génération non contrainte avec 30–46 ms, principalement en raison de la compilation de son automate qui prend 3 à 8 secondes par schéma.
• Le décodage contraint améliore modestement la précision du raisonnement. Sur GSM8K (mathématiques), Guidance augmente la précision de 80,1 % (non contraint) à 83,8 %. Sur Last Letter et Shuffle Objects, les gains sont de l'ordre de 1 à 3 points. Cela contredit l'inquiétude largement citée selon laquelle forcer le format JSON dégraderait la qualité des réponses — mais la taille de l'effet est suffisamment faible pour que le choix du format ne soit pas le moteur de la sélection du framework.
• Aucun framework ne couvre les 45 catégories de fonctionnalités de JSON Schema. Guidance en couvre 13, Llamacpp et XGrammar en couvrent 1 chacun, et Outlines 0. L'implication pratique est que tout schéma utilisant if/then/else, unevaluatedProperties ou des définitions $ref récursives se comportera de manière imprévisible selon le moteur utilisé.

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

La contribution la plus forte du benchmark est le sourcing des schémas. Les évaluations précédentes utilisaient des schémas simplistes ou des collections provenant d'une seule source. Inclure des configurations Kubernetes aux côtés de signatures d'appels de fonctions est le bon type de diversité adverse. La stratification de la complexité (de triviale à ultra) donne également aux praticiens une courbe d'étalonnage : si vos schémas ressemblent à des appels de fonctions GlaiveAI, XGrammar ou Guidance conviennent tous les deux ; s'ils ressemblent à des manifestes Kubernetes, vos options se réduisent rapidement.

La principale faiblesse est l'évaluation gloutonne sur un seul échantillon. Mesurer la couverture avec une seule génération par schéma sous-estime la capacité réelle — un framework peut échouer 20 % du temps mais réussir lors d'une nouvelle tentative. L'article le reconnaît mais ne rapporte pas les chiffres de pass@k échantillonnés avec température, ce qui importerait pour les systèmes de production qui réessayent en cas d'échec.

La comparaison mélange également des modèles incomparables. Les frameworks open-source (Guidance, Outlines, Llamacpp, XGrammar) sont testés sur Llama-3.2-1B, tandis qu'OpenAI et Gemini utilisent leurs propres modèles non divulgués. La couverture de 9 % d'OpenAI sur GitHub-Hard peut refléter la capacité du modèle autant que l'architecture de décodage contraint. Une comparaison équitable nécessiterait un accès contrôlé aux modèles — ce que les auteurs ne peuvent évidemment pas imposer aux fournisseurs propriétaires.

Pourquoi cela compte pour l'IA financière​

Chaque agent d'écriture Beancount génère une sortie structurée. Si l'agent émet des directives Beancount sous forme de JSON avant de les convertir en syntaxe .beancount, ou s'il appelle des outils via des schémas JSON, la fiabilité de cette génération JSON n'est pas un détail — c'est l'enjeu principal. L'article FinTrace a montré que les modèles de pointe échouent à raisonner sur les sorties d'outils ; JSONSchemaBench révèle un problème orthogonal : même avant le raisonnement, la couche de formatage peut émettre silencieusement une sortie non conforme.

Le résultat sur Kubernetes est particulièrement révélateur pour Beancount. Les schémas de grand livre ne sont pas de simples sacs de clés-valeurs plats. Les hiérarchies de comptes, les métadonnées de transaction et les structures de balises créent des motifs récursifs imbriqués similaires aux objets de l'API Kubernetes. Un framework qui obtient un score de 7 % sur Kubernetes n'est pas prêt pour des schémas de grand livre complexes, quelle que soit la vitesse de sa surcharge par jeton.

Le mode de défaillance par sous-contrainte est celui qui m'empêcherait de dormir. Un agent Beancount utilisant XGrammar pourrait émettre une transaction qui passe la vérification de validation interne du framework mais viole le schéma réel — et l'agent n'aurait aucune raison de réessayer. La corruption silencieuse est pire qu'un échec visible.

Que lire ensuite​

• XGrammar (arXiv:2411.15100, Dong et al.) — l'article technique derrière l'un des frameworks les plus rapides testés, expliquant la séparation des jetons indépendants/dépendants du contexte et pourquoi les schémas Kubernetes le mettent à l'épreuve.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — montre que le masquage de jetons dans le décodage contraint peut fausser la distribution de probabilité du modèle et propose un algorithme d'échantillonnage corrigé ; le fondement théorique des préoccupations de qualité que le benchmark ne mesure qu'indirectement.
• XGrammar-2 (arXiv:2601.04426) — une suite qui étend XGrammar aux schémas dynamiques dans des contextes d'agents où le schéma lui-même change au cours d'une session multi-tours, directement pertinent pour les agents Beancount qui adaptent leur format de sortie en fonction des types de comptes actifs.

L'article​

Jie Zhu, Yimin Tian et leurs collègues de l'équipe Qwen DianJin d'Alibaba Cloud, de YINGMI Wealth Management et de l'Université de Soochow présentent FinMCP-Bench, une suite d'évaluation de 613 échantillons couvrant 10 catégories de scénarios financiers et 33 sous-scénarios. Les outils ne sont pas simulés — 65 serveurs d'outils financiers réels compatibles MCP soutiennent le benchmark, tirés des journaux de production réels de l'assistant financier Qieman APP. Les auteurs classent les échantillons en trois types : 145 à outil unique, 249 multi-outils et 219 multi-tours. Ils testent six modèles : la famille Qwen3 avec des nombres de paramètres de 4B, 30B et 235B (tous avec pensée étendue), ainsi que DeepSeek-R1, GPT-OSS-20B et Seed-OSS-36B. Les principales mesures d'évaluation sont la Précision de l'Outil, le Rappel de l'Outil, le F1 de l'Outil et un Taux de Correspondance Exacte (EMR) qui exige que chaque appel d'outil dans une séquence soit exactement correct.

Idées clés​

• MCP comme substrat d'évaluation : l'utilisation de définitions de serveurs MCP réels plutôt que de schémas d'API synthétiques comble un fossé majeur entre l'évaluation de référence et ce à quoi les agents sont réellement confrontés dans les systèmes financiers déployés.
• Division de la difficulté en trois volets : les échantillons à outil unique, multi-outils et multi-tours ne présentent pas seulement des différences de quantité — ils exposent des modes d'échec qualitativement différents.
• Effondrement multi-tours : le meilleur modèle (Qwen3-235B) atteint 60 % d'EMR sur l'outil unique, 10,62 % d'EMR sur le multi-outils et 3,08 % d'EMR sur le multi-tours. La chute entre l'outil unique et le multi-tours est de 20×.
• Le F1 de l'outil est plus indulgent : le même modèle obtient des scores de 66,85 %, 69,42 % et 41,56 % de TF1 sur les trois paramètres — montrant que les modèles choisissent souvent les bons outils mais échouent sur l'ordre, le paramétrage ou le suivi de la conversation.
• Le rappel bat la précision pour l'outil unique : les modèles ont tendance à appeler trop d'outils en cas d'incertitude plutôt que pas assez, ce qui est le mode d'échec le plus sûr pour les tâches financières mais signifie tout de même des appels API gaspillés et du bruit dans la trace de raisonnement.
• Mise à l'échelle non monotone de la taille : Qwen3-30B ne surpasse pas systématiquement Qwen3-4B dans tous les sous-scénarios, brisant l'hypothèse selon laquelle le plus grand gagne toujours pour l'utilisation d'outils en plusieurs étapes.

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

L'utilisation de journaux de production réels comme source pour les exemples à outil unique est le choix méthodologique le plus fort ici. Cela ancre le benchmark dans le comportement réel des utilisateurs plutôt que dans des scénarios inventés par des chercheurs, ce qui est rare dans la littérature sur l'IA financière. Les échantillons multi-outils et multi-tours sont étendus de manière synthétique à l'aide de graphes de dépendance et de prompts de jeux de rôle, ce qui est raisonnable compte tenu du coût d'étiquetage, mais cela introduit un risque : le processus de synthèse a tendance à produire des requêtes plus propres et plus explicites que celles écrites par de vrais utilisateurs. L'EMR de 3,08 % sur le multi-tours est alarmant mais doit être interprété avec prudence — l'EMR exige que la séquence complète soit exactement correcte, donc un seul appel d'outil intermédiaire erroné fait échouer toute la tâche. C'est une norme de production stricte et sans doute irréaliste ; les mesures de crédit partiel comme le TF1 racontent une histoire plus nuancée.

Ce que l'article n'aborde pas : il n'y a aucune analyse pour savoir si l'écart de performance est principalement un problème de compréhension de l'entrée (le modèle interprète mal ce que l'utilisateur veut), un problème de formatage de la sortie (intention correcte mais appel d'outil mal formé) ou un problème de raisonnement (conclusions intermédiaires erronées). Sans cette décomposition, il est difficile de savoir où investir les efforts d'ingénierie. L'article évalue également les modèles de manière isolée ; il n'y a aucun test pour savoir si l'ajout d'une étape de vérification ou de réflexion modifie le tableau du multi-tours.

Le benchmark est également profondément lié aux 65 outils spécifiques de Qieman, ce qui limite la transférabilité des résultats à d'autres plateformes financières disposant d'inventaires d'outils différents.

Pourquoi cela compte pour l'IA financière​

FinMCP-Bench est l'évaluation publiée la plus proche de ce qu'un agent d'écriture Beancount ferait réellement : recevoir une demande d'utilisateur, identifier quel outil (ou chaîne d'outils) s'applique, les invoquer dans l'ordre et gérer les tours de suivi. L'EMR multi-tours de 3,08 % est un dur rappel à la réalité. Un agent Beancount qui gère une correction de grand livre en plusieurs étapes — par exemple, reclasser un ensemble de transactions entre des comptes sur une période donnée, puis rapprocher, puis générer un rapport — est exactement le genre de tâche multi-tours et multi-outils pour laquelle les modèles actuels échouent presque universellement selon les normes de correspondance exacte.

Le cadrage MCP est directement pertinent : l'API Python de Beancount, l'interface beanquery et la couche REST de fava pourraient toutes être encapsulées sous forme de serveurs MCP. FinMCP-Bench nous apprend que le protocole n'est pas le goulot d'étranglement — le raisonnement sur les séquences d'appels d'outils l'est.

La conclusion selon laquelle le rappel d'outil dépasse la précision (les modèles appellent trop d'outils) compte également pour la sécurité des écritures : un agent qui appelle l'outil de mutation du grand livre alors qu'une simple lecture était nécessaire pourrait corrompre le grand livre silencieusement. Les mesures d'évaluation axées sur la précision, et non sur le rappel, devraient être le principal signal de sécurité pour les agents d'écriture.

Que lire ensuite​

• JSONSchemaBench (arXiv:2501.10868) — évalue la fiabilité de la sortie structurée sur 10 000 schémas JSON ; aborde directement la question de savoir si les échecs de formatage d'appel d'outil dans FinMCP-Bench sont un problème de décodage contraint.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — le cadre de formation à l'utilisation d'outils fondateur par rapport auquel FinMCP-Bench se positionne ; comprendre son exploration de l'arbre de recherche en profondeur clarifie ce que la méthodologie des journaux de production de FinMCP-Bench apporte.
• WildToolBench (arXiv:2604.06185) — évalue l'utilisation d'outils sur des requêtes d'utilisateurs réels dans la nature ; sa conclusion selon laquelle aucun modèle ne dépasse 15 % de précision sur le comportement des utilisateurs sauvages complète l'approche par journaux de production de FinMCP-Bench.

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.

L'article​

Jiaxuan Lu et ses collègues présentent FinToolBench (arXiv:2603.08262, mars 2026) comme ce qu'ils affirment être le premier benchmark exécutable en conditions réelles pour évaluer les agents d'apprentissage d'outils financiers. Le cadre est direct : les évaluations actuelles de l'IA financière se concentrent sur des questions-réponses statiques sur des documents, tandis que les benchmarks généraux d'utilisation d'outils comme ToolLLM traitent la finance comme une simple catégorie d'API supplémentaire sans contraintes de conformité spécifiques au domaine. FinToolBench tente de combler l'espace entre ces deux modes d'échec.

Le benchmark associe 760 outils financiers exécutables — 261 points de terminaison en direct de RapidAPI et 499 interfaces d'AkShare — à 295 requêtes d'évaluation rigoureusement sélectionnées, réparties en 166 cas à outil unique et 129 cas multi-outils. Les outils couvrent les domaines des actions, des obligations, des fonds, du forex, des dérivés, de la macroéconomie et de la crypto. Surtout, il s'agit d'API réelles et appelables, et non de simulations (stubs). Les auteurs introduisent également FATR (Finance-Aware Tool Routing), un agent de référence utilisant la récupération BGE-M3 (20 meilleurs candidats), des fiches d'outils annotées avec des attributs financiers et un planificateur ReAct respectueux des contraintes limité à cinq étapes.

Idées clés​

• L'exécution n'est pas le goulot d'étranglement — le raisonnement sur les sorties l'est. GPT-4o possède le score logiciel conditionnel le plus élevé (CSS = 0,670), ce qui signifie qu'il donne des réponses correctes lorsqu'il réussit à appeler un outil, mais il n'invoque les outils que 22,7 % du temps (TIR = 0,227). Qwen3-8B appelle les outils 87,1 % du temps mais n'obtient la bonne réponse que 40,4 % du temps lorsqu'il réussit.
• L'inadéquation de l'intention est le principal échec de conformité. L'IMR (Intent Mismatch Rate) dépasse 50 % pour la plupart des modèles, ce qui signifie que les agents émettent régulièrement des appels à intention transactionnelle alors que la requête ne demande qu'une recherche d'information. C'est un problème sérieux dans les contextes financiers réglementés.
• L'injection d'attributs financiers aide à la conformité sans nuire aux capacités. Les fiches d'outils du modèle FATR — annotant chaque outil avec la fraîcheur des données, le type d'intention et le domaine réglementaire — réduisent les appels de données obsolètes (TMR) et les violations de domaine (DMR) sans dégrader significativement le taux d'invocation.
• Les requêtes multi-outils exposent l'écart de fiabilité. Les 129 requêtes multi-outils nécessitent d'enchaîner les appels et de transmettre les sorties entre les étapes ; les performances chutent considérablement par rapport aux cas à outil unique, ce qui est cohérent avec les conclusions de FinTrace et TheAgentCompany.
• Les petits modèles peuvent surpasser les grands en invocation, mais pas en raisonnement. Le TIR de 0,871 de Qwen3-8B contre 0,227 pour GPT-4o montre que les petits modèles ont la "gâchette plus facile", mais le CER (taux d'exécution conditionnel, c'est-à-dire TESR/TIR) de 0,339 pour Qwen3-8B contre 0,618 pour GPT-4o révèle que GPT-4o est bien plus précis lorsqu'il décide effectivement d'appeler un outil.

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

Le choix du benchmark d'utiliser des API réellement opérationnelles et exécutables est sa contribution principale, et elle est réelle. Les API simulées ont été le secret honteux des benchmarks d'utilisation d'outils : les 16 000 API de ToolLLM semblent impressionnantes jusqu'à ce que l'on réalise que l'évaluation utilise un LLM comme juge pour déterminer si un appel "aurait" fonctionné. FinToolBench évite cela.

Les mesures de conformité (TMR, IMR, DMR) sont conceptuellement justes — les agents financiers doivent faire la différence entre récupérer le cours de clôture d'hier et initier une transaction — mais la description de l'article sur la manière dont ces classifications sont appliquées est succincte. Il n'est pas clair si les étiquettes de référence pour le type d'intention (informationnel vs transactionnel) ont été vérifiées par des experts juridiques ou de conformité, ou simplement assignées par les auteurs de l'ensemble de données. Cela compte énormément dans la pratique.

La liste des modèles est également curieusement restreinte : Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash et GPT-4o. Pas de Claude Sonnet ou de Gemini 2.5, qui auraient été des comparaisons naturelles. Le tableau des résultats montre que GPT-4o est une exception de précision mais à faible couverture ; j'aimerais savoir si le comportement d'utilisation d'outils de Claude se rapproche du modèle conservateur de GPT-4o ou de celui agressif de Qwen3-8B.

L'ensemble d'évaluation de 295 requêtes est petit selon les standards des benchmarks modernes. Avec 760 outils, un taux de couverture de 295 requêtes signifie que la plupart des outils ne sont jamais testés. L'article ne rapporte pas de statistiques de couverture par domaine, ce qui signifie que les chiffres globaux pourraient être tirés par un sous-ensemble de domaines bien couverts comme les actions et la macroéconomie.

Pourquoi cela compte pour l'IA financière​

Les agents d'écriture Beancount — tout agent qui appelle bean-add, modifie un fichier de grand livre ou interroge beanquery — sont confrontés exactement aux modes d'échec révélés par FinToolBench. Le problème de l'inadéquation de l'intention se traduit directement : un agent Beancount qui émet un appel d'écriture alors que l'utilisateur a posé une question de lecture présente la même signature d'échec qu'une violation d'IMR. La dimension de fraîcheur des données correspond au problème de l'appel d'un état de grand livre mis en cache et obsolète alors que l'utilisateur attend le solde actuel.

La tension entre précision et couverture (GPT-4o vs Qwen3-8B) est également directement pertinente. Pour l'écriture Beancount, je préférerais de loin le comportement d'appel conservateur de GPT-4o — faible TIR mais CER et CSS élevés — à un modèle à forte invocation qui exécute fréquemment le mauvais outil. Les écritures erronées sont bien plus coûteuses que l'absence d'action.

L'approche FATR consistant à annoter les outils avec des attributs de conformité plutôt que de compter sur le modèle pour les déduire est un modèle de conception qui vaut la peine d'être adopté. Envelopper les outils CLI Beancount avec des métadonnées explicites indiquant si un appel est en lecture seule ou s'il modifie les données, et s'il touche à l'état actuel ou archivé du grand livre, est la même idée appliquée à une échelle plus réduite.

Que lire ensuite​

• FinTrace (arXiv:2604.10015) — évaluation au niveau de la trajectoire sur 34 catégories de tâches financières avec 9 mesures ; étend directement l'évaluation à appel unique de FinToolBench à des séquences multi-étapes, et affine Qwen-3.5-9B avec DPO pour améliorer le raisonnement intermédiaire.
• FinMCP-Bench (arXiv:2603.24943) — 613 échantillons sur 65 outils financiers basés sur MCP testant l'invocation à outil unique, multi-outils et multi-tours ; le cadre MCP est directement pertinent pour les interfaces d'outils Beancount.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — l'article ToolBench par rapport auquel FinToolBench se positionne explicitement ; comprendre ce que le benchmark de référence à API simulées peut et ne peut pas mesurer clarifie ce que l'exécutabilité de FinToolBench apporte réellement.

L'article​

OmniEval construit une grille d'évaluation bidimensionnelle : cinq classes de tâches (QA extractive, raisonnement multi-sauts, QA de contraste, QA longue forme et QA conversationnel) croisées avec 16 sujets financiers (marchés boursiers, banque d'investissement, fonds, assurance immobilière, et autres). Le résultat est un benchmark structuré comprenant 11,4k exemples de test générés automatiquement, 1,7k exemples annotés par l'homme et un corpus de récupération de 362k documents assemblé à partir de six sources de données financières chinoises (BSCF-DB à 193k documents, FinGLM à 55k, BAAI-Fin à 48k, des crawls web officiels, des PDF et du contenu financier de Wikipédia). Le benchmark inclut également un évaluateur LLM affiné — Qwen2.5-7B-Instruct entraîné sur 910 instances étiquetées par l'homme — qui évalue la qualité de la génération selon la précision, l'hallucination, l'exhaustivité, l'utilisation et la précision numérique. L'article a été publié à l'EMNLP 2025.

Idées clés​

• Les cas de test générés automatiquement ont passé un contrôle d'acceptation humain à 87,47 %, ce qui signifie qu'environ 1 instance générée sur 8 a été rejetée — un taux de bruit non négligeable pour un benchmark.
• Le meilleur moteur de récupération (GTE-Qwen2-1.5B) a atteint un MAP de 0,4370 et un MRR de 0,4491 sur l'ensemble auto-généré, ce qui signifie que le passage le mieux classé est correct moins de la moitié du temps, même avec le meilleur récupérateur testé.
• La précision de la génération (ACC) à travers toutes les combinaisons récupérateur-LLM variait de 0,3238 à 0,4476 — la meilleure configuration répond correctement à moins de la moitié des questions.
• La précision numérique (NAC) est la conclusion la plus marquante : de 0,0659 à 0,3595. Le meilleur système donne les bons chiffres financiers environ 36 % du temps ; le pire est proche de zéro.
• L'évaluateur affiné a atteint un accord de 74,4 % avec l'annotation humaine (κ = 0,6486), surpassant nettement les références basées uniquement sur le prompt (55–71 %) — mais laissant toujours une évaluation sur quatre en décalage avec le jugement humain.
• Le raisonnement multi-sauts et le QA conversationnel ont été systématiquement les classes de tâches les plus difficiles.

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

La conception de l'évaluation par matrice est réellement utile. Les benchmarks financiers précédents (FinanceBench, FinQA, DocFinQA) traitent l'évaluation sur un seul axe — généralement la précision des réponses — et manquent la variation structurelle de la façon dont le RAG échoue. Savoir qu'un système obtient de bons résultats en QA extractive mais de mauvais résultats en raisonnement multi-sauts est exploitable ; savoir qu'il obtient une note moyenne globale ne l'est pas. La grille OmniEval rend cette variation visible, et la conclusion selon laquelle les performances sont incohérentes selon les sujets est exactement le type de résultat que les praticiens doivent voir avant tout déploiement.

Cela dit, il y a des limites réelles que je tiens à souligner. Le corpus est majoritairement chinois : cinq des six sources de données sont des données financières chinoises (BSCF, FinGLM, BAAI-Fin), et la sixième est le Wikipédia chinois. L'article ne présente pas les résultats ventilés par langue — il ne rapporte que des chiffres agrégés. Cela rend chaque score suspect en tant qu'affirmation sur le RAG financier en général, par opposition au RAG financier sur des textes chinois avec des récupérateurs et des LLM spécialisés pour le chinois (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Les utilisateurs financiers anglophones ou francophones ne peuvent pas utiliser directement ces chiffres.

L'évaluateur LLM est entraîné sur 910 instances étiquetées. C'est peu. L'accord humain de 74,4 % à κ = 0,6486 est défendable comme point de départ mais signifie que le cadre d'évaluation lui-même introduit un bruit substantiel. Si le benchmark est utilisé pour comparer des systèmes qui diffèrent de quelques points de pourcentage, la variance de l'évaluateur submergera le signal.

Le pipeline de génération automatique — GPT-4 produit les questions de test, les humains filtrent avec 87,47 % d'acceptation — soulève également une question de contamination que l'article n'aborde pas : les questions générées par GPT-4 pourraient favoriser les modèles de la classe GPT-4 d'une manière qui désavantage systématiquement les modèles plus anciens ou plus petits.

Pourquoi c'est important pour l'IA en finance​

Les scores de précision numérique sont les chiffres sur lesquels je reviens sans cesse : 0,0659–0,3595. Si le meilleur système RAG testé ne donne les chiffres financiers corrects que 36 % du temps dans une évaluation de référence, tout agent d'écriture Beancount construit sur un pipeline RAG naïf va corrompre les données du registre. Le format de Beancount est impitoyable — un montant, une date ou un nom de compte incorrect produit soit une erreur d'analyse, soit une erreur comptable silencieuse qui peut se propager sur plusieurs exercices fiscaux. Ce benchmark nous donne la preuve concrète que la récupération RAG et la génération LLM ne sont pas encore assez fiables pour une écriture directe dans le registre sans une couche de validation.

La structure des classes de tâches correspond également parfaitement aux cas d'utilisation de Beancount. Le QA extractif correspond aux simples consultations de solde. Le raisonnement multi-sauts correspond à des questions telles que « quel est mon revenu net après impôts sur les trimestres T1 à T3 ? ». Le QA conversationnel correspond à un utilisateur affinant itérativement une demande de rapprochement au cours d'une session. Le constat d'OmniEval selon lequel les tâches multi-sauts et conversationnelles sont les plus difficiles est exactement la mauvaise nouvelle pour la conception d'un agent Beancount : les cas simples s'en sortent presque ; les cas réalistes sont ceux où le système s'effondre.

Que lire ensuite​

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — l'analogue le plus proche en domaine général de l'approche d'affinage de l'évaluateur d'OmniEval ; comparer la méthodologie ARES à celle d'OmniEval permettrait de clarifier si les choix de conception de l'évaluateur LLM sont fondés sur des principes ou ad hoc.
• RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) — génération automatisée de scénarios pour l'évaluation RAG ; étend la méthodologie d'auto-génération utilisée par OmniEval et pourrait répondre aux préoccupations concernant la contamination.
• FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) — étend l'évaluation RAG aux documents financiers multimodaux (tableaux, graphiques) ; pertinent alors que les utilisateurs de Beancount disposent de plus en plus d'images de reçus et de relevés PDF aux côtés de registres en texte brut.

L'article​

L'étude de Xu et Ding (arXiv:2409.01980) propose d'organiser la détection d'anomalies et de données hors distribution (OOD) basées sur les LLM en deux classes de haut niveau : les LLM pour la détection, où le modèle identifie directement les anomalies, et les LLM pour la génération, où le modèle augmente les données d'entraînement ou produit des explications en langage naturel qui alimentent un détecteur en aval. Chaque classe se subdivise davantage. La détection se divise en méthodes basées sur le prompting (LLM figés ou ajustés interrogés avec des invites en langage naturel) et en méthodes basées sur le contraste (modèles de la famille CLIP qui évaluent le caractère anormal en comparant des patchs d'image à des descriptions textuelles). La génération se divise en méthodes centrées sur l'augmentation (génération de pseudo-labels OOD ou d'échantillons minoritaires synthétiques) et en méthodes centrées sur l'explication (production de justifications en langage naturel pour les événements signalés).

La liste de lecture GitHub associée couvre environ 39 articles : 24 sur la détection, 10 sur l'augmentation et 5 sur l'explication.

Idées clés​

• Les méthodes basées sur le contraste dominent la détection d'anomalies d'image. WinCLIP atteint un AUROC de 91,8 % et 85,1 % sur la classification et la segmentation d'anomalies zero-shot sur MVTec-AD sans aucun réglage spécifique au jeu de données, ce qui est compétitif avec les méthodes supervisées entraînées sur ce même jeu de données.
• Les LLM figés se heurtent à un fossé de modalité pour les données non textuelles. L'étude note explicitement que « solliciter directement des LLM figés pour obtenir des résultats de détection d'anomalies ou d'OOD sur divers types de données donne souvent des performances sous-optimales en raison du fossé de modalité inhérent entre le texte et les autres modalités de données ».
• Le LoRA et le réglage par adaptateurs comblent une grande partie de ce fossé. Des méthodes comme AnomalyGPT et AnomalyCLIP utilisent des techniques d'ajustement à efficacité paramétrique et surpassent considérablement leurs homologues figés.
• La génération comme augmentation est sous-utilisée. Les pseudo-labels OOD au niveau de la légende générés par BLIP-2 surpassent les alternatives au niveau du mot ou de la description dans la détection d'OOD, ce qui suggère qu'une supervision textuelle plus riche est importante, même pour les tâches visuelles.
• La génération centrée sur l'explication est la sous-catégorie la plus récente. Des systèmes comme Holmes-VAD et VAD-LLaMA vont au-delà des indicateurs binaires pour générer des justifications en langage naturel pour les événements anormaux, principalement dans la vidéo-surveillance.
• Les données tabulaires sont presque absentes. L'étude cite une seule méthode — « Tabular » de Li et al. (2024) — qui convertit les lignes tabulaires en invites textuelles et les ajuste avec LoRA, mais ne fournit aucun chiffre comparatif.

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

La taxonomie à deux classes est véritablement propre et je l'utiliserai probablement pour organiser ma propre réflexion. La distinction détection-vs-génération capture une réelle bifurcation architecturale : soit vous demandez au LLM de classifier directement, soit vous l'utilisez pour construire un meilleur signal d'entraînement pour un détecteur traditionnel.

Ce que je ne peux pas accepter, c'est la présentation de l'article comme une étude de la détection d'anomalies au sens large. La couverture est massivement concentrée sur les images de défauts industriels (MVTec-AD, VisA) et la vidéo-surveillance (UCF-Crime, XD-Violence). Sur les quelque 39 articles répertoriés, presque aucun ne traite des données tabulaires ou financières. Les séries temporelles reçoivent quelques citations. Le tabulaire n'a droit qu'à une seule phrase. Ce n'est pas une carte du paysage pour Bean Labs — c'est une carte pour les chercheurs en vision par ordinateur qui veulent utiliser CLIP pour la détection de défauts.

Les auteurs reconnaissent que « les contraintes d'espace empêchent des résumés détaillés des mesures », ce qui est une façon polie de dire qu'il n'y a pas de tableaux comparatifs. Pour une étude de synthèse, l'absence de synthèse quantitative est une lacune importante. Les lecteurs ne peuvent pas utiliser cet article pour décider quel paradigme est le meilleur pour leur cas d'utilisation sans traquer chaque article cité individuellement.

Le défi des hallucinations est listé comme un problème ouvert, mais le traitement est superficiel — il nomme le risque sans analyser quels paradigmes de détection y sont plus ou moins sensibles, ni comment la génération centrée sur l'explication pourrait rendre les hallucinations plus détectables par une revue humaine.

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

Deux sous-catégories sont pertinentes malgré une couverture axée sur l'image. Premièrement, la sous-catégorie de génération centrée sur l'explication est exactement ce dont les agents d'audit Beancount ont besoin : pas seulement un indicateur qu'une écriture comptable est anormale, mais une phrase en langage naturel expliquant pourquoi. Les auditeurs financiers ne peuvent pas agir sur une sortie binaire. Deuxièmement, le silence quasi total de l'étude sur la détection d'anomalies tabulaires est en soi instructif — il confirme que le fil AnoLLM, CausalTAD et AD-LLM que j'ai suivi est une zone pionnière plutôt qu'un terrain balisé, et que la conception d'outils d'audit basés sur les LLM pour les registres Beancount nécessite de synthétiser des enseignements issus de la détection d'anomalies visuelles qui n'ont pas encore été portés vers les environnements tabulaires.

Le compromis entre prompting et réglage fin est la conclusion la plus exploitable : le prompting zero-shot fonctionne comme une première approximation mais souffre du fossé de modalité ; le réglage fin basé sur LoRA sur des exemples étiquetés représentatifs comble ce fossé. Pour un déploiement Beancount avec des exemples d'anomalies étiquetés provenant de registres historiques, la voie du réglage fin semble plus fiable que le simple prompting.

Que lire ensuite​

• « Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs » (arXiv:2406.03614) — utilise des plongements (embeddings) de transformeurs de phrases LLM sur de réelles écritures de grand livre ; un pont direct entre le cadre de cette étude et le cas d'utilisation tabulaire de Beancount.
• « Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework » (arXiv:2403.19735) — pipeline multi-agents pour la détection d'anomalies de données de marché ; le modèle de coordination multi-agents pourrait s'appliquer à l'audit de registres.
• AnomalyGPT (arXiv:2308.15366) — LVLM ajusté pour la détection d'anomalies industrielles avec localisation au niveau du pixel ; lire ceci clarifie ce que signifie réellement « le réglage des LLM pour la détection » sur le plan architectural, ce que l'étude décrit mais n'explique pas.

L'article​

Hsieh et al. partent d'une observation diagnostique : les LLM — même ceux entraînés sur de longs contextes — présentent un schéma d'attention persistant en forme de U. Les jetons (tokens) au début et à la fin de l'entrée reçoivent une attention disproportionnée, qu'ils soient pertinents ou non, tandis que les jetons au milieu sont systématiquement sous-pondérés. Les auteurs relient cela empiriquement à la baisse de précision du « perdu au milieu » plutôt que de le traiter comme un phénomène distinct.

Leur correctif est élégant dans son concept. Ils décomposent l'attention en deux composantes additives : la pertinence (ce que nous voulons) et le biais positionnel (ce que nous ne voulons pas). Pour isoler le terme de biais, ils font passer un document « fictif » (dummy) — un contenu de remplissage non informatif — à travers le même contexte à chaque position et enregistrent la distribution d'attention résultante. Cette attention du document fictif approxime le pur a priori positionnel. En le soustrayant des scores d'attention réels, on obtient un résidu qui reflète mieux la véritable pertinence :

Attention calibrée = Attn(document, k) − Attn(fictif, k)

Les scores redimensionnés sont ensuite utilisés pour reclasser ou re-pondérer les documents récupérés avant l'étape finale de génération de la réponse. De manière cruciale, aucun entraînement n'est requis. La calibration est appliquée au moment de l'inférence aux 16 dernières couches du décodeur et à toutes les têtes d'attention. Le coût est de O(K) passages en avant (forward passes) supplémentaires, où K est le nombre de documents récupérés — non négligeable mais prévisible.

Idées clés​

• Le biais d'attention en forme de U est intrinsèque à l'architecture du modèle et persiste même dans les modèles explicitement entraînés avec des objectifs de contexte long.
• Faire passer un document fictif (vide/bruit) à travers le même contexte de récupération isole l'a priori positionnel ; le soustraire élimine le biais sans aucun réglage fin (finetuning).
• Le Recall@3 sur NaturalQuestion (K=20, document d'or placé au milieu) bondit de 20,52 % à 68,32 % avec la calibration ; à K=10, de 36,38 % à 74,27 %.
• La précision du QA de bout en bout s'améliore de 6 à 15 points de pourcentage lorsque le document d'or est au milieu du contexte ; les améliorations se maintiennent dans 22 des 24 configurations expérimentales.
• La méthode surpasse six lignes de base de comparaison : attention standard, classement par génération de requête, incitation par génération de pertinence, tri par attention (Peysakhovich & Lerer 2023), réordonnancement des prompts et LongLLMLingua-rk.
• La méthode a été évaluée sur NaturalQuestion (2 655 requêtes réelles sur Wikipedia) et SynthWiki (990 entrées synthétiques générées par GPT-4).

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

Le résultat principal est frappant et je le crois. Un écart de Recall@3 de 20,52 % → 68,32 % pour les documents d'or en milieu de contexte n'est pas le genre de chiffre qui s'évapore sous examen — il mesure quelque chose de réel sur la façon dont l'attention est distribuée. La conception sans entraînement est un véritable avantage pratique : vous pouvez l'ajouter à n'importe quel pipeline RAG existant sans toucher aux poids du modèle.

Cela dit, j'ai quelques réserves. Premièrement, l'approche du « document fictif » suppose que le biais positionnel est grossièrement séparable par position et additif — une décomposition linéaire que les auteurs eux-mêmes signalent comme potentiellement simpliste. Le biais d'attention réel peut interagir avec le contenu de manière non linéaire. Deuxièmement, les O(K) passages en avant supplémentaires sont présentés comme « acceptables » mais ne sont jamais évalués en termes de latence ou de coût. Dans un système de production avec K=20 récupérations, vous effectuez 21 passages en avant au lieu d'un seul par requête. Pour un agent Beancount triant des centaines de transactions, ce multiplicateur compte.

Troisièmement — et c'est la limitation la plus intéressante — les auteurs notent que le biais positionnel pourrait en réalité être utile pour certaines tâches. Le biais de récence, par exemple, pourrait être ce qui permet à un modèle de pondérer correctement les écritures de grand livre récentes par rapport aux plus anciennes. Supprimer le biais sans discernement pourrait nuire aux tâches où la position est un signal valide. Ceci est reconnu mais non étudié.

Enfin, les expériences utilisent NaturalQuestion et un ensemble de données synthétique. Les documents spécifiques à la finance — tableaux denses, dépôts pluriannuels, écritures de grand livre avec une structure répétitive — sont très différents des passages Wikipedia du domaine général. La calibration devrait être validée sur ces distributions avant d'affirmer qu'elle fonctionnera pour le RAG financier.

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

Le lien direct est clair : chaque journal depuis DocFinQA tourne autour du même problème. Lorsqu'un agent Beancount récupère 20 écritures de grand livre pertinentes pour répondre à une question comme « rapprocher mars avec le relevé bancaire », les écritures au milieu de la fenêtre de récupération recevront systématiquement moins d'attention que celles en haut et en bas du contexte. Ce n'est pas un échec de la récupération — c'est un échec côté génération qu'aucune amélioration du classement de récupération ne corrigera.

La calibration « trouvé au milieu » est une atténuation plausible qui ne nécessite aucun réentraînement du modèle sous-jacent et pourrait être appliquée directement à l'étape de génération de n'importe quel pipeline de QA de grand livre. L'inquiétude concernant le coût O(K) est réelle mais gérable — une fenêtre de récupération de 20 documents avec un modèle de taille modérée reste tout à fait dans les limites du possible. Ce que je voudrais voir avant de le déployer est une validation spécifique sur des données structurées Beancount : la correction positionnelle aide-t-elle uniformément, ou supprime-t-elle par inadvertance le signal de récence qui rend les transactions récentes plus dignes de confiance que les anciennes ?

Le principe plus large — à savoir que les mécanismes d'attention encodent des a priori positionnels indépendamment de la pertinence du contenu, et que ces a priori peuvent être éliminés par calibration sans réentraînement — est à retenir. Cela ouvre la porte à des calibrations similaires pour d'autres biais : biais de fréquence des jetons, normalisation de la longueur d'entrée, biais de verbosité dans la génération.

Que lire ensuite​

• « Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel » (arXiv:2406.02536, ACL Findings 2025) — propose de mettre à l'échelle une seule dimension d'état caché plutôt que de soustraire les scores d'attention ; mérite d'être comparé directement à l'approche de « Found in the Middle ».
• « Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey » (arXiv:2409.01980, NAACL 2025) — le prochain sur la liste de lecture ; relie les fils de AnoLLM, CausalTAD et AD-LLM dans une taxonomie unifiée.
• Liu et al., « Lost in the Middle: How Language Models Use Long Contexts » (arXiv:2307.03172, TACL 2023) — le diagnostic original auquel répond l'article actuel ; lecture de fond essentielle.

L'article​

ReDAct (Reason-Defer-Act) s'appuie sur le paradigme de prompting ReAct et introduit une architecture d'agent à deux modèles. Un petit modèle peu coûteux — Qwen3-80B, Llama3.3-70B ou Llama4-Maverick — gère chaque étape par défaut. À chaque étape, il génère une trace de raisonnement, puis génère une action. Le système mesure l'incertitude au niveau des jetons sur la seule étape de génération d'action et la compare à un seuil calibré. Si l'incertitude dépasse ce seuil, l'étape est réexécutée par un grand modèle coûteux (GPT-5.2, Qwen3-235B ou Qwen3-480B) ; sinon, l'action du petit modèle est exécutée.

Les mesures d'incertitude sont fondées sur la théorie de l'information et ne nécessitent que les log-probabilités au niveau des jetons : Probabilité de Séquence (somme des log-probabilités négatives), Perplexité (normalisée par la longueur) et Entropie Moyenne des Jetons (entropie moyenne sur les positions des jetons). Le seuil est calibré à partir d'un ensemble de déploiements du petit modèle mis de côté, en choisissant la valeur qui produit un nombre cible K d'appels au grand modèle par épisode.

Idées clés​

• Mesurer l'incertitude à l'étape de l'action, pas à l'étape du raisonnement. Une expérience auxiliaire sur 2 411 étapes ALFWorld a révélé que l'incertitude au niveau du raisonnement a un faible pouvoir de discrimination entre les étapes correctes et incorrectes ; la perplexité au niveau de l'action possède une ROC-AUC et un PRR nettement plus élevés comme prédicteur de justesse.
• Le report basé sur la PPL avec Qwen3-80B + GPT-5.2 atteint 80,8 % ± 1,1 % sur ALFWorld, dépassant GPT-5.2 seul à 78,3 % ± 1,9 %, tout en coûtant 16,25 $ contre 45,21 $ — soit environ 64 % d'économie.
• Environ 15 % des étapes sont reportées en pratique pour correspondre à une cible de calibration d'environ 10 % ; l'écart provient du fait que les trajectoires échouées (plus courtes) contribuent de manière disproportionnée au budget de report.
• Un report aléatoire au même taux n'obtient que 77,0 % — ce qui est toujours mieux que le petit modèle seul (68,3 %), mais moins bon que le report guidé par la quantification de l'incertitude (UQ). Le signal d'incertitude compte réellement, et pas seulement le fait d'appeler plus souvent le grand modèle.
• MiniGrid montre moins de marge de progression. Qwen3-80B + GPT-5.2 avec report par PPL atteint 95,0 % contre 99,0 % pour GPT-5.2 seul. Le vocabulaire plus restreint de la tâche crée un plafond plus difficile pour l'approche de report lorsque le petit modèle est structurellement inadéquat.
• La distribution du report dépend de la tâche. ALFWorld reporte davantage dans les étapes ultérieures (historique de prompt plus long), tandis que MiniGrid montre un profil bimodal lié à la position initiale de l'agent. Cela signifie que la calibration d'un seuil fixe se généralise mieux au sein d'une même famille de tâches qu'entre familles de tâches différentes.

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

Le constat empirique central est crédible : la perplexité sur la chaîne d'action est un substitut raisonnable pour déterminer si une étape donnée est sur le point d'échouer. La décomposition raisonnement/action de ReAct offre naturellement un point propre pour attacher un signal d'incertitude, et l'expérience auxiliaire de prédiction de justesse apporte une véritable justification mécaniste à ce choix de conception.

Ce qui me convainc moins : le résultat "dépasse le grand modèle seul" sur ALFWorld. 80,8 % ± 1,1 % contre 78,3 % ± 1,9 % se chevauchent à un écart-type près. Les auteurs attribuent cela à des forces complémentaires — le petit modèle gère les étapes de routine sans la prise de risque occasionnelle du grand modèle — mais il n'y a pas d'ablation par étape pour vérifier ce récit. Cela pourrait tout aussi bien être du bruit.

Le choix des benchmarks est également restrictif. ALFWorld et MiniGrid sont des simulations domestiques textuelles et de la navigation dans des mondes en grille — des environnements étroits qui n'exercent pas l'appel d'outils, l'exécution de code ou la récupération de documents multiples. La question de savoir si le report calibré sur l'incertitude tient dans ces contextes plus riches (ceux pertinents pour Beancount) reste sans réponse. De plus, le choix de GPT-5.2 comme grand modèle rend les chiffres de coût difficiles à reproduire.

La procédure de calibration présente une circularité non traitée : le seuil est sélectionné sur la même distribution que celle sur laquelle il a été calibré, sans validation externe. Les auteurs reconnaissent le décalage de distribution entre la calibration (déploiements du petit modèle) et l'évaluation (déploiements hybrides), mais laissent la robustesse du seuil pour des travaux futurs.

Pourquoi cela est important pour l'IA financière​

Les agents de réécriture Beancount font face exactement à la même question de report à chaque transaction. Un achat courant en épicerie nécessite une catégorisation simple ; un swap de devises étrangères inhabituel à plusieurs étapes avec un libellé partiellement apparié nécessite l'intervention d'un humain. La pratique actuelle est soit l'automatisation complète (risquée), soit la révision humaine totale (coûteuse). Le cadre de ReDAct suggère un compromis viable : exécuter le modèle bon marché et escalader lorsque la perplexité sur l'écriture comptable candidate dépasse un seuil calibré.

Le contexte financier ajoute deux considérations que l'article ne traite pas. Premièrement, le report devrait ici souvent signifier s'arrêter et demander à l'utilisateur, et non appeler un LLM plus puissant — la norme de justesse du grand livre est l'intention de l'utilisateur, pas un score de benchmark. Deuxièmement, l'irréversibilité d'une écriture Beancount validée est plus élevée que celle d'un objet mal placé dans ALFWorld. La cible de calibration K devrait probablement être réglée de manière conservatrice vers une précision plus faible sur le petit modèle avant de reporter, et non l'inverse.

Le signal de réduction des coûts de 64 % mérite d'être pris au sérieux, même avec ces réserves. Si un agent Beancount traite un mois de transactions et que seulement 15 % des décisions de catégorisation nécessitent le modèle coûteux, l'économie de fonctionnement d'un agent de réécriture performant devient beaucoup plus attractive.

Que lire ensuite​

• KnowNo (Ren et al., 2023, CoRL) : "Robots that ask for help: uncertainty alignment for large language model planners" — utilise la prédiction conforme pour calibrer une garantie de couverture sur le moment où demander de l'aide. ReDAct ne se compare pas à lui ; comprendre le compromis entre les garanties conformes et la calibration de seuil est essentiel avant de choisir une approche de production. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. mis à jour, NAACL 2024) — une taxonomie systématique de la confiance verbalisée, des méthodes basées sur l'échantillonnage et de la calibration post-hoc ; le socle théorique pour décider si la perplexité est le bon indicateur d'incertitude ou si une mise à l'échelle des logits calibrée serait plus performante. [arXiv:2311.08298]
• UALA: Uncertainty-Aware Language Agent (Han, Buntine, Shareghi) — applique un seuil d'incertitude structurellement similaire à la décision d'invocation d'outil (appeler un outil vs se fier aux connaissances du modèle), réduisant les appels d'outils de plus de 50 % ; le complément direct à ReDAct pour l'axe de l'utilisation des outils de l'incertitude de l'agent. [https://uala-agent.github.io/]

L'article​

OpenHands (Wang et al., 2024 ; ICLR 2025) est une plateforme open-source pour la création et l'évaluation d'agents LLM agissant comme des développeurs logiciels généralistes. Mené par Xingyao Wang et Graham Neubig au sein d'une équipe de 24 auteurs, l'article affirme que la plupart des frameworks d'agents existants sont soit trop restreints à la recherche (boucles de tâches codées en dur), soit trop restreints à la production (source fermée ou à but unique) pour servir de base partagée à la communauté de recherche. OpenHands tente de corriger cela en fournissant un environnement d'exécution standardisé, une abstraction d'agent propre et 15 benchmarks d'évaluation intégrés sous un seul dépôt sous licence MIT.

L'environnement d'exécution (runtime) est un environnement isolé par Docker contenant un shell bash, un serveur Jupyter IPython et un navigateur Chromium contrôlé par Playwright. Les agents interagissent via trois types d'actions principaux : IPythonRunCellAction pour Python, CmdRunAction pour les commandes shell, et BrowserInteractiveAction pour la navigation web. Une primitive de coordination multi-agents, AgentDelegateAction, permet à un agent principal de générer des sous-agents spécialisés. La structure de base par défaut est CodeAct — initialement publié comme un article autonome soutenant que le code est l'espace d'action unifié idéal pour les agents LLM — et la plateforme propose plusieurs implémentations d'agents, dont un CodeActAgent généraliste et un BrowsingAgent spécialisé.

Idées clés​

• Le code comme espace d'action universel : CodeAct consolide toutes les actions de l'agent (édition de fichiers, appels d'API, transformations de données) en Python ou bash, permettant au LLM de raisonner dans le support sur lequel il a été le plus intensément entraîné. Cela évite la fragilité liée aux schémas JSON qui handicape les agents basés sur l'appel de fonctions (function-calling).
• Environnement d'exécution Docker isolé : chaque agent s'exécute dans un conteneur isolé, de sorte que les agents peuvent exécuter librement du code arbitraire sans compromettre la machine hôte — un prérequis pour tout agent financier en production à qui l'on pourrait confier de véritables identifiants.
• 15 benchmarks dans un seul banc d'essai : SWE-Bench Lite (réparation de code), HumanEvalFix (correction de bugs), WebArena (navigation web), GPQA (raisonnement de niveau universitaire), GAIA (résolution de tâches générales), et dix autres. Cette colocalisation évite les évaluations sélectives (cherry-picked).
• CodeActAgent + claude-3.5-sonnet atteint 26 % sur SWE-Bench Lite et 79,3 % sur HumanEvalFix ; BrowsingAgent atteint 15,5 % sur WebArena — des résultats compétitifs en "zero-shot" sans aucun entraînement spécifique à la tâche.
• Performance GAIA : 32,1 % avec GPTSwarm, bien en dessous de la base de référence humaine de 92 % — ce qui est cohérent avec tous les autres benchmarks d'agents généraux montrant un écart de 60 à 70 points entre l'humain et l'agent.
• Échelle de la communauté : 71,4k étoiles sur GitHub et plus de 188 contributeurs au moment de la soumission à l'ICLR ; TheAgentCompany a adopté OpenHands comme banc d'essai d'évaluation, lui conférant un statut de fait d'infrastructure de référence.

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

La conception de l'environnement d'exécution isolé est une ingénierie solide. Isoler l'exécution des agents dans Docker est le choix par défaut correct pour tout système qui pourrait plus tard recevoir un accès en écriture à de véritables grands livres financiers, et il est réellement utile que les benchmarks soient regroupés plutôt que dispersés dans des dépôts incompatibles.

La couverture des benchmarks est cependant plus aspirative que systématique. Les 15 benchmarks couvrent des types de tâches et des niveaux de difficulté radicalement différents sans cadre clair sur la manière dont les résultats devraient être agrégés ou comparés. Rapporter 26 % sur SWE-Bench Lite aux côtés de 79,3 % sur HumanEvalFix dans le même article risque de donner l'impression que le même agent est simultanément médiocre et excellent — les tâches ne sont tout simplement pas comparables. Les auteurs ne fournissent pas de méthodologie d'agrégation multi-benchmarks rigoureuse.

L'hypothèse CodeAct — selon laquelle le code est le bon format d'action universel — est contestée. Cela fonctionne bien pour les tâches de développement, mais impose une couche de médiation Python/bash pour chaque action, ce qui ajoute de la latence et échoue lorsque la sémantique de l'action ne correspond pas proprement au code (instructions utilisateur ambiguës, API uniquement en langage naturel). L'article n'effectue pas de benchmark par rapport à des espaces d'action non basés sur le code pour démontrer que l'avantage est réel plutôt que confondu par les capacités intrinsèques du LLM.

L'écart le plus important est peut-être la séparation entre évaluation et déploiement. Le chiffre de 26 % sur SWE-Bench provient d'un benchmark relativement propre et bien spécifié. Les rapports de la communauté et les fils de discussion GitHub décrivent systématiquement une fiabilité bien moindre sur des tâches réelles ambiguës ou à long horizon — le même mode d'échec que celui documenté par TheAgentCompany. L'article n'aborde pas la manière de mesurer ou d'améliorer la robustesse face au bruit des spécifications de tâches réalistes.

Pourquoi cela est important pour l'IA financière​

OpenHands est ce qui se rapproche le plus d'un substrat d'agent partagé pour la communauté. Si Bean Labs construit une infrastructure d'évaluation pour les agents Beancount, l'architecture d'exécution ici — isolation Docker, actions Python/bash, backends LLM interchangeables — mérite d'être adoptée plutôt que reconstruite. La primitive AgentDelegateAction correspond naturellement à un pipeline d'agent financier où un orchestrateur de haut niveau délègue à des sous-agents spécialisés : un pour la lecture du grand livre, un pour le signalement d'anomalies, un pour une proposition d'écriture qu'un humain révise.

Les chiffres de SWE-Bench et de TheAgentCompany, lus ensemble, établissent un a priori lucide : même les meilleurs agents disponibles ne réalisent qu'environ 26 à 30 % des tâches logicielles réalistes et non ambiguës. L'automatisation des grands livres financiers est plus difficile — les transactions sont souvent ambiguës, le rayon d'impact des erreurs est réel et l'intention de l'utilisateur est fréquemment sous-spécifiée. La conclusion correcte n'est pas que les agents ne sont pas prêts, mais que les premiers déploiements productifs seront des flux de travail d'écriture unique strictement délimités (suggestions de catégorisation, signalement de rapprochements) plutôt que des modifications autonomes du grand livre en plusieurs étapes.

Que lire ensuite​

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — associe un modèle peu coûteux à un modèle onéreux et ne délègue au modèle onéreux que lorsque l'incertitude est élevée ; aborde directement la manière dont un agent de type OpenHands devrait décider quand escalader une écriture Beancount à une révision humaine.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 séquences de tâches annotées par des experts à travers 34 scénarios financiers ; la méthodologie d'évaluation qui manque à OpenHands pour l'utilisation d'outils à long horizon spécifiques à la finance.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 échantillons à travers 65 outils financiers MCP réels, directement pertinent pour la manière dont un agent Beancount construit sur le runtime d'OpenHands serait évalué dans un déploiement MCP réel.

L'article​

Fin-RATE, publié en février 2026 par Yidong Jiang, Junrong Chen et leurs collègues de Yale et d'institutions partenaires, introduit un benchmark construit à partir de 2 472 dépôts SEC concernant 43 entreprises et 36 secteurs couvrant la période 2020-2025. Le benchmark organise 7 500 paires de questions-réponses curatées par des experts en trois types de tâches qui reflètent les flux de travail des analystes professionnels : DR-QA (détail et raisonnement au sein d'un seul dépôt), EC-QA (comparaison multi-entités de deux entreprises sur un sujet commun) et LT-QA (suivi longitudinal de la même entreprise à travers les périodes de reporting). Chaque type de tâche contient 2 500 questions. L'évaluation porte sur 17 LLM — des modèles propriétaires incluant GPT-4.1 et GPT-5, des modèles open-source généralistes comme DeepSeek-V3 et Llama-3.3-70B, et des modèles spécialisés en finance comme Fin-R1, Fino1-14B, FinanceConnect-13B et TouchstoneGPT-7B. La notation utilise un cadre unifié "LLM-as-Judge" avec trois juges indépendants (GPT-5, DeepSeek-V3.2, Qwen3-235B) évaluant chaque réponse sur l'exactitude et cinq dimensions analytiques.

Idées clés​

• La performance s'effondre à mesure que la complexité de la tâche augmente : la précision chute de 18,60 % entre la DR-QA sur document unique et la LT-QA longitudinale, et de 14,35 % entre la DR-QA et la EC-QA multi-entités, en moyenne sur les 17 modèles.
• GPT-5 avec recherche web est le plus performant, pourtant sa précision maximale ne plafonne qu'à 43-44 % sur les trois types de tâches — un résultat médiocre pour un benchmark censé refléter les flux de travail réels des analystes.
• Fin-R1, le modèle de raisonnement spécialisé en finance, atteint 57,48 % sur la DR-QA mais s'effondre à 3,32 % sur la EC-QA — une chute de 54 points qui dépasse de loin la dégradation de n'importe quel modèle généraliste.
• Dans des configurations RAG (Génération Augmentée par Récupération), la performance de tous les modèles tombe bien en dessous de 27 %, comparativement à une performance avec contexte de référence ("gold context") allant jusqu'à 57,48 % ; le pipeline de récupération, et non le LLM, est le goulot d'étranglement limitant.
• L'article introduit une taxonomie d'erreurs en 13 types répartis en quatre catégories : hallucinations et contradictions, erreurs numériques et sémantiques spécifiques à la finance, erreurs de compréhension de la requête/du contexte, et échecs au niveau de la récupération. Le manque de preuves ("Missing Evidence") représente 75,44 % des erreurs sur la tâche EC-QA sous RAG.
• Les modèles spécialisés en finance affichent des taux d'hallucination systématiquement plus élevés que les modèles généralistes sur les tâches complexes, malgré une meilleure maîtrise de la terminologie financière.

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

La structure à trois voies est véritablement bien conçue. La plupart des benchmarks financiers (FinQA, TAT-QA, FinanceBench) traitent les questions-réponses comme une tâche sur un document unique. Fin-RATE est l'un des premiers à modéliser explicitement la comparaison multi-entités et le suivi longitudinal comme des tâches de premier plan, et les résultats exposent une lacune fondamentale : les LLM actuels gèrent passablement les questions-réponses sur des divulgations isolées, mais s'effondrent dès qu'ils doivent synthétiser des informations à travers plusieurs documents, entités ou périodes.

L'effondrement de Fin-R1 est la découverte la plus frappante de l'article et je pense qu'elle est sous-estimée. Un modèle optimisé pour la finance qui excelle dans l'extraction sur document unique s'est apparemment enfermé dans une impasse lors de son entraînement : il a appris des modèles pour répondre au sein d'un seul document, et non des stratégies de raisonnement pour mettre en relation des entités et des périodes temporelles. C'est un avertissement concret contre le réglage fin (fine-tuning) sur un domaine étroit sans supervision explicite du raisonnement multi-documents. Le modèle a probablement sur-appris le schéma superficiel consistant à "trouver le chiffre dans le dépôt" et n'a aucune voie de généralisation pour "comparer ce chiffre au chiffre équivalent dans un autre dépôt d'une autre entreprise".

Cela dit, certaines préoccupations méthodologiques méritent d'être signalées. GPT-5 est simultanément l'un des modèles évalués et l'un des trois juges notant les réponses. Les auteurs utilisent trois juges pour réduire les biais individuels, ce qui aide, mais le chevauchement juge-modèle avec le modèle évalué le plus puissant est inconfortable. L'article rapporte un accord inter-juges élevé mais ne quantifie pas séparément quelle fraction des réponses de GPT-5 a été notée par GPT-5 lui-même, ni si les scores auto-évalués de GPT-5 diffèrent systématiquement des deux autres juges. Tout biais d'auto-évaluation gonflerait le résultat global pour le modèle le plus performant de l'étude.

L'échantillon de 43 entreprises est également restreint. La couverture des types de dépôts est louablement large (10-K, 10-Q, 8-K, 6-K, DEF 14A, et plusieurs séries S et SC), mais les mêmes 43 entreprises apparaissent dans toutes les tâches. Les modèles ayant vu les divulgations de ces entreprises lors du pré-entraînement bénéficient d'un avantage non quantifié, et l'article n'inclut aucune analyse de contamination.

La découverte sur la récupération est importante mais incomplète. L'article identifie que la performance RAG s'effondre d'environ 30 points par rapport au contexte de référence parce que la récupération échoue. Mais il ne teste qu'une seule configuration de récupération — il traite l'échec de récupération comme un diagnostic plutôt que comme une variable à faire varier systématiquement. Un article de suivi balayant les architectures de récupération sur Fin-RATE serait bien plus exploitable.

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

L'audit de grand livre Beancount nécessite précisément les deux capacités que Fin-RATE révèle comme défaillantes : le suivi longitudinal (comment ce compte a-t-il évolué au fil des exercices ?) et la comparaison multi-entités (le bilan de cette filiale concorde-t-il avec l'état consolidé ?). La chute de précision de 18,60 % sous suivi temporel est un chiffre concret qui devrait calibrer les attentes pour tout agent Beancount raisonnant sur plusieurs périodes de reporting. Si les modèles de pointe échouent à 43 % lors de questions-réponses longitudinales sur la SEC avec un contexte de référence, un agent Beancount naviguant dans des historiques de grands livres sur plusieurs années devrait être conçu avec une récupération explicite, un ancrage temporel et une escalade humaine — et non une inférence LLM de bout en bout.

La primauté de la récupération est la découverte la plus importante pour la priorité de conception des systèmes. Si la performance avec contexte de référence est presque le double de la performance RAG, le bon investissement réside dans un meilleur découpage (chunking), une meilleure sélection de passages et une meilleure récupération — et non dans un LLM de base plus performant. Cela reflète ce que DocFinQA a trouvé pour les dépôts SEC à contexte long : le pipeline autour du modèle est le goulot d'étranglement.

L'avertissement concernant Fin-R1 s'applique également directement au cas d'usage Beancount. Un réglage fin sur la syntaxe DSL de Beancount et les schémas de transactions peut produire un modèle qui gère bien la génération d'écritures simples, mais qui échoue lors du rapprochement multi-comptes et multi-périodes qui rend l'audit utile. La spécialisation sans entraînement au raisonnement multi-documents est fragile, précisément de la manière mesurée par Fin-RATE.

Que lire ensuite​

• Fin-R1 (arXiv:2503.16252) — pour comprendre quelle configuration d'entraînement a produit une performance multi-documents aussi fragile, et si le raisonnement multi-documents a jamais été envisagé.
• FinTrace (arXiv:2604.10015) — évaluation au niveau de la trajectoire de l'appel d'outils par les LLM à travers 34 catégories de tâches financières ; complète la vision statique de Fin-RATE par un diagnostic au niveau du processus indiquant où les modèles invoquent les bons outils mais échouent à raisonner sur les résultats.
• OpenHands (arXiv:2407.16741) — la plateforme d'agents ouverte sous-jacente aux évaluations de TheAgentCompany ; comprendre son architecture permet de clarifier quelles capacités d'agent de base étaient disponibles et quelles lacunes sont attribuables à la difficulté de la tâche plutôt qu'aux limitations de la plateforme.

L'article​

Chanyeol Choi, Jihoon Kwon et leurs collègues d'une société d'IA financière présentent un ensemble de données de 5 703 triplets requête-preuve-réponse annotés par des experts, provenant d'un service de questions-réponses pour analystes de fonds spéculatifs. Les documents sont des formulaires 10-K de 490 sociétés du S&P 500, collectés sur SEC EDGAR. Ce qui distingue FinDER des benchmarks précédents, c'est le type de requêtes : 89,86 % d'entre elles contiennent trois abréviations ou acronymes spécifiques au domaine ou plus. Au lieu de « Quel est le revenu total de la société X pour l'exercice 2023 ? », un analyste réel pourrait taper « GOOGL 10-K FY23 revs breakdown by segment ». L'ensemble de données a été publié lors de l'atelier ICLR 2025 sur les avancées de l'IA financière et est apparu plus tard à l'ICAIF 2025.

Idées clés​

• Le rappel de récupération est choquant de faiblesse partout : E5-Mistral (le meilleur modèle de récupération dense) n'atteint que 25,95 % de rappel global du contexte ; BM25 s'arrête à 11,68 %. La catégorie « Financials » — la plus directement liée à la comptabilité — est la plus difficile : 15,84 % et 6,42 % respectivement.
• L'ambiguïté des requêtes coûte à elle seule 8,2 points de précision : En testant E5-Mistral sur 500 requêtes, les auteurs comparent des paraphrases bien formulées (33,9 de précision) aux requêtes abrégées réelles (25,7 de précision). L'écart est entièrement attribuable à la gestion des abréviations et acronymes, et non à la complexité des documents.
• La qualité de la récupération est le goulot d'étranglement dominant pour la génération : Les LLM sans contexte obtiennent un score proche de zéro (9 à 10 % de réponses correctes) ; avec les 10 meilleurs passages récupérés, ils atteignent 29 à 34 % ; avec un contexte d'oracle parfait, ils bondissent à 60-68 %. Cet écart de 35 points entre les conditions réalistes et l'oracle est plus important que l'écart entre les modèles open-source et les modèles de pointe.
• L'arithmétique compositionnelle échoue même avec une bonne récupération : Les tâches de calcul en plusieurs étapes (requêtes compositionnelles) n'atteignent qu'environ 20 % d'exactitude sur les quatre modèles — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill et Qwen-QWQ — même avec les 10 meilleurs passages récupérés. GPT-o1 mène sur les multiplications avec 42,90 % mais chute à 27,78 % sur les divisions.
• Le réordonnancement par LLM apporte une amélioration modeste mais constante : En laissant les modèles réordonner les 10 meilleurs résultats d'E5-Mistral avant de répondre, Claude-3.7-Sonnet atteint un F1 de 63,05 et GPT-o1 atteint 62,90. Deepseek-R1-Distill suit à 60,01, malgré de fortes performances en raisonnement structuré par ailleurs.
• La difficulté par catégorie est inégale : Les requêtes sur les risques sont les plus faciles à récupérer (E5-Mistral : 33,07 de rappel) ; les données financières restent les plus difficiles (15,84). Cela corrèle avec la structure des requêtes — les divulgations de risques utilisent de la prose en langage naturel, tandis que les tableaux financiers utilisent une notation numérique dense.

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

La contribution principale est solide : il s'agit d'une distribution de requêtes réelles d'analystes en activité, et le problème des abréviations est authentique. Tout benchmark construit à partir de Wikipédia ou de crowdsourcing de type FinQA passe à côté de cela. La structure d'évaluation à trois niveaux — sans contexte, récupération réaliste, contexte d'oracle — est la bonne conception ; elle sépare proprement la qualité de la récupération de la qualité du raisonnement et montre l'écart de génération résiduel (toujours ~32-34 % d'échec même avec un contexte parfait sur des questions qualitatives).

Le point faible de l'article est la reproductibilité. Au moment de la publication, l'ensemble de données n'était pas public — les auteurs déclarant qu'ils « prévoient de le rendre public ultérieurement ». C'est un problème majeur pour un article d'atelier se présentant comme un standard d'évaluation. Des benchmarks qui ne sont pas publiés ne sont pas des benchmarks ; ce sont des études de cas. Il est apparu depuis à l'ICAIF 2025, donc une publication a pu suivre, mais la version arXiv ne le confirme pas.

L'évaluation de la récupération n'utilise également que quatre modèles à étape unique (BM25, GTE, mE5, E5-Mistral). Il n'y a pas de récupération hybride, pas d'expansion de requête, pas de HyDE, ni d'étape de réécriture ciblant spécifiquement le problème des abréviations. Étant donné que les auteurs ont précisément caractérisé l'écart dû aux abréviations, il est surprenant qu'ils ne testent pas la solution évidente : étendre la requête (« GOOGL » → « Alphabet Inc. ») avant la récupération. Cette expérience est absente.

Les résultats de génération méritent une lecture attentive. La performance de ~9-10 % sans contexte n'est pas une borne inférieure utile — c'est essentiellement zéro — mais le plafond de l'oracle à 60-68 % est plus informatif qu'il n'y paraît. Même avec le bon passage en main, les meilleurs modèles échouent sur environ un tiers des questions qualitatives et quatre cinquièmes de l'arithmétique compositionnelle. Ce plafond compte : il signifie que la récupération seule ne peut pas résoudre le problème.

Pourquoi cela compte pour l'IA financière​

La distribution des requêtes dans FinDER correspond bien à la manière dont les utilisateurs de Beancount interagissent réellement avec un agent de grand livre. Un utilisateur qui tient ses comptes depuis des années tapera des requêtes abrégées et contextuelles — « AMZN card Q3 reimb? » plutôt que « Quels sont les remboursements par carte de crédit Amazon au troisième trimestre ? ». Les modèles d'embedding standards échoueront à récupérer les bonnes entrées car ils ont été entraînés sur du texte propre en langage naturel. La chute de précision de 8,2 points entre les requêtes propres et réelles est probablement conservatrice pour le domaine d'un grand livre personnel, où le sténogramme idiosyncrasique (« prop mgmt fee » pour « frais de gestion immobilière ») est encore plus éloigné des données d'entraînement que les abréviations standards de la SEC.

Le plafond de rappel de contexte de 25,95 % sur E5-Mistral est une contrainte structurelle : tout pipeline RAG pour Beancount doit prévoir une large fraction de preuves manquées. Une implication est qu'une nouvelle récupération à haut rappel (passes multiples, formulations de requêtes diversifiées) importe plus que l'amélioration du F1 sur une seule passe. Une autre est que la normalisation des requêtes — mapper le sténogramme de l'utilisateur vers des noms de comptes canoniques avant la récupération — devrait être une étape de prétraitement explicite, et non laissée au modèle d'embedding.

L'exactitude de 20 % en arithmétique compositionnelle, même avec un contexte d'oracle, est un signal distinct : pour les tâches de calcul Beancount, le goulot d'étranglement de la génération est le raisonnement, pas la récupération. Le déchargement de style PAL (générer de l'arithmétique Python plutôt qu'un calcul en texte libre) reste la bonne réponse pour les tâches numériques, quelle que soit la qualité de la récupération.

Que lire ensuite​

• Fin-RATE (arXiv:2602.07294) — le benchmark compagnon pour le suivi multi-période sur les dépôts SEC ; l'exactitude chute de 18,60 % sur les tâches temporelles, ce qui correspond directement au problème du grand livre Beancount sur plusieurs années.
• IRCoT (arXiv:2212.10509, ACL 2023) — entrelacer la récupération avec le raisonnement par chaîne de pensée ; la structure de récupération multi-passes répond directement au faible rappel en une seule passe révélé par FinDER.
• Expansion de requêtes avec LLM pour la récupération spécifique à un domaine — aucun article de benchmark ne couvre encore bien ce sujet, mais l'écart d'abréviation de FinDER en fait une priorité de recherche de premier ordre ; chercher « HyDE financial domain » et « query expansion SEC filings 2025 » est le bon point de départ.

L'article​

"Lost in the Middle: How Language Models Use Long Contexts" par Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni et Percy Liang présente deux expériences ciblées : une réponse aux questions multi-documents sur NaturalQuestions-Open (avec 10, 20 et 30 documents récupérés) et une récupération synthétique de paires clé-valeur (avec 75, 140 et 300 paires). Dans chaque expérience, ils font varier systématiquement l'emplacement du document pertinent ou de la paire clé-valeur au sein du contexte d'entrée — début, milieu ou fin — tout en maintenant le reste fixe. Le résultat est net : la performance trace une courbe en forme de U avec un creux au milieu du contexte, et cette courbe apparaît dans chaque modèle testé.

Idées clés​

• La forme en U est réelle et cohérente. Dans le cadre d'une QA à 20 documents, la performance à la première position était d'environ 75 % et s'est dégradée jusqu'à environ 55 % à la position 10 avant de remonter à environ 72 % à la position 20 — soit un écart de ~20 points entre les extrémités et le centre.
• Tous les modèles suivent le même schéma. Les modèles testés couvrent les types fermés et ouverts, petits et grands : GPT-3.5-Turbo (4K et 16K), GPT-4, Claude-1.3 (8K et 100K), MPT-30B-Instruct et LongChat-13B. La courbe en U est apparue dans chacun d'eux, y compris les modèles explicitement commercialisés pour leurs fenêtres de contexte étendues.
• Même Claude-1.3-100K n'est pas immunisé. La variante au contexte de 100K s'est comportée comme les autres. Une large fenêtre de contexte ne signifie pas que le modèle y prête attention de manière uniforme.
• La base de référence "closed-book" (sans documents) fixe un seuil décevant. GPT-3.5-Turbo sans aucun document a répondu correctement à 56,1 % de NaturalQuestions ; avec un accès "oracle" au seul document pertinent, il a atteint 88,3 %. Mais aux pires positions intermédiaires dans le réglage à 20 documents, la performance est tombée en dessous de la base de référence sans documents — ce qui signifie que l'ajout de contexte était activement nuisible.
• Les modèles encodeur-décodeur (Flan-T5-XXL, Flan-UL2) sont plus robustes dans leur longueur d'entraînement mais régressent lorsque les contextes la dépassent. La différence architecturale compte, mais les deux types se dégradent tout de même à grande échelle.
• La cause profonde est le masquage de l'attention causale. Chaque jeton ne peut prêter attention qu'aux jetons précédents, de sorte que les positions au tout début accumulent un poids d'attention total plus important à travers le modèle que les positions au milieu. Les effets de récence tirent également vers le haut la fin du contexte.

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

La conception expérimentale est ici admirablement propre : la position est la seule variable manipulée, les tâches sont des références standard et les résultats se reproduisent sur une large gamme de familles de modèles. Je n'ai aucune objection au résultat central.

Ce que je trouve moins convaincant, c'est la présentation de la tâche de récupération clé-valeur comme un substitut significatif pour une utilisation réelle. Les recherches d'UUID à UUID testent si un modèle peut répéter une chaîne mémorisée, pas s'il peut effectuer un raisonnement. La courbe en U y apparaît également, ce qui renforce l'affirmation du biais de position, mais cela signifie aussi que l'article confond deux phénomènes différents : la précision de la récupération sur des tâches de correspondance exacte et la qualité du raisonnement sur des passages pertinents. J'aimerais savoir si la forme en U s'aggrave ou s'améliore lorsque le document pertinent nécessite une inférence en plusieurs étapes avant la réponse finale, et pas seulement une répétition textuelle.

Il existe également une lacune que les auteurs reconnaissent pour la plupart mais ne comblent pas : ils ne testent jamais si le réglage fin par instructions (instruction fine-tuning) ou le RLHF modifie la sensibilité à la position, seulement si une fenêtre de contexte plus large le fait. Étant donné que la cause profonde est architecturale (masquage causal), je soupçonne que le réglage par instructions ne résoudra pas le problème, mais l'article ne le confirme pas.

Pourquoi cela compte pour l'IA financière​

Cet article fournit l'explication mécaniste d'un schéma empirique que je rencontre sans cesse. DocFinQA s'est effondré sur de longs rapports de la SEC. IRCoT et FLARE récupèrent tous deux plusieurs passages et les concatènent avant le raisonnement. Chaque pipeline RAG que j'ai examiné dans un contexte financier déverse les passages récupérés de manière séquentielle dans l'invite (prompt) et espère que le modèle prêtera attention au bon passage.

L'implication pour les agents Beancount est concrète. Si un agent récupère dix écritures comptables comme contexte, les écritures en positions 3 à 7 présentent le risque le plus élevé d'être ignorées ou de faire l'objet d'hallucinations. Ce n'est pas un problème de récupération — c'est un problème de présentation. Deux réponses découlent de cet article : soit placer les écritures les plus pertinentes d'un point de vue diagnostic en premier (et en dernier), soit ne pas concaténer du tout et raisonner sur un seul passage à la fois.

Ce résultat complique également le récit des LLM à long contexte. Chaque trimestre, un nouveau modèle annonce une fenêtre de contexte plus large. Cet article dit qu'une fenêtre longue ne signifie pas ce que vous pensez si vous distribuez uniformément les preuves à l'intérieur. Un modèle au contexte de 128K qui enterre la transaction pertinente à la position 60K est moins efficace qu'un modèle au contexte de 4K qui récupère précisément le bon passage.

Pour la sécurité des écritures (write-back), les implications sont inconfortables : si l'on demande au modèle de résumer une session comptable et que la règle de politique pertinente "ne pas comptabiliser cette transaction" apparaît au milieu d'une longue invite système, le modèle peut agir comme s'il n'avait jamais lu cette règle.

Que lire ensuite​

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) — propose le codage positionnel multi-échelle (Ms-PoE) comme solution sans réentraînement via la mise à l'échelle RoPE ; revendique une amélioration allant jusqu'à 3,8 points sur Zero-SCROLLS, s'attaquant directement à la courbe en U.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198) — adopte l'approche opposée et entraîne le modèle à être explicitement agnostique à la position ; la comparaison avec Ms-PoE clarifie si le réglage fin ou les astuces au moment de l'inférence sont le meilleur levier.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536) — identifie la dimension spécifique des états cachés positionnels responsable du biais et la met à l'échelle sans réentraînement ; le correctif le plus chirurgical proposé à ce jour, pertinent pour le déploiement de modèles existants sans nouvel entraînement.

L'article​

Tiankai Yang, Yi Nian et leurs collègues de l'USC et de Texas A&M introduisent AD-LLM (arXiv:2412.11142, ACL Findings 2025), le premier benchmark pour évaluer systématiquement les LLM à travers trois paradigmes de détection d'anomalies sur des jeux de données NLP. Le cadre est celui de la classification à classe unique (one-class classification) : les données d'entraînement ne contiennent que des échantillons normaux, et le modèle doit signaler les anomalies lors du test. Les cinq jeux de données — AG News, BBC News, IMDB Reviews, N24 News et SMS Spam — proviennent tous de tâches de classification de texte où une catégorie est désignée comme anormale. L'article confronte deux LLM, GPT-4o et Llama 3.1 8B Instruct, à 18 lignes de base (baselines) non supervisées traditionnelles allant de méthodes de bout en bout (CVDD, DATE) à des combinaisons en deux étapes d'embeddings et de détecteurs (embeddings OpenAI + LUNAR, LOF, Isolation Forest, etc.).

Idées clés​

• La détection zero-shot fonctionne bien pour le texte. GPT-4o obtient un AUROC de 0,9293 à 0,9919 sur les cinq jeux de données dans le paramètre Normal+Anomalie ; Llama 3.1 atteint 0,8612 à 0,9487. La meilleure ligne de base traditionnelle, OpenAI + LUNAR, obtient environ 0,92 sur AG News — GPT-4o l'égale ou la bat sans aucun entraînement.
• L'augmentation synthétique aide de manière constante mais modeste. Les échantillons synthétiques générés par LLM améliorent le pipeline OpenAI + LUNAR sur les cinq jeux de données. L'augmentation par description de catégorie améliore également la plupart des lignes de base, bien que les gains soient inégaux — Llama 3.1 améliore l'AUROC de +0,07 sur IMDB Reviews, mais les résultats ailleurs sont plus faibles.
• La sélection de modèle est le maillon faible. GPT-o1-preview recommande des modèles qui surpassent la performance moyenne de base sur la plupart des jeux de données, et s'approche occasionnellement de la meilleure méthode (par exemple, sur IMDB Reviews et SMS Spam). Mais il n'identifie jamais de manière fiable le meilleur performeur, et les auteurs reconnaissent que les recommandations sont basées sur des entrées simplistes manquant de statistiques spécifiques aux données.
• L'écart entre l'open-source et le propriétaire est réel. L'avantage d'AUROC de GPT-4o sur Llama 3.1 8B est de 4 à 13 points selon le jeu de données, un écart cohérent avec le schéma observé dans les articles sur la détection d'anomalies tabulaires en zero-shot.
• La détection d'anomalies en NLP manque encore d'un benchmark définitif. Cinq jeux de données, tous dérivés de corpus de classification, c'est peu. L'article compagnon NLP-ADBench (EMNLP Findings 2025) passe à huit jeux de données et 19 algorithmes, mais utilise toujours la même construction de "catégorie-sémantique-comme-anomalie" qui rend ces tâches quelque peu artificielles.

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

Les résultats sur le zero-shot sont crédibles. Utiliser les LLM comme scoreurs sans ajustement fin sur des données d'anomalies étiquetées est réellement utile lorsque la classe d'anomalie est sémantiquement cohérente — un message de spam diffère d'un message légitime de manières qu'un modèle de langage bien entraîné comprend. Les chiffres d'AUROC sont élevés, et la comparaison avec des lignes de base solides basées sur les embeddings OpenAI est équitable.

La portée, cependant, est étroite d'une manière que l'article minimise. Les cinq jeux de données encodent les anomalies comme une catégorie de sujet différente — spam contre SMS légitimes, informations d'un éditeur exclu contre flux habituels. Cela signifie que le LLM effectue essentiellement une classification thématique, une tâche pour laquelle il est explicitement pré-entraîné. Le benchmark n'inclut pas d'anomalies sémantiques au sein d'une seule catégorie (par exemple, des transactions inhabituelles au sein d'un même type de compte), ce qui est précisément le genre d'anomalie qui importe pour l'audit financier.

Les tâches d'augmentation de données et de sélection de modèles sont évaluées sur les mêmes cinq jeux de données, de sorte que l'article finit par évaluer si les LLM peuvent améliorer marginalement différentes facettes du même problème étroit. Les auteurs listent librement six limitations — notamment le fait qu'ils ne testent qu'un sous-ensemble de LLM, excluent les régimes few-shot et d'ajustement fin, et s'appuient sur des entrées simplistes pour la sélection de modèles — ce qui est intellectuellement honnête mais souligne également le caractère préliminaire de ce benchmark.

Un résultat à signaler pour les sceptiques : les scores AUPRC sont nettement inférieurs à l'AUROC pour les deux modèles. Llama 3.1 sur BBC News atteint un AUROC de 0,8612 mais seulement un AUPRC de 0,3960, reflétant le déséquilibre des classes dans la configuration à classe unique. Dans des contextes d'audit de haute précision, l'AUPRC est la métrique la plus significative, et ici le tableau est moins flatteur.

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

Le programme de Bean Labs implique deux cas d'utilisation de détection d'anomalies : repérer des écritures comptables inhabituelles en temps réel (tabulaire, structuré) et signaler des textes narratifs suspects dans les factures, les mémos ou les tickets de support (NLP non structuré). AD-LLM s'adresse directement au second cas et nous donne un plafond réaliste : GPT-4o peut détecter en zero-shot des anomalies au niveau du sujet dans le texte avec un AUROC supérieur à 0,93 sur des jeux de données propres et équilibrés. C'est un indicateur utile, mais les anomalies narratives dans les grands livres sont plus subtiles — un mémo de facture qui décrit un service de routine mais appartient à un fournisseur signalé pour des schémas suspects n'est pas un problème de classification thématique. Le benchmark fournit un point de départ, pas une réponse finale.

La conclusion sur la sélection de modèle est également intéressante pour la conception de systèmes. Le rêve de demander à un LLM "quel détecteur d'anomalies dois-je utiliser sur ce jeu de données ?" et d'obtenir une réponse fiable ne se concrétise pas encore. Cela signifie que choisir entre un ajustement fin de style AnoLLM, un prompting causal de style CausalTAD ou une méthode d'embedding classique nécessite toujours un jugement humain ou une évaluation empirique systématique — cela ne peut pas être délégué à un conseiller LLM.

Que lire ensuite​

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025) — le benchmark compagnon du même groupe, couvrant huit jeux de données et 19 algorithmes ; il fournit le contexte plus large des lignes de base classiques que la portée de cinq jeux de données d'AD-LLM ne peut offrir.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025) — passe en revue l'ensemble du paysage des approches de détection d'anomalies basées sur les LLM à travers les modalités textuelles, d'image et tabulaires ; il replace AD-LLM par rapport aux travaux antérieurs.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — le pendant tabulaire ; comparer son approche basée sur la vraisemblance (likelihood) à la stratégie zero-shot basée sur les prompts d'AD-LLM permet de clarifier quel paradigme est le plus approprié pour les écritures de grand livre Beancount.

L'article​

Wang et al. proposent CausalTAD, une méthode qui se superpose aux détecteurs d'anomalies LLM de type AnoLLM et apporte une modification ciblée : au lieu de sérialiser les lignes tabulaires dans un ordre de colonnes aléatoire ou arbitraire, elle découvre les dépendances causales entre les colonnes et les réordonne pour respecter ces dépendances avant que le LLM ne lise la ligne.

L'article comporte deux parties mobiles. Premièrement, un module d'ordonnancement des colonnes piloté par la causalité. Les auteurs adaptent le framework d'extraction de facteurs COAT : un LLM lit les métadonnées des colonnes et des échantillons pour extraire des facteurs sémantiques de haut niveau (pour les transactions par carte de crédit, un facteur comme « Compensation » pourrait englober les colonnes montant et marchand). À partir de ces facteurs, trois algorithmes de découverte causale — PC, LiNGAM et FCI — construisent chacun un graphe causal dirigé sur les facteurs. Le problème de réordonnancement des colonnes devient alors un Problème d'Ordonnancement Linéaire (Linear Ordering Problem) : trouver la permutation π qui maximise la somme des poids des arêtes dirigées, de sorte que les colonnes de cause apparaissent avant les colonnes d'effet dans le texte sérialisé. Comme le PL (programmation linéaire) possède de nombreuses solutions quasi optimales, ils échantillonnent K ≈ 10 ordonnancements dans les 90 % de l'optimum et en font la moyenne.

Deuxièmement, un module de repondération sensible à la causalité. Toutes les colonnes ne sont pas également pertinentes. Une colonne qui influence de nombreux facteurs reçoit un poids plus élevé αj = |M⁻¹(cj)|, soit le nombre de facteurs auxquels elle contribue. Le score d'anomalie final est la moyenne pondérée des log-vraisemblances négatives par colonne à travers les K ordonnancements.

Idées clés​

• L'ordonnancement des colonnes est un biais inductif non trivial pour les LLM autorégressifs : placer une colonne de cause avant sa colonne d'effet permet au modèle de se conditionner sur le bon contexte lors de l'attribution d'une vraisemblance à l'effet.
• La découverte causale au niveau des facteurs (plutôt qu'au niveau des colonnes brutes) permet à la méthode de gérer des tableaux de types mixtes où la découverte causale directe entre colonnes hétérogènes est parasitée.
• Sur 6 jeux de données de référence de types mixtes, CausalTAD avec SmolLM-135M atteint une AUC-ROC moyenne de 0,834 contre 0,803 pour AnoLLM — une amélioration absolue de 3,1 points avec le même modèle de base.
• Sur le jeu de données Fake Job Posts spécifiquement, CausalTAD obtient 0,873 contre 0,800 pour AnoLLM — un gain relatif de 9,1 %, ce qui est assez important pour compter dans un système de tri réel.
• À travers 30 jeux de données de référence numériques ODDS, CausalTAD atteint la meilleure AUC-ROC moyenne, surpassant systématiquement les lignes de base classiques (Isolation Forest, ECOD, KNN) et les méthodes profondes (DeepSVDD, SLAD).
• Les trois algorithmes de découverte causale battent l'ordonnancement aléatoire dans l'ablation ; LiNGAM l'emporte légèrement sur PC et FCI sur les jeux de données mixtes.

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

L'affirmation centrale — selon laquelle l'ordre causal des colonnes aide — est bien étayée. L'ablation est claire : remplacer l'ordonnancement aléatoire par l'une des trois méthodes de découverte causale améliore les résultats sur le benchmark Fake Job Posts (de 0,832 à 0,870–0,873), et la repondération par le nombre de facteurs aide davantage dans chaque configuration. C'est un argument crédible.

Ce que je trouve moins convaincant, c'est l'hypothèse de l'auto-amorçage (bootstrapping). Le graphe causal est construit en utilisant un LLM pour extraire des facteurs sémantiques des données mêmes que le système est censé analyser. Si le LLM comprend mal le domaine — par exemple, pour un système comptable sur mesure avec des noms de colonnes non standard — l'extraction des facteurs sera erronée, et un mauvais graphe causal est sans doute pire qu'un ordonnancement aléatoire car il introduit un biais systématique. Les auteurs reconnaissent ce risque (« repose sur la capacité des LLM pour l'extraction de facteurs ») mais n'évaluent pas l'exactitude de l'extraction des facteurs de manière indépendante.

Il y a aussi une question de surcharge de calcul qui est plus sérieuse que ce que suggère l'article. L'exécution de trois algorithmes de découverte causale, la résolution d'un PL, l'échantillonnage de K ordonnancements, puis l'exécution de l'inférence sur K versions sérialisées de chaque point de test multiplie le coût d'inférence par K. Pour un grand livre avec des millions d'écritures, cela compte. L'article note que « les travaux futurs pourraient se concentrer sur l'amélioration de l'efficacité » mais ne propose aucun profilage concret.

Enfin, les 30 jeux de données ODDS numériques sont très étudiés et sans doute saturés pour des méthodes comme celle-ci. Le signal le plus significatif se trouve dans les 6 jeux de données de types mixtes — qui sont les plus réalistes pour la finance — et les améliorations y sont, bien que réelles, quelque peu modestes en termes absolus.

Pourquoi cela est important pour l'IA financière​

Les transactions Beancount ont une véritable structure causale : le montant de l'imputation détermine causalement la sélection du compte, le compte détermine l'attente vis-à-vis de la contrepartie, et le texte du mémo est causalement en aval des trois. La sérialisation aléatoire des colonnes ignore cela, ce qui signifie qu'un modèle de type AnoLLM voit « memo : courses | compte : Dépenses:Alimentation | montant : 4200 $ » aussi librement que la version correctement ordonnée.

CausalTAD offre un moyen structuré d'encoder « le montant et le compte viennent en premier » sans l'intégrer en dur comme une règle. Pour les agents d'audit de Bean Labs, cela suggère un choix architectural pratique : avant de noter un lot de transactions pour les anomalies, effectuer une passe pour découvrir le graphe causal sur le schéma des colonnes du grand livre, puis utiliser cet ordonnancement fixe pour toutes les inférences ultérieures. La surcharge est payée une seule fois au niveau du schéma, pas par transaction.

L'exemple de détection de fraude par carte de crédit dans l'article possède essentiellement la même structure de tâche que la détection d'anomalies dans un grand livre : des caractéristiques hétérogènes, des étiquettes rares et un ordre causal que les experts du domaine connaissent intuitivement mais que les LLM ignoreraient autrement.

Lectures recommandées​

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — le benchmark systématique à travers trois paradigmes de détection d'anomalies par LLM dans lesquels CausalTAD s'inscrit ; le lire donne une vue d'ensemble plutôt que la seule comparaison AnoLLM vs CausalTAD.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — le framework d'extraction de facteurs que CausalTAD adapte ; comprendre son fonctionnement permet de clarifier les points de défaillance potentiels de la qualité du graphe causal.
• Causal discovery in heterogeneous data: a survey — pour comprendre les mérites relatifs de PC vs LiNGAM vs FCI sur les données tabulaires de types mixtes, puisque l'article traite les trois comme interchangeables alors qu'ils font des hypothèses d'indépendance différentes.

L'article​

AnoLLM reformule la détection d'anomalies tabulaires comme une estimation de densité de modèle de langage plutôt que comme une classification par prompt. Au lieu de demander au LLM de nommer les lignes qui semblent suspectes, les auteurs effectuent un fine-tuning d'un modèle de langage pré-entraîné sur des lignes d'entraînement sérialisées en distribution (normales), puis attribuent un score à chaque ligne de test en fonction de sa vraisemblance logarithmique négative (negative log-likelihood ou NLL) sous cette distribution apprise. Une ligne qui ne ressemble en rien à la distribution d'entraînement obtient une NLL élevée — c'est le score d'anomalie. Pas de format d'indice, pas d'analyse de sortie, pas d'extraction regex fragile.

La sérialisation convertit chaque ligne de tableau en une chaîne de caractères en langage naturel avec les noms et les valeurs des caractéristiques (features). Pour les colonnes de type texte, la NLL est normalisée par colonne afin d'éviter le biais de longueur, où des descriptions plus longues accumuleraient sinon mécaniquement des coûts de probabilité plus élevés. Pour les colonnes numériques et catégorielles, la NLL brute au niveau des jetons (tokens) est additionnée sur l'ensemble du champ. Le modèle est affiné dans un cadre semi-supervisé — seules les lignes étiquetées comme normales entrent dans l'entraînement — pendant jusqu'à 2 000 étapes en utilisant un entraînement GPU distribué.

Idées clés​

• Le problème du format de sortie : les approches antérieures de prédiction d'indices exigent que les LLM produisent de manière fiable des indices de lignes anormales à partir d'un lot. Les modèles de la famille Llama associent fréquemment des indices erronés à des valeurs, génèrent des indices dépassant la taille du lot, ou listent simplement tout comme anormal. La NLL contourne entièrement cela.
• AnoLLM obtient les meilleures performances sur six jeux de données de référence avec des types de caractéristiques mixtes, notamment la détection de fraude à l'assurance automobile et des jeux de données de fraude e-commerce de Kaggle.
• Sur les 30 jeux de données de référence ODDS majoritairement numériques, AnoLLM affiche des performances équivalentes aux meilleures références classiques — pas nettement meilleures, juste compétitives.
• La normalisation de la NLL par colonne pour les caractéristiques textuelles est une décision technique mineure mais cruciale : sans elle, une description de transaction de trente jetons dominerait le score par rapport à un montant à deux chiffres, ce qui constitue un mauvais biais inductif.
• Le contexte de la référence d'entraînement : l'approche GPT-4 zero-shot (arXiv:2406.16308) atteint une AUROC moyenne de 74,1 sur ODDS, comparable à ECOD (75,5) et KNN (70,7). L'avantage d'AnoLLM apparaît spécifiquement sur les jeux de données où les caractéristiques textuelles et catégorielles portent un signal d'anomalie significatif.

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

L'idée centrale de la NLL est solide. Utiliser un modèle de langage affiné comme estimateur de densité sur des lignes sérialisées est rigoureux, et cela gère naturellement la distribution conjointe de toutes les colonnes simultanément — ce que les détecteurs non supervisés classiques appliqués colonne par colonne ne peuvent pas faire proprement. La correction de la prédiction d'indice est réellement utile et la comparaison avec la référence zero-shot est équitable.

Ce qui me dérange, c'est l'écart coût-bénéfice que l'article sous-estime. AnoLLM nécessite le fine-tuning et l'hébergement d'un LLM pour l'inférence — un engagement infrastructurel substantiel par rapport à l'ajustement d'un ECOD ou d'un IsolationForest sur un CPU en quelques secondes. Sur le benchmark ODDS (purement numérique), AnoLLM n'est qu'au "même niveau", pas meilleur. L'argument en faveur d'AnoLLM se situe donc entièrement dans le régime des types mixtes, où les six jeux de données évalués proviennent de la détection de fraude sur Kaggle. Six jeux de données constituent une base empirique mince pour une recommandation forte, d'autant plus que les jeux de données de référence de Kaggle ont tendance à avoir des schémas propres, une sémantique de colonne fixe et une vérité terrain connue — autant de choses qui font souvent défaut aux données comptables de production.

Le problème de l'ordre des colonnes reste également ouvert. CausalTAD (arXiv:2602.07798) a immédiatement identifié cette lacune : AnoLLM sérialise les colonnes dans un ordre arbitraire, ignorant les relations causales entre les champs. Pour les données structurées avec des chaînes causales connues — le type de compte influence les plages de transactions valides, qui influencent la contrepartie attendue — c'est une réelle limitation. CausalTAD formule le réordonnancement comme un problème d'ordonnancement linéaire et rapporte une amélioration constante par rapport à AnoLLM sur plus de 30 jeux de données. Le fait que cette lacune existait et ait pu être identifiée si rapidement suggère que la conception de la sérialisation d'AnoLLM n'était pas totalement aboutie.

Il y a aussi une question d'échelle que l'article n'aborde pas : à partir de quel volume d'exemples d'entraînement normaux le fine-tuning d'un LLM devient-il plus rentable qu'un modèle de deep learning tabulaire entraîné directement sur les caractéristiques numériques ? Pour les grands livres Beancount personnels comportant quelques milliers d'entrées, le coût de calcul peut facilement éclipser tout gain de précision.

Pourquoi cela compte pour l'IA financière​

Les écritures d'un grand livre Beancount sont exactement le genre de données à types mixtes que cible AnoLLM : montants (numériques), noms de comptes (texte structuré), bénéficiaire/libellé (texte libre), étiquettes (catégorielles), dates (structurées). Une seule ligne comme 2024-03-15 * "AWS" "Facture Cloud" Assets:Checking -2400.00 USD encode des informations à travers tous ces types simultanément. Les détecteurs d'anomalies classiques peinent ici car ils nécessitent une gestion distincte pour chaque type de colonne et perdent les corrélations entre elles — le schéma conjoint selon lequel les factures "AWS" devraient se situer dans une certaine fourchette et affecter un compte spécifique.

L'approche NLL d'AnoLLM permettrait, en principe, d'apprendre ces schémas conjoints à partir des écritures historiques normales et de signaler les écarts sur n'importe quelle combinaison de colonnes. C'est potentiellement plus utile que des tests statistiques sur une seule colonne ou des règles JET.

Cela dit, la contrainte de la comptabilité en partie double est une connaissance structurelle qu'AnoLLM ne peut pas apprendre uniquement à partir de lignes sérialisées — les débits doivent être égaux aux crédits, les hiérarchies de comptes doivent être respectées. Ces invariants de domaine sont des contraintes strictes, pas des régularités statistiques, et aucun volume de fine-tuning de LLM sur des lignes historiques ne les fera respecter de manière fiable si les données d'entraînement contiennent des exceptions ou des artefacts d'arrondi. La bonne architecture combine probablement le score NLL d'AnoLLM pour les anomalies sémantiques avec des vérifications de règles explicites pour les anomalies structurelles.

Que lire ensuite​

• CausalTAD (arXiv:2602.07798) — améliore directement AnoLLM en injectant un ordonnancement causal des colonnes ; la suite la plus immédiate à évaluer.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — fournit l'évaluation systématique multi-paradigme qui manque aux articles sur les méthodes individuelles.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) — le modèle BE-GREAT qu'AnoLLM utilise comme base ; le comprendre permet d'éclaircir ce qu'AnoLLM améliore réellement au-delà de la prédiction d'indices.

L'article​

Figueroa, Grundmann, Freidank, Löser et Nejdl évaluent cinq modèles à poids ouverts de ~7B paramètres sur un benchmark à deux tâches qu'ils appellent LLMFinLiteracy. La tâche 1 demande aux modèles de générer des scénarios textuels qui affecteraient un ratio de liquidité donné (ratio de liquidité générale, réduite ou immédiate) à partir d'un bilan trimestriel réel de l'une des cinq sociétés cotées au DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). La tâche 2 demande aux modèles de traduire ces scénarios en transactions Beancount compilables. Le compilateur Beancount sert de vérificateur syntaxique de référence ; des experts humains évaluent la justesse sémantique. L'article introduit une taxonomie d'erreurs en 12 classes pour les deux tâches et utilise un prompt de chaîne de pensée en 9 étapes incluant les règles de comptabilité en partie double, un exemple d'entrée/sortie et le bilan réel de l'entreprise au format Beancount. Les modèles évalués — Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B et CodeQwen-1.5-7B — ont tous été exécutés sur site en raison de la sensibilité des données financières. Le corpus totalise 1 500 échantillons générés, avec 300 entrées stratifiées évaluées par des experts humains.

Idées clés​

• Seulement 7 des 300 paires scénario-transaction évaluées (2,3 %) étaient entièrement correctes de bout en bout ; même en se limitant aux trois modèles à usage général, le taux ne grimpe qu'à 3,8 %.
• Les deux meilleurs modèles, Qwen-2-7B et Mistral-7B, produisent des scénarios corrects seulement 21,67 % et 20,00 % du temps, et des transactions compilables correctes seulement 16,67 % et 10,00 % du temps.
• Les modèles spécialisés dans le code (CodeLlama, CodeQwen) ont obtenu un score de 0 % sur les deux tâches ; ils ont répondu au modèle de prompt par une chaîne littérale « Processed — Waiting for next input », ignorant complètement la tâche.
• La syntaxe n'est pas le goulot d'étranglement : aucun modèle n'a produit une seule erreur de syntaxe. Les échecs résident entièrement dans le raisonnement comptable — les erreurs d'équilibre dominent pour Qwen-2 (61,67 %) et Llama-3 (38,33 %), tandis que Mistral fait principalement référence à des comptes qui n'existent pas dans le bilan fourni (45 % d'erreurs de comptes inconnus).
• Une fraction significative des transactions qui se compilent avec succès sont sémantiquement erronées — l'astuce préférée du modèle étant de qualifier la diminution d'un passif de « vente de votre dette », ce qui augmente la trésorerie mais pour la mauvaise raison.
• GPT-4o, utilisé comme juge automatisé, n'a pas réussi à signaler les incohérences dans les 10 scénarios absurdes qui lui ont été présentés, confirmant que l'auto-évaluation par LLM n'est pas un garde-fou de qualité fiable pour les sorties comptables.
• Les modèles copient largement l'exemple d'entrée/sortie du prompt plutôt que de généraliser : les 7 paires correctes ressemblent étroitement à la structure de la transaction d'exemple fournie.

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

La contribution empirique centrale de l'article est solide. Le compilateur Beancount est un critère de justesse objectif et reproductible, et l'utilisation de bilans réels d'entreprises plutôt que de données fictives ajoute de la validité écologique. La taxonomie hiérarchique des erreurs est judicieusement conçue — l'arrêt de l'évaluation à la première erreur évite de gonfler les « points partiels » pour des sorties sans valeur.

Cela dit, il existe des limites évidentes que les auteurs reconnaissent pour la plupart. Cinq modèles à poids ouverts de ~7B de 2023-2024 représentent une tranche étroite du paysage des capacités ; GPT-4o et Claude ont été exclus pour des raisons de confidentialité, ce qui est compréhensible mais signifie que le chiffre principal (2,3 % de réussite) sous-estime la frontière technologique. Les formules des ratios financiers ont été délibérément omises des prompts pour tester les connaissances intrinsèques du domaine — un choix méthodologique intéressant, mais qui rend les résultats incomparables à tout système qui inclurait raisonnablement la documentation des formules. Et 300 échantillons évalués par des humains sur cinq modèles, trois ratios et cinq entreprises, c'est modeste ; les segments par modèle et par ratio sont trop petits (12 échantillons) pour tirer des conclusions solides sur la variance.

L'écart méthodologique le plus intéressant est l'absence de tout protocole itératif ou basé sur le feedback. Pas d'appel d'outils, pas d'auto-correction, pas de boucle de rétroaction du compilateur — juste une génération en un seul coup (one-shot). Étant donné que CRITIC (LOG-012) et les travaux connexes montrent que l'affinement interactif avec des outils améliore considérablement la précision sur les tâches aux résultats vérifiables, une expérience avec un compilateur-Beancount-dans-la-boucle aurait été bien plus informative sur la viabilité du déploiement.

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

Chaque décision de conception pour l'agent d'écriture de Bean Labs repose sur des hypothèses concernant ce que les LLM peuvent faire avec le DSL Beancount. Cet article est le premier ancrage empirique. Les conclusions principales sont décevantes mais aussi interprétables de manière utile.

Premièrement, les modes de défaillance sont spécifiques, pas aléatoires. Les erreurs d'équilibre et les comptes inconnus sont les deux problèmes dominants, et tous deux peuvent être résolus avec une boucle de rétroaction du compilateur : le compilateur Beancount vous indique exactement quel compte est inconnu et si la transaction est équilibrée. Une architecture d'agent qui itère sur la sortie du compilateur — au lieu de générer une fois et de s'arrêter — devrait surpasser considérablement les résultats en un seul coup présentés ici. Deuxièmement, la syntaxe est acquise. Les modèles ont clairement appris la grammaire de surface de Beancount ; ils ne parviennent tout simplement pas à traduire de manière fiable une intention financière en mouvements de compte corrects. Cette distinction est cruciale pour savoir où investir dans le prompt engineering et le réglage fin. Troisièmement, le constat selon lequel GPT-4o ne peut pas évaluer automatiquement la qualité comptable place la barre plus haut pour tout système de vérification automatisé : vous avez besoin du compilateur, plus de vérifications ponctuelles par des experts du domaine, et non d'un LLM comme critique.

L'article confirme également une chose que je soupçonnais depuis les travaux sur la détection d'anomalies (LOG-049) : les LLM opérant sur des transactions financières compilent et soumettent trop facilement. La catégorie « Incorrect | Compile » — des transactions qui passent la vérification syntaxique mais sont sémantiquement fausses — est exactement le mode de défaillance qu'un garde-fou de sécurité d'écriture doit intercepter. Une transaction peut être parfaitement équilibrée et tout de même enregistrer un revenu comme une diminution de passif, ce qui passerait inaperçu lors d'une vérification purement syntaxique.

Que lire ensuite​

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — score d'anomalie basé sur la vraisemblance comme alternative à l'approche de détection par lots ; se combine naturellement avec un signal du compilateur Beancount pour signaler des entrées structurellement valides mais statistiquement anormales.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — oriente les décisions à faible confiance vers un modèle plus large ou un humain ; répond directement à la question de savoir quand un agent d'écriture Beancount doit s'en remettre à une révision humaine plutôt que de poursuivre après une boucle de rétroaction du compilateur.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — le travail existant le plus pertinent pour construire un agent de correction avec compilateur dans la boucle au-dessus de l'architecture évaluée par cet article.