TAPAS: Zwak gesuperviseerde tabel-QA zonder SQL, en wat dit betekent voor Beancount

Ik heb veel tijd besteed aan de text-to-SQL-lijn — BIRD, DIN-SQL, MAC-SQL — maar die gaan allemaal uit van een aanname die ik in twijfel wil trekken: dat de juiste interface voor tabel-QA het genereren van SQL is. TAPAS, gepubliceerd door Herzig et al. bij Google Research (ACL 2020), kiest voor de tegenovergestelde aanpak. Het genereert nooit een query. In plaats daarvan selecteert het cellen en past het optioneel een scalaire aggregatie toe, getraind end-to-end op basis van enkel de antwoord-denotaties.

Het artikel

TAPAS breidt BERT uit om tabellen te coderen door zes nieuwe embedding-dimensies toe te voegen bovenop de standaard positie- en segment-ID's. Kolom-ID en Rij-ID markeren waar elk token zich in het tabelraster bevindt. Een Rank-ID codeert de relatieve numerieke volgorde binnen sorteerbare kolommen (rank 0 betekent niet vergelijkbaar, rank i+1 voor de i-de kleinste waarde). Een indicator voor Vorige Antwoord (Previous Answer) markeert cellen die in de vorige gespreksronde werden geselecteerd. Gecombineerd met de binaire segment-embedding die vraagtokens onderscheidt van tabeltokens, geeft dat TAPAS zijn tokenrepresentatie van zeven types.

Tijdens inferentie selecteert het model een set cellen door drempelwaarden toe te passen op de waarschijnlijkheden per cel, en past vervolgens een van de vier aggregatie-operators toe — NONE, COUNT, SUM of AVERAGE — om het uiteindelijke antwoord te produceren. Er is geen tussenliggende SQL of logische vorm. De pre-training voert een standaard gemaskeerd taalmodel-doel (masked language model) uit op 6,2 miljoen tabel-tekstparen van de Engelstalige Wikipedia.

Belangrijkste ideeën

• De kolom/rij-embeddings zijn dragend voor de structuur. Ablatie toont aan dat het verwijderen ervan 19,4 nauwkeurigheidspunten kost op SQA, 10,6 op WikiSQL en 11,6 op WikiTQ — veel groter dan enig ander architectonisch onderdeel.
• Tabel-pre-training is bijna even belangrijk. Het verwijderen ervan verlaagt SQA met 12,5 punten en WikiTQ met 11,1 punten, zelfs na fine-tuning.
• Op SQA (conversationele tabel-QA) verhoogt TAPAS de nauwkeurigheid van 55,1% naar 67,2%, een sprong van 12 punten. De Previous Answer token-embedding is het mechanisme dat de overdracht in gesprekken laat werken zonder een aparte state tracker.
• Op WikiSQL (enkele tabel, meestal opzoeken en aggregeren) bereikt TAPAS 83,6% — wat in feite overeenkomt met de 83,9% van de state-of-the-art semantische parser, met nul SQL-generatie.
• Transfer learning van WikiSQL naar WikiTQ (meerstaps-redenering over meerdere kolommen) levert 48,7% op, 4,2 punten boven de toenmalige state-of-the-art. SQA-transfer geeft 48,8%.
• Zwakke supervisie is de belangrijkste claim op het gebied van betaalbaarheid: het model wordt getraind op (vraag, antwoord)-paren, niet op (vraag, SQL, antwoord)-triplets, zodat je grote corpora kunt annoteren zonder SQL-expertise.

Wat standhoudt — en wat niet

Het kerninzicht — dat veel tabel-QA-vragen beantwoord kunnen worden door cellen te selecteren en een van de vier scalaire bewerkingen toe te passen — is empirisch solide voor de geteste benchmarks. Maar de eerlijke foutanalyse van het artikel op WikiTQ is veelzeggend: 37% van de fouten wordt door de auteurs zelf niet geclassificeerd, 16% vereist tekstmanipulatie die het model niet kan uitvoeren, en 10% betreft complexe temporele redeneringen. Dat betekent dat het plafond van TAPAS niet ligt bij de aggregatie-operators die fout zouden zijn; het gaat erom dat hele categorieën vragen structureel buiten het bereik vallen.

De beperking van 512 tokens is een harde grens. Tabellen met meer dan ongeveer 500 cellen moeten worden ingekort, en het model heeft geen mechanisme voor redeneren over meerdere tabellen. Dit is geen optimalisatieprobleem — het is een architectonisch probleem. Het model kan ook geen aggregaties nesten: een vraag als "hoeveel accounts hebben een gemiddeld saldo groter dan nul?" vereist twee stappen (gemiddelde binnen een COUNT-predicaat), wat de head met vier operators niet kan uitdrukken.

TAPEX (ICLR 2022) pakt de bottleneck van pre-training rechtstreeks aan door Wikipedia tabel-MLM te vervangen door synthetische SQL-executie op automatisch gegenereerde programma's, wat WikiTQ naar 57,5% (+4,8) en SQA naar 74,5% (+3,5) brengt. Dat is een aanzienlijk verschil. Maar TAPEX erft dezelfde architecturale beperkingen wat betreft tabelgrootte en compositiediepte.

De diepere, onopgeloste vraag die geen van beide artikelen beantwoordt, is of het cel-selectieparadigma op praktische gronden beter past bij tabel-QA in de echte wereld dan SQL-generatie — niet op basis van benchmarknauwkeurigheid, maar op basis van controleerbaarheid en garanties voor correctheid. Het selecteren van cellen is opaak: je krijgt een antwoord maar geen programma. SQL-generatie is omslachtig maar verifieerbaar. Voor productiegebruik weegt die afweging zwaarder dan een paar punten nauwkeurigheid.

Waarom dit belangrijk is voor financiële AI

Een Beancount-ledger is in feite een platte, gestructureerde tabel: rekeningen in rijen, bedragen, datums, valuta's en tags in kolommen. Het directe cel-selectieparadigma van TAPAS sluit natuurlijk aan bij de meest voorkomende ledgerqueries — "wat is het totaal uitgegeven aan boodschappen in maart?" — wat precies SUM- en COUNT-aggregaties zijn over gefilterde rijen. De Previous Answer-embedding is direct nuttig voor conversationele sessies waarbij een gebruiker een query verfijnt ("en hoe zit het met vorig jaar?").

Maar Beancount-ledgers op schaal overschrijden de beperkingen van TAPAS. Een meerjarenoverzicht met duizenden transacties overschrijdt het budget van 512 tokens met vele malen. Rekeninghiërarchieën vereisen redenering over groepen rijen. Queries zoals "welke rekeningen hebben een netto-uitstroom die groter is dan hun gemiddelde over de afgelopen drie jaar?" hebben geneste aggregaties nodig die de head met vier operators niet kan uitdrukken. En cruciaal: voor de veiligheid bij het terugschrijven biedt cel-selectie geen controleerbaar programma om te controleren voordat een wijziging wordt doorgevoerd. SQL biedt tenminste een inspecteerbaar artefact.

Mijn voorlopige conclusie is dat het cel-selectieparadigma de juiste interface is voor een natuurlijke taal, read-only querylaag over kleine ledger-snapshots — de transacties van een maand, de geschiedenis van een enkele rekening. Voor redeneren over de volledige ledger en alles wat met schrijven te maken heeft, blijft een programma-synthesebenadering (of het nu in SQL-stijl of de Beancount-DSL is) veiliger en expressiever.

Wat nu te lezen

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — de directe opvolger die Wikipedia MLM vervangt door synthetische SQL-executie; geeft direct antwoord op de vraag of pre-training op programma's beter werkt dan pre-training op tekst voor tabel-QA.
• Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — gebruikt GPT-3 om programma's in SQL of Python over tabellen te genereren en behaalt SOTA op WikiTQ; de hybride aanpak waar voorstanders van cel-selectie rekening mee moeten houden.
• OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — combineert natuurlijke tabelcorpora met synthetische SQL-gegevens in een enkel pre-trainingrecept; test of TAPAS en TAPEX complementair zijn in plaats van concurrerend.