TableMaster : Raisonnement adaptatif pour la compréhension de tableaux avec les LLM

Le grand livre Beancount est, par essence, un tableau structuré : les comptes comme colonnes, le temps comme axe, les montants et les devises comme valeurs. Tout agent qui raisonne sur celui-ci doit faire ce que TableMaster fait — trouver les bonnes lignes et colonnes, comprendre la signification des chiffres et choisir entre un calcul symbolique ou un raisonnement en langage naturel. TableMaster de Lang Cao et Hanbing Liu (arXiv:2501.19378) est le pipeline de compréhension de tableaux le plus performant que j'ai vu à ce jour sans réglage fin (fine-tuning), et je voulais comprendre s'il fait réellement progresser l'état de l'art de manière structurée ou s'il se contente d'empiler des heuristiques de prompting jusqu'à ce que le benchmark s'améliore.

L'article

TableMaster est un framework basé sur le prompting qui s'attaque à quatre modes d'échec spécifiques des LLM lors de réponses aux questions tabulaires : ils peinent à localiser la cellule pertinente dans un grand tableau, ils ignorent le contexte sémantique encodé dans les en-têtes de colonnes, ils hallucinent des calculs arithmétiques lors d'un raisonnement en texte brut, et ils échouent lorsque le raisonnement symbolique (SQL, Python) rencontre des données bruitées ou de types mixtes. Les auteurs répondent à chaque échec par un module dédié, assemblé dans un pipeline en trois étapes. La première étape construit un « tableau de focalisation » (table-of-focus) — un sous-tableau élagué contenant uniquement les lignes et colonnes pertinentes pour la requête — en utilisant une recherche de colonnes classées par LLM et un filtrage de lignes basé sur SQL. La deuxième étape verbalise ce sous-tableau en langage naturel et vérifie si l'extrait est suffisant pour répondre à la question, en l'élargissant de manière itérative si nécessaire. La troisième étape applique un raisonnement adaptatif : un LLM décide pour chaque requête s'il doit exécuter une chaîne de pensée (chain-of-thought) sur la description verbalisée ou générer et exécuter du Python ou du SQL, le chemin symbolique étant guidé par la description en langage naturel pour gérer les cas où les valeurs du tableau sont des chaînes de caractères complexes plutôt que des données numériques propres.

Aucun nouveau modèle n'est entraîné. Tout fonctionne sur des LLM polyvalents (GPT-3.5-turbo, GPT-4o-mini, Llama-3.1-70B) via le prompting.

Idées clés

• Sur WikiTQ avec GPT-4o-mini, TableMaster atteint 78,13 %, contre 55,60 % pour Chain-of-Table et 64,73 % pour PoTable sur le même modèle — une amélioration de 13,40 points par rapport à la meilleure référence suivante.
• Le même schéma se répète avec GPT-3.5-turbo (68,21 % contre ~58 % auparavant) et Llama-3.1-70B (77,95 %), montrant que les gains ne sont pas spécifiques à un modèle.
• Sur TabFact (vérification de faits), TableMaster atteint 90,12 % avec GPT-4o-mini contre 84,24 % pour Chain-of-Table — une amélioration plus modeste mais constante.
• L'ablation révèle que la suppression du raisonnement textuel est ce qui nuit le plus (–4,28 %), suivie de la suppression de l'extraction de structure (–3,38 %). Le basculement adaptatif entre les modes est véritablement structurant.
• La taille du tableau est le principal indicateur d'échec : les performances se dégradent de manière monotone à mesure que le nombre de lignes, de colonnes et de jetons augmente, quel que soit le modèle.
• Le raisonnement symbolique se dégrade de 31,8 % sur les tableaux bruités contre 20,5 % pour le raisonnement textuel — le chemin symbolique guidé par le texte existe précisément pour atténuer ce mode d'échec.
• Le raisonnement textuel seul se dégrade de 20,1 % sur les requêtes lourdes en calcul contre 72,4 % sur les tâches sans calcul — illustrant exactement pourquoi le basculement hybride est crucial.

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

Le diagnostic des quatre défis est bien motivé et correspond clairement à des cas d'échec réels. L'ablation est honnête : la suppression de n'importe quel composant est préjudiciable, avec une ampleur proportionnelle à l'utilisation réelle de ce composant. C'est plus probant que les ablations habituelles où la suppression de composants ne change rien parce que le modèle a appris à les contourner.

Ce que je trouve plus difficile à évaluer est le classificateur de raisonnement adaptatif lui-même. La décision d'orienter une requête vers le texte ou le code est prise par le LLM via le prompting — l'article n'indique pas à quelle fréquence cet aiguillage est correct, ce qui se passe en cas d'erreur (par exemple, orienter un calcul vers le texte), ou si une règle simple (la requête contient-elle des opérateurs arithmétiques ?) obtiendrait des performances comparables. Étant donné que le raisonnement textuel est le plus gros contributeur dans l'ablation, je soupçonne que la plupart des requêtes empruntent par défaut le chemin textuel et que la branche symbolique porte une fraction plus faible que ce que la présentation suggère.

La comparaison avec Chain-of-Table est également légèrement gonflée par le contexte. L'évaluation originale de Chain-of-Table utilisait PaLM 2 et GPT-3.5 — le chiffre de 55,60 % pour Chain-of-Table affiché pour GPT-4o-mini pourrait refléter un manque d'optimisation des prompts de Chain-of-Table pour ce modèle plutôt qu'un véritable avantage architectural. Cela n'invalide pas le résultat, mais cela signifie que l'écart mis en avant doit être lu comme une borne supérieure de l'amélioration réelle.

L'article a fait l'objet de six révisions depuis janvier 2025, ce qui est inhabituel. La portée est limitée aux jeux de données en anglais et aux tableaux allant jusqu'à quelques centaines de lignes. Aucune analyse du surcoût n'est présentée — chaque requête nécessite désormais plusieurs appels au LLM (classement des colonnes, SQL des lignes, vérification de suffisance, verbalisation, aiguillage, raisonnement), et aux prix des modèles de pointe, cela s'accumule rapidement.

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

Les modes d'échec que TableMaster traite sont exactement ceux auxquels je m'attends pour les agents de grand livre Beancount. Un grand livre avec trois ans de transactions sur 40 comptes est un tableau large et sémantiquement riche — « quel était mon revenu net provenant du travail en freelance au T3 2023 ? » nécessite de trouver les bons comptes (recherche de colonnes), de filtrer par date (recherche de lignes), de comprendre que « freelance » correspond à plusieurs noms de comptes (enrichissement sémantique) et de sommer les montants avec précision (arithmétique symbolique). Le pipeline de TableMaster, appliqué à une interface beanquery, s'attaquerait précisément à ces étapes.

La limitation la plus importante pour les grands livres est l'échelle. Les tableaux WikiTQ ont au plus quelques dizaines de lignes et une poignée de colonnes ; un véritable grand livre Beancount pluriannuel contient des milliers d'écritures. L'article montre que les performances se dégradent de manière monotone avec la taille du tableau et ne teste pas au-delà de quelques centaines de lignes. L'extraction du tableau de focalisation est censée répondre à ce problème, mais le filtre de lignes basé sur SQL est lui-même une requête générée par LLM sur l'ensemble du tableau — déplaçant le problème complexe plutôt que de le résoudre. L'interaction avec une mémoire hiérarchique de type MemGPT ou avec une couche beanquery pré-indexée est la prochaine étape naturelle.

Le chemin symbolique guidé par le texte est directement applicable à Beancount. Les montants des grands livres sont souvent entourés de métadonnées (codes de devises, annotations de lots, marqueurs de prix de revient) qui feraient échouer un parseur de nombres Python naïf. Ancrer la génération de code dans une description en langage naturel de ce que le code doit calculer est une atténuation judicieuse, bien qu'elle nécessite une évaluation systématique sur de réels formats d'exportation Beancount.

Ce qu'il faut lire ensuite

• H-STAR: LLM-driven Hybrid SQL-Text Adaptive Reasoning on Tables (arXiv:2407.05952) — le précurseur le plus direct de l'aiguillage adaptatif de TableMaster, avec une stratégie d'extraction en deux étapes (colonnes puis lignes) ; il vaut la peine de comparer directement les architectures pour comprendre l'apport de TableMaster.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — bien que TableMaster cible le QA, la représentation du tableau et le pipeline de normalisation sont tout aussi pertinents pour la détection d'anomalies ; le score basé sur la vraisemblance d'AnoLLM nécessite une étape de pré-traitement similaire.
• CFMS: A Coarse-to-Fine Multimodal Synthesis Framework for Enhanced Tabular Reasoning (arXiv:2604.10973) — semble étendre l'idée d'extraction progressive (coarse-to-fine) aux tableaux multimodaux ; pertinent si les visualisations de grands livres Beancount (graphiques, relevés PDF) doivent être réconciliées avec des entrées textuelles structurées.