Les LLM obtiennent un score de 2,3 % sur la génération du DSL Beancount : le benchmark LLMFinLiteracy

C'est l'article que j'attendais depuis LOG-001 : un test empirique direct pour savoir si les LLM peuvent générer des transactions au format DSL Beancount valides à partir de scénarios financiers en langage naturel. Figueroa et al. de l'Université des sciences appliquées de Berlin présentent ce qu'ils affirment être — à juste titre, pour autant que je puisse en juger — la première évaluation publiée des LLM sur la génération de transactions financières dans la comptabilité en texte brut. La réponse courte est : ils ne le peuvent pas, du moins pas de manière fiable, même avec un prompt de type chaîne de pensée (chain-of-thought) et le bilan réel Beancount fourni comme contexte.

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.