TAPAS: Slabo dohliadané tabuľkové QA bez SQL a čo to znamená pre Beancount

Venoval som čas línii text-to-SQL — BIRD, DIN-SQL, MAC-SQL — ale všetky tieto prístupy zdieľajú predpoklad, ktorý chcem spochybniť: že správnym rozhraním pre tabuľkové QA je generovanie SQL. TAPAS, publikovaný Herzigom a kol. v Google Research (ACL 2020), vsádza na opačnú kartu. Nikdy negeneruje dopyt. Namiesto toho jednoducho vyberá bunky a voliteľne aplikuje skalárnu agregáciu, pričom je trénovaný end-to-end výhradne z denotácií odpovedí.

Článok

TAPAS rozširuje BERT o kódovanie tabuliek pridaním šiestich nových dimenzií embeddingov k štandardným ID pozície a segmentu. ID stĺpca (Column ID) a ID riadka (Row ID) označujú, kde sa každý token nachádza v tabuľkovej mriežke. Poradové ID (Rank ID) kóduje relatívne číselné poradie v rámci zoraditeľných stĺpcov (poradie 0 znamená neporovnateľné, poradie i+1 pre i-tu najmenšiu hodnotu). Indikátor predchádzajúcej odpovede (Previous Answer) označuje bunky, ktoré boli vybrané v predchádzajúcom konverzačnom kole. V kombinácii s binárnym embeddingom segmentu, ktorý rozlišuje tokeny otázky od tokenov tabuľky, to dáva modelu TAPAS jeho sedemtypovú reprezentáciu tokenov.

V čase inferencie model vyberie množinu buniek nastavením prahu pravdepodobnosti pre každú bunku a potom aplikuje jeden zo štyroch agregačných operátorov — NONE (žiadny), COUNT (počet), SUM (súčet) alebo AVERAGE (priemer) — na vytvorenie konečnej odpovede. Neexistuje žiadne medziľahlé SQL ani logická forma. Predtrénovanie prebieha pomocou štandardného cieľa maskovaného jazykového modelu (MLM) na 6,2 miliónoch párov tabuľka – text z anglickej Wikipédie.

Kľúčové myšlienky

• Embeddingy stĺpcov a riadkov sú nosné. Ablácia ukazuje, že ich odstránenie stojí 19,4 bodu presnosti na SQA, 10,6 na WikiSQL a 11,6 na WikiTQ — čo je oveľa viac ako u akéhokoľvek iného architektonického komponentu.
• Predtrénovanie na tabuľkách je takmer rovnako dôležité. Jeho odstránenie znižuje SQA o 12,5 bodu a WikiTQ o 11,1 bodu, a to aj po doladení (fine-tuning).
• Na SQA (konverzačné tabuľkové QA) TAPAS zvyšuje presnosť z 55,1 % na 67,2 %, čo je 12-bodový skok. Embedding tokenu Previous Answer je mechanizmus, vďaka ktorému konverzačná kontinuita funguje bez samostatného sledovača stavu.
• Na WikiSQL (jedna tabuľka, väčšinou vyhľadávanie a agregácia) TAPAS dosahuje 83,6 % — čím v podstate vyrovnáva špičkový sémantický parser (83,9 % SOTA) pri nulovom generovaní SQL.
• Prenosové učenie z WikiSQL na WikiTQ (viackrokové uvažovanie nad viacerými stĺpcami) prináša 48,7 %, čo bolo o 4,2 bodu viac ako vtedajší stav techniky. Prenos z SQA prináša 48,8 %.
• Slabý dohľad (weak supervision) je hlavným argumentom pre dostupnosť: model je trénovaný na pároch (otázka, odpoveď), nie na trojiciach (otázka, SQL, odpoveď), takže môžete anotovať veľké korpusy bez znalosti SQL.

Čo pretrváva – a čo nie

Základný poznatok — že mnohé tabuľkové QA otázky možno zodpovedať výberom buniek a aplikovaním jednej zo štyroch skalárnych operácií — je pre testované benchmarky empiricky podložený. Ale úprimná analýza chýb v článku o WikiTQ je výpovedná: 37 % chýb nie je klasifikovaných ani samotnými autormi, 16 % vyžaduje manipuláciu s reťazcami, ktorú model nedokáže, a 10 % zahŕňa komplexné časové uvažovanie. To znamená, že strop TAPAS nie je v tom, že by agregačné operátory boli nesprávne; ide o celé kategórie otázok, ktoré sú štrukturálne mimo jeho dosahu.

Obmedzenie na 512 tokenov je tvrdá stena. Tabuľky s viac ako približne 500 bunkami musia byť orezané a model nemá žiadny mechanizmus na uvažovanie nad viacerými tabuľkami. Toto nie je problém ladenia — je to architektonický problém. Model tiež nedokáže vnárať agregácie: otázka typu „koľko účtov má priemerný zostatok vyšší ako nula?“ vyžaduje dva prechody (priemer vo vnútri predikátu COUNT), čo hlava so štyrmi operátormi nedokáže vyjadriť.

TAPEX (ICLR 2022) priamo rieši úzke hrdlo predtrénovania nahradením MLM na tabuľkách z Wikipédie syntetickým vykonávaním SQL na automaticky generovaných programoch, čím posúva WikiTQ na 57,5 % (+4,8) a SQA na 74,5 % (+3,5). To je významný rozdiel. TAPEX však dedí rovnaké architektonické obmedzenia veľkosti tabuľky a hĺbky kompozície.

Hlbšou nevyriešenou otázkou, ktorú nerieši ani jeden z článkov, je, či je paradigma výberu buniek z praktických dôvodov lepšia pre reálne tabuľkové QA než generovanie SQL — nie z hľadiska presnosti v benchmarkoch, ale z hľadiska auditovateľnosti a záruk správnosti. Výber buniek je nepriehľadný: dostanete odpoveď, ale žiadny program. Generovanie SQL je rozvláčne, ale overiteľné. Pre produkčné použitie je tento kompromis dôležitejší než pár bodov presnosti.

Prečo je to dôležité pre finančnú AI

Beancount účtovná kniha je v podstate plochá, štruktúrovaná tabuľka: účty v riadkoch, sumy, dátumy, meny a značky v stĺpcoch. Paradigma priameho výberu buniek modelu TAPAS sa prirodzene mapuje na najbežnejšie dopyty v účtovnej knihe — „aká je celková suma vynaložená na potraviny v marci?“ — čo sú presne agregácie SUM a COUNT nad filtrovanými riadkami. Embedding Previous Answer je priamo užitočný pre konverzačné relácie, kde používateľ upresňuje dopyt („a čo minulý rok?“).

Beancount účtovné knihy vo väčšom rozsahu však narážajú na obmedzenia TAPAS. Viacročná účtovná kniha s tisíckami transakcií prekračuje limit 512 tokenov o niekoľko rádov. Hierarchie účtov si vyžadujú uvažovanie naprieč skupinami riadkov. Dopyty ako „ktoré účty majú čistý odliv väčší ako ich priemer za posledné tri roky?“ potrebujú vnorené agregácie, ktoré hlava so štyrmi operátormi nedokáže vyjadriť. A čo je kritické: pre bezpečnosť spätného zápisu neposkytuje výber buniek žiadny auditovateľný program, ktorý by sa dal skontrolovať pred potvrdením zmeny. SQL aspoň poskytuje kontrolovateľný artefakt.

Môj predbežný záver je, že paradigma výberu buniek je správnym rozhraním pre vrstvu dopytov v prirodzenom jazyku len na čítanie nad malými snímkami účtovnej knihy — transakcie za mesiac, história jedného účtu. Pre uvažovanie nad celou účtovnou knihou a čokoľvek, čo zahŕňa spätný zápis, zostáva prístup syntézy programu (či už v štýle SQL alebo Beancount DSL) bezpečnejší a expresívnejší.

Čo si prečítať ďalej

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — priamy nástupca, ktorý nahrádza MLM z Wikipédie syntetickým vykonávaním SQL; priamo odpovedá na to, či predtrénovanie na programoch prekonáva predtrénovanie na texte pre tabuľkové QA.
• Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — využíva GPT-3 na generovanie programov v SQL alebo Pythone nad tabuľkami a dosahuje SOTA na WikiTQ; hybridný prístup, s ktorým sa zástancovia výberu buniek musia vyrovnať.
• OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — kombinuje prirodzené tabuľkové korpusy so syntetickými SQL dátami v jednom recepte na predtrénovanie; testuje, či sú TAPAS a TAPEX skôr komplementárne než konkurenčné technológie.