Chain-of-Table : Évolution des tableaux dans la chaîne de raisonnement des LLM

Je reviens sans cesse au même constat inconfortable concernant le raisonnement tabulaire : lorsque les LLM expliquent leur travail sur des tableaux en utilisant une chaîne de pensée textuelle ordinaire, ils narrent une représentation tout en raisonnant sur une autre. Chain-of-Table, un article de Google Research publié à l'ICLR 2024, prend cette tension au sérieux et propose une solution simple : laisser le tableau lui-même porter l'état de raisonnement intermédiaire, et non le texte.

L'article

Wang et al. présentent Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding (arXiv:2401.04398, ICLR 2024). L'article aborde une lacune laissée par l'incitation par chaîne de pensée (CoT) standard lorsqu'elle est appliquée aux données tabulaires : la CoT raisonne en langage naturel, mais les tableaux sont des artefacts structurés, et la narration textuelle des transformations de tableaux est à la fois verbeuse et sujette à des pertes d'information. L'idée centrale est de laisser le LLM planifier une séquence d'opérations tabulaires programmatiques — filtrer, grouper, trier, sélectionner une colonne, ajouter une colonne — en exécutant chacune d'elles pour produire un état de tableau intermédiaire, et en réinjectant ce tableau évolué au LLM comme entrée pour l'étape suivante. La réponse finale est générée à partir de l'état terminal du tableau plutôt qu'à partir d'une longue chaîne textuelle. Les auteurs font une analogie explicite avec le développement SQL : un analyste qualifié écrit des étapes intermédiaires CREATE TABLE ... AS SELECT, et non une seule requête monolithique. Chain-of-Table formalise cette pratique pour les agents LLM.

L'évaluation couvre trois points de référence : WikiTableQuestions (WikiTQ), TabFact et FeTaQA. Le modèle principal est PaLM 2, avec une validation croisée sur GPT-3.5 et LLaMA 2 70B.

Idées clés

• Chain-of-Table atteint une précision de dénotation de 67,31 % sur WikiTQ contre 61,48 % pour Dater, la base de référence précédente la plus solide — une amélioration de +5,83 points de pourcentage.
• Sur les tableaux dépassant 4 000 jetons, l'avantage passe à +10,25 points (44,87 % contre 34,62 %), ce qui est l'endroit où la méthode importe le plus en pratique.
• La précision de TabFact atteint 86,61 % contre 84,63 % pour Dater ; le score BLEU de FeTaQA passe de 29,47 à 32,61.
• Les cinq opérations atomiques — f_select_row, f_select_column, f_group_by, f_sort_by, f_add_column — couvrent la grande majorité des schémas de raisonnement observés dans ces tests ; f_group_by effectue l'essentiel du travail sur WikiTQ, où le comptage est le principal mode d'échec.
• Chain-of-Table nécessite au maximum 25 générations d'échantillons par question, contre 50 pour Binder et 100 pour Dater — un gain d'efficacité de 50 à 75 % parallèlement à une meilleure précision, ce qui est véritablement inhabituel dans la recherche sur les LLM où le compromis va presque toujours dans l'autre sens.
• L'approche est indépendante du modèle : elle surpasse systématiquement les bases de référence CoT textuelles sur PaLM 2, GPT-3.5 et LLaMA 2.

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

La contribution empirique centrale de l'article est solide. Les points de référence sont standards, les bases de référence sont équitables et l'histoire de l'efficacité est convaincante. Faire du tableau lui-même une représentation intermédiaire explicite plutôt que de le narrer en prose est une idée propre avec une motivation intuitive, et les résultats sur les grands tableaux sont les preuves les plus convaincantes : lorsque le tableau tient à peine dans le contexte, le fait d'avoir des opérations qui le réduisent progressivement à l'essentiel est clairement préférable à la production d'encore plus de texte.

Cela dit, il existe de réelles lacunes. L'analyse de la propagation des erreurs est superficielle. Si le LLM génère un mauvais argument f_select_row à la deuxième étape d'une chaîne de cinq étapes, chaque opération suivante s'exécute sur un tableau intermédiaire corrompu, et la réponse finale est sans valeur. L'article rapporte la précision globale mais n'analyse pas la fréquence à laquelle le raisonnement échoue en raison d'erreurs aux premières étapes par rapport aux étapes tardives, ou si l'approche est robuste aux opérations partiellement erronées. Pour une méthode qui dépend d'une séquence d'appels corrects, il s'agit d'une omission significative.

Le vocabulaire des opérations est également un pari. Cinq opérations couvrent la plupart des modèles dans WikiTQ et TabFact parce que ces tests ont été conçus autour de tâches de tableaux relationnels. Les tableaux financiers du monde réel — bilans, balances de vérification, états fiscaux — nécessitent couramment des jointures entre tableaux liés, des agrégats calculés avec des conditions (SOMME des débits OÙ le compte COMMENCE PAR '6') et des transformations pivots. Aucun de ces éléments ne figure dans l'ensemble des opérations. Les auteurs le reconnaissent implicitement mais ne le testent pas.

Enfin, il n'y a pas de justification théorique expliquant pourquoi les états de tableaux intermédiaires devraient être meilleurs que le texte intermédiaire. L'intuition est séduisante, mais l'article est purement empirique. Les travaux suivants (TableMaster, arXiv:2501.19378 ; H-STAR, NAACL 2025) sont rapidement passés à des approches hybrides adaptatives mélangeant SQL et raisonnement textuel, ce qui suggère que la communauté a perçu la même lacune que moi : les opérations purement tabulaires ne sont pas universellement meilleures, mais simplement meilleures sur les tests effectués.

Pourquoi cela compte pour l'IA financière

Pour les agents de grand livre Beancount, l'architecture de Chain-of-Table correspond presque parfaitement à ce que je souhaite dans un pipeline de rétro-écriture. Une requête Beancount telle que « quelles sont mes dépenses nettes par catégorie pour le premier trimestre, en excluant les transactions étiquetées :ignore ? » nécessite exactement le type de transformations de tableau séquentielles proposées par l'article : filtrer les lignes par date, filtrer par étiquette, grouper par catégorie de compte, sommer les montants. Si l'agent peut planifier cela comme une chaîne d'opérations intermédiaires explicites plutôt que de générer une requête unique ou de raisonner en prose, la piste d'audit est lisible et chaque étape est vérifiable indépendamment.

L'amélioration de l'efficacité sur les grands tableaux est également directement pertinente. Un grand livre Beancount pluriannuel avec des dizaines de milliers de transactions dépasse facilement les 4 000 jetons lorsqu'il est matérialisé. L'amélioration de 10 points dans ce régime n'est pas un artefact de test ; elle reflète ce qui se passe réellement lorsque le tableau doit être progressivement restreint avant que le raisonnement puisse être précis.

La pièce manquante pour Beancount est l'opération de jointure. La comptabilité en partie double lie les transactions entre les comptes, et toute tâche de rapprochement nécessite un raisonnement sur au moins deux chronologies de comptes. Chain-of-Table tel qu'il est publié ne peut pas exprimer cela. Étendre le vocabulaire des opérations pour inclure des jointures entre comptes est la prochaine étape d'ingénierie évidente pour un agent de raisonnement Beancount en production.

Ce qu'il faut lire ensuite

• Chain-of-Query: Unleashing the Power of LLMs in SQL-Aided Table Understanding via Multi-Agent Collaboration (2025, arXiv:2508.15809) — étend le concept d'opération vers la génération SQL multi-agents, ce qui comble la lacune des jointures.
• TableMaster: A Recipe to Advance Table Understanding with Language Models (arXiv:2501.19378) — introduit un raisonnement adaptatif qui bascule entre les opérations tabulaires et la CoT textuelle ; le successeur le plus direct de Chain-of-Table.
• DATER: Decomposition-based Text-to-SQL for LLMs over Long Context (arXiv:2308.01463) — approche de décomposition complémentaire pour le SQL complexe sur de grands schémas, pertinente pour la conception d'interfaces en langage naturel pour beanquery.