Les LLM peuvent-ils raisonner sur des données tabulaires ? Ce que quatre benchmarks nous disent sur l'IA financière

Les tableaux sont le mode de pensée des comptables. Un grand livre Beancount est essentiellement un tableau — les comptes en lignes, les dates et les montants en colonnes, les assertions comme contraintes entre les cellules. Ainsi, lorsque j'ai commencé à me demander si les LLM pouvaient alimenter des agents financiers autonomes, j'ai sans cesse été confronté à la même question préalable : peuvent-ils seulement lire un tableau de manière fiable ? La littérature à ce sujet est plus accablante que ce à quoi je m'attendais.

L'étude

Fang et al. ont publié "Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey" dans TMLR 2024 (arXiv:2402.17944). Il s'agit d'une taxonomie de 41 pages couvrant trois domaines : la prédiction de résultats structurés à partir de caractéristiques tabulaires, la génération de données tabulaires synthétiques et la compréhension des tableaux suffisamment poussée pour répondre à des questions les concernant. Le volet compréhension — réponse aux questions sur les tableaux (TableQA), vérification des faits et raisonnement structurel — est l'endroit où réside le travail le plus pertinent pour l'IA financière.

L'article que j'ai lu en parallèle, "Table Meets LLM: Can Large Language Models Understand Structured Table Data?" par Sui et al. (WSDM 2024, arXiv:2305.13062), adopte une approche plus contrôlée : ils définissent un benchmark de Capacité de Compréhension Structurelle (SUC) avec sept tâches spécifiques — partition de tableau, détection de taille, détection de cellules fusionnées, recherche de cellule, recherche inversée, récupération de colonne et récupération de ligne — et testent directement GPT-3.5 et GPT-4. Pas de chaînes de raisonnement, pas d'astuces de récupération. Juste : le modèle peut-il faire ce qu'on lui demande ?

Idées clés

• L'écart de format est réel et étonnamment important. Sur le benchmark SUC, la sérialisation HTML surpasse le format de langage naturel avec séparateurs d'environ 6,76 % globalement. Le classement — HTML > XML > JSON > Markdown > NL+Sep — se maintient de manière cohérente à travers les tâches. Les fichiers Beancount sont plus proches de l'extrémité "langage naturel" de ce spectre, ce qui est un signal d'alarme.
• La recherche de cellule est étonnamment difficile. GPT-3.5 n'atteint que 44 % de précision sur la recherche directe de cellule (trouver la valeur à la ligne X, colonne Y). GPT-4 atteint 73,34 % sur la même tâche. Pour une opération déterministe qu'une formule de tableur traite en microsecondes, un écart de 26 points de pourcentage entre les modèles est alarmant.
• Les exemples few-shot sont des piliers structurels. La suppression des exemples 1-shot des invites SUC a provoqué une chute de précision globale de 30,38 % sur toutes les tâches. La compréhension structurelle du modèle est fortement étayée par la démonstration, et non véritablement intériorisée.
• L'écart humain-LLM sur les TableQA réels est énorme. TableBench (arXiv:2408.09174, AAAI 2025) évalue 886 questions à travers la vérification des faits, le raisonnement numérique, l'analyse de données et la visualisation. La précision humaine est de 85,91 %. GPT-4-Turbo obtient un score de 40,38 %, GPT-4o de 42,73 %. Les meilleurs modèles actuels affichent des performances correspondant à environ la moitié du niveau humain sur un benchmark conçu pour refléter la complexité des tableaux du monde réel.
• L'effondrement de la complexité sur les tableurs financiers est sévère. FinSheet-Bench (arXiv:2603.07316) teste les LLM sur des modèles de fonds de capital-investissement avec une complexité structurelle variable. Les recherches simples atteignent 89,1 % de précision. Les agrégations complexes chutent à 19,6 %. Le plus grand fichier de test (152 entreprises, 8 fonds) donne une précision moyenne de 48,6 % pour l'ensemble des modèles, contre 86,2 % pour le fichier le plus simple.
• Les tableaux longs cassent catégoriquement les modèles. L'enquête TMLR rapporte qu'au-delà de 1000 tokens, les performances de GPT-3 se dégradent jusqu'à devenir presque aléatoires. Même les modèles avec une fenêtre de contexte de 200K peinent avec des jeux de données massifs en raison du coût quadratique de l'auto-attention sur de longues séquences.

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

Le benchmark de Sui et al. est soigneusement conçu et les chiffres sont crédibles. La conclusion selon laquelle le HTML surpasse le markdown pour les tâches structurelles est contre-intuitive — le markdown est plus compact et les LLM en voient davantage lors de l'entraînement — mais elle s'aligne sur ce que l'on pourrait attendre : le balisage explicite du HTML donne au modèle plus de points d'ancrage pour naviguer dans la structure sans avoir à l'inférer.

Ce dont je doute : la technique d'auto-augmentation (incitation en deux étapes où la première invite demande au modèle d'identifier les valeurs critiques avant de répondre) produit des améliorations de 0,84 à 5,68 % sur les benchmarks en aval comme TabFact et ToTTo. Ce sont des chiffres réels issus d'expériences réelles, mais ils sont marginaux. La technique ne résout pas le problème fondamental — c'est un correctif d'ingénierie d'invite par-dessus une compréhension structurelle véritablement faible.

L'étude TMLR souffre du problème de portée commun à toutes les synthèses : elle couvre tout, de la prédiction tabulaire (le royaume de XGBoost) à la synthèse générative de tableaux en passant par les questions-réponses, ce qui dilue l'analyse. La section la plus exploitable pour mes besoins est le volet questions-réponses structurées, et même là, l'étude catalogue principalement des méthodes plutôt que de synthétiser celles qui sont réellement fiables.

La conclusion de FinSheet-Bench selon laquelle les agrégations complexes obtiennent un score de 19,6 % est le signal d'alarme le plus spécifique à la finance ici. L'agrégation de portefeuille, les consolidations au niveau des fonds et les comparaisons multi-périodes sont exactement les opérations qui rendent le reporting financier non trivial — et c'est précisément là que les LLM s'effondrent.

Pourquoi cela compte pour l'IA financière

Les journaux Beancount sont des tableaux. Lorsqu'un agent autonome lit un grand livre pour détecter des anomalies, générer des rapports ou décider d'une écriture comptable, il effectue un raisonnement tabulaire. Les preuves suggèrent que les LLM actuels gèrent raisonnablement bien les recherches simples (récupération de cellule à 73 % pour GPT-4) mais s'effondrent sur les opérations qui comptent le plus : l'agrégation en plusieurs étapes, l'estimation de la taille pour les grands livres volumineux et le raisonnement sur les variations structurelles.

La découverte sur la sérialisation a des implications pratiques immédiates. Si je transmets des fichiers Beancount à un LLM, le format que je choisis affecte la précision de plusieurs points de pourcentage avant même d'avoir écrit une seule ligne de logique d'agent. La syntaxe native de Beancount est proche de l'extrémité "NL+Sep" de la hiérarchie des formats — lisible pour les humains, sous-optimale pour les LLM. Convertir vers un format intermédiaire plus structuré (un tableau JSON ou HTML des transactions) avant de nourrir un modèle peut valoir le coût du prétraitement.

L'effondrement de la complexité à grande échelle est la conclusion la plus sobre. Un véritable grand livre Beancount pour une petite entreprise peut comporter des milliers de transactions, des dizaines de comptes et un historique sur plusieurs années. Les résultats de FinSheet-Bench suggèrent qu'une fois qu'un tableau atteint la taille où il devient réellement important, la précision des LLM se dégrade dans une zone qui n'est pas sûre pour des écritures comptables autonomes.

Que lire ensuite

• TableLLM (arXiv:2311.09206) — un modèle affiné entraîné sur 169 tableaux Kaggle (UniPredict) ; il surpasserait considérablement GPT-4 en zero-shot sur la prédiction tabulaire, ce qui suggère qu'un réglage fin spécifique au domaine reste la bonne approche pour les tâches de tableaux financiers.
• TAT-QA (arXiv:2105.07624) — un jeu de données spécifiquement pour le raisonnement discret sur des documents financiers hybrides (tableaux + texte, comme les rapports de résultats) ; le modèle TAT-LLM qui l'accompagne est le précédent le plus direct pour l'application de modèles spécialisés au raisonnement tabulaire financier.
• ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412) — se concentre sur les perturbations adverses comme le mélange des lignes et le réordonnancement des colonnes ; si un agent Beancount est robuste au réordonnancement, c'est le signe qu'il comprend la structure plutôt que la position.