TAPAS: Schwach überwachtes Table-QA ohne SQL und was es für Beancount bedeutet

Ich habe mich in letzter Zeit mit der Text-zu-SQL-Entwicklungslinie beschäftigt – BIRD, DIN-SQL, MAC-SQL – aber alle basieren auf einer Annahme, die ich hinterfragen möchte: dass das richtige Interface für Table-QA die Generierung von SQL ist. TAPAS, veröffentlicht von Herzig et al. bei Google Research (ACL 2020), setzt auf das Gegenteil. Es generiert niemals eine Abfrage. Stattdessen wählt es einfach Zellen aus und wendet optional eine skalare Aggregation an, die End-to-End ausschließlich aus Antwort-Denotationen trainiert wurde.

Die Arbeit

TAPAS erweitert BERT zur Kodierung von Tabellen, indem es sechs neue Embedding-Dimensionen zusätzlich zu den standardmäßigen Positions- und Segment-IDs hinzufügt. Spalten-ID und Zeilen-ID markieren, wo sich jeder Token im Tabellengitter befindet. Eine Rang-ID kodiert die relative numerische Reihenfolge innerhalb sortierbarer Spalten (Rang 0 bedeutet nicht vergleichbar, Rang i+1 für den i-t kleinsten Wert). Ein Vorherige-Antwort-Indikator markiert Zellen, die in der vorangegangenen Konversationsrunde ausgewählt wurden. Zusammen mit dem binären Segment-Embedding, das Frage-Token von Tabellen-Token unterscheidet, ergibt dies die siebenfache Token-Repräsentation von TAPAS.

Zur Inferenzzeit wählt das Modell eine Menge von Zellen aus, indem es Schwellenwerte für die Wahrscheinlichkeiten pro Zelle festlegt, und wendet dann einen von vier Aggregationsoperatoren an – NONE, COUNT, SUM oder AVERAGE –, um die endgültige Antwort zu generieren. Es gibt kein SQL oder eine logische Zwischenform. Das Pre-training führt ein standardmäßiges Masked-Language-Model-Objective über 6,2 Millionen Englisch-Wikipedia-Tabelle-Text-Paaren aus.

Kernideen

• Die Spalten/Zeilen-Embeddings sind tragend. Ablationsstudien zeigen, dass ihr Entfernen 19,4 Genauigkeitspunkte bei SQA, 10,6 bei WikiSQL und 11,6 bei WikiTQ kostet – weitaus mehr als jede andere Architekturkomponente.
• Tabellen-Pre-training ist fast ebenso wichtig. Ohne dieses sinkt SQA um 12,5 Punkte und WikiTQ um 11,1 Punkte, selbst nach dem Fine-Tuning.
• Bei SQA (konversationsbasiertes Table-QA) steigert TAPAS die Genauigkeit von 55,1 % auf 67,2 %, ein Sprung von 12 Punkten. Das Vorherige-Antwort-Token-Embedding ist der Mechanismus, der den Gesprächskontext ohne separaten State-Tracker ermöglicht.
• Bei WikiSQL (Einzeltabelle, meist Suche und Aggregation) erreicht TAPAS 83,6 % – was im Wesentlichen dem semantischen Parser mit dem SOTA-Wert von 83,9 % entspricht, und das völlig ohne SQL-Generierung.
• Transfer-Learning von WikiSQL auf WikiTQ (mehrstufige Argumentation über mehrere Spalten) ergibt 48,7 %, 4,2 Punkte über dem damaligen Stand der Technik. SQA-Transfer ergibt 48,8 %.
• Schwach überwachtes Lernen ist das zentrale Argument für die Wirtschaftlichkeit: Das Modell wird auf (Frage, Antwort)-Paaren trainiert, nicht auf (Frage, SQL, Antwort)-Tripeln, sodass man große Korpora ohne SQL-Fachwissen annotieren kann.

Was Bestand hat – und was nicht

Die zentrale Erkenntnis – dass viele Table-QA-Fragen durch die Auswahl von Zellen und die Anwendung einer von vier skalaren Operationen beantwortet werden können – ist für die getesteten Benchmarks empirisch fundiert. Aber die ehrliche Fehleranalyse der Autoren zu WikiTQ ist aufschlussreich: 37 % der Fehler werden von den Autoren selbst als nicht klassifizierbar eingestuft, 16 % erfordern String-Manipulationen, die das Modell nicht beherrscht, und 10 % betreffen komplexe zeitliche Argumentation. Das bedeutet, dass die Obergrenze von TAPAS nicht an falschen Aggregationsoperatoren liegt; es liegt daran, dass ganze Kategorien von Fragen strukturell außerhalb des Rahmens liegen.

Die 512-Token-Beschränkung ist eine harte Wand. Tabellen mit mehr als etwa 500 Zellen müssen gekürzt werden, und das Modell verfügt über keinen Mechanismus für Argumentationen über mehrere Tabellen hinweg. Dies ist kein Optimierungsproblem – es ist ein architektonisches. Das Modell kann Aggregationen auch nicht verschachteln: Eine Frage wie „Wie viele Konten haben einen durchschnittlichen Saldo von mehr als Null?“ erfordert zwei Durchläufe (Durchschnitt innerhalb eines COUNT-Prädikats), was der Kopf mit den vier Operatoren nicht ausdrücken kann.

TAPEX (ICLR 2022) adressiert den Pre-training-Engpass direkt, indem es das Wikipedia-Tabellen-MLM durch synthetische SQL-Ausführung auf automatisch generierten Programmen ersetzt, wodurch WikiTQ auf 57,5 % (+4,8) und SQA auf 74,5 % (+3,5) steigt. Das ist ein signifikanter Unterschied. Aber TAPEX erbt die gleichen architektonischen Einschränkungen bei Tabellengröße und Kompositionstiefe.

Die tiefergehende ungelöste Frage, die keines der Papiere beantwortet, ist, ob das Zellenauswahl-Paradigma aus praktischen Gründen besser für reales Table-QA geeignet ist als die SQL-Generierung – nicht wegen der Benchmark-Genauigkeit, sondern wegen der Auditierbarkeit und Korrektheitsgarantien. Die Auswahl von Zellen ist undurchsichtig: Man erhält eine Antwort, aber kein Programm. SQL-Generierung ist wortreich, aber überprüfbar. Für den Produktionseinsatz ist dieser Kompromiss wichtiger als ein paar Genauigkeitspunkte.

Warum das für Finanz-KI wichtig ist

Ein Beancount-Ledger ist effektiv eine flache, strukturierte Tabelle: Konten in Zeilen, Beträge, Daten, Währungen und Tags in Spalten. Das direkte Zellenauswahl-Paradigma von TAPAS lässt sich natürlich auf die gängigsten Ledger-Abfragen übertragen – „Wie viel wurde im März insgesamt für Lebensmittel ausgegeben?“ – was genau SUM- und COUNT-Aggregationen über gefilterte Zeilen entspricht. Das Vorherige-Antwort-Embedding ist direkt nützlich für Konversationssitzungen, in denen ein Benutzer eine Abfrage verfeinert („und wie sieht es mit dem letzten Jahr aus?“).

Aber Beancount-Ledger in großem Maßstab sprengen die Grenzen von TAPAS. Ein mehrjähriges Ledger mit Tausenden von Transaktionen überschreitet das 512-Token-Budget um Größenordnungen. Kontenhierarchien erfordern Argumentation über Zeilengruppen hinweg. Abfragen wie „Welche Konten haben einen Nettoabfluss, der größer ist als ihr Durchschnitt der letzten drei Jahre?“ erfordern verschachtelte Aggregationen, die der Kopf mit vier Operatoren nicht ausdrücken kann. Und ganz entscheidend: Für die Sicherheit beim Rückschreiben bietet die Zellenauswahl kein prüfbares Programm, das vor dem Bestätigen einer Änderung kontrolliert werden kann. SQL bietet zumindest ein inspizierbares Artefakt.

Meine vorläufige Schlussfolgerung ist, dass das Zellenauswahl-Paradigma das richtige Interface für eine schreibgeschützte Abfrageschicht in natürlicher Sprache über kleinen Ledger-Snapshots ist – die Transaktionen eines Monats, die Historie eines einzelnen Kontos. Für Argumentationen über das gesamte Ledger und alles, was Rückschreibevorgänge betrifft, bleibt ein Programm-Synthese-Ansatz (ob im SQL-Stil oder als Beancount-DSL) sicherer und ausdrucksstärker.

Was man als Nächstes lesen sollte

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) – der direkte Nachfolger, der Wikipedia-MLM durch synthetische SQL-Ausführung ersetzt; beantwortet direkt, ob das Pre-training auf Programmen das Pre-training auf Text für Table-QA schlägt.
• Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) – verwendet GPT-3 zur Generierung von Programmen in SQL oder Python über Tabellen und erreicht SOTA auf WikiTQ; der hybride Ansatz, mit dem sich Verfechter der Zellenauswahl auseinandersetzen müssen.
• OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) – kombiniert natürliche Tabellenkorpora mit synthetischen SQL-Daten in einem einzigen Pre-training-Rezept; testet, ob TAPAS und TAPEX komplementär statt konkurrierend sind.