TableLlama : un modèle ouvert de 7B peut-il égaler GPT-4 en compréhension de tableaux ?

Le journal MAC-SQL de la semaine dernière m'a fait réfléchir au maillon le plus faible des agents basés sur des tableaux : la capacité du modèle sous-jacent à comprendre la structure et la sémantique d'un tableau avant même de générer une requête. TableLlama (NAACL 2024) s'attaque directement à cette couche — non pas en améliorant l'interface de requête, mais en construisant un modèle open source généraliste capable de gérer un large éventail de tâches liées aux tableaux sans ingénierie spécifique à la tâche. Je le lis en ce moment car c'est la réponse la plus directe à la question de savoir si un modèle ouvert de 7B peut réellement égaler GPT-4 sur les problèmes de compréhension de tableaux auxquels un agent Beancount serait confronté.

L'article

TableLlama, par Tianshu Zhang, Xiang Yue, Yifei Li et Huan Sun de l'Université d'État de l'Ohio, affine Llama 2 (7B) sur un nouveau jeu de données de réglage par instructions nommé TableInstruct — 2,6 millions d'exemples couvrant 11 tâches de tableaux. Pour gérer le contexte étendu imposé par les tableaux, ils utilisent LongLoRA, une approche d'extension efficace en paramètres qui porte la fenêtre de contexte à 8 000 jetons sans réentraînement complet. L'évaluation couvre huit tâches intra-domaine (annotation de type de colonne, extraction de relations, liaison d'entités, augmentation de schéma, remplissage de lignes, QA sur tableaux hiérarchiques, QA sur cellules mises en évidence et vérification de faits) ainsi que six jeux de données hors domaine sur lesquels le modèle n'a jamais été entraîné.

L'affirmation principale : un seul modèle ouvert affiné peut égaler ou battre l'état de l'art (SOTA) spécifique à chaque tâche sur la plupart des benchmarks intra-domaine et surpasser le modèle de base Llama 2 de 5 à 44 points absolus hors domaine — réduisant notamment l'écart avec GPT-4 sur plusieurs tâches.

Idées clés

• Sur les tâches intra-domaine, TableLlama bat de manière décisive GPT-4 sur les tâches de reconnaissance structurelle : Annotation de type de colonne (F1 94,39 contre 31,75), Extraction de relations (F1 91,95 contre 52,95), BLEU FeTaQA (39,05 contre 21,70) et précision d'exécution HiTab (64,71 contre 48,40).
• Sur les jeux de données hors domaine, la situation s'inverse. GPT-4 mène sur la précision WikiTQ (68,40 contre 35,01) et HybridQA (58,60 contre 39,38) — deux tâches qui nécessitent un raisonnement compositionnel multi-sauts sur les tableaux plutôt qu'une simple reconnaissance de motifs structurels.
• WikiSQL expose l'écart de génération de requêtes de manière flagrante : TableLlama obtient 50,48 % contre un SOTA de 92,70 %. Cet écart de 42 points est le chiffre le plus pertinent en pratique pour quiconque construit des interfaces de langage naturel vers requête.
• LongLoRA est ici un pilier essentiel. Les tableaux financiers sont longs. Sans la fenêtre de contexte étendue, toute cette classe de tâches serait hors de portée pour un modèle de 7B.
• Les auteurs reconnaissent que les contraintes de calcul les ont limités à la taille 7B, laissant les variantes 13B et 70B non évaluées.

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

La configuration du benchmark compare des éléments incomparables d'une manière qui mérite examen. La comparaison intra-domaine oppose un TableLlama affiné à un GPT-4 en mode zero-shot. Sur les tâches basées sur TURL comme l'Annotation de type de colonne, le score de 31,75 F1 de GPT-4 ne signifie pas que GPT-4 est fondamentalement incapable de comprendre les types de colonnes — cela signifie qu'une invite zero-shot sans réglage spécifique au format échoue sur un jeu de données qui attend un format de sortie très particulier. La comparaison honnête se situe sur les tâches hors domaine, où aucun des deux modèles n'a vu de données d'entraînement, et là l'écart est frappant : précision WikiTQ de 35,01 contre 68,40.

WikiTQ est le bon test de résistance car il nécessite des questions telles que "Quel pays a remporté le plus de médailles dans les épreuves où le record précédent a été établi avant 1990 ?" — un véritable raisonnement compositionnel à travers les cellules du tableau. Le déficit de 33 points de TableLlama sur WikiTQ par rapport à GPT-4 est le signal le plus clair que le réglage par instructions sur des tâches structurelles ne se transfère pas automatiquement au raisonnement relationnel.

Les victoires sur l'augmentation de schéma et la liaison d'entités sont réelles et significatives — ces tâches exigent véritablement de comprendre la structure du tableau d'une manière avec laquelle une invite GPT-4 zero-shot a du mal. Mais elles sont également plus proches de la recherche d'information que du raisonnement, ce qui limite la généralisation de ces résultats.

Une autre préoccupation : le jeu de données TableInstruct de 2,6 millions d'exemples représente un effort d'ingénierie important, mais il regroupe des types de tâches très différents dans un format d'instruction unique. Il n'y a pas d'ablation montrant quels types de tâches interfèrent entre eux ou lesquels sont déterminants pour les gains hors domaine. Le propre benchmark de suivi du groupe de l'OSU (TableBench, AAAI 2025) a révélé que les modèles affinés sur TableInstruct atteignent des performances comparables à GPT-3.5 mais restent en deçà de GPT-4 — ce qui tempère considérablement l'optimisme de l'article original.

Pourquoi cela est important pour l'IA financière

Les journaux Beancount sont des tableaux structurés : chaque entrée possède une date, un compte, un montant et des métadonnées optionnelles. Les tâches de tableaux de cet article correspondent directement aux opérations qu'un agent Beancount doit effectuer. L'annotation de type de colonne correspond à la compréhension de quels comptes appartiennent à quel type (Actif, Passif, Dépenses). La liaison d'entités correspond à la résolution des noms de bénéficiaires à travers des descriptions de transactions incohérentes. Et l'écart WikiSQL correspond précisément au problème de l'interface en langage naturel pour beanquery.

Les résultats ici me donnent une vision calibrée : un modèle affiné de 7B peut gérer la reconnaissance de la structure du journal de manière assez fiable pour être utile, mais on ne peut pas encore lui faire confiance pour traduire des questions libres en expressions beanquery correctes sans un modèle plus performant dans la boucle. La précision de 50 % sur WikiSQL (contre 93 % pour le SOTA) signifie qu'une interface beanquery basée uniquement sur un modèle ouvert générerait des requêtes erronées environ la moitié du temps sur des formulations de questions peu familières. Pour un agent d'écriture, ce taux d'échec est trop élevé. Pour une interface de requête en lecture seule avec révision humaine, cela pourrait être acceptable comme premier brouillon.

La contribution de LongLoRA est directement applicable : les journaux Beancount s'étendant sur plusieurs années peuvent facilement dépasser les 8 000 jetons, et l'approche présentée ici montre comment affiner pour de longs tableaux sans puissance de calcul prohibitive.

Lectures complémentaires

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) — le suivi du groupe de l'OSU qui évalue plus de 30 LLM sur des QA de tableaux plus complexes et constate que l'écart entre les modèles ouverts et GPT-4 persiste même après l'affinage TableInstruct.
• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — pré-entraînement sur l'exécution SQL synthétique par opposition au réglage par instructions ; une base de référence importante pour le débat pré-entraînement contre affinage dans la compréhension de tableaux.
• Rethinking Table Instruction Tuning (arXiv:2501.14693) — travaux récents remettant en question la généralisation de la recette standard de TableInstruct et examinant quels choix de composition de données importent le plus.