TAPAS : Table QA supervisé de manière faible sans SQL, et ce que cela signifie pour Beancount

J'ai passé du temps sur la lignée text-to-SQL — BIRD, DIN-SQL, MAC-SQL — mais tous partagent une hypothèse que je souhaite remettre en question : l'idée que la bonne interface pour le Table QA est la génération de SQL. TAPAS, publié par Herzig et al. chez Google Research (ACL 2020), fait le pari inverse. Il ne génère jamais de requête. À la place, il sélectionne simplement des cellules et applique éventuellement une agrégation scalaire, entraînée de bout en bout à partir des seules dénotations de réponse.

L'article

TAPAS étend BERT pour encoder des tableaux en ajoutant six nouvelles dimensions d'intégration (embeddings) en plus des ID de position et de segment standard. L'ID de colonne et l'ID de ligne marquent l'emplacement de chaque jeton dans la grille du tableau. Un ID de rang encode l'ordre numérique relatif au sein des colonnes triables (le rang 0 signifie non comparable, le rang i+1 pour la i-ème plus petite valeur). Un indicateur de Réponse Précédente signale les cellules qui ont été sélectionnées lors du tour conversationnel précédent. Combiné à l'intégration de segment binaire qui distingue les jetons de question des jetons de tableau, cela donne à TAPAS sa représentation de jetons à sept types.

Au moment de l'inférence, le modèle sélectionne un ensemble de cellules en appliquant un seuil aux probabilités par cellule, puis applique l'un des quatre opérateurs d'agrégation — AUCUN, COMPTER, SOMME ou MOYENNE — pour produire la réponse finale. Il n'y a pas de SQL intermédiaire ou de forme logique. Le pré-entraînement exécute un objectif de modèle de langage masqué standard sur 6,2 millions de paires texte-tableau issues de Wikipédia en anglais.

Idées clés

• Les intégrations de colonnes/lignes sont porteuses. L'ablation montre que leur suppression coûte 19,4 points de précision sur SQA, 10,6 sur WikiSQL et 11,6 sur WikiTQ — bien plus que tout autre composant architectural.
• Le pré-entraînement sur les tableaux importe presque autant. Sa suppression fait chuter le SQA de 12,5 points et WikiTQ de 11,1 points, même après un ajustement fin (fine-tuning).
• Sur SQA (Table QA conversationnel), TAPAS fait passer la précision de 55,1 % à 67,2 %, un bond de 12 points. L'intégration du jeton de Réponse Précédente est le mécanisme qui permet le report conversationnel sans suivi d'état séparé.
• Sur WikiSQL (tableau unique, principalement recherche et agrégation), TAPAS atteint 83,6 % — égalant pratiquement l'analyseur sémantique SOTA à 83,9 %, avec zéro génération de SQL.
• L'apprentissage par transfert de WikiSQL vers WikiTQ (raisonnement multi-étapes, multi-colonnes) donne 48,7 %, soit 4,2 points au-dessus de l'état de l'art de l'époque. Le transfert SQA donne 48,8 %.
• La supervision faible est l'argument principal d'accessibilité : le modèle est entraîné sur des paires (question, réponse), et non sur des triplets (question, SQL, réponse), ce qui permet d'annoter de grands corpus sans expertise SQL.

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

L'idée centrale — selon laquelle de nombreuses questions de Table QA peuvent être résolues en sélectionnant des cellules et en appliquant l'une des quatre opérations scalaires — est empiriquement solide pour les benchmarks testés. Mais l'analyse honnête des erreurs de l'article sur WikiTQ est révélatrice : 37 % des erreurs ne sont pas classées par les auteurs eux-mêmes, 16 % nécessitent des manipulations de chaînes de caractères que le modèle ne peut pas faire, et 10 % impliquent un raisonnement temporel complexe. Cela signifie que le plafond de TAPAS n'est pas dû à des opérateurs d'agrégation incorrects ; il s'agit de catégories entières de questions qui sont structurellement hors de portée.

La contrainte de 512 jetons est un mur infranchissable. Les tableaux de plus de 500 cellules environ doivent être tronqués, et le modèle n'a aucun mécanisme pour le raisonnement multi-tableaux. Ce n'est pas un problème de réglage, c'est un problème architectural. Le modèle ne peut pas non plus imbriquer les agrégations : une question comme « combien de comptes ont un solde moyen supérieur à zéro ? » nécessite deux passes (une moyenne à l'intérieur d'un prédicat COMPTER), ce que la tête à quatre opérateurs ne peut pas exprimer.

TAPEX (ICLR 2022) s'attaque directement au goulot d'étranglement du pré-entraînement en remplaçant le MLM de tableau Wikipédia par une exécution SQL synthétique sur des programmes auto-générés, poussant WikiTQ à 57,5 % (+4,8) et SQA à 74,5 % (+3,5). C'est un écart significatif. Mais TAPEX hérite des mêmes limites architecturales sur la taille des tableaux et la profondeur compositionnelle.

La question plus profonde et non résolue qu'aucun des deux articles n'aborde est de savoir si le paradigme de sélection de cellules est mieux adapté au Table QA du monde réel que la génération SQL pour des raisons pratiques — non pas la précision des benchmarks, mais les garanties d'auditabilité et de correction. La sélection de cellules est opaque : on obtient une réponse mais pas de programme. La génération SQL est verbeuse mais vérifiable. Pour une utilisation en production, ce compromis importe plus que quelques points de précision.

Pourquoi cela compte pour l'IA financière

Un registre Beancount est effectivement un tableau plat et structuré : les comptes en lignes, les montants, les dates, les devises et les balises (tags) en colonnes. Le paradigme de sélection directe de cellules de TAPAS correspond naturellement aux requêtes de registre les plus courantes — « quel est le montant total dépensé en épicerie en mars ? » — qui sont exactement des agrégations SOMME et COMPTER sur des lignes filtrées. L'intégration de la Réponse Précédente est directement utile pour les sessions conversationnelles où un utilisateur affine une requête (« et qu'en est-il de l'année dernière ? »).

Mais les registres Beancount à grande échelle brisent les contraintes de TAPAS. Un registre pluriannuel comprenant des milliers de transactions dépasse le budget de 512 jetons de plusieurs ordres de grandeur. Les hiérarchies de comptes nécessitent un raisonnement sur des groupes de lignes. Des requêtes telles que « quels comptes ont un flux sortant net supérieur à leur moyenne sur les trois dernières années ? » nécessitent des agrégations imbriquées que la tête à quatre opérateurs ne peut pas exprimer. Et point critique : pour la sécurité de l'écriture (write-back), la sélection de cellules ne fournit aucun programme auditable à vérifier avant de valider une modification. Le SQL fournit au moins un artefact inspectable.

Ma conclusion provisoire est que le paradigme de sélection de cellules est la bonne interface pour une couche de requête en lecture seule en langage naturel sur de petits instantanés de registre — les transactions d'un mois, l'historique d'un seul compte. Pour le raisonnement sur l'ensemble du registre et tout ce qui implique l'écriture, une approche de synthèse de programme (qu'elle soit de style SQL ou en DSL Beancount) reste plus sûre et plus expressive.

Que lire ensuite

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — le successeur direct qui remplace le MLM Wikipédia par l'exécution de SQL synthétique ; répond directement à la question de savoir si le pré-entraînement sur des programmes bat le pré-entraînement sur du texte pour le Table QA.
• Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — utilise GPT-3 pour générer des programmes en SQL ou Python sur des tableaux et atteint le SOTA sur WikiTQ ; l'approche hybride avec laquelle les défenseurs de la sélection de cellules doivent composer.
• OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — combine des corpus de tableaux naturels avec des données SQL synthétiques dans une seule recette de pré-entraînement ; teste si TAPAS et TAPEX sont complémentaires plutôt que concurrents.